測試全綠，線上卻掉單、庫存鎖死、後台開關沒作用？
ecommerce-cia 盯的是錢和庫存真正走過的路 —— 從結帳、Callback、退款到後台，一條一條驗給你看。
Green tests, lost orders. ecommerce-cia audits the path money and stock actually take — and walks first-time builders through Taiwan's payment gateways from zero.
快速開始 Quick start · 串接稽核 Wiring audit · 抓到過什麼 What it catches · 支援金流 Providers · 常見問題 FAQ · 安裝 Install
claude plugin marketplace add mixocreative/ecommerce-cia && claude plugin install ecommerce-cia@mixocreative
你的商店上線了，測試也全過了。然後：客人付了錢訂單卻顯示「未付款」、過期訂單的退庫存把已付款訂單的庫存也退掉了、後台把 ATM 轉帳關掉了結帳頁照樣出現、藍新的 Callback 重送一次庫存就被釋放兩次。每一段程式單獨看都沒錯，錯在它們之間。
對 AI Agent 輸入
/ecommerce-cia，它會把結帳 → 金流 → Callback → 訂單 → 庫存 → 出貨 → 退款 → 後台整條路走一遍，在測試環境實際下單驗證，再交出一份每一條「通過」都附證據的報告。還沒串金流？它會切換成新手引導模式，一次問一個問題，帶你從零接好藍新、綠界或 LINE Pay。
Your shop is live and every test passed. Then a paid order shows "unpaid", the expiry job restocks an order that was already paid, the admin switched ATM transfer off but checkout still offers it, and one duplicate gateway callback releases the stock twice. Each piece is correct alone; the defect is between them. /ecommerce-cia walks checkout → gateway → callback → order → stock → fulfilment → refund → admin, places real sandbox orders, and reports nothing as passed without evidence from this run. No gateway yet? It switches to setup mode and walks you through NewebPay, ECPay or LINE Pay from zero.
1. 安裝 Install（其他方式見 Install）
claude plugin marketplace add mixocreative/ecommerce-cia && claude plugin install ecommerce-cia@mixocreative2. 直接對 Agent 下指令 Ask your agent — 複製任一則：
/ecommerce-cia 上線前稽核，Screen 等級
我要開一家網路商店，想用藍新收信用卡跟超商代碼，從零帶我串。
幫我確認：後台關掉的付款方式，結帳頁是不是真的不會出現？Callback 重送兩次會不會重複扣庫存？
我們的電商是自己寫的，下一步該稽核什麼？用參考系統當檢查清單，跑一次 Walk 等級的串接稽核。
/ecommerce-cia pre-launch audit: place one sandbox order per payment method,
then cancel and refund each, and show me the stock at every step.
3. 你會拿到什麼 What comes back
- 稽核模式 Audit：給老闆看的 5 行白話摘要（哪裡安全、哪裡危險、先做什麼），接著是每個步驟一行、每個發現附
檔案:行號與引用程式碼，以及一張證據帳冊（PASS / FAIL / UNVERIFIED / UNPROVEN，每個 PASS 都指向這次執行產生的檔案）。 - 新手引導模式 Setup：一張準備就緒卡，每項前置需求 ✅ / ⏳ / ❌，附負責人、日期，以及每種付款方式的實機探針結果。
A feature comparison asks: "Do we have refunds?" A wiring audit asks: "What happens if a payment succeeds, the callback is lost, stock changes, the invoice write fails, and the operator opens the order two days later?" That is where custom commerce engines break — and it is the question ecommerce-cia asks first, about your shop, and answers with evidence.
功能比較問的是：「我們有退款功能嗎？」串接稽核問的是：「如果付款成功、Callback 掉了、庫存變了、發票寫入失敗，而管理員兩天後才打開這張訂單，會發生什麼事？」 自己寫的電商系統就是在這裡出事。
ecommerce-cia第一個就問你的商店這個問題，並用證據回答。
Three layers, every run｜每次都檢查三層： function logic (each function correct on its own) · relationship wiring (every call made, every result persisted, retries and partial failures handled) · lifecycle business rules (the whole shop obeys its rules when events arrive late, twice or out of order). The report counts findings per layer — a report with only the first layer was not a wiring audit.
A side-by-side state map per lifecycle｜每個流程的對照狀態圖 — a mature reference (ProcessWire Commerce, WooCommerce, Shopify, Saleor) is used as a checklist of stages, never as the truth; your own rules, the gateway manuals, Taiwan invoice law and your architecture are the authority:
| Lifecycle｜流程 | Reference path｜參考系統 | Your path｜你的系統 | Failure / retry｜失敗與重試 | Operator sees｜後台看到 |
|---|---|---|---|---|
| Checkout 結帳 | cart → order → payment | cart → locked stock → order → redirect | duplicate submit, expired order | clear refusal or order state |
| Payment 付款 | confirmation → paid | callback → verify / re-query → settlement | missing / forged / late callback | order warning + reconciliation |
| Refund 退款 | request → status | provider request → pending → reconcile | provider timeout, partial refund | refund exception on the order |
| Shipping 物流 | fulfilment → delivered | parcel → carrier event → notice | duplicate / out-of-order event | traceable shipment issue |
| Invoice 發票 | order → invoice | paid order → obligation → book / correction | failed or missing obligation | visible invoice finding |
| Download 下載 | paid → download | entitlement → pinned file key | expired link, file replaced | recoverable access |
Seven questions for every connection｜每一條串接問七個問題: is it actually called? is the result saved? safe if retried twice? one authoritative state when systems disagree? can a job stop unnoticed? does an unresolved case show on the order page, not only in logs? is there a test that breaks this connection?
Seven deliberate failures｜七種刻意製造的故障 — reject the invoice write · replay a callback · callback before the customer returns · two checkouts on the last unit · refund provider times out · download file removed after sale · reconciliation job stopped. The only passing outcomes: the system recovers, or the problem appears in admin.
The deliverable is a traceability matrix, not a code review｜交付的是規則追溯矩陣，不是 Code Review:
| Business rule｜商業規則 | Code that enforces it | Connected systems | Proof | Outcome |
|---|---|---|---|---|
| Never oversell physical stock｜實體庫存絕不超賣 | checkout + stock ledger | cart, order, payment expiry | concurrency test | covered / gap |
| Never fulfil an unverified payment｜未驗證的付款絕不出貨 | callback reducer + re-query | gateway, order, download, invoice | replay / forged callback tests | covered / gap |
| Every sale gets the right invoice｜每筆交易都有正確發票 | settlement + invoice obligation | order, refund, invoice book | success / failure / retry tests | covered / gap |
| Every unresolved money state reaches admin｜未解決的金流狀態一定出現在後台 | reconciliation + findings UI | worker, order list, dashboard | forced-failure walk | covered / gap |
…plus a gap register with the exact file:line and proof status of every gap. Ask "what should we audit next?" and this — a reference-guided Walk — is what it recommends. Full method: references/wiring-walk.md.
Planted in the runnable fixture shop, each one invisible to a reading-only review and to a green suite — found only by running the system:
以下是可實際執行的測試商店裡埋的缺陷，只讀程式碼或只看測試都抓不到，必須把系統跑起來才會現形：
| 情境 Case | 大家看到的 What everyone saw | 實際上 What was true |
|---|---|---|
| 重送的通知 Duplicate notify | 金流 Callback 驗簽通過、訂單已付款 | 同一則通知送兩次，庫存被釋放兩次 |
| 永遠不更新的快取 Stale storefront | 前台顯示「有庫存」 | 前台讀的快取沒有任何程式在刷新 |
| 看不見規格的後台 Blind admin | 後台庫存頁數字正確 | 後台看不到變體（尺寸/顏色），老闆以為有貨 |
| 違反自家條款的退款 Policy drift | 退款按鈕正常運作 | 退款規則跟商店自己寫的退貨政策相反 |
| 後台開關沒作用 Dead control | 後台把付款方式關了 | 結帳邏輯根本沒讀那個設定 |
And from live sandboxes, real gateway behaviour the docs do not spell out: NewebPay answers MPG02003 for a method your console has not enabled; LINE Pay answers 1172 to a repeated confirm and 1165 to a repeated refund; ECPay's CheckMacValue reproduced byte-for-byte from its published example. Full table in Live-verified.
也包含在真實測試環境量到、文件沒寫清楚的金流行為：藍新未開通的付款方式回
MPG02003、LINE Pay 重複 confirm 回1172、重複退款回1165、綠界CheckMacValue與官方範例逐位元組一致。
Found a commerce bug class it missed? Share the lesson.｜發現它漏掉的電商 bug？歡迎分享案例。
我沒串過金流，也不是工程師，用得了嗎？｜Never integrated a gateway — can I use it?
可以，這正是新手引導模式的用途。每次只問一個帶 2–4 個選項的問題，結尾給一個下一步。AI 負責查手冊、解釋欄位、跑探針；身分資料、密碼與後台設定由你本人輸入。
Yes — that is setup mode. One question at a time with choices; the AI reads the manuals and runs the probes, you type identity, passwords and console changes yourself.
它會碰到正式環境或真的扣款嗎？｜Will it touch production or charge real money?
不會。探針預設只連測試環境，沒有明確旗標就拒絕連正式環境；金鑰永遠不會印出來。稽核中絕不呼叫有副作用的正式 API。
No. Probes target sandboxes and refuse production without an explicit flag; keys are never printed.
跟金流商自己出的 Skill 有什麼不同？｜How is it different from a vendor's own skill?
金流商的 Skill 教你「怎麼呼叫它的 API」；ecommerce-cia 檢查的是「呼叫完之後，你的訂單、庫存、退款、後台是不是還對得起來」，而且跨金流商一致。詳見 How it differs from vendor skills。
A vendor skill teaches its API; this one checks that your orders, stock, refunds and admin still agree after the call — the same way across providers.
只支援台灣嗎？｜Taiwan only?
台灣金流最深（藍新、綠界、LINE Pay、PAYUNi、TapPay，含 ATM 虛擬帳號、超商代碼、超商取貨付款、統一發票、七天鑑賞期），也涵蓋 Stripe 與 Adyen 的簽章與 Webhook 合約。結帳、庫存、退款、冪等性這些稽核邏輯則與國家無關。
Deepest for Taiwan; Stripe and Adyen webhook/signature contracts are covered too, and the checkout, stock, refund and idempotency doctrine is country-neutral.
要跑多久？會改我的程式嗎？｜How long? Will it change my code?
報告第一行會寫明深度：Screen 2–4 小時、Walk 1–2 天、Full 不設限。只有「本地、可還原、附測試」的修正會自動 commit（不 push）；其餘附 patch 交給你決定。
Screen 2–4 h, Walk 1–2 days, Full open-ended. Only local, reversible, test-backed fixes are committed automatically (never pushed); everything else comes to you as a patch.
需要搭配 cia 嗎？｜Do I also need cia?
建議一起安裝。cia 負責通用的程式完整性，ecommerce-cia 負責電商專屬規則；兩者各自執行，你也可以要求「兩個一起跑」，共用的工作只做一次。
Recommended. cia owns universal integrity, this skill owns commerce doctrine; ask for both and the shared work runs once.
New in this release — evidence discipline borrowed from reverse engineering. Every claim is tagged OBSERVED / INFERRED / UNKNOWN; every promise the owner made becomes an obligation with exactly one owner in the code and a verifier that names it; a test can only close a claim at its own strength (a mocked gateway never proves a real callback); "nothing reads it" must state where it looked; cut-off output is never counted; contradictions between manual, sandbox and code are recorded instead of resolved by preference; and a new reverse-trace mode starts from what the system visibly does and traces inward. See references/evidence.md. Ideas adapted from REA.
本版新增：從逆向工程借來的證據紀律。 每一條結論都標記「實測 / 推論 / 未知」；老闆說過的每一個承諾都變成一條義務（Obligation），在程式裡必須剛好有一個負責者、一個點名它的驗證；測試只能證明與自己同等強度的事（用假金流的測試，永遠證明不了真的 Callback）；「沒有程式在讀」必須說清楚找過哪裡；被截斷的輸出不算數；手冊、測試環境與程式碼互相矛盾時，記錄下來而不是挑方便的那邊相信；新增反向追蹤模式：從系統看得見的行為出發，一路追到程式碼裡。詳見
references/evidence.md。概念改編自 REA。
Last scored fixture run: see tests/RUNS.md — python tools/score.py prints it, --gate refuses a push that scores below the run before (RUNBOOK step 6).
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）。
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.
| Ordinary code review / linter｜一般 Code Review / Linter | This skill｜這個 Skill | |
|---|---|---|
| Question asked｜切入角度 | Is each line written correctly?｜程式碼每一行有沒有寫對？ | When money moves, does the whole thing behave the way you think?｜錢在流動的時候，整體行為是不是真的跟你想的一樣？ |
| Unit of inspection｜檢查粒度 | one file, one function｜單一檔案、單一 Function | one deadline across time, one switch across layers, one callback against the vendor spec｜跨時間的時效設定、跨架構的設定開關、對照廠商 API 規格的回呼邏輯 |
| Finds｜抓得到的 Bug | syntax, types, null checks, style, a bug inside a function｜語法錯誤、型別出錯、沒防到 Null、Style 不符、單一 Function 裡面的邏輯漏洞 | a payment switch nobody reads, stock released on a live order, a gateway field read wrong, a green report that skipped the DB tests｜根本沒被讀取到的付款開關、未完結訂單直接被拿去退庫存、讀錯金流 Response 欄位、偷偷跳過 DB 測試的假綠燈 |
| Cannot find｜抓不到的盲點 | anything that lives between two correct functions｜夾在兩個「看起來完全正常」的 Function 之間的各種問題 | (it starts there)｜（這正是它發揮作用的地方） |
| Proof it accepts｜驗收標準 | "tests pass"｜只要顯示「Test Passed」就算過 | the exact run line with counts, plus one real sandbox checkout per gateway with the callback verified｜拿到真正執行過的測試筆數與斷言數，加上每家金流商都在 Sandbox 實際走過一遍結帳並驗過 Callback |
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 幫你守住系統裡的每一分錢。
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:
- 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.
- 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.
- 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 關心的是另一件事：他們彼此之間到底有沒有搭上線？而且有沒有在正確的時間點對齊資訊？ 舉三個實務上超常發生的慘劇：
- 店長明明在後台把「ATM 轉帳」關掉了，收銀員結帳時卻還在繼續收。 原因出在根本沒人把後台的開關設定串到收銀員的流程裡。雖然兩邊的 Code 單獨看都「寫得很好沒 Bug」，但最後客人用 ATM 轉帳付了錢，系統卻再也無法確認訂單。這種狀況我們叫它死開關，這個 Skill 會把後台每一個設定硬生生拿去跟「應該執行它的 Code」對質。
- 倉庫預設幫客人保留商品 30 分鐘，但同一時間店長開啟了一種需要 3 天才會入帳的付款管道。 當客人選了這個付款方式，30 分鐘保留期一到，商品就被系統釋出；等客人隔天順利付完款，才發現東西早就賣光了。每一道步驟各自看都沒有錯，錯在步驟之間的「時間差沒對齊」。這就叫過期快照。
- 會計跑過來說「帳全部對上了！」，結果其實只查了幾張容易翻到的帳單。 遇到放假沒開門的銀行帳目就直接跳過不查。測試報告看起來一片綠燈，實際上根本毫無參考價值。這就是典型的空洞通過。這個 Skill 會把任何被 Bypass 掉的測試直接歸類為「未驗證」，絕對不放水給過。
它執行的步驟非常乾脆：先幫你的電商程式碼畫出一張組織架構圖（釐清誰是收銀員、倉管、店長跟會計），接著仔細體檢他們之間的每一條溝通管道，最後直接點名哪裡的溝通斷鏈了、發生在哪個檔案、第幾行、該怎麼修正。
Three objections engineers raise when they first meet this skill, and the honest answer to each.
1. "You are mixing code review with testing. They are separate stages for a reason." They stay separate here too: tests run in Step 1 and again in full in Step 3; review is a person or a review tool. This skill is a third thing — a cross-boundary invariant audit — for the defect that neither stage asks about: every function correct on its own, the failure in the channel between two of them. A setting nothing reads, a watchdog that reports "0 problems" whether or not it looked, a page that throws on every request while its guard test sits 4,500 tests deep in a seven-hour suite. Review checks style and logic; tests check behaviour; neither asks "who reads this value?" S21 ("the suite is an instrument too") is not a merge of the two — it audits the tests for passes that prove nothing. This skill does not replace review or tests, and says so.
2. "This is prompting dressed up in academic words."
Prompting does not produce a numbered sweep list with an answer key. The fixture harness
(tests/) plants ten defects under a green suite and scores each cold run: hits, near-misses,
misses, false positives. That number moves when the doctrine moves; a prompting habit cannot be
scored. Where the objection is right is the vocabulary: S5, System 3*, S22.8 are noise to a
reader who has not seen the map, which is why §0.15 / §0.16 bind every user-facing message to plain
words, and why this README says it in plain engineering terms first:
this is a checklist of ways a system fails between its parts, walked along a map of who
controls what, with a test that proves the checklist still finds what it was written to find.
3. "Day-to-day coding does not need a systems model. CI/CD and discipline are enough." For a script, yes — which is why the audit has tiers, and Screen is two to four hours, not a week. The case for it is code written with an AI: a day of agentic development creates ten times the boundaries a person would, and "write a bit, test a bit" fails exactly at the boundaries. CI catches regressions; it does not catch a feature that was designed and never wired (S13), a control that reaches no decision (S5), or a detector that went blind (S20). Invariants written at the source are what make AI-generated code checkable — the auditor has something to hold the output to, instead of reading it and hoping.
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 模型即時生成。
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）核心概念在於：任何能夠在動態環境中持續存活的系統，必然具備由五個子系統構成的結構，而且這種結構在每一個遞迴層級上都完美複製：
| System｜系統 | Role｜扮演角色 | In a shop｜對應到電商系統的具體模組 |
|---|---|---|
| 1 | does the work｜執行層（Operations） | checkout, order placement, payment capture, fulfilment, entitlement grant｜處理結帳、建立訂單、發起請款、安排出貨、發放數位商品下載權限 |
| 2 | damps oscillation between the parts of System 1｜協調層（Coordination） | stock reservation, payment deadlines, callback idempotency, order state machines｜防止 System 1 各模組互相打架：包含庫存保留鎖定、付款時效控制、Callback 冪等性處理、訂單狀態機 |
| 3 | commands and allocates resources to System 1｜管理層（Control） | payment-method toggles, shipping rules, tax settings, admin pages, feature flags｜發布指令與分配資源給 System 1：包含付款方式開關、運費算表、稅務設定、Admin 後台介面、Feature Flag 控制 |
| 3* | audits System 1 directly, bypassing its own reports｜獨立稽核（Audit） | test suites, reconciliation against provider statements, probes, sandbox walks｜不聽信 System 1 的自我報告，直接進行實地查帳：包含 Test Suite、金流對帳腳本、探測 Monitoring Script、Sandbox 實測 |
| 4 | faces the environment and the future｜研發與外觀（Intelligence） | gateway specs, logistics APIs, callback formats, tax and invoice regulation｜掌握外部環境變化與未來規格：包含金流商 API 規格書、物流 API、Webhook 格式、稅務與電子發票法規 |
| 5 | identity and policy; receives the algedonic (pain) signal｜政策與願景（Policy） | fail-closed defaults, refund policy, kill switches, amount-mismatch alerts｜定義系統身分與核心政策，並接收全局「痛覺」訊號：包含故障時預設關閉（Fail-Closed）、退款政策、緊急熔斷機制、金額不符警報 |
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
PaymentMethodfield. The vendor spec defines a sharedPaymentTypefor 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 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 區塊、每一條退款流程，都要一路追查到「到底由誰來做最終決策」。
- 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. - 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.
- 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.
- Report structurally: every finding names its defect class and the VSM channel it sits on.
- 第一步先把電商模組對應到 System 1–5 架構（詳見 §0.9 第 0 步），並產出一張完整的對照表：標註每個元件、所屬的子系統，以及彼此間的資料通道（
producer → consumer）。- 順著通道逐一體檢：強制執行二十二項深度掃描（詳見 §0.9）。後面列出的每種缺陷類型，本質上都是某條出了問題的斷鏈通道；每個掃描點都是直接對照架構圖來查，絕對不是拿
grep隨便搜搜字串而已。- 評判標準是「能不能在真實世界存活」，而不只是「語法對不對」：§2 會嚴格抽查金流、庫存、訂單、數位權限這四大區塊各自的五層系統是否齊備、System 3* 稽核機制有沒有獨立於 System 3 之外，以及各類痛覺路徑（如金額不符、Callback 驗簽失敗、自我修復機制）有沒有順暢通到 System 5。
- 輸出結構化報告：針對抓到的每一個問題，精確標明缺陷類型以及所屬的 VSM 溝通通道。
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）：
| Term｜專業術語 | Meaning｜實際代表的意思 |
|---|---|
| TOCTOU race｜TOCTOU 競態條件 | a predicate checked at one step, dropped at the step that acts｜某個狀態在 SELECT 時明明確認過沒問題，結果到了 UPDATE 那一刻條件卻早就變了 |
| Temporal coupling / stale snapshot｜時間耦合／過期快照 | a value frozen at one moment, re-read live by a later reader｜某個數值在下單時就被凍結起來，但後續的邏輯卻又跑去讀取最新的即時變數 |
| Semantic drift｜語意漂移（Semantic Drift） | code's reading of an external field diverges from the vendor spec｜程式碼對外部 API 欄位涵義的理解，跟金流商原廠 Spec 寫的完全對不上 |
| Dead control｜死開關（Dead Control） | an admin toggle or flag no runtime path consumes｜後台明明做好了開關 UI，但全域程式碼中沒有任何一條執行路徑真正去讀取它 |
| Fail-open default｜出錯就放行（Fail-Open） | an error path that proceeds as if the read succeeded｜當系統跑到 Error Handling 路徑時，居然把它當成成功回應繼續往下執行 |
| Vacuous pass｜空洞的通過（Vacuous Pass） | a suite that says OK because the meaningful tests skipped or never ran｜測試報告顯示綠燈過關，但實際上核心測試案例早就被 Skip 掉或是壓根沒跑 |
| Deferred-work residue｜「之後補」的殘骸 | a "follow-up commit" comment that never landed｜Code 裡面寫著 // TODO 說下個 commit 會補齊，結果過了好幾年都沒人處理 |
| Rename residue｜重構改名殘骸 | a consumer still bound to the old name｜核心變數或 Function 已經改名，但角落還殘留著綁定舊名稱的呼叫端 |
| Diagnosis without probe｜沒實測就盲目診斷 | a cause concluded from an error message, not a direct check｜遇到 Error 只憑空印出來的字串猜原因，完全沒有深入探查底層真實狀況 |
| Boundary schema drift｜邊界結構漂移 | a payload acted on before its shape and type are validated｜跨系統傳進來的 Payload 資料，連資料結構跟型別都還沒驗證就直接拿來跑邏輯 |
| Cascade / retry storm｜連鎖失敗／重試風暴 | one step's failure or retry becomes a crash, duplicate write, or orphaned side effect｜單一步驟出錯或發起 Retry，結果一路引爆系統崩潰、資料重複寫入，或是留下沒清乾淨的副作用 |
| Orphan capability｜孤兒功能（designed-but-unbuilt，已設計但未串接） | a class, table, column or design-document promise with no caller, no writer, no page and no gap-register row｜Class、資料庫表格、欄位或設計文件中的承諾，沒有任何呼叫者、寫入者、網頁，也沒有記錄在缺口登記表中 |
| Scope shadow｜範圍陰影（Scope Shadow） | an audit of one diff or module whose report reads as whole-system green｜明明只審查了單一 Diff 或模組，報告讀起來卻像是整個系統都綠燈放行 |
| Corner disagreement｜四角分歧（Corner Disagreement） | customer, operator, logistics provider and payment gateway describe one order differently; or a built method is not reachable under the shipped configuration｜消費者、營運人員、物流商與金流商對同一筆訂單狀態認定不一致；或是已開發的付款方式在目前發布的設定下根本無法到達 |
| Hosted-surface control｜託管頁面控制無效（Hosted-Surface Control） | a shop setting claims to restrict a choice the buyer makes on the gateway's own page, where the request cannot express it｜商店後台設定宣稱能限制買家在金流商託管頁面上的選擇，但 API 請求根本無法傳達該限制 |
| Sampled, not enumerated｜採樣代替窮舉（Sampled, Not Enumerated） | one payment × delivery cell read and generalised to the grid; a later finding disproves the method, not just the answer｜僅測試了「付款 × 物流」矩陣中的單一格子就推論整張網格正常；後續的發現推翻的是整套檢查方法，而不只是那一格的答案 |
| Environment constraint never crossed｜環境約束未交集（Environment Constraint Never Crossed） | a gateway's requirement on the host (fixed egress IP, cron, persistent disk) and the launch host's capability both written down, never multiplied｜金流商對主機的要求（固定 Outbound IP、Cron 排程、持久化磁碟）與上線主機的能力都有記載，但從未進行交叉比對驗證 |
| Service-variant confusion｜服務類型混淆（Service-Variant Confusion） | 取貨付款 vs 取貨不付款, platform vs direct, B2C vs C2C — same carrier, different caps, fees and templates, audited as one｜取貨付款 vs 取貨不付款、平台型 vs 獨立型、B2C vs C2C —— 同一家物流商卻有不同的上限、費率與單據樣式，卻被當作同一種服務審查 |
| Blind instrument｜盲目儀表（Blind Instrument） | the settlement reconcile or capture sweep stopped running or examined nothing, and the report looked identical to a clean one｜對帳或請款的掃描腳本停止運作或根本沒檢查任何東西，產出的報告卻跟沒有問題時一模一樣 |
| Unrendered surface｜未渲染介面（Unrendered Surface） | a state the system can reach has no screen, or one nobody rendered, or one no person can dismiss — so "ignore" happens by default｜系統可能達到的狀態沒有對應的畫面、或是沒人渲染該畫面、或是沒有人能關閉該畫面 —— 導致預設直接「忽略」 |
| Vacuous or too-late proof｜空洞或過遲的驗證（Vacuous or Too-Late Proof） | a test asserting emptiness passes for an unrelated reason; or the guard sits so deep in a slow suite nobody reaches it｜斷言「空值」的測試因無關原因通過；或是防禦機制放在太慢的測試套件深處導致根本沒人執行到 |
Prompt with any of those terms, or "audit the wiring and runtime behaviour, not the code", and the sweeps run first.
只要你的 Prompt 裡出現上面任何一個術語，或是提到「幫我稽核邏輯接線跟實際行為，不要只看程式碼表面」，這個掃描流程就會自動啟動。
Each defect class above is a broken channel between two VSM systems; the sweeps are organised by channel, not by file:
每一個 Bug 本質上都是兩個 VSM 子系統之間斷裂的通道；因此所有掃描都是按照「通道」來劃分，而不是按檔案目錄分類：
| Channel｜溝通通道 | Sweeps that walk it｜負責掃描這條通道的檢查項 |
|---|---|
| System 3 → System 1 (control to consumer)｜管理層到執行端（Control to Operations） | dead control, deferred-work residue, stale snapshot |
| System 1 → System 1 across time｜跨時間維度（Across Time） | TOCTOU race, rename residue |
| System 4 ↔ environment｜對外部環境（To Environment） | semantic drift, boundary schema drift |
| System 3* → System 3｜獨立稽核對管理層（Audit to Control） | vacuous pass, diagnosis without probe |
| System 5 defaults｜政策預設機制（Policy Defaults） | fail-open, cascade / retry storm |
| System 3 → System 4 (a setting that must reach the provider's page)｜System 3 → System 4（必須傳達到金流商頁面的設定） | hosted-surface control, sampled-not-enumerated, service-variant confusion｜託管頁面控制無效（hosted-surface control）、採樣代替窮舉（sampled-not-enumerated）、服務類型混淆（service-variant confusion） |
| System 4 requirement × launch host｜System 4 需求 × 上線主機 | environment constraint never crossed｜環境約束未交集（environment constraint never crossed） |
| System 3* on itself (is the safety net still looking?)｜System 3* 對自身的監控（安全網是否還在運作？） | blind instrument, vacuous or too-late proof｜盲目儀表（blind instrument）、空洞或過遲的驗證（vacuous or too-late proof） |
| Customer × operator × logistics × gateway｜消費者 × 營運人員 × 物流商 × 金流商 | corner disagreement (the four-corner walk), terminal-state accountability｜四角分歧（corner disagreement，即四角走位）、終態責任歸屬（terminal-state accountability） |
| System 1 → a screen someone opens｜System 1 → 人員開啟的畫面 | unrendered surface, orphan capability, scope shadow｜未渲染介面（unrendered surface）、孤兒功能（orphan capability）、範圍陰影（scope shadow） |
A channel on the map with no sweep site named against it is reported as unswept.
只要架構圖上有任何一條通道沒有被掃描點覆蓋到，報告就會直接將其標示為「未掃描」。
- Discovers the project's runtime bindings itself (test runner, canonical environment, sandbox credentials file, preview URL, admin route) and announces them.
- 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.
- 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. - 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.
- 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. - 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.
- 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.
- 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…).
- Speaks plainly when the owner is not an engineer (§0.16) and opens every report with five plain lines.
- 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).
- 自動摸清專案執行環境（包含找出測試指令、正式環境配置、Sandbox 金鑰檔、Preview 網址、Admin 路徑）並在第一時間向你回報。
- 先畫出 VSM 架構圖（§0.9 第 0 步），再順著通道發動二十二項強制掃描（§0.9）。每一項掃描都會獨立輸出一行進度；只要少一行就視同任務未完成。
- 貫徹電商硬派教條：嚴格檢查付款、庫存、訂單、數位商品、折扣邏輯與財務一致性的核心不變量；每個業務關心點都必須有獨立狀態機，而不是只靠一個粗暴的
order.status處理；確保購買與退訂流程完全對稱；防範免費與 0 元訂單被 Abuse；確保金流 Gateway 完整性（防偽、關聯性、冪等性、Browser 與 Server 雙通道驗證、非同步付款機制）；涵蓋退款、權限與財務對帳。- 內建台灣在地化專章（TW-0 至 TW-14）：包含綠界 ECPay 與藍新 NewebPay 的 Callback 處理機制、ATM 虛擬帳號／超商代碼／超商條碼等非同步金流、超商物流與重新選擇門市流程、超商取貨付款與純取貨驗證、新台幣無小數點特性處理、電子發票串接，以及消保法七天鑑賞期退貨處置。
- 全自動執行七步上線前檢查（§0.6）：包含快速跑 Lint 與範疇測試、執行
/cia、電商專屬稽核、正式環境完整測試、針對每個語系與 Route 進行瀏覽器模擬實走、每家金流商各在 Sandbox 跑一筆真實結帳並驗證 Callback，最後產出帶有明確未決事項的編號報告。- 堅持「沒證據就絕不放行」。被跳過的 DB 或金流測試會直接被標註為「N 項未驗證」，絕對不給假綠燈。這一輪新寫的測試程式碼，必須附上真實跑過的那一行測試數字。
- 能在引導模式下幫你從零開始開一家店 (§0.15)：包含五家金流商指南（藍新 NewebPay、綠界 ECPay、LINE Pay 直連、統一金流 PAYUNi、TapPay）、寫 Code 前的前置需求與主機檢查、實機探針，以及準備就緒卡。
- 內建多國合規轉接層：包含台灣 TW-0…TW-14；同等深度的歐盟、日本、美國、英國轉接器；以及跨 13 種法規體系（GDPR、個資法、PIPA、APPI、LGPD…）的全球條款與隱私檢查。
- 當老闆不是工程師時能用白話溝通 (§0.16)，且每份報告皆以五行白話開頭。
- 通過冷啟動測試：由全新的 Agent 對帶有標準答案的測試商店執行；每一種模式都有留下紀錄的執行結果，而且零誤報（
tests/RUNS.md）。
The audit answers "is this wrong?". Build mode answers the question that comes first in real work: "what does right look like, and how would I know?"
It exists because of an objection worth taking seriously — that an AI cannot write a backend that handles money correctly. That objection is right about one thing: code which looks correct is the cheapest thing a language model produces. The answer is not more careful-sounding code. It is to name the properties an operation must have, and to prove each one with something that fails when the property is absent.
稽核模式回答的是「這裡寫錯了嗎？」；建置模式回答的是實務上更早出現的問題：「寫對長什麼樣子？我怎麼知道它真的對？」
會有這個模式，是因為一個值得認真看待的質疑：AI 寫不出能正確處理金流的後端。這個質疑有一半是對的——「看起來正確」的程式碼，正是語言模型最擅長、也最廉價的產出。正確的回應不是把程式碼寫得更小心，而是把一個操作必須具備的性質講清楚，並且為每一個性質寫出「性質不成立時就會失敗」的驗證。
Four properties for any write that moves money, stock, a claim on work or an entitlement｜任何會 動到金錢、庫存、工作認領或權益的寫入，都需要這四個性質：
| Property 性質 | Mechanism 機制 | The proof 如何證明 |
|---|---|---|
| Atomic 具原子性 | 單一 transaction，所有失敗路徑都 rollback | 在第一次寫入之後、commit 之前注入故障——第一次的寫入必須消失 |
| Race-free 無競態 | 條件判斷寫在 UPDATE 裡面，由受影響列數決定結果 |
在「只能有一個贏家」的情況下同時發動兩次 |
| Idempotent 冪等 | 呼叫端提供的 key 加上 UNIQUE 約束，且寫在同一個 transaction 內 | 同一把 key 送兩次，第二次不得重複套用 |
| Loud 不吞錯 | 「拒絕」是回傳值，「故障」是例外，兩者永遠不同型別 | 兩者都要斷言 |
tools/reference/stock_reduction.php implements all four for the operation shops get wrong most
often, and tools/reference/prove_stock_reduction.php proves them in eight checks — run it
yourself｜這兩個檔案是可執行的範本，不是示意用的程式碼片段，請直接跑起來看：
PROVED the happy path 5 - 2 = 3, one movement row explaining it
PROVED IDEMPOTENT: a replay re-applies nothing stock still 3, still one movement
PROVED IDEMPOTENT: a refusal replays as itself the decision is recorded, not just the success
PROVED LOUD: a refusal is a value, not silence nothing written, nothing partial
PROVED LOUD: a negative quantity is refused qty < 1 cannot reach the SQL
PROVED RACE-FREE: two callers, one unit exactly one ok, one refusal, stock 0 - never -1
PROVED ATOMIC: a fault after the decrement rolled back to 5, no operation recorded, and it threw
PROVED LOUD: the fault was not swallowed no success-shaped value was returned
The seventh check is the one most codebases never write. A happy-path test passes against an implementation with no transaction at all; only a fault injected after the first write and before the commit separates atomic from merely transaction-shaped.
第七項檢查，是絕大多數專案從來不會寫的那一項。只測 happy path 的測試，就算底下完全沒有 transaction 也會過；唯有「在第一次寫入之後、commit 之前注入故障」，才分得出真的具原子性與只是長得像有 transaction。
The full standard — including what the operation still owes beyond correctness: the movement row
that explains the number, the screen the refusal reaches, the boundary it must not cross — is
references/build-standard.md｜完整標準（含「正確之外還欠什麼」：解釋數字來源的異動紀錄、拒絕訊息要出現在哪個畫面、哪些責任不屬於這個函式）寫在 references/build-standard.md。
A skill that grades other people's evidence should be able to show its own｜一個專門檢查別人「有沒有證據」的工具，自己更應該拿得出證據。
| Measurement 量測 | What it is 這是什麼 | Result 結果 |
|---|---|---|
| Corpus 真實專案樣本 | 在維護者修好該 bug 的前一個 commit 稽核真實專案；該修復 commit 的 diff 就是標準答案，而稽核者永遠看不到它 | 8 個案例中 6 中 / 1 部分中 / 1 未中，橫跨 6 種缺陷類型、7 種語言 |
| Blind-forward 盲測前瞻 | 取專案歷史中段的快照，完全沒有標準答案；稽核完成後，才用專案自己後續的 commit 回放比對 | 8 個稽核發現，0 個判斷錯誤，4 個經獨立驗證為真，但尚未有維護者事後修正 |
| Precision 精確率 | 刻意寫成「看起來像缺陷、其實正確」的對照組：有 ADR 具名授權的顯示路徑 fail-open、正確的 compare-and-swap 就放在錯誤版本旁邊 | 12 個對照組，0 個誤報 |
| Cheap model 低成本模型 | 同一套測試樣本改用較小的模型跑——只有貴的模型才成立的稽核準則，等於只有一種預算能用 | 差距從 4 分縮小到 1 分 |
| Cost 成本 | 每次執行的 token 與時間，讓預算可以被規劃 | 121k–259k tokens，每個發現約 10k–29k |
Every corpus and blind-forward run above was made by the cheap model｜上表所有真實專案與盲測前瞻的執行，用的都是便宜的模型。
The most useful row in the table is a miss. A .env loader caught its own failure, wrote
log.debug, and booted on defaults. A cold run audited that exact file, filed a different
fail-open in it, and walked past this one — because this one logs. Nobody runs production at
debug.
整張表裡最有價值的一列，是那個沒中的案例。一個
.env載入器把自己的失敗 catch 起來，寫了一行log.debug，然後用預設值繼續開機。冷啟動的稽核跑過那個檔案、在裡面抓到另一個 fail-open，卻放過了這一個——因為這一個「有寫 log」。但沒有人的正式環境會開在 debug 等級。兩個 Skill 現在都會把 log 等級納入判斷，測試樣本裡也補上了對應的缺陷，讓這個教訓不會隨時間腐爛。
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、絕對不刪除素材資料夾，也絕對不聽從在網頁或檔案內容裡「看到」的任何指令注入。
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）：以 ✅ / ⏳ / ❌ 標示每項前置需求，附上負責人與預計日期，並明確列出所有「等待金流商處理」的項目。
| Step｜步驟 | What happens｜執行內容 |
|---|---|
| Latest manuals｜最新官方手冊 | fetched from the vendor's production page (never the sandbox portal's stale copy), cited by page｜直接抓取金流商正式環境網頁的最新內容（絕不採信測試環境入口裡的過期副本），並附上頁碼引用 |
| Choice menu｜選項選單 | what you sell → which methods (with caps and who switches each on) → delivery and chains → hosting → invoices｜賣什麼產品 → 支援哪些付款方式（含金額上限與開通權限） → 物流與通路 → 主機環境 → 電子發票 |
| Prerequisites before code｜寫 Code 前的前置需求 | identity documents, bank account, SMS number, HTTPS domain or tunnel, application forms — with who acts and how long it takes｜身分認證文件、銀行帳戶、簡訊驗證號碼、HTTPS 網域或 Tunnel、申請表單 — 並註明執行者與所需時間 |
| Host before code｜寫 Code 前的主機檢查 | a table of what the gateway needs (inbound 443, stable outbound IP for logistics, cron, clock) against shared hosting, VPS, PaaS, serverless｜對照金流商的需求（如 Inbound 443、物流用的固定 Outbound IP、Cron 排程、時鐘同步）與共享主機、VPS、PaaS、Serverless 的規格差異表 |
| Sandbox and proof｜測試環境與驗證 | guided registration, console activation, then a synthetic probe per method: PASS, or the exact refusal code and what it means｜一步步引導註冊、後台開通，並對每種付款方式發射模擬探針：回傳 PASS，或是印出精確的拒絕代碼與含義 |
| Wiring, walk, go-live｜串接、走位與上線 | the contract in the order things go wrong, one sandbox order per method, a production checklist with a canary｜依故障可能發生的順序排列合約規範，每種付款方式完成一筆測試訂單，並提供含 Canary 小流量驗證的上線清單 |
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）主機實測。
| Provider｜金流商 | Guide + tools｜指南與工具 | Verified｜實測驗證狀態 |
|---|---|---|
| 藍新 NewebPay（default｜預設） | manuals + the 65-document hidden inventory (application forms behind every "why is this method still off"), MPG probe, callback verify/simulate, readiness card｜官方手冊 + 藏在深處的 65 份文件庫（解開「為什麼這個付款方式還沒開通」背後的申請表單）、MPG 探針、Callback 驗證／模擬器、準備就緒卡 | live on a real sandbox shop: 7 methods PASS with the server-side payType block; not-enabled → MPG02003; wrong key → MPG03009｜在真實測試商店實測：7 種付款方式皆 PASS（由伺服器端的 payType 區塊確認）；未開通 → MPG02003；金鑰錯誤 → MPG03009 |
| 綠界 ECPay | markdown-twin docs by page id, public stage keys, AIO probe, CheckMacValue verify/make/sign｜按頁碼 ID 整理的 Markdown 雙生文件、公開測試環境金鑰、AIO 探針、CheckMacValue 驗證／壓碼／簽章 |
live on ECPay's public stage: PASS; wrong keys → 10200073; CheckMacValue reproduces ECPay's published worked example byte-for-byte｜在綠界公開測試環境實測：過關；金鑰錯誤 → 10200073；CheckMacValue 算出的結果與綠界官方範例逐 Byte 完全吻合 |
| LINE Pay（direct, or via a gateway｜直連或經由金流轉接） | the direct-vs-via decision first; docs from developers-pay.line.me (Online API v3 and v4); HMAC signer cross-checked against an independent implementation; request probe with --check for the five status codes; error translator for the returnCode table｜先做「直連 vs 經由金流轉接」的決定；參閱 developers-pay.line.me 官方文件（Online API v3 及 v4）；HMAC 簽章器與獨立實作交叉比對；附 --check 的請求探針可讀五種狀態碼；針對 returnCode 對照表的錯誤碼轉譯器 |
full walk live on a sandbox Channel, v3 and v4 (paymentProvider: TSP): request → simulator PAY NOW → 0110 → confirm (payInfo CREDIT_CARD) → details (CAPTURE) → refund; retries answer 1165 / 1172 / 0123; wrong credentials → 1104; signer known-answer equals Python's stdlib HMAC｜在測試環境 Channel 上完整實測 v3 與 v4（paymentProvider: TSP）：請求 → 模擬器 PAY NOW → 0110 → confirm（payInfo CREDIT_CARD）→ 查詢明細（CAPTURE）→ 退款；重試分別回 1165 / 1172 / 0123；錯誤憑證 → 1104；簽章器的已知答案測試與 Python 標準庫的 HMAC 完全一致 |
| 統一金流 PAYUNi（secondary｜次要） | docs via the ShowDoc API, AES-256-GCM envelope, UPP probe reading the page's JS_INFO verdict｜透過 ShowDoc API 取得文件、AES-256-GCM 加密包裝、讀取頁面 JS_INFO 判決結果的 UPP 探針 |
live on a real sandbox shop: Credit · ATM · CVS → PASS; wrong IV → Hash比對不符合; a method the console has not enabled → UPP020xx decrypted from the ReturnURL auto-form｜在真實測試商店實測：信用卡 · ATM · 超商代碼 → PASS；IV 錯誤 → Hash比對不符合；後台未啟用的付款方式 → 從 ReturnURL 自動表單解密出 UPP020xx |
| TapPay（secondary｜次要） | tokenising SDK model, Pay by Prime, wallets, 3DS notify, dry-run probe｜Token 化 SDK 模型、Pay by Prime、電子錢包、3DS 通知、乾跑（Dry-run）探針 | by documentation; a live probe needs an SDK-issued prime by design｜依據官方規格書比對；按架構設計，實機探針需有 SDK 產生的 Prime |
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，自己則專注把關周邊的所有防護。
| Check｜檢查項目 | Result｜實測結果 |
|---|---|
tools/newebpay/probe_mpg.php on a real NewebPay sandbox shop｜在真實藍新測試商店執行 tools/newebpay/probe_mpg.php |
CREDIT · WEBATM · VACC · CVS · BARCODE · LINEPAY · ESUNWALLET → PASS; a product not enabled → MPG02003; a wrong HashIV → MPG03009｜CREDIT · WEBATM · VACC · CVS · BARCODE · LINEPAY · ESUNWALLET → PASS；未開通項目 → MPG02003；HashIV 錯誤 → MPG03009 |
tools/ecpay/probe_aio.php on ECPay's public stage merchant｜在綠界公開測試環境商店執行 tools/ecpay/probe_aio.php |
Credit, BNPL → PASS; wrong keys → 10200073｜信用卡、BNPL → PASS；金鑰錯誤 → 10200073 |
tools/newebpay/probe_mpg.php --selftest and callback.php selftest｜執行 tools/newebpay/probe_mpg.php --selftest 與 callback.php selftest |
reproduce the NDNF-1.2.5 manual's worked example byte-for-byte: TradeInfo (448 hex), TradeSha, and the manual's signed callback body verified and decoded to PaymentType=CREDIT｜逐位元組（byte-for-byte）精準重現 NDNF-1.2.5 手冊範例：TradeInfo（448 個十六進位字元）、TradeSha，以及手冊中的簽章 Callback 內文通過驗證並解碼出 PaymentType=CREDIT |
tools/ecpay/callback.php selftest｜執行 tools/ecpay/callback.php selftest |
matches ECPay's published CheckMacValue example byte-for-byte｜與綠界官方公佈的 CheckMacValue 範例逐 Byte 完全一致 |
tools/linepay/probe_request.php on a real LINE Pay sandbox Channel｜在真實 LINE Pay 測試環境 Channel 執行 tools/linepay/probe_request.php |
request PASS (v3 and v4) → PAY NOW → --check 0110 → --confirm payInfo CREDIT_CARD 1 → --details CAPTURE → --refund refundTransactionId; re-refund 1165, re-confirm 1172, check after 0123; confirm-before-approval 1169 then 0122; fake credentials → 1104; production refused without a flag｜請求 PASS（v3 與 v4）→ PAY NOW → --check 0110 → --confirm 得 payInfo CREDIT_CARD 1 → --details 為 CAPTURE → --refund 得 refundTransactionId；重複退款 1165、重複 confirm 1172、完成後查詢 0123；未核准就 confirm 回 1169 且交易作廢（0122）；假憑證 → 1104；未帶指定旗標時拒絕連線正式環境 |
tools/payuni/probe_upp.php on a real PAYUNi sandbox shop｜在真實 PAYUNi 測試商店執行 tools/payuni/probe_upp.php |
Credit · ATM · CVS → PASS; wrong IV → Hash比對不符合; LinePay / ICash / Aftee / JKoPay / ApplePay → UPP02073/49/50/109/63 此支付工具未啟用 (decrypted, HashInfo verified); AES-256-GCM envelope self-tested｜信用卡 · ATM · 超商代碼 → PASS；IV 錯誤 → Hash比對不符合；LinePay / ICash / Aftee / 街口 / ApplePay → UPP02073/49/50/109/63 此支付工具未啟用（已解密並驗證 HashInfo）；AES-256-GCM 加密封包已通過自我測試 |
tools/newebpay/fetch_manuals.py｜執行 tools/newebpay/fetch_manuals.py |
reads the production download page (403 to curl) and lists the 65 documents the visible tab hides｜可成功讀取正式環境下載頁（一般 curl 會被回 403），並列出前端頁籤隱藏的 65 份文件 |
Cold runs by a fresh agent (tests/RUNS.md)｜由全新 Agent 進行冷啟動測試（tests/RUNS.md） |
setup Q1 · setup 4-turn · plain-language audit · paired run — 0 false positives, 16/16 defects on the fixture shop｜新手引導 Q1 · 新手引導 4 輪對話 · 白話 Audit · 配對執行 — 0 誤報，精準抓出測試商店中的 16/16 個缺陷 |
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. Providers: NewebPay 藍新, ECPay 綠界, LINE Pay, PAYUNi 統一金流, TapPay, Stripe (docs read 2026-09-24; signature scheme proved offline, endpoint and error envelope proved live) and Adyen (the webhook contract only, and it carries the one cross-provider inversion in this skill: Adyen instructs merchants to acknowledge before processing, so the rule that grades that CRITICAL elsewhere is wrong there). tests/fixture-shop/ is a PHP shop with 16 known defects and an answer key, audited by reading; tests/fixture-shop-live/ is a runnable PHP+sqlite shop whose eight defects only a running system shows — a storefront reading a cache nothing refreshes, an admin screen blind to variants, a duplicate provider notification that releases stock twice, a refund that contradicts the shop's own written policy — with tests/verify-fixture-shop-live.py proving every planted row still reproduces; tests/RUNBOOK.md scores a run; tests/RUNS.md is the ledger, and since 2026-09-24 its second table scores what a run executed, not only what it found. 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/fixture-shop-live/是一個可實際執行的 PHP + SQLite 商店，其中 8 個缺陷只有在實際執行時才能發現——前台讀取的是未更新的庫存快取、後台庫存頁面根本看不到規格商品、重複的金流通知會釋放兩次庫存、退款沒有依照商店自訂的政策退回庫存；tests/verify-fixture-shop-live.py則用來證明每一個埋入的缺陷仍能重現。tests/RUNBOOK.md用於為執行評分；tests/RUNS.md為測試紀錄帳本。全工具零第三方套件依賴：僅需 Python 3.10+ 標準庫與 PHP 8。
| Generic audit prompts｜通用型 Audit Prompt | Vendor API skills (ECPay's ecpay-api-skill, paid-tw/skills)｜金流商官方 API Skill |
ecommerce-cia｜ecommerce-cia | |
|---|---|---|---|
| Knows 取貨付款 is two facts (goods, money)｜知道「取貨付款」包含貨物與金流兩個獨立事實 | no｜否 | no｜否 | yes — TW-7, S15, S16｜是 — TW-7, S15, S16 |
| Says what to obtain before coding, and who must act｜在寫 Code 前告知應取得何種資料及由誰執行 | no｜否 | no｜否 | yes — readiness card｜是 — 準備就緒卡 |
| Checks whether the host can do what the gateway needs｜檢查主機環境是否符合金流商要求 | no｜否 | no｜否 | yes — S19 per hosting shape｜是 — S19 針對不同主機型態進行檢查 |
| Proves a method is on instead of trusting a toggle｜實測驗證付款方式已開通而非盲信後台開關 | no｜否 | no｜否 | yes — live probes｜是 — 實機探針 |
| Generates the API code｜產生 API 程式碼 | some｜部分會 | yes, deeply｜是，深度支援 | defers to the vendor skill where one exists｜若有官方 Skill 則委派給官方處理 |
| Finds the defect under a green test suite｜在綠燈測試套件下依然能找出隱藏缺陷 | no｜否 | no｜否 | yes — 22 sweeps, the four-corner walk｜是 — 22 項地毯式掃描與四角走位驗證 |
| Speaks to a non-engineer｜能用非工程師聽得懂的白話溝通 | no｜否 | no｜否 | yes — plain-language contract｜是 — 白話報告條約 |
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 與章節編號保留在報告檔案中）、將整個流程畫成編號站牌、轉譯錯誤內容而非直接引用原文、明確標示每項等待由誰負責及從何時開始卡住。在觸及真實金錢或身分驗證前改用放慢的審慎語氣，且每份報告開頭皆以五行白話總結 —— 什麼是安全的、什麼還不安全、第一步該先做什麼。
Claude Code, as a plugin (recommended)｜推薦透過 Claude Code Plugin 安裝：
claude plugin marketplace add mixocreative/ecommerce-cia
claude plugin install ecommerce-cia@mixocreativeOr 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-ciaOpenAI Codex：
git clone https://github.com/mixocreative/ecommerce-cia ~/.codex/skills/ecommerce-ciaRequirements 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；整體流程會分別呼叫這兩套工具。
/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 還沒串通的專案中啟動。
| File｜檔案 | Purpose｜主要用途 |
|---|---|
SKILL.md |
the runbook: routing, discovery, seven-step protocol, autonomy contract, sweep index, escalation, setup mode, plain-language contract, start menu｜操作手冊：包含路由、探索、七步驟協定、自主權合約、掃描索引、通報機制、新手引導模式、白話報告條約、啟動選單 |
references/sweeps.md |
S1–S22 with methods, gradings and report-line formats｜S1–S22 包含檢驗方法、評分標準與報告單行格式 |
references/doctrine.md, domains.md, theory.md, reporting.md |
audit doctrine, the domain chapters §8–§25, the VSM, finding format and severity｜Audit 原則、領域章節 §8–§25、Viable System Model (VSM)、缺失格式與嚴重程度定義 |
references/evidence.md |
claim tags, authority ladder, the obligation ledger (intent → owner → verifier), unknowns, bounded negatives, contradictions, reverse trace｜結論標記、證據強度階梯、義務帳冊（意圖 → 負責程式 → 驗證）、未知清單、有邊界的「找不到」、矛盾紀錄、反向追蹤 |
references/wiring-walk.md |
feature list vs wiring: three layers, six-lifecycle state map, seven connection questions, faults F1–F7, question banks, traceability matrix, gap register｜功能 vs 串接：三層檢查、六大流程對照圖、每條串接七問、七種故障注入、問題清單、規則追溯矩陣、缺口登記表 |
references/taiwan-adapter.md |
TW-0…TW-14｜TW-0…TW-14 台灣特定條款 |
references/newebpay-onboarding.md, ecpay-onboarding.md, linepay-onboarding.md, payuni-onboarding.md, tappay-onboarding.md |
the five provider guides｜五家金流商的新手上路指南 |
references/jurisdictions.md, global-compliance.md |
EU / Japan / US / UK adapters; terms and privacy across 13 regimes｜歐盟 / 日本 / 美國 / 英國轉接器；跨 13 種法規體系的條款與隱私合規檢查 |
tools/ |
detectors, doc fetchers, probes, callback verifiers, readiness card, error translator｜偵測器、文件抓取工具、探針、Callback 驗證器、準備就緒卡、錯誤碼轉譯器 |
tests/ |
the fixture shop with its answer key, the run book and the run ledger｜附帶解答的測試商店、測試手冊與測試執行帳本 |
- cia: Code Integrity Auditor for any codebase. Finds the bugs that live between two correct functions.
- token-economy-delegation: One router for local Ollama, Codex and Claude. Bulky jobs go to the cheapest worker whose answer can be checked; a failed check escalates. Pairs well with a long audit.
如果它幫你在上線前抓到掉單或庫存 bug，給個 ⭐ 讓更多台灣開發者找到它。If it saved you a lost order, a ⭐ helps the next shop find it.
MIT