review

review — 构建前反驳规范

每条发现都要引用证据——文件:行号或来源。没有证据 → 标记 [unverified]。默认立场是反驳：你无法证明无误的缺陷，就应记录下来，而不是轻易放过。

LLM 无法仅凭自己的判断自我纠正——如果放任不管，它就会偏离或退化。审查应采用唯一有效的方式：由一个独立的怀疑者，锚定于外部判定依据——代码、§R、测试套件、文档。说“看起来不错”不算审查。尝试反驳才算。

何时审查

• 在对影响范围大的变更执行 /build 之前（共享模块、身份验证、数据、资金、公共 API）。
• 规范修改了其他代码所依赖的 §I 或 §V。
• 评估规模后认为，构建错误的代价 > 进行一轮审查的代价。

对于微小、可逆且充分理解的变更，可跳过。对拼写错误进行对抗式审查只会凭空捏造缺陷并浪费预算——自我批判悖论确实存在。

阶段 0 — 阅读并掌握

阅读规范：§G §C §I §R §V §T。掌握全文。你审查的是规范，不是你对话内容的记忆。

阶段 1 — 构建资深审查者

构建一个真正有判断依据的审查者，而不是泛泛批评者：

• 代码库 — grep/阅读规范涉及的模块。现有模式是什么？已有的不变量是什么？
• §R — 调研得出了什么结论？与 §R 矛盾的规范决策就是一条发现。
• 当前资料 — 对不确定的最佳实践主张，进行查证。过时的假设就是缺陷。

没有证据的审查者只是在发表意见。先取得足够依据。

阶段 2 — 反驳

从以下方面攻击规范。针对每一项，尝试找出会导致问题的情况：

• 目标与现实 — §G 解决的是实际问题，还是某个代理问题？
• 缺失的不变量 — 哪些问题可能发生，却没有被任何 §V 捕获？（大多数发现都在这里）
• 接口偏差 — §I 是否符合调用方已有的预期？（引用调用方所在的文件:行号）
• 约束冲突 — 两条 §C 是否相互矛盾？其中一条是否与 §R 冲突？
• 未覆盖的边界情况 — 哪种输入、顺序、故障或并发情况没有被任何 §T 覆盖？
• 抽象层级 — §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，绝不含糊。审查是阻止自信地构建出错误结果的检查点。

边界

• ⊥ 编写 SPEC.md。起草 §V 并交给 spec。
• ⊥ 不要把没有证据的发现当作事实。标记 [unverified]。
• ⊥ 不要审查琐事。合理评估规模，或跳过。
• ⊥ 不要改写用户意图。你要强化规范，而不是取代其目标。