verification-gate

name	verification-gate
description	完成前驗證閘門，強制要求提供新鮮的驗證證據才能宣稱完成。當 agent 或使用者聲稱「完成了」「修好了」「測試通過」「done」「fixed」但未附驗證證據時自動啟用。
allowed-tools	Read, Bash, Grep, Glob

Verification Gate — 完成前驗證閘門

借鑑 obra/superpowers 的 verification-before-completion 概念。

鐵律

執行命令 → 讀取輸出 → 然後才能宣稱結果。 沒有新鮮證據就不能宣稱完成。

「新鮮」= 本次工作中、最後一次修改之後實際執行並觀察到的結果。 「之前跑過」「應該可以」「改動很小」都不算。

驗證流程

1. 識別驗證項目 — 依宣稱類型對照：

   宣稱	必要驗證
   測試通過	執行測試指令，讀完整輸出（通過/失敗/跳過數，不只看 exit code）
   建置成功	執行 build，確認零錯誤、輸出檔案存在
   bug 已修復	重現原始問題步驟，確認不再發生
   功能已實作	端對端執行該功能（真實 API / 瀏覽器，同 8 步迴圈步驟 5）
   沒有迴歸	執行完整相關測試套件，確認無新增失敗
   lint / 型別正確	執行 linter / type checker，確認零錯誤
   subagent 回報完成	讀 subagent 改的檔案 + 親自重跑它聲稱通過的驗證

2. 執行並讀取 — 等命令完成，逐行讀輸出，記錄警告與異常

3. 裁決 — 全過 → 附證據宣稱完成；任何失敗 → 停止、修復、從頭重驗

4. 宣稱完成（附證據） — 報告格式：項目 / 命令 / 結果 / 證據摘要，逐列列出

修 bug 時的迴歸驗證模式：git stash && <測試>（看到失敗）→ git stash pop && <測試>（看到通過）。

紅旗 — 看到即停下補驗證

• 「應該」「大概」「我覺得」等不確定語氣出現在完成宣稱裡
• 宣稱完成但沒有貼出任何命令輸出
• 引用修改前的測試結果
• 「手動驗證過了」但沒說步驟
• 未經確認就採信 subagent 的回報

合理化防範

藉口	現實
「這只是重構，不影響行為」	重構是最常引入 bug 的操作之一
「型別系統已經保證了」	型別不能保證運行時行為
「改動太小」	小改動也能破壞系統
「我很確定」	確定程度不能替代證據
「時間不夠 / 測試太慢」	debug 花的時間更多；至少跑相關子集
「本地跑得好好的」	環境差異存在，CI 也要過

與原生 /goal 的關係

互補：/goal（Claude Code ≥ 2.1.139）負責「要不要再跑一輪」；本閘門負責「這一輪能不能 說完成」。用 /goal 自主收斂時，鐵律仍適用於每一輪 — 評估器讀到的「完成」必須是 執行命令、讀取輸出後的結果。

不適用

純討論/設計（沒有完成宣稱）、文件撰寫、探索性調查。