code-review

代码审查

用于审查本地更改、PR 更改或进行审查迭代。先阅读 references/repository.md，再阅读与更改部分相关的说明。审查人员只报告发现的问题；由更改负责人进行修复。

审查预算

接受可选参数 max-turns=<positive integer>；默认值为 10。首次审查前，拒绝缺失、为零、为负、非整数或格式错误的值。上限不限。每次完整审查都计入预算；预算耗尽且尚未得到 RESULT: PASSED 时，停止审查并基于当前证据询问是否启动新的、经明确授权的审查。绝不自动延长预算。

1. 确定实际审查范围

审查当前预期的更改，而不仅仅是 HEAD：

1. 从明确指定的目标、PR 元数据或仓库默认值中确定基准；若存在歧义，则询问；
2. 计算已提交的范围 base...HEAD；
3. 合并暂存区中的更改（git diff --cached）、未暂存的更改（git diff）以及预期纳入的未跟踪文件；
4. 每次审查前及每次修复后重新计算合并后的范围。

只有当实际差异带来风险时，未更改的代码才可作为证据。保留工作树中无关的更改。

2. 仓库基线

阅读 AGENTS.md、适用的贡献者说明、格式化／lint／测试命令、架构／领域文档，以及更改部分的规范。仓库规则决定严重性和必需的验证。除非生成器输入／模板／配置发生更改，否则跳过生成的输出。

3. 审查轮次

机械审查

结合上下文阅读每个更改文件。检查正确性、安全性／隐私、数据丢失、授权／验证、兼容性／契约、错误处理、并发、迁移／配置，以及行为测试。参见 review.md。

结构审查

仅在明确要求或仓库规定时运行。应用 structural-review.md：查找实质性的复杂度、所有权、不变量、边界或重复规范辅助函数方面的回退。不要因表面问题、行数或推测性的重构而阻止更改。

验证审查

对于可运行行为、API／契约、权限、任务／事件、迁移、生成的客户端或浏览器可见的更改，推导具体的成功、负面、权限和边界案例。应用 validation.md。浏览器／线上／工作树工具是否可用取决于实际情况，绝不默认假定可用。

问题标准

只报告由差异导致、具有实质影响且可采取行动的风险。严重性如下：

• **严重：**可能导致安全／隐私泄露、数据损坏／丢失、公共契约遭破坏或主路径中断。
• **重要：**对正确性、授权、持久化、兼容性、覆盖率、架构或更改所涉及的热路径性能造成实质风险。
• **摘要：**具体的可维护性观察；除非涉及实质风险，否则绝不阻止更改。

每个根本原因只报告一项发现，并锚定到最佳的已更改 path:line。说明具体风险、仓库证据／规则，以及所需操作。省略称赞、偏好、过时／重复的评论和推测性的清理建议。

有限轮次的审查循环

使用 loop.md。负责人修复后，由协调者运行确定性检查，然后重新计算完整的实际范围，并要求重新进行只报告发现问题的审查。绝不凭假设清除问题发现。若仍有实质问题发现、范围扩大或预算耗尽，则停止审查，基于当前证据请求下一步指示。

输出约定

审查人员只返回问题发现，不编辑、提交、推送或发布内容。每轮审查都以以下内容结尾：

CODE REVIEW
Scope: <base>...<head plus staged/unstaged/untracked intended overlay>
Depth: <standard|structural>
Findings: <none|severity summaries with path:line>
Checks: <not run|required commands and outcomes>
Residual risk: <none|summary>
RESULT: PASSED|FAILED

最终输出的末尾必须是非空行，且内容必须精确为 RESULT: PASSED 或 RESULT: FAILED。只有在所有由差异导致的实质风险都已分类、没有未解决的严重／重要问题发现、所选的必需验证已通过或明确受阻，且已对当前实际范围重新进行审查时，才能通过。