--- name: review description: 当用户要求对明确的需求、设计、计划、代码、diff、MR 或交付物作独立冷读，或需要判断它能否继续合并、测试或交付时使用。锁定准确对象与 baseline，检查完整影响面，独立证伪候选问题，并以证据给出裁决。直接实现、只有解释、没有可审查对象，或低风险小改没有独立审查价值时不触发。 --- # review ## 从作者之外重建判断 评审不是替作者润色，也不是复述已有结论。先确认被审查对象的准确版本、工作树状态、任务承诺和比较 baseline；作者摘要、测试名称、先前评审与多数意见都只是线索。对象或基线的缺口会改变结论时，不猜一个方便的版本继续。 ## 看完整影响面，按风险分配深度 从原始对象建立变化面：所有变更文件或章节，以及真正受影响的调用者、契约、权限、状态、数据、异步过程和下游消费者。每个实质表面都应被检查、以证据判定无关，或留下具名证据缺口；完整覆盖不等于平均用力，风险决定深度。发现第一个问题后继续看完对象。 公共接口、信任边界、I/O 与恢复、热路径或高风险组合实际存在时，分别深入兼容、安全、可靠性、性能与组合风险；不适用必须来自对象证据，不能用作者保证或“通常不会发生”代替。 完整影响面也包括变化自身的纪律与项目承担：每个 hunk 是否可追溯到当前承诺，是否夹带 scope 外改动、重复权威来源、绕过项目标准，测试是否真正约束新增行为与回归面，注释、死代码或抽象是否仍表达真实结构；结构是否落在正确的架构边界，新增公共表面、所有权、兼容、运维与长期维护成本由谁承担。更小不自动更诚实，更整齐也不足以支付这些成本。 变化评审只把本次引入或显著放大的问题归给当前对象。既有问题仅在用户要求整体审计，或它会使当前裁决失真时展开，并明确来源。 ## Finding 必须走通证据链 报告的问题必须能够从具体输入、状态、调用者或代码结构，走过实际文件、接口与状态转换，到达错误结果、破坏的承诺或具体长期成本，并给出可打开的代码、命令、日志、规则或运行结果。处理方向要说明正确修复落在哪里、是否属于当前对象，以及仍未确认什么。 问题优先级由现实影响、触发可达性和恢复代价决定：`P0` 只用于广泛、灾难性或不可逆的发布阻断，`P1` 是现实可达的重要失败，`P2` 是普通但具体、作者知道后应该修的问题，`P3` 只保留低影响但价值明确的改进。优先级不表示证据强弱、scope 关系或处理方式，不能包装猜测，也不能掩盖真实阻断问题。风格偏好、理论可能和没有价格的“应该重构”不是 finding。 报告前把每个候选重新当作未证实假设。主动寻找上游门、类型与权限保证、调用契约、补偿机制和相反运行证据；依赖外部语义时查一手文档、源码或可重放结果。被推翻的候选删除；部分成立的候选修正其机制、影响和优先级；缺少证据的保留为具名缺口。失败于证伪不等于已经确认。 ## 给出一个诚实裁决 最终裁决只有： - `approve`：没有必须先修的问题或未决责任人决定，关键证据足够； - `request_changes`：存在已经独立走通、且当前对象前进前必须解决的问题； - `needs_more_evidence`：具名证据缺口可能改变能否前进； - `blocked`：准确对象不可用或审查已被取消。 需要用户接受风险、改变产品承诺或扩大范围时，交给责任人或 `shape`；决定成立前不能与 `approve` 并存。未检查的表面和不稳定证据也不能被沉默写成批准。 ## 保持作者与裁决分离 默认不直接修改自己正在批准的对象。用户要求评审后修复时，先保存评审结论，再进入 `dev`；随后复核原 finding、受影响路径和新 diff，而不是把作者信心当成关闭证据。 简单评审直接在对话中让 findings 先行，再给裁决、边界和剩余风险。当前任务有 `context.md`，且结论需要保存或交接时，写 `/review/review.md`，以 [review.demo.md](references/templates/review.demo.md) 为唯一结构来源，并更新 Current Artifacts。 完成时，对象与 baseline 明确，完整影响面有去向，所有报告的问题都经过独立复核，证据缺口没有伪装成 finding 或 `approve`，裁决与真实证据一致。