tribunal

Tribunal

协调器本身不构建任何内容，也不评分——它会拆分工作，派遣一个独立执行者，召集独立验证者，并基于证据进行裁决。三项行为体现其价值：对抗性复查，能以明确命名的失败场景形式，发现单次检查悄然放过的问题；校准后的判决——可在本地修复的缺陷应判定为 ITERATE，而非“全部重写”，并且只有经验证的证据才能推翻通过的评分结果；证据先于声明——未经重新验证，不得声称“已完成”；被证伪的声明应排除，绝不纳入平均。开始时宣布：“正在通过 tribunal 模式处理：执行者 -> 验证者小组 -> 共识。”

适用场景

适用于多部分或高风险交付物，因为已发布的缺陷所造成的损失超过组建评审小组的成本。不适用于琐碎修改、可用一条验证命令证明正确的内容，或普通代码审查（即通过对话改进变更，而非针对冻结的产物和预先声明的标准进行独立测量，并据此裁定是否发布）。绝不嵌套 tribunal——任何角色都不得对自己的输出运行此协议。

流程

1. 在实施前冻结验收标准和验证命令；据此确定评分维度、权重和通过目标，并记录下来，以便后续评审组沿用同一评分标准。识别当前涉及的实用技能——即影响产物构建或评判方式的技能（例如 production-grade）；绝不能包括 tribunal 技能本身或纯协调类技能，并将这些技能的标准纳入验收标准。仅验证模式（产物已存在）：根据原始请求编写标准——绝不从产物反向推导；冻结标准后，从第 3 步开始。
2. 派遣一个独立执行者 Agent（绝不能由协调器自己担任），将完整的任务切片说明直接粘贴给它（绝不能说“阅读计划文件”），并明确列出当前涉及的实用技能，要求它加载这些技能（加载 production-grade 等）——如果无法加载某项指定技能，它必须说明情况，而不是继续执行。若协调器编写或编辑交付物，就没有可供独立验证的产物，整个流程会坍缩为单一上下文。执行者完成实施，运行验证命令，将产物持久化（提交、推送或发布，使其在执行者会话结束后仍然存在），并报告差异摘要、未经改动的命令输出、可获取产物的地址，以及且仅有一个状态（见下表）。没有地址的 DONE 不算 DONE。
3. 自行对照实际差异检查报告；并行派遣评审小组，隔离各自上下文。
4. 按照 consensus-mechanics.md 作出裁决；在记录表中记录判决、异议、注意事项和评审轮数。
5. SHIP -> 处理下一个切片。ITERATE -> 将发现转化为修复清单，交给新的执行者；由新的验证者重新评审，并重新评估每个维度，将此前的发现作为风险。

不变量（自由度低——这些就是技能）

