昨天，我們整理了這次修改的審查結果與待決事項。接下來如果要把程式交出去，我還得回答：交哪一份？它跑過哪些檢查？該找的人接受了嗎？

前面不是沒有規則。完成條件寫過了，測試跑過了，需要誰接受也討論過了。問題是：下次換一個人提交修改，這些事情還會確實做一次嗎？

今天把其中能執行的部分接成流程，最後留下發布包、版本與檢查結果。發布包就是 dotnet publish 產生的程式與必要檔案，準備部署到測試環境，還不代表已獲准正式上線。本篇實跑本機交付檢查，遠端 CI/CD 則說明接入方式。

前面約好的事，交付時在哪裡執行？

Day 3 我把審查分成三層，Day 4 把查法留下來，Day 13 用它整理修改的接受依據。現在要把這些約定接到每次交付會經過的位置。

這張表是團隊接入的位置圖，不是全數完成的清單。本次實跑涵蓋固定檢查、失敗診斷與發布包驗證；共用 PR 審查與遠端批准還沒有接上。Day 5 的投入紀錄則留作改善依據，不因為少記幾分鐘就擋住交付。

先把本機檢查接到打包之前

回到本篇實跑。共同訂單服務的教學延伸版放在 examples/sdlc-delivery；baseline 保留並行取消缺口，fixed 則把讀取、判斷與寫回放進同一個鎖定範圍。歷史開發原件保留，沒有改寫成這一輪的結果。

把 Day 11 的核心規則測試、Day 12 的整合驗證放進同一個入口，Day 6 約好的完成條件才有固定的檢查位置。deliver.py 負責排好命令、保存每步輸出，失敗就停止：

ci.py 是執行順序的入口；verify-integration.py 會啟動 API 與假通知接收端，實際送請求。加上 --artifact 後，它使用指定的發布包，不重新建置另一份。

其中 routing-selftest 只證明判級程式的自我測試通過，**不是這次 PR 已完成判級，更不是 Owner 已批准。**本機腳本也不會替遠端分支政策背書。

在實驗目錄先執行修正版，名稱使用尚未存在的資料夾名稱：

python deliver.py fixed my-candidate --with-concurrency

本次保存的 candidate-checked 四步都通過：並行驗證有 81 項檢查，從包執行的 Smoke Test 有 10 項。後者檢查啟動後的基本行為，沒有把建置再算一次。結果資料夾留下 report.json、package/ 與 package-manifest.json。

這就是今天交出的東西：一份可啟動的發布包，以及能對上它的檢查結果。

放一份錯的進來，流程會停嗎？

只有成功還不夠。我也用保留缺口的 baseline 跑同一條流程：

python deliver.py baseline my-failure --with-concurrency --diagnose-with-claude

最後一個參數會把限定的教學程式與失敗摘要傳給 Claude 服務，產生模型費用；不加它就只執行本機檢查。

這輪二十張訂單各同時收到八個取消請求，另加 50ms 教學延遲放大競態窗口。既有 CI 通過，但每張單出現八次轉換與八份不同通知，並行檢查失敗。這是刻意放大問題的演練，不能當作線上發生率。

此時流程停止打包，自動把失敗步驟、檢查摘要與兩個限定程式檔交給 Claude。它用 claude -p、空工具表做唯讀文字分析；--safe-mode 避免額外載入個人設定，不等於作業系統沙箱。

它自己把回覆切成三段。先看它怎麼分事實與推論（節錄自 runs/acceptance-auto-01/diagnosis-result.json，推論第 3 點略）：

【事實】直接來自證據
- 轉換次數錯誤：20 張訂單的 *-transitions 全部失敗。每張都是
  requests=8, changed=8, refunds=8。依 BR-04，每張單應只有 1 次轉換。
- 程式碼的讀改寫不是原子操作：store.TryGet → await Task.Delay →
  Cancellation.Cancel → store.Put。OrderStore 的 lock 只各自保護
  Put 和 TryGet，沒有把整段包成一個臨界區。

【推論】尚未驗證
1. 根因很可能是 check-then-act 競態。8 個並行請求都在任何一個 Put
   之前讀到 Cancelled=false，所以 Transitioned() 全部回傳 true。
2. 50 ms 延遲只是放大了既有的窗口，不是缺陷的來源。因此推測
   OC_TEST_DELAY_MS=0 時仍會重現，只是機率較低、次數不固定。
