verify

verify：完成前驗證

目的：杜絕「假完成」。每一個 ✅ 都必須有貼出來的指令與輸出當證據；沒有證據就不是 ✅。

執行步驟（依序，不可跳過）

1. 複述完成判準

用一句話寫出這個任務原本的完成判準（來自 tasks/todo.md 或使用者的原話）。

• 如果寫不出具體判準 → 停，先回去確認任務範圍，不要繼續。

2. 跑現有測試

• 先找測試指令：依序檢查 package.json 的 scripts、Makefile、pyproject.toml、CI 設定檔（.github/workflows/）。
• 跑它，貼出輸出最後 10 行。
• 找不到任何測試 → 明確寫「本專案無測試」，不要假裝跑過。
• 測試失敗 → 不是完成。回去修，或如實回報失敗內容。

3. 手動走 happy path

• 用真實指令實際執行改動的功能（curl、跑 script、開頁面），不是只看程式碼「應該會動」。
• 貼出實際輸出。

4. 走至少 2 個邊界情況

從這個清單挑與改動相關的：空輸入、超長輸入、不存在的檔案/ID、權限不足、重複執行（冪等性）、並發、非 ASCII 字元。

• 每個邊界情況：一行寫「輸入 → 預期 → 實際」。

5. 檢查沒有新的警告或錯誤

• 重看步驟 2–4 的輸出有無 warning / error / deprecation。
• 有 log 檔就 tail 一下。

6. 審視 diff

• git diff --stat（或比對改動清單），確認：
  • 沒有除錯碼（console.log、print、註解掉的程式碼）
  • 沒有與任務無關的檔案被改到
  • diff 大小與任務規模相稱（小任務出現大 diff = 警訊，回報它）

7. Staff engineer 之問

自問：「一位資深工程師會核准這個 PR 嗎？」有任何遲疑 → 把遲疑的點寫進回報，不要吞掉。

回報格式（固定模板）

## 驗證報告
- 完成判準：<一句話>
- 測試：✅/❌/無測試 — <指令> → <輸出尾行>
- Happy path：✅/❌ — <指令> → <實際輸出>
- 邊界情況：
  - <輸入> → 預期 <X> → 實際 <Y> ✅/❌
  - <輸入> → 預期 <X> → 實際 <Y> ✅/❌
- 新警告/錯誤：無 / <內容>
- Diff：<N 檔 / M 行>，無除錯碼、無無關改動
- 未驗證項目：<誠實列出，說明原因>
- 已驗證: <hard-rules #3；本輪未引用使用者陳述的程式碼事實則寫「不適用」>
- 範圍外發現: <hard-rules #4；記到 tasks/todo.md 的項目，或「無」>
- AUTH: 使用者說「<原話>」<judgment.md §1；本輪無不可逆動作則寫「不適用」>

上面最後三行是逐字必填欄位，不是可省略的過程細節（reporting.md §2 末段）。

鐵則

• 任何一項標 ⚠️ 未驗證都可以，但用 ✅ 包裝沒驗證過的項目是最嚴重的違規。
• 這份報告是給使用者的回報主體，不是附錄。