独立审查：四类实例

“让写它的同一个 Agent 检查它，结论永远是一团和气。”

Atlas 把「独立审查」做成流水线里的一等机制：不指望某一次提示词写得委婉，而是靠四件硬东西落地 —— 进程边界 + 权威输入 + 分级闭集 + 留痕双份。

1. 四类实例

四类实例共用同一套骨架条款（正文只在 shared/independent-review.md 一份，各实例不复制），各自只声明自己的四项：审查维度 / 回退环取值 / 权威输入 / fan-out 单位与阈值。

#	实例	fan-out 单位	权威输入（缺则不得给「通过」）	门禁挂点
①	PRD	不扇出（单审查者：本实例的维度本身就是跨域一致性判据）	结构事实 + 范围冻结结论	交付用户 review 前的自检
②	E2E 用例	页面分片（复用 testid 双向校验的同一分区键）+ 超阈值（20 条或 500 行）按用例 ID 区间再切 + 一个全局审查者	域级 PRD 的 AC + 该页用例分片的 testid 清单	阻断脚本生成
④	设计决策	按 frontier 轮次（一轮问答一次）	设计树 + 前沿问题 + 该轮推荐	低风险一致 ⇒ 自动通过；高风险四条一律人工
⑤	实现代码（CLI 式独立审查）	不扇出（diff 即范围）	需求卡 + 受影响域级 PRD 的 AC + 受影响用例分片	收口完成门：有 `Critical` ⇒ 域不收口

编号取自契约本身（shared/independent-review.md §1）。

只审不改：审查者不落笔改动被审对象；发现的问题映射回生成阶段，改完必须重跑全部维度（改动即作废旧结论）。
先独立得出结论，再与推荐比对：审查者在不看生成者自评 / 推荐答案的前提下给出结论，之后才与推荐比对。禁止「你同意吗」式提问 —— 同源推荐 + 同框评审会让「一致」失去证据力。
分级只有三档（取值写死）：
- Critical —— 会让下游产出建立在错误事实上的缺陷，或断言通过而行为不存在的假绿通道 ⇒ 门禁阻断；
- Major —— 不影响下游可执行性，但让产出与依据脱节：覆盖缺口、维度冲突、术语漂移、回退环指错；
- Minor —— 一致性、措辞、可读性。
每条 finding 必带「回退环」，取值从该实例的闭集里选；跨环时另标首改环（必须最先动的那一环）。
维度封闭 + 兜底出口：审查者只按该实例的固定维度填结论表；另有可选字段 other，契约要求它默认留空，且 other 报出的问题不计入门禁（只作人工参考）。完全封闭会把荒谬但真实的问题挡在维度外，全开放则退化为无界探索。
缺权威输入 ⇒ 不得给「通过」：必须明确说明「无法判定完整性」，且不得以「文档内部自洽」代替完整性结论。

实测过的问题：模型在审查数十个文件的大 diff 时会悄悄跳过文件。所以实例 ⑤ 的报告必须带两个对账字段：

应审 N = 审查器 --preview 给出的 Will review 数（按扩展名过滤后的真实范围，不用 git diff 全量计数）；
实审 M = 审查器汇总的实审文件数；
reviewed < expected 或预算击穿 ⇒ 报告级状态至少 WARN；CLI 不报实审数 ⇒ 转换器拒绝产出（缺权威输入不得给「通过」）。

报告落盘当轮必跑形态 + 对账门：scripts/validate_review_report.py --dir <报告目录>。

双份留痕：人读 README.md（审查总结 / 问题清单 / 被审对象与轮次）+ 机读 review.json；
落点：product/<环>/reviews/<日期>-<范围>/ —— 独立审查报告属该环自己的产物目录；
被审对象的正文不得写入审查意见：审查报告是记录类，被审对象是交付面，只写被接受的最终状态。这也正是「不许偷改 PRD 把门刷绿」的落地方式；
校准是收敛的控制环，不是固定比例：跟踪一致率 / 漏报率 / 分歧率；分歧率连续为 0 不直接回退全人工，而是触发一轮加强抽样复核 —— 抽样漏报 > 0，才算「橡皮图章」坐实。

三处 reviews/ 的角色不要混用，见产物落点与生命周期。