review-change

审查变更

以独立审查者的身份审查差异，而不是作为实现者为工作辩护。

流程

1. 确定审查范围

确定要审查的固定点或差异：

• 用户提供的分支、提交、标签或合并基点。
• 如果未提供固定点，则审查当前工作树。
• 补丁文件或粘贴的差异。

如果范围不明确，请先询问固定点，再进行审查。

2. 收集审查所需信息

只收集审查者需要的上下文：

• 差异。
• 任务说明、计划、问题描述、PRD 或用户请求（如有）。
• 相关测试和验证输出。
• 相关时，参考项目规范或附近的惯例。

不要把实现者的解释当作证据。请根据差异和源代码进行核实。

3. 选择审查视角

分别通过不同视角进行审查，每个视角由一位审查者负责。阅读 lenses.md，了解每个视角要回答的问题、所需输入、排除项和必需证据。

• 单个切片： 正确性和测试质量。
• 高风险切片（公共契约、持久化数据、共享模块、生产路径）或已完成的功能： 增加设计契合度和简洁性。对于已完成的功能，应针对整个分支进行设计契合度审查，因为各自契合的切片组合后可能逐渐偏离。
• 安全性： 只要差异涉及身份验证、授权、不可信输入或机密信息，就进行安全性审查。

用户或计划可能会指定不同的视角；请遵循其要求。

4. 在全新上下文中运行审查者

每个视角并行启动一个子代理，避免审查者受到实现者解释或其他视角的影响。每份说明都应包含差异范围、计划或请求、来自 lenses.md 的视角定义，以及下方的评级规则。要求他们报告发现，而不是提供安慰：

Review this change through the <lens> lens only. Report findings inside that lens, each with file and line, the concrete trigger, and the evidence the lens requires. Mark anything you could not back with that evidence as unconfirmed. Rate each finding with the supplied "Rate Blocker or Hardening" rules. Do not summarize the change.

要求 TDD 时，测试质量审查者还要检查可用的实现前 RED 阶段证据；如果缺少证据，应报告为未知，而不是根据最终差异推断。

如果无法使用子代理，则逐个运行各个视角，并在每次审查时从头重新阅读差异。

5. 确认后再报告

合并不同视角中的重复发现。然后使用 /verification-evidence 亲自确认每个候选阻断级问题：尽可能重新运行复现步骤，否则逐行追溯其路径。未能通过确认的问题不予报告；用一行说明其数量（“忽略了 N 个未确认的问题”），以便用户可以索取这些问题。

如果验证或 CI 失败，请区分由差异导致的失败与环境或基础设施导致的失败。

6. 判定为阻断项或加固项

仅分两个级别：阻断项（合并前必须修复）和 加固项（记录在剩余风险中，不要求修复）。加固项还必须有一个具体触发条件——谁在什么实际条件下执行什么操作。“理论上可能发生竞争”或“如果有人以后……”都不是触发条件；应删除该项。

用一句话说明触发条件，且只能使用产品支持的操作。每次运行该路径都会出现的缺陷，无需进一步分析可达性即为阻断项，但须符合下文的影响门槛；无人能到达的路径不算路径。本节其余内容仅适用于触发条件取决于顺序、偶然情况或特定输入的情形。

对于这类情况，只有在无人刻意安排时就会出现的触发条件，才属于阻断项；你必须指出支持这一判断的证据：所依据的流量模式、部署模型或操作，以及你在仓库、配置或文档中的具体发现位置。仅指出某项操作通常受支持，并不构成证据；几乎每个产品都会部署、重启、重试和逐出缓存。基于假设的部署事实应判为加固项，并将尚未解决的问题列入待解决问题。

影响决定两端的判定。触发条件会自行出现，但最坏结果仅为外观问题或可恢复问题时，应判为加固项。需要刻意安排才能触发，但会跨越权限边界或造成不可恢复的数据丢失时，应判为阻断项。

如果仓库、配置或文档将不可信方纳入威胁模型——例如存在暴露的路由、身份验证边界或有文档说明的租户隔离——那么该方就是正常参与者：构造输入属于其正常操作，唯一需要判断的是他们能否凭实际可获得的权限访问该路径。如果没有任何内容能证明此类暴露，则应判为加固项，并将相关问题列入待解决问题。

可测试性不是筛选标准。只要审查者有决心，几乎任何场景都能通过模拟构造出失败测试，包括没人会遇到的场景。

应针对可达性、影响和证据，分别判定每项发现。所有发现的评级都可以相同；绝不要为了凑出不同等级而提升或降低某项评级。

7. 优先报告发现

“发现”部分仅列阻断项；加固项列入“剩余风险”。每项阻断项应包括：

• 文件和行号（如有）。
• 问题。
• 具体触发条件——谁执行什么操作会触发该问题。
• 建议的修复或验证方式。

如果没有阻断项，应说明此次更改通过审查，并且仅在“剩余风险”下列出已触发的加固项。不要为了让审查显得有必要而编造阻断项。

输出

使用以下结构：

## Findings

## Open Questions

## Residual Risk (triggered Hardening only; end with the omitted-unconfirmed count)

## Validation Notes

跳过空白部分，但“没有阻断项”为主要结论时除外。

完成标准

当每个选定的审查视角都已给出结论、每项已报告的阻断项都经过重新运行或追踪确认且包含具体触发条件和该审查视角的证据、每项加固项都说明了具体触发条件，并且未确认的发现仅以省略数量的形式呈现时，审查即告完成。

没有阻断项就表示更改通过。到此为止，不要重新检查审查中已经覆盖的代码。