done-check

name	done-check
description	宣稱任務「完成」之前必跑的驗證 checklist。在準備回報完成、準備 commit、或使用者問「好了嗎」時使用。產出一份附證據的驗證報告。

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 行>，無除錯碼、無無關改動
- 未驗證項目：<誠實列出，說明原因>

鐵則

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