自动复审循环

要解决的具体问题

大重构很少在一轮审查里收敛。multi-model-review 单轮会给出一堆 findings，但你改完权限模型、并发路径之后，旧问题可能被新问题掩盖，或者修复动作本身引入回归。结果是「review 通过了」和「上线能跑」之间隔着一层侥幸。

Autoreview Loop 的思路很直白：把审查当成循环，而不是一次性事件。每一轮都要对上一轮的结论做状态确认，修复动作必须留下证据，循环只在明确定义的条件下才停止。

核心能力与关键步骤

Scope snapshot（范围快照）：每轮开始时记录轮次编号、当前 diff 摘要、未关闭的 findings 列表。所有信息追加到 review-log.md，作为这一轮唯一的上下文来源。

Review pass（审查）：沿用 multi-model-review 的输出格式，本轮只允许两种动作：确认旧 findings 状态（OPEN / FIXED / WONTFIX），或新增必须附证据的 findings。旧项状态需要全部更新完毕才算完成。

Fix pass（修复）：优先级依次为正确性 / 资金 / 安全 → 数据丢失 / 串号 → 测试缺口 → 可维护性。禁止借修复名义扩大 scope。声称 FIXED 的项必须有 diff 或测试证据支撑。

Stop conditions（停止条件）：三选一退出——CLEAN（无 OPEN 的 P0/P1）、CAP（达到 MAX_ROUNDS，列出残留项）、ABORT（发现方向性错误需要重设计）。

适用边界与注意点

• 小补丁不要用它，单轮 multi-model-review 就够了。
• 每轮都要把日志写下来，轮次一多上下文很容易丢。
• 不要为了假装 clean 把 P0 降级成 P2。
• 方向错了就 ABORT 转 redesign，超过上限还在硬改是典型信号。
• 使用前需确认你对相关账号、系统和数据有充分授权，并遵守平台规则与频率限制。