dev-review — 审查者（阶段 3）
用独立的眼光审视变更。根据任务而非空泛标准来审查差异。
| 调用 | dev-review <TASK> |
| 输入 | 工作树差异 + memory/spec/<TASK>/analysis.md 和 implementation.md |
| 输出 | memory/spec/<TASK>/review.md，status: draft，裁决：批准 / 需要修改 |
| 门控 | 所有者接受裁决 — 见下方的 所有者门控 |
| 下一步 | 需要修改 → 再次调用 dev-implement <TASK>；批准 → 所有者合并变更 |
0. 入口检查
- 未提供
<TASK>→ 询问。 implementation.md缺失或为空 → 停止：尚无内容可供审查。implementation.md仍是status: draft→ 说明情况，但如果所有者要求仍可审查，但在裁决中记录阶段 2 未通过其门控。- 在查看差异前先阅读分析文档。不了解意图就评判变更只会产生风格评论，而错过重要发现。
流程（通用）
-
重新推导意图：从任务和分析中理解意图；然后判断差异是否实现了该意图。一个放到错误地方的漂亮变更是严重的发现。
-
正确性优先：边界情况、错误路径、并发、边界处的数据结构。然后是约定和清晰度。仅涉及风格的琐事放在最后并明确标记。
-
不要相信实施者的证据 — 自行复现。 重新运行决定性验证（当测试集较长时，委托给
dev-reviewer子代理）。实施说明记录了运行的内容；你的工作是检查这些内容仍然成立，并且运行了正确的内容。 -
检查影响范围：还有哪些代码使用了被修改的代码？搜索差异未触及的使用点；意外的锁文件、配置文件或生成文件更改都是发现。
-
报告发现，而非修复。 按严重程度（严重 / 应修复 / 琐事）报告，附带文件和行号；琐碎的机械修复可以直接应用，其余一律返回给
dev-implement。将裁决写入memory/spec/<TASK>/review.md，开头为：--- task: <TASK> stage: review status: draft verdict: approve | needs-changes ---
特定技术栈的审查检查
node: 差异引入的类型逃逸（any、as、@ts-ignore）；无错误处理的 Promise 链；无意的依赖或锁文件漂移；绕过项目图表的单体库编辑（跨包的深层相对导入）。
jvm: 新边界处的空值处理（Kotlin 平台类型、Optional 误用）；资源处理（try-with-resources / use）；新 Bean 的事务和 DI 作用域；测试是否实际运行（正确的模块、正确的命名约定）。
android: 检查生命周期，而不仅仅是逻辑 — 在 Composable 或 Activity 中启动的工作必须能应对旋转，并在作用域死亡时停止（在 repeatOnLifecycle/collectAsStateWithLifecycle 中收集，用正确的作用域取消协程）。长时间存活对象中持有的 Context 是内存泄漏。AndroidManifest.xml 中的新权限也需要运行时请求路径；高于 minSdk 的 API 需要显式门控。发布版本与调试版本不同 — 任何反射性内容（序列化、Room、DI）的 R8/ProGuard 规则都是变更的一部分。另外询问仪器测试是否实际运行过：它们是 CI 最常跳过的测试。
php: 新代码上的 declare(strict_types=1) 以及参数/返回类型；触及路径中的注入面（原始 SQL、未转义的输出）；差异引入的错误抑制（@）；配置/DI 变更与框架约定一致。
python: 新边界处的类型注解（Any、缺少返回类型、# type: ignore）；可变默认参数和可变类级状态；资源关闭（文件和连接的 with 语句）以及 async 调用是否实际被 await；吞掉异常的异常处理（except Exception: pass）；清单和锁文件同时更改（pyproject.toml 与 uv.lock / poetry.lock），或两者都不改；Django：每个模型变更都有可逆的迁移；测试放在运行器能找到的地方（tests/、test_*.py、conftest.py fixture），且未被过时的标记跳过。
所有者门控
在此停止 — 审查者从不合并变更也从不重新实施变更。用两句话报告裁决及其驱动的发现。
- 需要修改 → 所有者决定；经其确认后，循环返回
dev-implement <TASK>，该命令会追加到implementation.md而非重新开始。review.md保留作为错误记录。 - 批准 → 经所有者明确接受后，设置
status: approved。合并变更（提交、分支、推送）是所有者根据工作区 Git 法则执行的操作 — 而非此技能的职责。
完成条件
review.md 包含其前置数据和带有按严重程度分类的发现的裁决，决定性验证由你重新运行，聊天摘要用两句话给出裁决。仅批准那些你愿意在别人事后分析中捍卫的内容。