4. 業務影響：實際影響要看下游是否冪等，目前證據無法判斷。

【建議的下一個檢查】
挑一張單，篩出 logs.jsonl 裡 event=cancel 的紀錄，確認是否有 8 筆
result=ok, transitioned=true 且 request_id 各不相同、時間戳落在同一個
約 50 ms 的窗口內。同時對照 /metrics：oc_transitions_total 與
oc_notify_sent_total 應該是 160。

先講清楚時間順序，免得把它的功勞說大：fixed 那一版我在 18:45 就寫好、18:51 跑完四步，這次診斷是四小時後的 22:52 才跑的。它不是指導我修的人，它讀到的只有 baseline 的失敗紀錄。

有價值的是它獨立指到了同一個位置：事實段最後一條講的「store.TryGet → Task.Delay → Cancel → store.Put，lock 只各自保護 Put 和 TryGet」，正是我改掉的那一段。它沒有看到 fixed，也沒有人告訴它答案。

還有一點是我原本沒想清楚的：它不把我設的 50ms 教學延遲當成根因，推論第 2 點明講那只是「放大了既有的窗口」。如果我當時的第一反應是把延遲調小看看會不會變好，那只會讓問題變得偶發、更難查——方向是錯的。

至於推論 2 本身（沒有人為延遲是否仍會重現），本輪沒有驗，不能寫成實測。回覆最後一句是它自己加的：「此診斷未修改、未修復，也未執行任何指令。」

這裡的 Claude 是失敗處理分支，不是放行者：它讀限定輸入、交回分析，不改碼、不批准，也不會因為診斷回來就讓打包繼續。

十種交付情境，該擋的有沒有擋住？

看過一輪成功與失敗，我還想確認：流程是不是只剛好攔住這一種錯？於是另外寫了 verify-delivery-gates.py，先列好十種情境與預期停止位置，再執行。六種應該停止、四種應該繼續，這是測試設計，不是事後挑出來的成功率。

這是一個本機關卡測試套件。它在每種情境複製一份教學程式，真正執行編譯、核心規則、API 整合、打包與啟動檢查，不修改既有實驗。AI 審查狀態與 Owner 批准則使用標示為 fixture 的測試資料：驗的是收到這種狀態後會不會停，不代表 Claude 真的審了十次，或真人真的批准。

結果是 六種停止、四種繼續，十種都與事先的預期一致。其中第六種最值得留下：檔案已經打包完成，程式卻啟動不了。它的 result.json 長這樣：

"steps": [ {"stage":"build","exit":0}, {"stage":"domain","exit":0},
           {"stage":"integration","exit":0}, {"stage":"publish","exit":0},
           {"stage":"smoke","exit":1} ],
"package_created": true,
"ready_for_load": false

package_created 是 true，ready_for_load 是 false。 前四步全綠、包也產出來了，只有啟動那一步紅——如果只看「有沒有產物」就會把它當成可交付。

讀者可以在相同實驗目錄重跑，使用新的名稱：

python verify-delivery-gates.py my-gate-check

expectations.json 保存事先預期；每個子目錄保存實際命令輸出與 result.json，總表在 report.json。套件全部符合預期才回傳 0，所以「六種預期被擋」也算測試成功。它用來驗證關卡，不是拿這個綠燈取代真正修改的 CI。

這輪驗證本機關卡的行為。 第 5 種情境使用批准測試資料，不能當成 Azure DevOps 合併保護的實測結果。

驗過的，就是準備交出去的那一包

修正版的 package-manifest.json 記錄十個檔案的 SHA-256，用來確認後續拿到的是相同位元組。它能協助辨識產物，不能代替可信建置來源與存取控制。

下一篇的負載驗證直接使用這份 candidate-checked/package，啟動前後核對清單，不重新編譯後沿用這次的綠燈。讀者自己重跑時，則把 my-candidate 作為後續命令的發布包名稱。

這份教學服務仍是單一程序、記憶體儲存，沒有正式身分驗證或跨程序交易。原始報告也保留 owner_accepted=false、remote_deployed=false。它是本機檢查通過、可繼續驗證的發布包，不是已獲准正式發布的版本。

接到團隊流程：CI/CD 負責哪一段

