reviewlisted

# 工作流结构评审 `review` 用 **Spec / scope / diff / docs / entropy / risk** 六把尺检查当前结果，并默认采用 **adversarial review posture**：把实现视为未证明可信，先构造可能失败路径，再寻找代码、文档、测试或 evidence 反证。它抓正确性、范围、设计风险、缺失测试和文档漂移；fresh evidence sufficiency 与 ready judgement 归 `verify`。 ## 路由快照 - **Use when**: 有意义改动已经稳定，需要在 ready 前判断范围、正确性、文档、熵和风险。 - **Do not use when**: 工作仍在 WIP、失败正在发生、或唯一问题是缺 fresh evidence。 - **Route to**: 无 blocking finding 转 `verify`；有结构问题转 `implement`；失败不明转 `diagnose`。 ## 目的 review 必须同时检查"做超了"和"做欠了"。它可以判断"没有结构性 blocker"，但不能作为最终 ready gate。通过后仍路由到 `verify`；若已有 fresh evidence，则走 `verify` fast-path 做短重检和 claim mapping。 默认原则：meaningful diff 必须先尝试 **隔离 reviewer**，失败、不可用或成本明显不成比例时才 fallback。隔离优先级： 1. read-only subagent / independent reviewer。 2. Codex 环境中的 `codex exec review`。 3. Codex 环境中的 `codex exec` + review packet + reviewer prompt。 4. packet-based fallback，由当前 agent 按同一 prompt 做弱隔离审查。 fallback 不是静默自审；输出必须记录机制、失败原因或跳过原因。Tiny / trivial diff 可以直接 fallback，但必须说明为什么不属于 meaningful diff。 ## 何时使用 ### 触发信号 - `implement` 完成一个 slice、即将转下一阶段。 - `diagnose` 修复稳定，要回主流程。 - 用户说「review 一下」「这样可以吗」「能不能合并」「commit 前检查」「sanity check」。 - 准备调用 `verify` 之前的结构性把关。 - 多 agent 协作时上一个 agent 刚交付，本 agent 接手前。 ### 不要使用 - 工作还在 WIP 中、active slice 未稳定：继续 `implement`。 - 工作完全没有稳定到可审状态：继续 `implement`。 - 用户要架构建议：转 `brainstorm`。 - 失败正在发生：转 `diagnose`。 ### 路由规则 | 状态 | 下一步 | | --- | --- | | review 通过或仅有 evidence gap | `verify` | | review 找出 Critical/Important findings | `implement` | | review 发现 Spec 漂移 | `brainstorm` 或 `plan