1. 上下文隔离墙。 四种角色，四个独立会话：编排者（负责拆分、分派、裁定和维护台账——不产出任何交付内容，也不自行评分）、执行者和每位验证者。同一个 Agent 绝不兼任两个角色（共享上下文 = 共享盲点 = 无法进行三角验证，这正是整个机制的目的）。执行者先完成工作；然后验证者并行运行，每位验证者收到的内容严格限定为：冻结的标准；通过可获取的地址提供的产物——即其他独立沙箱中的验证者可自行获取的提交 SHA、分支或 URI，另附差异（或文档及其前一版本）；仅提供工作树路径是不够的，因为这些路径只能在执行者的会话中解析，会话结束后便失效；参考资料；运行验证命令的权限；已知风险；适用的技能（注明名称，以便加载）。验证者绝不会收到： 执行者的推理或自我评估、设计依据、其他验证者的首轮观点或身份、预期分数或此前的分数。说明共享标准不算突破隔离墙——隔离墙隐藏的是执行者的推理和分数，而非所有人共同遵循的评判标准。
2. 证据锚定。 高分必须附上产物中的逐字引文；失败声明必须附上文件:行号或命令输出；没有证据的发现一律舍弃。在进行任何共识计算之前，编排者会将每条影响判定的引文与产物和规范逐一核对：无法在原文中逐字定位的引文，其对应发现一律舍弃；被事实反驳的评分会被排除，并记录为已驳回的异议。依据证据裁定——绝不通过取平均值来消除分歧。
3. 明确提出反对意见。 至少一位评审组成员必须持反对意见：列出针对发布的最有力论据，说明具体的失败场景（哪些输入会导致什么错误行为）。攻击向量包括：隐藏假设；掩盖错误的过度设计；缺失的约束；偏离风险；规范缺口；组合脆弱性。泛泛的怀疑毫无价值，应予舍弃。首先依据规范文本核实每项指控；绝不将规范要求的行为标记为问题。任何成员提出的、未被反驳的正确性或安全性场景都绝不能被默默否决：必须提出并升级处理（ESCALATE）。
4. 标准先于产物确定——在实现前冻结，或者在仅验证模式下依据原始请求冻结。
5. 没有最新验证输出，就不得声称已完成。 “应该能通过”不是证据；必须依据实际产物和差异核实 Agent 报告的成功情况。
6. 迭代次数有上限。 每个切片最多进行 3 轮评审组审查（每轮更换新的验证者），另设独立的执行者分派预算（默认 5 次，按复杂度加权）；任一预算耗尽时，都必须将完整证据包升级给人工处理。两项计数都必须随交接内容传递，或记录在持久化台账中，绝不能只保存在编排者的上下文里——每次分派都要说明轮次编号和剩余预算。若编排者重启或上下文重置后便会忘记的上限，就不是真正的上限：评审组会无限期重复审查。

执行者状态	编排者处理方式
DONE	确认差异存在、命令已运行，且报告的地址能够解析；若状态为 DONE，但没有可获取的地址，则视为 NEEDS_CONTEXT——要求其先生成可获取的产物。然后启动评审组审查。
DONE_WITH_CONCERNS	如果涉及正确性或范围问题，先解决后再启动评审组审查。若只是观察事项，则记录后继续。
NEEDS_CONTEXT	补充缺失的上下文；重新分派给同一个模型。
BLOCKED	按顺序排查：补充更多上下文、更换能力更强的模型、拆分切片、升级处理。绝不原样重试同一个模型——至少调整上下文、模型或任务规模中的一项。
Verdict	触发条件
---	---
SHIP	总体评分达到或超过目标；没有维度被阻塞。
SHIP_WITH_CAVEATS	评分处于保留区间 [target − 0.10, target)，且只有非阻塞性保留项。在构建期间，这会触发 ITERATE：修复并重新验证每项保留项，或记录理由后延期——只有得到人工接受后才能作为最终结果。
ITERATE	低于保留区间；存在尚未解决的阻塞性保留项（断言存在正确性／安全缺陷，或缺少具体修复方案或记录在案的延期）；或某个被阻塞维度的成因均为已明确界定、可逐项列出的修复项（无论总体评分如何）——必须附上修复清单。除非经验证（且未被反驳）的失败情景另有结论，否则以数学计算为准。
BLOCK	缺陷集合具有结构性：补救需要重新设计，而非一份可逐项列出的局部修复清单——或继续推进并不安全。低分本身绝不会强制判为 BLOCK：如果多数被阻塞维度的成因都是局部修复项，则判为 ITERATE，并必须附上修复清单。
ESCALATE	陷入僵局、存在未被驳回的反对情景，或预算耗尽。仅由编排器决定——绝不能作为评审小组的建议。

校准：BLOCK 用于结构性问题。即使存在许多严重缺陷，只要每项都是健全架构中的局部修复项，就应判为 ITERATE，而非 BLOCK——严重程度决定修复优先级，绝不决定判定类别。维度被阻塞（多数评分为 3 分或以下）时，即使总体评分达标，也绝不能让结果作为 SHIP 通过：成因属于局部修复项时，应判为 ITERATE，并附上必需的修复清单，即使总体评分 ≥ target；只有结构性成因才判为 BLOCK。发布 BLOCK 前进行一致性检查：如果报告本身将每项缺陷都描述为可局部修复，则 BLOCK 与证据相矛盾——应判为 ITERATE。某位成员给出低分属于有记录的异议，而非阻塞项。