上面這些都在我這台機器上。換一個人提交修改，他會不會跑同一套？我在本機跑過測試、又改了幾行才提交，Reviewer 看到「測試通過」，也不知道那是改之前還是改之後的結果。

所以這條入口要接到 CI：由它在 PR 更新時針對這次版本執行檢查，把結果連回對應的提交，讓接手的人看得到。官方 Playbook 把 PR Review、Hook 與 CI/CD 都放在 Deploy 一起討論，提醒的正是這件事——交付不只要程式能啟動，還要知道前面的約定由誰執行、誰能讓它往下走。Anthropic Playbook

以團隊使用的 Azure DevOps 為例，接入後應該長這樣（以下是目標流程，本篇沒有建立遠端 Pipeline）：

條件未滿足就停止；工具、Claude 與 Owner 各有位置。

接到 Azure DevOps 時，在目標分支設定 Build validation，讓 PR 更新後自動執行驗證，再要求必要檢查與指定 Reviewer 批准。檢查失敗或批准未齊，就不能正常完成合併。**Day 13 留給 Owner 的決定，在這裡成為合併前的條件。**合併後再由 Pipeline 打包、部署到測試環境。

這裡沿用 Day 3 的三層分工，以及 Day 4 留下的共用查核方法。前面出現的幾份文件，各有自己的工作：

• CLAUDE.md：專案知識與開發慣例，讓 Claude 理解既有約定。
• REVIEW.md：這次審查要查什麼、哪些問題重要。自訂審查入口必須明確讀入，不能假設檔案存在就有效。
• Hook：在 Claude 執行特定動作時檢查或阻擋。它只涵蓋有配置並觸發它的操作，不能代替遠端合併保護。
• CI 與分支政策：執行固定檢查，並決定缺少必要結果或批准時能不能合併。

審查依據接回 Day 7 的專案知識、Day 9 釐清的需求，以及 Day 10 的設計與實作計畫。訂單案例的 REVIEW.md 可以先寫得很小；下面是接入範例，並非本次診斷已使用的政策：

# 訂單取消審查政策
- 對照 spec.md 與 plan.md，指出沒有需求依據的行為變更。
- 查取消條件、重複請求與通知副作用；每項發現附位置與依據。
- 將退款與取消規則的改動送給 Domain Owner，不自行批准。
- 將行為錯誤、資料外洩與違反政策列為重要問題；未知另列。
- 不重複報告 CI 已檢查的格式問題，不把測試通過當成業務接受。

AI 交回的是發現與建議，不會因為寫了「重要」就自動擋住 PR。團隊還要定義哪些結果阻擋、哪些交人判斷，以及必要審查不可用時如何處理。這些條件要接到實際檢查狀態與保護規則。

寫下規則之後，還要指定讀取它的入口，以及不符合時停止的位置。

回到一開始：規則要有執行的位置

• Day 3 的三層分工，到了交付流程要分清楚：工具執行檢查、AI 協助查核、人接受必要決策。
• 規則文件留下查法；CI 與保護機制負責在條件未滿足時停止。本次十種本機情境，六種停止、四種繼續，都符合事先預期。
• 通過後留下發布包與檢查結果，後續使用同一份產物，才能知道自己到底驗了哪個版本。

打包完成就可以上線了嗎 ? 明天來聊聊打包後上線前還需要注意什麼 :)

參考資料：

• Anthropic：The AI-Native SDLC Playbook：Deploy 中的 PR 審查、Hook 與 CI/CD 分工；本文遠端流程與政策片段是接入設計。
• Microsoft：Azure Repos Git 的 Pipeline 觸發與 PR 驗證：PR Build validation 的設定位置。
• 十種情境原件： sdlc-delivery/runs/gates-20260928-01 保存預期、逐步命令與總表；六種停止、四種繼續。審查及批准是測試資料，並未呼叫模型或取得真人批准。
• 本文實作紀錄： sdlc-delivery/runs/acceptance-auto-01 保存限定輸入、模型回覆與失敗狀態；acceptance-auto-01-concurrency 保存負向檢查；candidate-checked 保存四步通過的發布包與清單。
• 資料界線： 全部是本機教學實跑。未完成遠端 PR／CI/CD 接入、Owner 接受或正式發布；未量得人工省時。費用與時間來自 CLI JSON，不是人的投入。
• 操作附件保留重跑命令與完整診斷。系列 repo尚待同步本次新增包，不能把既有公開檔案當作這輪原件。