review-fix

Review Fix

运行“审查 → 修复 → 验证”循环。保持审查独立，并严格限定在请求的更改范围内。

1. 审查

1. 明确审查目标、固定版本、源问题或规范（如有），以及相关的仓库说明。
2. 加载 code-review 并遵循其要求。告知它：差异中新增或强化的文档属于正在审查的实现，不能扩大源问题或规范的范围；当文档承诺的内容超出要求时，建议缩小文档范围。先让全新的 Standards 和 Spec 审查员完成报告，再进行编辑。
3. 将每项发现归类为 fix、not-actionable、out-of-scope 或 blocked。只有证据足以支持更改时，才将需要判断的代码异味视为可处理项；不得仅为满足差异中新增或强化的文档而扩大实现范围。

所有发现均有处理结论后再继续。

2. 修复

在审查范围内修复每项可处理的发现：

• 对于可在双方认可的测试接缝处覆盖的行为，加载 tdd，并采用红 → 绿循环。
• 直接修复明确的文档、配置、命名和重构问题。
• 如果原因不明确、故障难以复现、问题具有间歇性或与性能有关，或者首次修复失败，则加载 diagnosing-bugs。

每次修复后运行最小范围的相关检查。所有可处理的发现均已验证，或有证据表明受阻后，再继续。

3. 验证

1. 运行审查目标的相关检查。
2. 对照发现检查最终差异。如果修复实质性地改变了设计或范围，则重新运行 code-review。
3. 只有在被指定负责提交时才创建提交。
4. 返回 passed、fixed 或 blocked，并说明发现的处理结论、修改的文件、检查、适用时的提交，以及尚未解决的阻碍。

只有在每项发现均有处理结论、每项修复均有验证证据后，才能结束。