review — 在构建前驳倒规格说明。
每一项发现都引用证据 —— 文件:行 或来源。没有证据 → 标记 [unverified]。默认被驳倒：一个你无法证明的缺陷，是你记录下来的缺陷，而不是被你放过的一个。
一个 LLM 无法仅凭自身判断自我纠错 —— 放任不管，它会漂移或退化。Review 以唯一有效的方式修正这一点：一个独立的怀疑者，锚定在外部神谕之上 —— 代码、§R、测试套件、文档。“看起来不错”不是评审。一次驳倒尝试才是。
何时评审
在高爆炸半径的变更（共享模块、鉴权、数据、金钱、公共 API）上执行 /build 之前。
规格触及了其他代码所依赖的 §I 或 §V。
规模适配（Right-sizing）表明：错误构建的代价 > 一次评审的成本。
对于琐碎、可逆、已充分理解的变更则跳过。对错别字进行对抗性评审会幻觉出缺陷并浪费预算 —— 自我批评悖论是真实存在的。
阶段 0 — 捕获
阅读规格：§G §C §I §R §V §T。把握全部内容。你评审的是规格，而不是你对对话的记忆。
阶段 1 — 构建资深评审者
构建一个拥有真实权威的评审者，而不是泛泛的批评者：
代码库 —— 对本规格触及的模块做 grep/阅读。已存在哪些模式、哪些不变量？
§R —— 研究确立了哪些结论？一个与 §R 相矛盾的规格决策就是一项发现。
实时 —— 对于任何你不确定的最佳实践主张，去获取它。一个过时的假设就是一个缺陷。
没有证据的评审者只是一个观点。先赢得权威。
阶段 2 — 驳倒
沿以下轴线攻击规格。对每一条，尝试找出它失效的情形：
目标 vs 现实 —— §G 解决的是实际问题，还是一个替代品？
缺失的不变量 —— 有什么可能出错而没有任何 §V 能捕获？（大多数发现都在这里）
接口漂移 —— §I 是否与调用方已有的期望匹配？（引用调用方，文件:行）
约束冲突 —— 两条 §C bullet 是否相互矛盾？其中一条是否与 §R 冲突？
无主的边界 —— 没有任何 §T 覆盖的输入、顺序、失败或并发场景。
高度（Altitude）—— §T 过于模糊而无法行动，还是过于细碎而只是在打字？
阶段 3 — 分类
每项发现：证据 → 主张 → 严重程度。
BLOCK —— 基于此规格构建会交付一个真实缺陷。必须先修复。
HARDEN —— 新增/锐化一条 §V，使构建无法使其回归。
NOTE —— 值得知道，但不阻塞。
没有证据？降级为 NOTE 并标记 [unverified]。⊥ 把猜测夸大为 BLOCK。
阶段 4 — 加固 §V 与门禁
每项 HARDEN 发现 → 一行 §V 草稿（可测试，引用它所守护的 §I/行为）。交给 spec 去撰写。
以一个明确的门禁结尾：
review verdict
BLOCK: 1 — §I.api shape ≠ caller src/client.ts:40. fix §I before build. HARDEN: 2 — drafted V8 (idempotent refund), V9 (tx around dual write). NOTE: 1 — §T4 vague, split before /build. gate: NO-GO until BLOCK cleared. then /build §T after spec writes V8,V9.
GO 或 NO-GO，绝不耸肩。Review 是阻止一次自信的错误构建的检查点。
边界
⊥ 写 SPEC.md。起草 §V 并交给 spec。
⊥ 把没有证据的发现当作事实通过。标记 [unverified]。
⊥ 评审琐碎之事。规模适配或跳过。
⊥ 重写用户意图。你加固规格，不替换它的目标。