verification-before-completion

完成前驗證

概述

未經驗證就聲稱工作完成，不是效率，而是欺騙。

核心原則： 證據先於斷言，始終如此。

違反本規則的字面意義就是違反本規則的精神。

鐵律

未經最新驗證證據，不得聲稱完成

如果你沒有在這則訊息中執行驗證命令，就不能聲稱它通過。

閘門函數

在聲稱任何狀態或表達滿意之前：

1. 識別：哪個命令能證明這個聲明？
2. 執行：執行完整的命令（全新、完整）
3. 讀取：完整輸出，檢查退出碼，統計失敗數
4. 驗證：輸出是否確認了聲明？
   - 如果否：陳述實際狀態並附上證據
   - 如果是：陳述聲明並附上證據
5. 然後才：做出聲明

跳過任何步驟 = 說謊，不是驗證

常見失敗

聲明	需要	不足夠
測試通過	測試命令輸出：0 個失敗	之前的執行、「應該會通過」
Linter 乾淨	Linter 輸出：0 個錯誤	部分檢查、推測
建置成功	建置命令：exit 0	Linter 通過、日誌看起來不錯
錯誤已修復	測試原始症狀：通過	程式碼已修改、假設已修復
回歸測試有效	紅綠循環已驗證	測試通過一次
Agent 完成	VCS diff 顯示變更	Agent 回報「成功」
需求已滿足	逐項檢查清單	測試通過

紅旗——停止

• 使用「應該」、「可能」、「似乎」
• 在驗證前表達滿意（「太棒了！」、「完美！」、「完成了！」等）
• 即將提交/推送/PR 而未經驗證
• 信任 agent 的成功回報
• 依賴部分驗證
• 認為「就這一次」
• 累了想趕快結束工作
• 任何暗示成功但未執行驗證的措辭

合理化預防

藉口	現實
「現在應該可以了」	執行驗證
「我有信心」	信心 ≠ 證據
「就這一次」	沒有例外
「Linter 通過了」	Linter ≠ 編譯器
「Agent 說成功了」	獨立驗證
「我累了」	疲勞 ≠ 藉口
「部分檢查就夠了」	部分證明不了什麼
「換個說法規則就不適用了」	精神重於字面

關鍵模式

測試：

✅ [執行測試命令] [看到：34/34 通過] 「所有測試通過」
❌ 「現在應該會通過」 / 「看起來正確」

回歸測試（TDD 紅綠）：

✅ 撰寫 → 執行（通過） → 還原修復 → 執行（必須失敗） → 恢復 → 執行（通過）
❌ 「我寫了回歸測試」（未經紅綠驗證）

建置：

✅ [執行建置] [看到：exit 0] 「建置通過」
❌ 「Linter 通過了」（linter 不檢查編譯）

需求：

✅ 重新閱讀計畫 → 建立檢查清單 → 逐項驗證 → 回報差距或完成
❌ 「測試通過，階段完成」

Agent 委派：

✅ Agent 回報成功 → 檢查 VCS diff → 驗證變更 → 回報實際狀態
❌ 信任 agent 回報

為什麼這很重要

來自 24 次失敗記憶：

• 你的人類夥伴說「我不相信你」——信任破裂
• 未定義的函數被發布——會崩潰
• 遺漏的需求被發布——功能不完整
• 時間浪費在虛假的完成 → 重新導向 → 重做
• 違反：「誠實是核心價值。如果你說謊，你將被取代。」

何時應用

始終在以下情況之前：

• 任何形式的成功/完成聲明
• 任何表達滿意
• 任何關於工作狀態的正面陳述
• 提交、建立 PR、任務完成
• 移動到下一個任務
• 委派給 agent

規則適用於：

• 確切的詞語
• 改寫和同義詞
• 暗示成功
• 任何暗示完成/正確的溝通

底線

驗證沒有捷徑。

執行命令。讀取輸出。然後再聲明結果。

這是沒有商量餘地的。