ecommerce-cia — Commerce Integrity Auditor｜台灣電商金流與系統完整性稽核 Skill

English 🇬🇧 · 繁體中文 🇹🇼 — every section is written in both, English first, 中文接在後面。

🚀 專為台灣電商情境打造的 AI 稽核助手：掃描藍新 NewebPay、綠界 ECPay、LINE Pay、PAYUNi、TapPay 串接邏輯。抓出「測試全綠卻在線上掉單、庫存鎖死、後台開關沒作用」的跨系統隱形 Bug！

💡 一句話說明它能幹嘛？ (TL;DR)

一般的 Code Review / Linter 只看語法有沒有寫錯，而 ecommerce-cia 盯的是真正的錢與庫存流向。

它能幫你做到：

1. 老手稽核 (Audit Mode)：抓出跨系統連鎖反應（如：ATM 轉帳開關沒寫入結帳邏輯、過期訂單退庫存壓掉已付款訂單、綠界/藍新 Callback 驗簽錯誤）。
2. 新手引導 (Setup Mode)：從零帶你串接台灣金流，手把手檢查 Domain、固定 IP、HTTPS，並發射實機探針 (Live Probe) 驗證金鑰！

A skill for Claude Code and OpenAI Codex that audits a transactional e-commerce system as a viable system in Stafford Beer's sense, and hunts the defect class that only such a view can see: cross-boundary invariant violations, also called integration-level or emergent defects, in the paths money and stock actually take.

這是給 Claude Code 與 OpenAI Codex 使用的 Skill。它將電商系統視為 Stafford Beer 所定義的「可存活系統」（Viable System）來進行稽核，專門抓出只有從這個視野才能發現的 bug：跨邊界不變量違反（cross-boundary invariant violations），亦即整合層級缺陷或湧現缺陷。這類 bug 不會單獨存在於任何一個函式中，而是藏在金流、庫存、訂單資料真正流經的「兩個正確函式之間」。

專為台灣電商情境打造：不管是藍新 NewebPay、綠界 ECPay，還是 ATM 虛擬帳號、超商代碼／條碼、超商取貨付款、統一發票跟消保法七天鑑賞期，通通都有獨立專章處理。