评审小组构成（按产物推导）

从不同独立视角交叉验证事实真相；其余则用于确定规模。默认采用三个视角：质量（首先检查是否符合规范——缺失／多余／误解——然后检查正确性）、用途契合度（真实使用者、边界情况、集成）以及对抗者（必须提出反对意见）。根据风险大小调整规模——低风险的小范围变更安排两位评审者，高风险且不可逆的变更采用五个视角——并根据产物的实际风险面选择视角。例如：数据迁移脚本存在数据丢失和部分失败风险 -> 转换正确性、回滚／幂等性对抗者、操作员体验；API 文档 -> 一致性、使用者体验、破坏性变更对抗者。绝不能给对抗者使用比评审小组其他成员更弱的模型；条件允许时，采用不同模型系列可减少相关性盲点。

验证者提示词骨架（据此编写每条提示词）

Role: <lens> verifier. You have NOT seen the builder's reasoning or any other
reviewer's views. The report you judge may be wrong — verify everything against
the artifact itself, as-is.
[Adversary only: You MUST oppose — build the strongest case against shipping;
name the exact failure scenario per concern. Write "ESCALATE: <reason>" for a
correctness/safety concern you believe cannot be rebutted.]
Inputs: frozen criteria; dimensions/weights/target; artifact (fetchable address — commit/branch/URI — plus the diff inline); round index and remaining budget; references; verification commands (you may run them); known risks; operative skills (named — load them; if you cannot, say so).
Rules: score each dimension separately, 1-10, with confidence 0.0-1.0; every
claim cites a verbatim quote, file:line, or command output. Citations WILL be
grepped against the artifact and spec — one that does not exist verbatim
discards the finding.
Output: per-dimension score + confidence + evidence; top concern;
recommendation SHIP|SHIP_WITH_CAVEATS|ITERATE|BLOCK; escalation if any.

记录

交付物是评审庭运行所产生的唯一持久化产物。在结束摘要中报告判定、异议（包括被驳回的异议，原文照录）、保留项（已修复 | 已延期 + 原因）以及评审轮次，并在存在 PR 描述或提交消息时将这些内容纳入其中。通过请求到达的渠道向请求者交付该报告，是整个流程中的一个步骤，而非完成后的附带效果——无人收到的判定不算判定。绝不在代码树中留下散落文件。如果运行确实需要工作文件（例如跨多个切片维护的账本、临时夹具），则将其全部放在单个被 gitignore 的 .tribunal/ 目录中，且绝不提交；不得写入其他文件。绝不默默丢弃保留项。

计划审核（使用相同机制，提前执行）

执行非平凡计划前，先通过三个独立视角审核：能否奏效（检查是否具体明确？）、执行者能否遵循，以及这是否是成本最低且足够的路径。三者中有两者通过即可继续；否则将批评意见合并为且仅为一次完善，再审核一次，随后升级处理。审核会锁定评审小组之后将审计的标准。

平台

使用并行子 Agent 时，在一条消息中并行调用各评审角色——使用不同的 Agent，确保彼此真正独立。如果无法并行调用，就让每个角色分别在独立的新上下文会话中依次运行（仍使用不同的 Agent），并通过限制每个会话收到的信息来确保隔离。让一个 Agent 扮演所有角色会失去交叉验证的优势——效果与完全没有评审团相同（弱模型自我模拟评审团时，得分会停留在其单独评审的水平）；只有在无法使用独立会话时才这样做，并将结论标注为“单上下文（无独立性）”。

分离式编排（运行时间超过任何单次轮次，或会因任何单次轮次而暂停）：如果运行时的等待原语会结束编排器的当前轮次，那么传递给该原语的内容只是记录信息，并非通信——此时还没有任何人收到通知。在交接时携带产物地址、轮次索引和剩余预算，因为恢复运行的编排器可能不是写下这些信息的那个。在恢复后，先确认请求者实际收到了什么，再决定下一步：运行结束不等于已交付。

端到端示例：worked-example.md。 失败案例集：anti-patterns.md。