curtischoutw done-check：完成前驗證
目的：杜絕「假完成」。每一個 ✅ 都必須有貼出來的指令與輸出當證據；沒有證據就不是 ✅。
執行步驟（依序，不可跳過）
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 末段）。
鐵則
- 任何一項標 ⚠️ 未驗證都可以，但用 ✅ 包裝沒驗證過的項目是最嚴重的違規。
- 這份報告是給使用者的回報主體，不是附錄。