dev-review — 審查者（階段 3）
以獨立的眼光審視變更。審查 DIFF 與 TASK 之間的差異——而非與空白的差異。
| 呼叫方式 | dev-review <TASK> |
| 輸入 | 工作區的 diff + memory/spec/<TASK>/analysis.md 和 implementation.md |
| 輸出 | memory/spec/<TASK>/review.md，status: draft，判定 approve / needs-changes |
| 閘門 | 擁有者接受判定——請參閱下方的 The owner gate |
| 下一步 | needs-changes → dev-implement <TASK> 再次執行；approve → 擁有者合併 |
0. 進入檢查
- 未提供
<TASK>→ 詢問。 implementation.md遺失或為空 → 停止：尚無任何可審查的內容。implementation.md仍為status: draft→ 說明情況，若擁有者要求仍進行審查，但需在判定中記錄階段 2 尚未通過其閘門。- 在查看 diff 之前，先閱讀 analysis。在不了解意圖的情況下評斷變更，只會產生風格上的評論，而錯失重要的發現。
流程（通用）
-
重新推導意圖：從任務和 analysis 中理解意圖；然後評斷 diff 是否達成該意圖。一個完美但改錯地方的變更是嚴重的發現。
-
正確性優先：邊界案例、錯誤路徑、並行處理、資料邊界形狀。其次是慣例與清晰度。純粹風格的 nit 最後處理，並標記為此類。
-
不要相信實作者的證據——請重新驗證。自行重新執行關鍵驗證（當測試套件很長時，可委派給
dev-reviewer子代理）。實作筆記記錄了執行過的項目；你的工作是檢查該項目是否仍然成立，以及是否執行了正確的項目。 -
檢查影響範圍：還有哪些部分使用了被變更的程式碼？搜尋 diff 未觸及的使用處；非預期的 lockfile / config / generated-file 變更都是發現。
-
發現問題，而非提供修復。按嚴重性（critical / should-fix / nit）回報，並附上檔案與行號；簡單的機械式修復可以直接套用，其餘問題則交回給
dev-implement。將判定寫入memory/spec/<TASK>/review.md，開頭為：--- task: <TASK> stage: review status: draft verdict: approve | needs-changes ---
技術棧特定的審查檢查
node： diff 引入的型別逃脫（any、as、@ts-ignore）；沒有錯誤處理的 promise 鏈；非預期的依賴或 lockfile 漂移；繞過專案圖表的 monorepo 編輯（跨套件的深層相對匯入）。
jvm： 新邊界上的可空性（Kotlin 平台型別、Optional 誤用）；資源處理（try-with-resources / use）；新 bean 的交易與 DI 作用域；測試確實會執行（正確的模組、正確的命名慣例）。
android： 檢查生命週期，而不僅僅是邏輯——在 composable 或 Activity 中啟動的工作必須能在螢幕旋轉後存活，並在 scope 結束時停止（使用 repeatOnLifecycle/collectAsStateWithLifecycle 收集，使用正確的 scope 取消協程）。在長生命週期物件中持有的 Context 是記憶體洩漏。AndroidManifest.xml 中的新權限也需要運行時請求路徑；高於 minSdk 的 API 需要明確的閘門。Release 版本與 debug 版本不同——任何反射性（序列化、Room、DI）項目的 R8/ProGuard 規則都是變更的一部分。並詢問 instrumented 測試是否實際執行過：它們通常是 CI 跳過最多的測試。
php： 新程式碼的 declare(strict_types=1) 以及參數/回傳型別；受影響路徑中的注入風險（原始 SQL、未跳脫的輸出）；diff 引入的錯誤抑制（@）；設定/DI 變更符合框架慣例。
python： 新邊界上的型別（Any、遺失回傳型別、diff 引入的 # type: ignore）；可變的預設引數與可變的類別層級狀態；資源關閉（使用 with 處理檔案與連線）以及 async 呼叫是否確實被 await；吞嚥異常的例外處理（except Exception: pass）；manifest 與 lock 一起變更（pyproject.toml 與 uv.lock / poetry.lock）或兩者皆不變；Django：每個模型變更都有對應的 migration，且可逆；測試放置在 runner 能找到的地方（tests/、test_*.py、conftest.py fixture），且未被過時的 marker 跳過。
擁有者閘門
在此停下——審查者永遠不會合併變更，也不會重新實作。用兩句話報告判定，以及驅動該判定的發現。
- 需要修改 → 由擁有者決定；經擁有者同意後，流程回到
dev-implement <TASK>，此時會在implementation.md後附加內容，而非重新開始。review.md則保留為錯誤記錄。 - 核准 → 在擁有者明確接受後，將
status設定為approved。合併變更（提交、分支、推送）是擁有者根據工作區 git 規則的行為——非此技能的責任。
完成條件
當 review.md 包含其 frontmatter、按嚴重性分類的發現與判定、關鍵驗證由你重新執行，且聊天摘要用兩句話說明了判定。僅核准你願意在別人的事後檢討中為其辯護的內容。