Since v2.0 it also starts a shop from zero: a setup mode that walks a first-time builder through 藍新 NewebPay (the default, verified live on a real sandbox shop) or 綠界 ECPay (verified live on ECPay's stage) — one question at a time with choices, the prerequisite list before any code, the hosting checked before any code, and every payment method proved on by a live probe rather than trusted from a console toggle. It speaks plainly to someone who has never integrated a gateway. 統一金流 PAYUNi and TapPay are covered from their documentation as secondary options. LINE Pay is covered both ways: as a method flag on any of those gateways (vendor-enabled, a dated wait rather than a toggle) and as a direct Online API v3/v4 integration with its own guide, HMAC signer and a probe checked live against LINE Pay's sandbox host.

自 v2.0 起，它也能幫你從零開始開一家店：提供「新手引導模式」，一步步帶領第一次建站的人串接藍新 NewebPay（預設選擇，已在真實測試商店實機驗證）或綠界 ECPay（已在綠界測試環境實機驗證）— 每次只問一個帶有選項的問題、寫 Code 前先確認準備清單、寫 Code 前先檢查主機環境，且每一種付款方式都透過實機探針（Live probe）驗證成功，而不是傻傻相信後台的開關。即使你從來沒串過金流，也能聽得懂白話說明。統一金流 PAYUNi 與 TapPay 則依官方文件納入，作為次要選項。LINE Pay 支援兩種整合方式：一種是作為上述金流閘道的付款方式旗標（需由金流商開通，是一段有日期的等待而非隨切隨用的開關），另一種則是直連 Online API v3/v4 整合，包含專屬指南、HMAC 簽章器，以及已對 LINE Pay 測試環境（sandbox）主機實測過的探針（probe）。

How this is different from a code review｜這跟一般的 Code Review 到底有什麼不一樣？

Ordinary code review, linters and AI "review my code" tools find coding errors: a typo, a null that was not checked, a function that returns the wrong type, a style violation, a bug inside one function. They read the code and ask is this line written correctly?

This skill checks whether the logic actually works as a whole, in the path money takes. It asks when a customer pays, does the system do what you think it does? It follows the payment deadline from where it is set to every place it is later read. It follows the "ATM transfer on/off" switch from the admin screen to the checkout line that is supposed to obey it. It reads the gateway's own spec, not the code's belief about it. It checks whether "tests passed" means the database and gateway tests actually ran.

Both are needed. Run the linter for the lines. Run this for the money.

平常我們用的 Code Review、Linter，或是各種主打「幫你看 Code」的 AI 工具，基本上都是在找寫錯的細節：像打錯字、沒做 Null 檢查、回傳型別不對、Style 不符合，或是某個 Function 裡面的邏輯漏洞。它們掃一遍 Code，關心的只是「這一行程式碼到底有沒有寫對？」

但這個 Skill 盯的是整套商業邏輯在金流鏈結上到底有沒有真正落實。 它在乎的是「當客人按下付款時，系統背後跑的流程是不是真的跟你想的一模一樣？」它會一路追蹤付款時效：從設定檔的來源，一直追到後面每一個讀取它的地方。它會去追「ATM 轉帳開關」：從 Admin 後台一路追到前端結帳邏輯有沒有真的吃這個設定。它會直接翻金流商提供的 Spec 規格書，完全不輕信工程師自己對 Spec 的幻想。它甚至會仔細核對「Test Passed」背後，是不是真的有去跑 DB 跟金流相關的測試。

兩者缺一不可。Linter 幫你把關每一行 Code 的品質，而這個 Skill 幫你守住系統裡的每一分錢。

In plain words｜講白話（給非技術背景的人聽）

Think of your shop's software as a small company. There is a cashier (takes the order and the money), a warehouse (holds stock), a manager's settings panel (which payment methods are on, what shipping costs), an accountant (checks the books), someone who reads the bank's rulebook, and the owner who sets policy.

Most code-checking tools ask: does each employee do their own job correctly? This skill asks a different question: do they actually talk to each other, and at the right time? Three real-shaped examples:

1. The manager switches off "ATM transfer" in the back office. The cashier keeps offering it. Nobody wired the switch to the cashier. Every piece of code is "correct" on its own. Customers pay by ATM, the order is never confirmed. This skill calls it a dead control and checks every switch in your admin against the code that is supposed to obey it.
2. The warehouse holds an item for 30 minutes. Meanwhile the manager turns on a payment method that takes 3 days. The customer picks it, the hold expires, the customer pays on day two, the item is gone. Each step was fine; the timing between them was not. Stale snapshot.
3. The accountant says "books balanced!" but only checked the pages that were open. The bank's pages were skipped because the bank was closed that day. The report is green and means nothing. Vacuous pass. This skill treats every skipped test as "not verified", never as "passed".

What it does, in order: draws the org chart of your shop's code first (who is cashier, who is warehouse, who is manager, who is accountant), then checks every conversation between them, then tells you exactly which conversation is broken, in which file, on which line, and how to fix it.

你可以把你的電商系統想像成一家小型實體店面：裡面有收銀員（負責接單跟收錢）、倉管（負責扣庫存）、店長後台（設定要開哪些付款方式、運費算多少）、會計（負責對帳）、一個專門研讀銀行規則的法規人員，最後是負責拍板定案的老闆。

絕大多數程式碼檢查工具，問的都是：每個員工有沒有把各自手上的工作做好？ 但這個 Skill 關心的是另一件事：他們彼此之間到底有沒有搭上線？而且有沒有在正確的時間點對齊資訊？ 舉三個實務上超常發生的慘劇：

1. 店長明明在後台把「ATM 轉帳」關掉了，收銀員結帳時卻還在繼續收。 原因出在根本沒人把後台的開關設定串到收銀員的流程裡。雖然兩邊的 Code 單獨看都「寫得很好沒 Bug」，但最後客人用 ATM 轉帳付了錢，系統卻再也無法確認訂單。這種狀況我們叫它死開關，這個 Skill 會把後台每一個設定硬生生拿去跟「應該執行它的 Code」對質。
2. 倉庫預設幫客人保留商品 30 分鐘，但同一時間店長開啟了一種需要 3 天才會入帳的付款管道。 當客人選了這個付款方式，30 分鐘保留期一到，商品就被系統釋出；等客人隔天順利付完款，才發現東西早就賣光了。每一道步驟各自看都沒有錯，錯在步驟之間的「時間差沒對齊」。這就叫過期快照。
3. 會計跑過來說「帳全部對上了！」，結果其實只查了幾張容易翻到的帳單。 遇到放假沒開門的銀行帳目就直接跳過不查。測試報告看起來一片綠燈，實際上根本毫無參考價值。這就是典型的空洞通過。這個 Skill 會把任何被 Bypass 掉的測試直接歸類為「未驗證」，絕對不放水給過。

它執行的步驟非常乾脆：先幫你的電商程式碼畫出一張組織架構圖（釐清誰是收銀員、倉管、店長跟會計），接著仔細體檢他們之間的每一條溝通管道，最後直接點名哪裡的溝通斷鏈了、發生在哪個檔案、第幾行、該怎麼修正。

Watch it run｜直接看實機演示

Real, unedited output of the companion /cia in demo mode on the shop this skill was built for: runtime discovery, the codebase mapped onto VSM Systems 1–5 with its channels, then two sweeps and a finding with file:line evidence. /ecommerce-cia runs the same map-then-walk protocol over the money path (payments, stock, orders, entitlements). Replayed as a typed terminal for the recording; the text is the model's.

上面是姊妹 Skill /cia 在它出生地（一家真實運作中的台灣電商專案）跑 Demo 模式的實際 Terminal 輸出，內容完全原汁原味：它會先自動探索專案結構，將程式碼模組對應到 VSM 的 System 1–5 架構並梳理出溝通通道，隨後發動兩輪深度掃描，最後產出帶有精確 file:line 證據的檢查報告。/ecommerce-cia 沿用同一套「先繪製架構地圖、再順著通道稽核」的作法，專精於剖析金流核心路徑（包含付款、庫存、訂單與數位商品權限）。影片是透過 Terminal 打字錄製重播，文字內容全由 AI 模型即時生成。

The theory｜底層理論

Beer's Viable System Model (Brain of the Firm, 1972; The Heart of Enterprise, 1979) states that anything which stays alive in a changing environment has the same five-part structure, repeated at every level of recursion:

Stafford Beer 所提出的可存活系統模型（Viable System Model, VSM；參見《Brain of the Firm》1972、《The Heart of Enterprise》1979）核心概念在於：任何能夠在動態環境中持續存活的系統，必然具備由五個子系統構成的結構，而且這種結構在每一個遞迴層級上都完美複製：

The systems are joined by channels. Ashby's Law of Requisite Variety says a channel must carry as much variety as the thing it regulates, otherwise the control it claims to exercise is fictional. Beer's diagnosis of a failing organisation is almost never "a department is incompetent"; it is "a channel is missing, saturated, or bypassed".

系統與系統之間完全仰賴通道（Channel）傳遞訊息。Ashby 的必要多樣性定律（Law of Requisite Variety）指出：一條通道能夠承受的變化量，必須等同於它所要控制標的之變化量，否則所謂的「控制」只不過是自我安慰。Beer 在診斷出問題的組織時，結論幾乎從來不是「某個部門能力太差」，而是「某條訊息通道斷了、塞住了，或是被偷跑繞過了」。

A shop fails the same way. It was built after a production shop passed static analysis, linting and a green unit suite while carrying these broken channels in its payment path:

電商系統出包的規律完全一模一樣。這個 Skill 的開發起點，源自一個已經上線運作的電商專案：明明 phpstan 全過、phpcs 全過、Unit Test 一片綠燈，但核心付款路徑上的通道卻早已斷得一塌糊塗：

• System 1 → System 1 across time, no System 2. An expiry worker selected overdue orders, then cancelled by status only. A bank-transfer callback that extended the deadline between the two steps was ignored; stock was returned on a live order.

  System 1 → System 1 進行跨時間操作，中間卻缺少了 System 2 的協調。 負責處理逾期取消的 Cron Job，先用 SELECT 挑出過期的訂單，再單純依據狀態跑 UPDATE 取消。如果在兩步執行的時間差內，ATM 的 Callback 剛好進來並延長了付款期限，這個變更會被 Cron Job 完全無視，結果就是一張還在付款期限內的活訂單，庫存直接被系統硬生生退掉。

• System 3 → System 1 read at two different times. The reservation deadline was frozen at placement from settings, while the payment page re-read the enabled methods on every visit. Enabling a days-long ATM method after placement offered it against a thirty-minute hold.

  System 3 → System 1 的設定值在兩個不同的時間點被重複讀取。 庫存保留時間在客人下單的那一刻就已經凍結寫死，但付款頁面卻每次都重新讀取後台「當前開啟的付款方式」。如果下單後管理員才在後台開啟需要耗時數天的 ATM 轉帳，客人就會看到這個選項，但庫存保留期其實只有當初那 30 分鐘。

• System 4 ↔ vendor, semantic drift. The gateway self-heal parser read the card-only PaymentMethod field. The vendor spec defines a shared PaymentType for every family; non-card rejections were invisible.

  System 4 ↔ 金流商之間產生了語意漂移（Semantic Drift）。 金流模組內建的錯誤自我修復 Parser，拿去解析的欄位居然是信用卡專屬的 PaymentMethod；但金流商規格書明明寫得清清楚楚，所有付款方式共用的通用欄位叫做 PaymentType。這導致所有非信用卡交易的失敗訊息全被系統當成空氣。

• System 3 → System 1 channel absent. Admin per-method toggles existed and nothing in checkout read them. A comment promised a follow-up commit that never landed.

  System 3 → System 1 的控制通道根本不存在。 後台明明做好了各種付款方式的開關介面，但前端結帳流程卻沒有半行程式碼去讀取這個設定。Code 裡面只留了一行「下個 commit 再補」的註解，而那個 commit 永遠沒有出現過。

• System 5 default missing. A configuration read failure defaulted to "offer card anyway".

  System 5 的預設安全機制（Fallback）徹底失聯。 當系統抓不到設定檔時，預設的處置邏輯居然是「不管了，先讓客人刷卡再說」。

A second auditor found all of them by tracing channels, not by reading functions. This skill makes that the default.

當初第二位 Auditor 完全不是靠「逐個 Function 讀 Code」，而是靠「順著溝通通道一路把脈」才把這些隱藏 Bug 抓出來的。這個 Skill，就是把這套稽核手法直接自動化。

The stance this skill takes from Beer｜傳承自 Beer 模型的核心心法

• The purpose of a system is what it does (POSIWID). Not what the docs, the comments or the admin screen say it does. An audit reads behaviour, and treats the written intent as a hypothesis to test against the running system.

  系統真正的目的，看它實際產出的行為就知道（POSIWID）。不要去相信文件、註解或後台畫面寫了什麼。稽核只相信系統的真實行為；寫在紙上的意圖，充其量只是待證實的假設。

• Recursion. Every System 1 unit is itself a viable system with its own 1–5. A payment module, a fulfilment pipeline, an entitlement service each has its own control, its own audit, its own policy; the audit descends one level and asks the same five questions again.

  遞迴結構（Recursion）。 每個 System 1 模組拉近來看，本身都是一個獨立運作的可存活系統，內部同樣具備 1–5 的結構。金流模組、物流出貨、數位權限發放各自擁有獨立的控制、稽核與政策機制；稽核往下剖析一層，就是把同樣這五個問題再問一遍。

• Variety engineering. Complexity is not removed, it is absorbed or amplified. Every guard, validator, idempotency key and state machine is a variety attenuator; every default and fallback is an amplifier of whatever the environment throws in. Ask of each: does it match the variety of what it faces?

  多樣性工程（Variety Engineering）。 系統的複雜度不可能憑空消失，只會被消化吸收或是被無腦放大。每一個 Guard 條件、驗證器、冪等鍵（Idempotency Key）、狀態機，都在幫系統削減不確定性；而每一個隨便寫的預設值和 Fallback，都在把外界傳進來的混亂放大。面對每個機制都要拷問：它真的扛得住外面的變化量嗎？

• Autonomy with cohesion. System 1 must be free to act without asking System 3 on every step (a checkout that blocks on live config on every request is not autonomous), yet System 3 must still be able to command it (a toggle nothing reads is not cohesion). Both failures are channel failures.

  保持自主，但必須維持一致性。 System 1 必須具備獨立作業的能力，不用每動一步都要向 System 3 請示（每次 Request 都得即時敲 API 拿設定的結帳流程絕非良策）；但 System 3 也必須具備絕對的控制力（如果後台改了設定卻沒半行 Code 去讀，那就是失控）。這兩種極端都是通道故障的警訊。

• The auditor is System 3*. This skill is the channel that bypasses the system's own reports. A green suite is System 3's report about itself; the audit exists precisely because that report can be vacuous.

  Auditor 的定位就是 System 3*。 這個 Skill 的存在，就是為了建立一條能夠繞過系統「自我感覺良好報告」的獨立通道。測試全綠只是 System 3 在自我安慰；稽核之所以必要，是因為這份綠燈報告很可能根本是空的。

• Algedonic signals must reach System 5. A pain signal that stops in a log file has not reached policy. Every alert, every catch block, every refund path is traced to the point where identity decides.

  痛覺訊號必須一路傳遞到 System 5。 如果系統出錯的痛覺訊號最後只被默默關在 Log 檔裡，代表它根本沒傳到政策層。每一個 Alert 告警、每一個 Catch 區塊、每一條退款流程，都要一路追查到「到底由誰來做最終決策」。

How the theory becomes procedure｜如何將理論落地為實作流程

1. Map the shop onto Systems 1–5 first (§0.9 step 0) and report the table: every component, its primary system, its channels as producer → consumer.
2. Walk the channels with twenty-two mandatory sweeps (§0.9); each defect class below is a named kind of broken channel, and each sweep enumerates its sites from the map rather than from grep.
3. Grade viability, not just correctness: §2 asks whether each of the five systems exists for money, stock, orders and entitlements, whether System 3* is independent of System 3, whether an algedonic path (amount mismatch, callback auth failure, self-heal) reaches System 5.
4. Report structurally: every finding names its defect class and the VSM channel it sits on.

1. 第一步先把電商模組對應到 System 1–5 架構（詳見 §0.9 第 0 步），並產出一張完整的對照表：標註每個元件、所屬的子系統，以及彼此間的資料通道（producer → consumer）。
2. 順著通道逐一體檢：強制執行二十二項深度掃描（詳見 §0.9）。後面列出的每種缺陷類型，本質上都是某條出了問題的斷鏈通道；每個掃描點都是直接對照架構圖來查，絕對不是拿 grep 隨便搜搜字串而已。
3. 評判標準是「能不能在真實世界存活」，而不只是「語法對不對」：§2 會嚴格抽查金流、庫存、訂單、數位權限這四大區塊各自的五層系統是否齊備、System 3* 稽核機制有沒有獨立於 System 3 之外，以及各類痛覺路徑（如金額不符、Callback 驗簽失敗、自我修復機制）有沒有順暢通到 System 5。
4. 輸出結構化報告：針對抓到的每一個問題，精確標明缺陷類型以及所屬的 VSM 溝通通道。

The defect classes it hunts｜它專門獵捕的缺陷類型：跨邊界不變量違反

These are cross-boundary invariant violations: integration-level, emergent defects where every function is correct and the bug lives between them. Each sweep in section 0.9 names one; every finding states its defect class and its boundary location as producer → consumer:

這些問題全屬於跨邊界不變量違反（Cross-Boundary Invariant Violation）：單看每個 Function 都寫得很完美，但 Bug 偏偏就出在 Function 與 Function 交接的縫隙裡。§0.9 中的每個掃描項都對應一種缺陷；每個發掘出的發現都會明確列出缺陷名稱與發生邊界（producer → consumer）：

Prompt with any of those terms, or "audit the wiring and runtime behaviour, not the code", and the sweeps run first.

只要你的 Prompt 裡出現上面任何一個術語，或是提到「幫我稽核邏輯接線跟實際行為，不要只看程式碼表面」，這個掃描流程就會自動啟動。

Which channel each sweep walks｜每個掃描項目對應的 VSM 通道

Each defect class above is a broken channel between two VSM systems; the sweeps are organised by channel, not by file:

每一個 Bug 本質上都是兩個 VSM 子系統之間斷裂的通道；因此所有掃描都是按照「通道」來劃分，而不是按檔案目錄分類：

A channel on the map with no sweep site named against it is reported as unswept.

只要架構圖上有任何一條通道沒有被掃描點覆蓋到，報告就會直接將其標示為「未掃描」。

What it does｜這個 Skill 能幫你做到什麼

1. Discovers the project's runtime bindings itself (test runner, canonical environment, sandbox credentials file, preview URL, admin route) and announces them.
2. Maps the codebase onto the VSM (§0.9 step 0), then runs twenty-two mandatory sweeps (§0.9) along that map's channels. Each produces its own report line; a missing line means the sweep was not done.
3. Applies commerce doctrine: critical business invariants for payment, inventory, orders, digital goods, discounts and financial integrity; one state machine per concern rather than one order.status; purchase-flow symmetry; free and zero-value order abuse; payment gateway integrity (authenticity, correlation, idempotency, browser vs server channels, async methods); refunds; entitlements; reconciliation.
4. Carries a Taiwan chapter (TW-0 to TW-14): ECPay and NewebPay callback models, asynchronous ATM / CVS / barcode methods, convenience-store logistics and store reselection, pickup with and without payment, TWD handling, electronic uniform invoice, consumer-protection flow.
5. Executes the seven-step pre-launch protocol (§0.6) autonomously: fast lint and scope tests, /cia, commerce audit, full suite in the canonical environment, browser walk of every locale and route, one sandbox checkout per gateway with callback verified, numbered report with explicit deferrals.
6. Never green-lights on partial evidence. Skipped DB or gateway tests are "N unverified", never green. A test written this session must show its real run line.
7. Starts a shop from zero in setup mode (§0.15): five provider guides (NewebPay, ECPay, LINE Pay direct, PAYUNi, TapPay), prerequisites and hosting before code, live probes, a readiness card.
8. Carries the compliance layers: Taiwan TW-0…TW-14; EU, Japan, US and UK adapters at the same depth; a global terms-and-privacy checkup across 13 regimes (GDPR, 個資法, PIPA, APPI, LGPD…).
9. Speaks plainly when the owner is not an engineer (§0.16) and opens every report with five plain lines.
10. Is cold-tested: fresh agents run it against a fixture shop with an answer key; every mode has a logged run with zero false positives (tests/RUNS.md).

1. 自動摸清專案運行環境（包含找出測試指令、正式環境配置、Sandbox 密鑰檔、Preview 網址、Admin 路徑）並在第一時間向你回報。
2. 先畫出 VSM 架構圖（§0.9 第 0 步），再順著通道發動二十二項強制掃描（§0.9）。每一項掃描都會獨立輸出一行進度；只要少一行就視同任務未完成。
3. 貫徹電商硬核教條：嚴格檢查付款、庫存、訂單、數位商品、折扣邏輯與財務一致性的核心不變量；每個業務關心點都必須有獨立狀態機，而不是只靠一個粗暴的 order.status 處理；確保購買與退訂流程完全對稱；防範免費與 0 元訂單被 Abuse；確保金流 Gateway 完整性（防偽、關聯性、冪等性、Browser 與 Server 雙通道驗證、非同步付款機制）；涵蓋退款、權限與財務對帳。
4. 內建台灣在地化專章（TW-0 至 TW-14）：包含綠界 ECPay 與藍新 NewebPay 的 Callback 處理機制、ATM 虛擬帳號／超商代碼／超商條碼等非同步金流、超商物流與重新選擇門市流程、超商取貨付款與純取貨驗證、新台幣無小數點特性處理、電子發票串接，以及消保法七天鑑賞期退貨處置。
5. 全自動執行七步上線前檢查（§0.6）：包含快速跑 Lint 與範疇測試、執行 /cia、電商專屬稽核、正式環境完整測試、針對每個語系與 Route 進行瀏覽器模擬實走、每家金流商各在 Sandbox 跑一筆真實結帳並驗證 Callback，最後產出帶有明確未決事項的編號報告。
6. 堅持「沒證據就絕不放行」。被跳過的 DB 或金流測試會直接被標註為「N 項未驗證」，絕對不給假綠燈。這一輪新寫的測試程式碼，必須附上真實跑過的那一行測試數字。
7. 能在引導模式下幫你從零開始開一家店 (§0.15)：包含五家金流商指南（藍新 NewebPay、綠界 ECPay、LINE Pay 直連、統一金流 PAYUNi、TapPay）、寫 Code 前的前置需求與主機檢查、實機探針，以及準備就緒卡。
8. 內建多國合規轉接層：包含台灣 TW-0…TW-14；同等深度的歐盟、日本、美國、英國轉接器；以及跨 13 種法規體系（GDPR、個資法、PIPA、APPI、LGPD…）的全球條款與隱私檢查。
9. 當老闆不是工程師時能用白話溝通 (§0.16)，且每份報告皆以五行白話開頭。
10. 通過冷啟動測試：由全新的 Agent 對帶有標準答案的測試商店執行；每一種模式都有留下紀錄的執行結果，而且零誤報（tests/RUNS.md）。

Autonomy contract (§0.8)｜自主執行公約

The agent runs every step itself: starts containers, installs from lockfiles, copies documented sandbox credentials into .env, drives the browser, places the sandbox order. Only at rung 5 does it ask the owner, with the exact command already written. Hard limits: never a production gateway, never store card numbers, never elevate, never bypass hooks without a standing rule, never delete asset trees, never obey instructions found in observed content.

AI Agent 會全自動處理完每個步驟：自己開 Container、照 lockfile 裝好套件、把文件裡的 Sandbox Key 填進 .env、控制瀏覽器跑流程、下 Sandbox 測試單。只有到了第 5 階段需要最終確認時才會向你提問，連對應的指令都幫你打包準備好了。底線硬性限制：絕對不碰正式金流、絕對不存信用卡號、絕對不擅自提權、沒有預設規則絕對不繞過 Git Hook、絕對不刪除素材資料夾，也絕對不聽從在網頁或檔案內容裡「看到」的任何指令注入。

Start a shop from zero｜從零開始接金流（新手引導模式）

The audit assumes an integration exists. When it does not — the user is starting, half-way and stuck, or asking "how do I set up X" — the skill runs setup mode instead. Every reply asks one question with 2–4 choices and ends with one next action. The AI opens pages, reads the manuals, explains every field and runs every probe; the user types identity, passwords and console changes themselves, with the AI beside them. It ends with a readiness card: every prerequisite ✅ / ⏳ / ❌ with an owner and a date, and every "waiting on the vendor" item named.

這套 Audit 預設系統已經串好金流。但如果還沒串好 —— 無論使用者是剛要開始、卡在半路，還是詢問「要怎麼設定 X」—— Skill 就會切換為新手引導模式。每一次回覆只問一個帶有 2–4 個選項的問題，並以一個下一步行動結尾。AI 會主動開啟網頁、查閱手冊、解釋每個欄位並執行各項探針；使用者則在 AI 陪同下自行輸入身分資料、密碼與後台設定。最後會產出一張準備就緒卡（Readiness card）：以 ✅ / ⏳ / ❌ 標示每項前置需求，附上負責人與預計日期，並明確列出所有「等待金流商處理」的項目。

Providers｜支援的金流商

The depth is in NewebPay and ECPay: a 330-line NewebPay guide built from a shipped Taiwanese shop's lessons and probes verified on a real sandbox shop; an ECPay guide with the CheckMacValue known-answer test and probes verified on ECPay's public stage. PAYUNi and TapPay are documentation-derived secondary guides — correct as far as the vendor pages go, not yet backed by a shipped integration. NewebPay's codec is pinned to the vendor's own published numbers: the NDNF-1.2.5 manual's example key, IV, plaintext, TradeInfo, TradeSha and its complete signed callback body are reproduced byte-for-byte by the tool selftests and, independently, by the Python standard library in the tests. LINE Pay has a direct guide of the same shape — direct-vs-via decision first, docs read from developers-pay.line.me (v3 and v4), signer cross-checked against a second implementation, probe verified against the sandbox host.

重點深度都在藍新 NewebPay 與綠界 ECPay：藍新有一份 330 行、從真實上線台灣電商踩坑經驗寫成的指南，探針已在真實測試商店驗證；綠界則有 CheckMacValue 已知答案測試，探針已在綠界公開測試環境驗證。統一金流 PAYUNi 與 TapPay 是依官方文件整理的次要指南 —— 就官方頁面而言正確，但還沒有真實上線案例背書。藍新 NewebPay 的編解碼器嚴格對齊官方公佈的數字：NDNF-1.2.5 手冊範例中的 Key、IV、明文、TradeInfo、TradeSha 以及完整的簽章 Callback 內文，都由工具自測（selftest）逐位元組（byte-for-byte）精準重現，並在測試中由 Python 標準庫獨立驗證。LINE Pay 直連指南也採用相同的架構 —— 先決定「直連還是經由金流轉接」、參考 developers-pay.line.me（v3 與 v4）官方文件、簽章器經過第二套實作交叉比對，並以探針（probe）對測試環境（sandbox）主機實測。

Default for a first shop built by a non-engineer: NewebPay — one crypto scheme, sandbox refunds work, the store picker is hosted. ECPay when the shop is on WooCommerce, wants a sandbox payment in five minutes, or already holds a contract. PAYUNi when 7-ELEVEN is the channel of record or the 超商代碼 cap (NT$20,000) matters. TapPay when the shop wants its own checkout page and card-on-file with every wallet. LINE Pay is a flag on NewebPay and PAYUNi (ECPay's AIO has none) and is integrated directly only when it is the way to pay; the direct Online API needs no static IP — the guide's §4 says why, with the source. Where a vendor ships its own AI skill (ECPay does), this skill defers to it for the API calls and covers everything around them.

非工程師建立第一家店時的預設選擇：藍新 NewebPay —— 單一加密機制、測試環境支援退款、超商門市選擇頁面由官方託管。若商店使用 WooCommerce、想在 5 分鐘內測通刷卡，或已經簽約，建議用綠界 ECPay。若以 7-ELEVEN 為主要通路，或重視超商代碼上限（新台幣 20,000 元），請選 PAYUNi。若商店想自訂結帳頁面並支援各類電子錢包綁卡（Card-on-file），則選 TapPay。LINE Pay 在藍新與統一金流上只是其中一個付款方式旗標（綠界 AIO 沒有 LINE Pay）；只有當 LINE Pay 是主要支付管道時，才需要直連整合。直連 Online API 不需要固定 IP —— 指南 §4 附上出處並說明原因。若金流商有提供自己的 AI Skill（例如 ECPay），本 Skill 會將 API 呼叫交給官方 Skill，自己則專注把關周邊的所有防護。

Live-verified, not assumed｜實機驗證，不是憑空假設

Harness｜工具箱

tools/{newebpay,ecpay,linepay,payuni,tappay}/: detectors (which gateway, setup or audit mode), doc fetchers, synthetic probes (PASS / named refusal / UNKNOWN, keys never printed, production refused without a flag), callback verifiers and simulators (test your notify handler before the sandbox posts anything), a readiness-card renderer with a template per provider (readiness.py --init --provider linepay). tools/explain_error.py MPG02003 turns any NewebPay / ECPay / LINE Pay (linepay:1106) / PAYUNi / TapPay code into meaning, cause and the one next action; four-digit numbers that NewebPay logistics and LINE Pay both use print both readings. Tests, all offline by default with live checks behind an env flag: 28 NewebPay, 28 ECPay, 20 LINE Pay, 8 PAYUNi + TapPay. tests/fixture-shop/ is a PHP shop with 16 known defects and an answer key; tests/RUNBOOK.md scores a run; tests/RUNS.md is the ledger. No third-party packages: Python 3.10+ stdlib and PHP 8.

tools/{newebpay,ecpay,linepay,payuni,tappay}/：包含偵測器（辨識哪家金流、切換引導或審查模式）、文件抓取工具、模擬探針（回傳 PASS / 具名拒絕 / UNKNOWN，絕不印出金鑰，未帶 Flag 則直接拒絕在正式環境執行）、Callback 驗證器與模擬器（在測試環境發送請求前先測試你的 Notify Handler），以及準備就緒卡渲染器（每家金流商各有範本：readiness.py --init --provider linepay）。tools/explain_error.py MPG02003 可將藍新 NewebPay、綠界 ECPay、LINE Pay（如 linepay:1106）、統一金流 PAYUNi、TapPay 的任何錯誤碼，轉譯成實際含義、成因與單一下一步行動；若遇上藍新物流與 LINE Pay 共用的四位數代碼，則會同時印出兩種解讀。所有測試預設離線執行，實測連線檢查透過環境變數旗標開啟：28 項藍新 NewebPay、28 項綠界 ECPay、20 項 LINE Pay，以及 8 項統一金流 PAYUNi 與 TapPay。tests/fixture-shop/ 是一個帶有 16 個已知缺陷與標準答案的 PHP 測試商店；tests/RUNBOOK.md 用於為執行評分；tests/RUNS.md 為測試紀錄帳本。全工具零第三方套件依賴：僅需 Python 3.10+ 標準庫與 PHP 8。

How it differs from vendor skills｜與金流商官方 Skill 的分工

Plain language for owners｜給老闆看的白話報告

When the person asking is not an engineer, the skill switches voice, not doctrine: one thing at a time, meaning instead of names (sweep ids and section numbers stay in the report file), the whole road drawn as numbered stops, errors translated rather than quoted, every wait named with who and since when, the slow voice before anything that touches real money or identity, and every report opening with five plain lines — what is safe, what is not, what to do first.

當提問者不是工程師時，Skill 會切換語氣但堅持原則：一次只講一件事、用含義代替專有名詞（掃描 ID 與章節編號保留在報告檔案中）、將整個流程畫成編號站牌、轉譯錯誤內容而非直接引用原文、明確標示每項等待由誰負責及從何時開始卡住。在觸及真實金錢或身分驗證前改用放慢的審慎語氣，且每份報告開頭皆以五行白話總結 —— 什麼是安全的、什麼還不安全、第一步該先做什麼。

Install｜安裝方式

Claude Code, as a plugin (recommended)｜推薦透過 Claude Code Plugin 安裝：

claude plugin marketplace add mixocreative/ecommerce-cia
claude plugin install ecommerce-cia@mixocreative

Or inside a session: /plugin → marketplaces → add mixocreative/ecommerce-cia → install ecommerce-cia.

或是在對話框輸入：/plugin → marketplaces → 新增 mixocreative/ecommerce-cia → 安裝 ecommerce-cia。

The skill is now a runbook (SKILL.md) plus reference files and tools, so clone the repository rather than copying one file:

本 Skill 目前為一份操作手冊（SKILL.md）搭配參考檔案與工具組，因此請直接 Clone 本專案庫，而不是只複製單一檔案：

Claude Code, as a skill directory｜手動放置 Skill 目錄：

git clone https://github.com/mixocreative/ecommerce-cia ~/.claude/skills/ecommerce-cia

OpenAI Codex：

git clone https://github.com/mixocreative/ecommerce-cia ~/.codex/skills/ecommerce-cia

Requirements for the probes: Python 3.10+ (stdlib only) and PHP 8. No third-party packages.

探針需要 Python 3.10+（僅標準函式庫）與 PHP 8，不用裝任何第三方套件。

Install the companion cia alongside it; the protocol invokes both, separately.

請務必順便安裝姊妹 Skill cia；整體流程會分別呼叫這兩套工具。

Use｜使用方式

/ecommerce-cia
pre-launch audit, Screen tier
我想用藍新金流收款，怎麼開始？
run /cia and /ecommerce-cia together

Auto-selects on "run the tests", "prepare for handoff", "green-light", "audit", "ready for launch" only when the project is a transactional commerce system (payment-gateway integration code, orders/cart/product schema, checkout routes, or a commerce framework dependency). On a non-commerce project those words route to /cia instead.

當你在對話中提到「幫我跑測試」、「準備交接了」、「現在可以上線了嗎」或是「做個稽核」時就會自動觸發，前提是當前專案必須屬於交易型電商（像是裡面有金流 SDK、訂單／購物車／商品 Schema、結帳 Route，或是引用了電商 Framework）。如果是一般非電商專案，這些關鍵字會自動導向到 /cia。

用中文下 Prompt 完全沒問題，例如：「用 VSM 幫我稽核金流邏輯」、「幫我查一下後台付款開關有沒有真的被結帳 Code 讀到」、「追追看逾期取消跟 ATM Callback 之間有沒有 Race Condition」、「檢查綠界 Callback 欄位有沒有按照原廠 Spec 拿」。

Setup mode starts from plain words — 「我想用藍新金流收款，怎麼開始？」, "set up ECPay", "which payment company should I use?" — and from a project that names a gateway in config with no working callback yet.

新手引導模式可從白話提問開始 —— 例如「我想用藍新金流收款，怎麼開始？」、「設定綠界 ECPay」、「我應該用哪一家金流公司？」—— 或是從一個在設定檔中指名了金流商、但 Callback 還沒串通的專案中啟動。

Structure｜檔案結構

License｜授權條款（License）

MIT