kopp0510 Verification Gate — 完成前驗證閘門
借鑑 obra/superpowers 的 verification-before-completion 概念。
鐵律
執行命令 → 讀取輸出 → 然後才能宣稱結果。 沒有新鮮證據就不能宣稱完成。
「新鮮」= 本次工作中、最後一次修改之後實際執行並觀察到的結果。 「之前跑過」「應該可以」「改動很小」都不算。
驗證流程
識別驗證項目 — 依宣稱類型對照：
宣稱 必要驗證 測試通過 執行測試指令，讀完整輸出（通過/失敗/跳過數，不只看 exit code） 建置成功 執行 build，確認零錯誤、輸出檔案存在 bug 已修復 重現原始問題步驟，確認不再發生 功能已實作 端對端執行該功能（真實 API / 瀏覽器，同 8 步迴圈步驟 5） 沒有迴歸 執行完整相關測試套件，確認無新增失敗 lint / 型別正確 執行 linter / type checker，確認零錯誤 subagent 回報完成 讀 subagent 改的檔案 + 親自重跑它聲稱通過的驗證 執行並讀取 — 等命令完成，逐行讀輸出，記錄警告與異常
裁決 — 全過 → 附證據宣稱完成；任何失敗 → 停止、修復、從頭重驗
宣稱完成（附證據） — 報告格式：項目 / 命令 / 結果 / 證據摘要，逐列列出
修 bug 時的迴歸驗證模式：git stash && <測試>（看到失敗）→ git stash pop && <測試>（看到通過）。
紅旗 — 看到即停下補驗證
- 「應該」「大概」「我覺得」等不確定語氣出現在完成宣稱裡
- 宣稱完成但沒有貼出任何命令輸出
- 引用修改前的測試結果
- 「手動驗證過了」但沒說步驟
- 未經確認就採信 subagent 的回報
合理化防範
| 藉口 | 現實 |
|---|---|
| 「這只是重構，不影響行為」 | 重構是最常引入 bug 的操作之一 |
| 「型別系統已經保證了」 | 型別不能保證運行時行為 |
| 「改動太小」 | 小改動也能破壞系統 |
| 「我很確定」 | 確定程度不能替代證據 |
| 「時間不夠 / 測試太慢」 | debug 花的時間更多；至少跑相關子集 |
| 「本地跑得好好的」 | 環境差異存在，CI 也要過 |
與原生 /goal 的關係
互補：/goal（Claude Code ≥ 2.1.139）負責「要不要再跑一輪」；本閘門負責「這一輪能不能
說完成」。用 /goal 自主收斂時，鐵律仍適用於每一輪 — 評估器讀到的「完成」必須是
執行命令、讀取輸出後的結果。
不適用
純討論/設計（沒有完成宣稱）、文件撰寫、探索性調查。