post-implementation-review

实施后审查

审查已完成的实现，默认应用明显且安全的 Bucket I 修复，并尽力在合理范围内反复检查，直到不再有 Bucket I 项。除非用户明确要求，否则不要暂存、提交或推送。

工作流

1. 确定范围。

   • 用户未指定范围时，默认检查当前未提交的更改。
   • 检查 git status --short、相关差异，以及判断更改所需的附近代码。
   • 区分审查的更改引入的问题与已有的技术债。

2. 审查实质性问题。

   • 宁可不报告，也不要报告依据薄弱的问题。
   • 仅记录明确、可操作的问题，并说明具体受影响的路径、触发场景和维护者可能采取的措施。
   • 检查正确性、状态/生命周期顺序、验证与不变量、类型/架构契合度、所有权边界、集成契约、测试以及用户可见的回归。只有按照此清单检查完范围内的每个更改文件，审查才算完成。

3. 在有帮助时使用子 Agent。

   • 采用能实质提升信心的最轻量审查方式：通常不使用，有时使用一位专注的审查者；仅在更改范围广或风险高、且审查角度各异时使用多位。
   • 适合交给子 Agent 的任务包括：以全新上下文复查第 2 步中的任一角度，以及并发、安全/隐私、性能、UI 行为，或对陌生子系统进行广泛调研。
   • 子 Agent 仅负责审查。要求其简要提供带有证据、受影响路径、触发场景、可能的验证方式，以及 Bucket I / Bucket II / 保持现状建议的发现。
   • 将子 Agent 的输出视为线索，而非结论。记录发现或应用修复前，务必自行核实证据。
   • 不要使用子 Agent 创建自主审查/修复循环，不要并行编辑，也不要在合理范围内的审查完成后继续审查。

4. 执行 Bucket I 清理循环。

   • Bucket I 修复应当范围狭窄、局部、处于审查范围内，可通过机械方式验证或不言自明，并且不涉及产品、设计、架构、发布、兼容性、代码变动幅度或风险判断。
   • 默认应用所有当前的 Bucket I 修复，除非用户说了 review-only、do not edit 或类似要求。
   • 应用 Bucket I 修改后，重新检查新差异和受影响的代码路径。如果出现新的 Bucket I 项，则应用修复并再次检查。
   • 在仍有价值时继续，直到不再有 Bucket I 项、只剩 Bucket II 决策、验证/范围/上下文阻碍安全继续，或再检查一轮只会造成无谓改动。
   • 除非某项内容显然已无用（例如未使用的导入或失效的文档链接），否则不要删除看起来是有意保留的代码。

5. 尊重人工决策边界。

   • 将较大的重构、含糊不清的修复、有风险的行为更改和设计选择列为 Bucket II。
   • 未经用户明确批准，不要实施 Bucket II。
   • 如果验证受阻、无法进行或因外部原因失败，应报告并停止；不要用更大范围的静态修改来弥补。

6. 验证。

   • 在实际可行时运行最相关的现有验证。
   • 优先对已修改部分进行针对性检查；除非更改风险值得进行，否则不要运行耗时较长的大范围测试套件。
   • 将无关的既有失败与审查修复引入的失败区分开来。

最终回复

报告：

• Bucket I — 已应用的安全修复：问题、修改的文件和验证证据；或 none
• Bucket II — 需要决策：所需决策及主要权衡；或 none
• 保持现状 — 检查后有意不处理的重要问题（如有必要）
• 运行的验证及其结果
• 如果验证被跳过或受阻，说明残余风险