用途
review-quality-gates 是一组门禁（gates）与合并（consolidation）规则，由 /senior-review:team-review 与 /senior-review:code-review 共用。它面向多审查者协作的代码审查流水线，约束审查者如何使用共享上下文、如何验证前提、如何评估定量声明，以及如何通过对抗式面板判定发现项。
核心不变式：共享上下文溯源规则
证据若来自某一共享产物，则不能独立佐证该产物中的主张。N 位审查者同意一个被共同给定的前提，这是一次观察，不是 N 次。该内容是流水线的第一级不变式，而非质量建议。它带来三点约束：
- 从 X 光输出或互连图中读取某主张的审查者，并未验证该主张；在据此提出发现项前必须独立重新推导。
- 共享前提的审查者之间的一致是回声（echo），不提升置信度，也不提升严重度；合并阶段需如实这样报告。
- 任何指标都不得奖励与共享产物的一致。互连图的使用率是运营数字，绝不是质量信号。
上下文共享模式
当 /team-review 以流水线模式运行（无 --no-context）时，审查者除原始代码外还会收到三个阶段 1 产物：
- X 光输出（来自 codebase-xray 插件），路径由编排命令记录：若命令自身启动了 X 光运行则为 $XRAY_RUN_DIR；若消费已存在的分析则为 .codebase-xray/ 镜像。文件包括 01-structure.md、02-interfaces.md、05-risks.md，以及可选的 03-flows.md、04-semantics.md、06-documentation.md、07-final-report.md。自行启动的运行从不读取镜像，因为镜像意为“最近一次已发布的运行”，而非“我刚产生的运行”。
- 互连图，位于 .team-review/02-interconnect.md（来自 codebase-xray:semantic-interconnect-mapper）：契约（形式/结构/隐式）、不变式、领域规则、假设（已验证/已记录/未验证）、集成热点、变更影响半径。
- 知识溯源，位于 .team-review/01-knowledge-provenance.md（来自 /team-review 阶段 1d）：各发现分支找到了哪些概念、双方都未找到的、以及二者不一致的。审查者从中推导候选关注点，故与上述两者一同分发。
另有第四类产物不属共享上下文：.team-review/01b-independent-claims.md，在阶段 1c 由 senior-review:premise-auditor 在对此前两者不可见的情况下推导。
审查者如何消费上下文
审查者不应读取整个上下文文件，而应依据 .team-review/02-interconnect.md 底部的 ## Reviewer Hints 章节，通过 Grep 或读取与自身维度相关的锚点。默认锚点路由按维度划分，例如：security 对应 ## Integration Hot-Spots（入站）、## Assumptions（未验证）、## Contracts（隐式、输入校验）；architecture（code-auditor）对应 ## Invariants、## Contracts（结构+隐式）、## Call Graph；logic-integrity、distributed-flows、chicken-egg、ui-races、temporal-resilience、data-integrity、resource-lifecycle、api-contracts 各自对应不同锚点；结构熵（diff 模式）为 none，不消费互连图。
文档给出了传给上下文感知审查者的提示词模板，其中强调共享上下文不是事实基准，而是某上游观察者产生的假设索引：标记 verified 的主张可直接复用；标记 documented、unverified 或 disputed 的主张是假设，必须独立重新推导后方可作为发现项前提；应主动寻找与上下文矛盾的代码路径、测试或文档；上下文中的沉默不等于不存在。每条发现项需引用 file:line，涉及互连图契约/不变式/假设的还须引用对应地图锚点。
度量
- 地图使用率（运营数字，非质量信号）：引用互连锚点的发现项占比。它只说明消费了多少地图，不说明审查好坏；在错误地图上的高值正是该流水线要避免的失败特征，因此不设目标。
- 质量信号包括：独立前提重建率、前提挑战率（Lens 0 实际攻击的合格前提占比）、地图挑战率（被显式测试而非假设的已消费地图行占比）、地图缺口率（[MAP-GAP] 发现项占总发现项的比例）、跨源佐证率（跨代码、测试与文档佐证）。其中跨源佐证率是诊断量，不是要最大化的数字。
原始模式回退（--no-context）
跳过流水线时，审查者只收到目标与 diff。此时不会生成 logic-integrity-auditor，也不派遣 premise-auditor，阶段 0c 不运行。所有发现项按构造即为独立，Lens 0 不会触发，合并阶段也不报告回声。审查者提示词中不应出现 .codebase-xray/、$XRAY_RUN_DIR 或 .team-review/02-interconnect.md 引用。
审查者流水线约定
每个在 /team-review 阶段 2 运行的审查者 agent 在其系统提示中包含 ## Pipeline Conventions 章节，含四条横切规则：范围预算（约 15 次文件读取无发现即停止并返回 scope-off-topic 报告）、无发现协议（返回“已检查 X、Y、Z：无问题”是合法输入而非失败）、Cross-Reviewer Notes（跨维度观察写入该章节，阶段 3 合并须扫描并路由）、互连锚点引用（适用时引用地图锚点）。
定量声明的证据等级
任何量化损害（N 次/天、GB、$/月、请求/秒）的发现项必须标注 measured 或 derived：measured 指通过运行 harness、模拟或复现获得，或读取真实日志/指标，并需一行说明方法；derived 指通过阅读代码计算得出，属假设而非事实，代码推导的损害估计在两个方向上都有过两个数量级的偏差。合并与验证阶段执行以下后果：仅有 derived 数字不能支撑 Critical 严重度（要么实测，要么封顶为 High 并指明后续测量）；不能仅凭 derived 数字将发现项关闭为可接受；验证面板将未标注的量化声明视为 derived，Lens 2（反驳）应主动检查所声称的速率或成本是否经得起代码实际控制流的检验。
任何损害随时间表现（重复、退化、沉默）的发现项必须说明用户或操作者看到什么、何时看到。“无（静默）”是严重度提升因素，绝不是缓解因素。
对抗式验证面板
发现项合并去重后，每个被选中的发现项由一个最多 4 名验证者的面板判定，每人持不同视角，替代单判官验证。四个视角如下：
- Lens 0：由 role: senior-review:premise-auditor 执行，按前提溯源门控，最先运行；对 premise_provenance 为 shared-context 或 mixed 的发现项运行，且不论溯源如何，对声明前提带全称或否定量词（no、never、cannot、always、only）的发现项运行。
- Lens 1 与 Lens 2：使用 role: general-purpose，并行跨发现项运行（run_in_background: true），不指定 model 以继承会话模型（推理密集）。
- Lens 3：严重度校准，使用 role: general-purpose 与 model: sonnet，受门控——仅为通过 Lens 1、2 的发现项（两者均为 REAL，或标记为 contested 的平局）生成。Lens 1、2 淘汰的发现项不进入 Lens 3，并在过滤记录中保留原严重度。
其他说明
文档还说明：同一规则跨模型族应用由 peer-review 插件（/peer-review:review）实现，它把计划或规格发送给不同模型族的挑战者，进行有证据支持的多轮审议；其中共享产物是挑战包，提供给挑战者的事实标记为 GIVEN，复述一次不算佐证，参与者自行到达权威来源时记录 GIVEN -> DERIVED 的升级。但该插件对主张的界定比本节更窄，因为两个前沿模型仍共享同语料：让第二意见值回成本的是误差去相关，而非洁净室式独立。上述内容的完整约束与提示词模板细节以原始资料为准。