git:20260912.9ee3372 to git:20260912.708b336

3 added, 1 removed. Audit A to A.

---
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 -u && <測試>`(看到失敗)→ `git stash pop && <測試>`(看到通過)。
**`-u` 不可省**:裸 `git stash` 不收未追蹤的新檔,修復若是「新增一個檔案」就整個沒被藏起來,
第一步照樣通過 —— 得到的是假的 PASS。更糟的是堆疊裡本來就有舊 stash 時:`git stash pop`
會把**不相干的那筆**彈回工作目錄,整條鏈 exit 0 全綠,還順手污染了工作目錄(實測)。
- 堆疊空的時候 `pop` 會 exit 1,這種失敗反而是大聲的。
+ 真正讓整條鏈靜靜變綠的是這一半:**`git stash -u` 在沒東西可存時 exit 0**
+ (只印「沒有要儲存的本機修改」),所以 `&&` 不會斷,後面的 `pop` 把舊 stash 彈出來也 exit 0。
+ 反過來,堆疊**空的**時候 `pop` 才會 exit 1(「未發現貯存條目。」)—— 那種失敗是大聲的。
另:這個模式只在修復**還沒 commit** 時成立 —— 8 步迴圈步驟 2 已經 commit 之後,
stash 無物可存,要改用 `git stash` 以外的方式(例如 `git revert --no-commit` 或在暫存 worktree 比對)。
## 紅旗 — 看到即停下補驗證
- 「應該」「大概」「我覺得」等不確定語氣出現在完成宣稱裡
- 宣稱完成但沒有貼出任何命令輸出
- 引用修改**前**的測試結果
- 「手動驗證過了」但沒說步驟
- 未經確認就採信 subagent 的回報
## 合理化防範
| 藉口 | 現實 |
|---------|------|
| 「這只是重構,不影響行為」 | 重構是最常引入 bug 的操作之一 |
| 「型別系統已經保證了」 | 型別不能保證運行時行為 |
| 「改動太小」 | 小改動也能破壞系統 |
| 「我很確定」 | 確定程度不能替代證據 |
| 「時間不夠 / 測試太慢」 | debug 花的時間更多;至少跑相關子集 |
| 「本地跑得好好的」 | 環境差異存在,CI 也要過 |
## 與原生 `/goal` 的關係
互補:`/goal`(Claude Code ≥ 2.1.139)負責「要不要再跑一輪」;本閘門負責「這一輪能不能
說完成」。用 `/goal` 自主收斂時,鐵律仍適用於每一輪 — 評估器讀到的「完成」必須是
執行命令、讀取輸出後的結果。
## 不適用
純討論/設計(沒有完成宣稱)、文件撰寫、探索性調查。