Back to Details

tribunal

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Tribunal

评审法庭（Tribunal）

The orchestrator builds nothing and scores nothing itself — it slices the work, dispatches a separate doer, convenes separate verifiers, and adjudicates on evidence. Three behaviors carry the value: an adversarial second look that catches what a single pass ships silently, as named failure scenarios; calibrated verdicts — locally fixable defects get ITERATE, not "rewrite everything", and passing math is overridden only by verified evidence; evidence before claims — nothing is "done" without fresh reproduction; refuted claims are excluded, never averaged in. Announce at start: "Running this through the tribunal pattern: doer -> verifier panel -> consensus."
编排者自身不负责构建成果，也不进行评分——它会拆分任务、指派独立的执行者、召集独立的验证者小组，并基于证据进行裁决。其核心价值体现在三点：对抗式二次检查，能发现单次流程中被忽略的隐性故障场景；校准化裁决——可本地修复的缺陷会触发ITERATE（迭代修改）而非「全盘重写」，已验证正确的内容仅能被确凿证据推翻；先证据后结论——没有全新的复验证结果，就不能判定「完成」；被反驳的结论会直接排除，而非进行平均处理。启动时需声明：「正在通过评审法庭模式执行：执行者→验证者小组→共识确认。」

When to use

使用场景

Multi-part or high-stakes deliverables where a shipped defect costs more than a panel. Not for trivial edits, anything one verification command proves, or ordinary code review (dialogue improving a change vs independent measurements of a frozen artifact against pre-declared criteria, adjudicated to a ship decision). Never nest tribunals — no role runs the protocol on its own output.
适用于多模块或高风险的交付成果，此时交付缺陷的成本高于组建验证小组的成本。不适用于琐碎编辑、可通过单一验证命令确认的内容，或常规代码评审（常规评审是通过对话优化变更，而本模式是针对冻结的工件，基于预先声明的标准进行独立评估并得出交付决策）。切勿嵌套评审法庭——任何角色都不得对自身输出执行本流程。

The loop

循环流程

  1. Freeze acceptance criteria and verification commands BEFORE implementation; derive scoring dimensions, weights, and a pass target from them, recorded so re-panels reuse the rubric. Identify the operative skills in play — those bearing on how the artifact is built or judged (e.g. production-grade); never the tribunal skill itself nor pure orchestration skills — and fold their standards into the criteria. Verify-only entry (artifact already exists): write criteria from the original request — never reverse-engineered from it — freeze, start at step 3.
  2. Spawn a SEPARATE doer agent (never the orchestrator itself) with the full slice spec pasted in (never "read the plan file") and the operative skills named with an instruction to load them (load production-grade, etc.) — if it cannot load a named skill it says so rather than proceeding. If the orchestrator writes or edits the deliverable, there is no independent artifact to verify and the run collapses to one context. The doer implements, runs the verification commands, and reports a diff summary, verbatim output, and exactly one status (table below).
  3. Check the report against the actual diff yourself; dispatch the panel in parallel, context-walled.
  4. Adjudicate per consensus-mechanics.md; record verdict, dissents, caveats, and round count in the ledger.
  5. SHIP -> next slice. ITERATE -> findings become a fix list for a fresh doer; re-panel with fresh verifiers re-scoring every dimension, prior findings as risks.
  1. 冻结验收标准与验证命令：在实现前完成冻结；从中衍生评分维度、权重及合格目标，并记录下来，以便后续评审复用该评估准则。明确涉及的核心技能——即影响工件构建或评判的技能（如生产级规范）——切勿包含评审法庭技能本身或纯编排技能，并将这些技能的标准纳入验收准则。若为仅验证模式（工件已存在）：需从原始需求中提取验收标准——切勿从工件反向推导——冻结后直接进入步骤3。
  2. 指派独立执行者Agent：（绝不能是编排者自身），需将完整的任务片段规范直接粘贴（而非「读取计划文件」），并指定核心技能，要求其加载（如加载生产级规范等）——若无法加载指定技能，需明确告知，不得继续执行。若编排者自行编写或编辑交付成果，则不存在可验证的独立工件，流程会退化为单一上下文模式。执行者完成实现后，需运行验证命令，并提交差异摘要、原始输出结果，以及唯一的状态（见下表）。
  3. 自行核对报告与实际差异：随后并行指派上下文隔离的验证者小组。
  4. 裁决：依据consensus-mechanics.md执行；将裁决结果、异议、附加条件及轮次记录到账本中。
  5. 后续处理：SHIP（通过交付）→进入下一个任务片段。ITERATE（迭代修改）→将评审发现转化为修复清单，指派新的执行者；重新召集新的验证者小组，对所有维度重新评分，并将之前的发现列为风险点。

Invariants (low freedom — these are the skill)

核心原则（自由度低——这正是本技能的关键）

  1. Context wall. Four roles, four separate sessions: the orchestrator (slices, dispatches, adjudicates, owns the ledger — produces NO deliverable content and assigns NO scores itself), the doer, and each verifier. One agent never plays two roles (shared context = shared blind spots = no triangulation, the entire point). The doer finishes first; then the verifiers run in parallel, each RECEIVING exactly: frozen criteria; the artifact (diff + new-file paths, or the document + its predecessor); reference materials; permission to run the verification commands; known risks; the operative skills (named, to load). Verifiers NEVER receive: the doer's reasoning or self-assessment, design rationale, each other's first-round views or identities, expected or prior scores. Naming shared standards is not a wall breach — the wall withholds the doer's reasoning and scores, not the bar everyone is measured against.
  2. Evidence anchoring. High scores require a verbatim quote from the artifact; failure claims require file:line or command output; evidence-free findings are discarded. Before any consensus math the orchestrator greps every verdict-driving citation against the artifact and spec: a quote that cannot be located verbatim discards its finding; factually refuted scores are EXCLUDED and logged as refuted dissent. Adjudicate on evidence — never average disagreement away.
  3. Explicit opposition. At least one panel member must oppose: build the strongest case against shipping as NAMED failure scenarios (which input, what wrong behavior). Attack vectors: hidden assumptions; over-engineering hiding bugs; missing constraints; drift risk; spec gaps; composition fragility. Generic skepticism is worthless — discard it. Confirm every accusation against the spec text first; never flag behavior the spec mandates. An unrebutted correctness or safety scenario from any member is never silently overruled: surface it (ESCALATE).
  4. Criteria precede the artifact — frozen before implementation, or from the original request in verify-only mode.
  5. No completion claims without fresh verification output. "Should pass" is not evidence; agent-reported success is checked against the actual artifact and diff.
  6. Bounded iteration. Max 3 panel rounds per slice (fresh verifiers each round) plus a separate doer-dispatch budget (default 5, complexity-weighted); whichever exhausts first -> ESCALATE to the human with the full evidence package.
Doer statusOrchestrator handling
DONEVerify diff exists and commands ran; proceed to panel.
DONE_WITH_CONCERNSCorrectness/scope concerns: address before panel. Observations: log, proceed.
NEEDS_CONTEXTSupply the missing context; re-dispatch the same model.
BLOCKEDTriage in order: more context, a more capable model, decompose the slice, escalate. Never retry the same model unchanged — change at least one of context, model, task size.
VerdictTrigger
SHIPOverall at or above target; no dimension blocked.
SHIP_WITH_CAVEATSIn the caveat band [target − 0.10, target), only non-blocking caveats. During a build this is an ITERATE trigger: each caveat fixed and re-verified, or deferred with a logged reason — final only if the human accepts.
ITERATEBelow the caveat band; a surviving blocking caveat (one asserting a correctness/safety defect, or lacking a concrete fix or logged deferral); or a blocked dimension whose causes are all localized, enumerable fixes (regardless of overall) — with a mandatory fix list. Math decides unless a verified (unrefuted) failure scenario overrides.
BLOCKThe defect set is structural: remediation needs redesign, not an enumerable list of localized fixes — or proceeding is unsafe. Low scores alone never force BLOCK: a majority-blocked dimension whose causes are all localized fixes is ITERATE with a mandatory fix list.
ESCALATEDeadlock, an unrebutted opposition scenario, or budgets exhausted. Orchestrator-only — never a panel recommendation.
Calibration: BLOCK is structural. Many severe defects that are each a localized fix in a sound architecture make ITERATE, not BLOCK — severity sets fix priority, never the verdict class. A blocked dimension (majority at 3 or below) never lets a passing overall slip through as SHIP: with localized causes it is ITERATE plus a mandatory fix list, even when overall ≥ target; only structural causes reach BLOCK. Consistency check before issuing BLOCK: if the report itself describes every defect as locally fixable, BLOCK contradicts the evidence — issue ITERATE. One member's low score is a logged dissent, not a block.
  1. 上下文隔离：分为四个角色，对应四个独立会话：编排者（拆分任务、指派角色、裁决、管理账本——不产出任何交付内容，也不进行评分）、执行者、每位验证者。一个Agent不得同时扮演两个角色（共享上下文=共享盲区=无法实现三角验证，而这正是本模式的核心价值）。执行者先完成任务；随后验证者并行运行，每位验证者仅能收到：冻结的验收标准、工件（差异文件+新文件路径，或文档及其前身）、参考资料、运行验证命令的权限、已知风险、核心技能（指定名称，需加载）。验证者绝不能收到：执行者的推理过程或自我评估、设计依据、其他验证者的首轮观点或身份、预期或过往评分。共享标准的名称不属于上下文泄露——隔离的是执行者的推理过程和评分，而非所有人需遵循的标准。
  2. 证据锚定：高分需提供工件中的原文引用；故障声明需提供文件:行号或命令输出；无证据的发现会被丢弃。在进行共识计算前，编排者需将所有影响裁决的引用与工件及规范进行比对：无法找到原文的引用会导致对应的发现被丢弃；被事实反驳的评分会被排除，并记录为被反驳的异议。裁决需基于证据——绝不能通过平均分歧来掩盖问题。
  3. 明确反对机制：小组中至少有一名成员必须持反对立场：针对交付构建最强有力的反对论据，需明确命名故障场景（输入是什么，会出现什么错误行为）。攻击方向包括：隐藏假设、过度设计掩盖的漏洞、缺失的约束、漂移风险、规范缺口、组合脆弱性。泛泛的怀疑毫无价值——需直接丢弃。需先对照规范文本确认每一项指控；绝不能标记规范要求的行为。任何成员提出的未被反驳的正确性或安全场景，绝不能被默默否决：需进行上报（ESCALATE）。
  4. 准则优先于工件——在实现前冻结，或在仅验证模式下从原始需求中提取。
  5. 无全新验证输出则不得声称完成：「应该通过」不是证据；Agent报告的成功需与实际工件及差异进行核对。
  6. 有限迭代：每个任务片段最多进行3轮评审（每轮使用新的验证者），加上独立的执行者指派预算（默认5次，按复杂度加权）；先耗尽任一预算则→将完整证据包升级上报给人类。
执行者状态编排者处理方式
DONE核对差异是否存在、验证命令是否执行；进入评审小组环节。
DONE_WITH_CONCERNS正确性/范围相关问题：在进入评审小组前解决。仅为观察意见：记录后继续流程。
NEEDS_CONTEXT补充缺失的上下文；重新指派同一模型。
BLOCKED按优先级处理：补充更多上下文、更换更强大的模型、拆分任务片段、升级上报。切勿在未做任何修改的情况下重试同一模型——至少需修改上下文、模型、任务规模中的一项。
裁决结果触发条件
SHIP整体评分达到或超过目标；无维度被阻塞。
SHIP_WITH_CAVEATS处于附加条件区间[目标值−0.10, 目标值)，且仅存在非阻塞性附加条件。在构建过程中，此结果会触发ITERATE（迭代修改）：需修复每个附加条件并重新验证，或记录理由后延期——仅当人类认可时，才可作为最终结果。
ITERATE低于附加条件区间；存在未解决的阻塞性附加条件（即断言存在正确性/安全缺陷，或缺乏具体修复方案或延期记录）；或存在被阻塞的维度，且其原因均为可本地化枚举的修复方案（无论整体评分如何）——需提供强制修复清单。除非有已验证（未被反驳）的故障场景推翻，否则由评分结果决定。
BLOCK缺陷集合具有结构性：修复需要重新设计，而非枚举本地化修复方案——或继续执行存在安全风险。仅低分绝不会触发BLOCK：若多数被阻塞的维度原因均为本地化修复方案，则触发ITERATE并提供强制修复清单。
ESCALATE出现僵局、未被反驳的反对场景，或预算耗尽。仅能由编排者触发——绝非评审小组的建议。
校准说明：BLOCK针对结构性问题。在架构合理的情况下，即使存在多个严重但可本地化修复的缺陷，也会触发ITERATE而非BLOCK——缺陷严重程度决定修复优先级，而非裁决类别。被阻塞的维度（多数评分≤3）绝不会让整体合格的结果通过为SHIP：若原因是本地化的，则触发ITERATE并提供强制修复清单，即使整体评分≥目标值；仅结构性原因才会触发BLOCK。在发布BLOCK裁决前需进行一致性检查：若报告本身描述所有缺陷均可本地化修复，则BLOCK与证据矛盾——应触发ITERATE。单个成员的低分仅记录为异议，而非阻塞。

Panel composition (derive per artifact)

小组组成（根据工件定制）

Independent vantage points triangulate ground truth; the rest is sizing. Default three lenses: quality (spec compliance first — missing / extra / misunderstood — then correctness), fitness-for-purpose (real consumer, edge cases, integration), and the adversary (must oppose). Scale to stakes — two reviewers for a small low-risk slice, five lenses for a high-stakes irreversible one — picking lenses from the artifact's actual risk surface. Example: a data-migration script risks data loss and partial failure -> transform-correctness, a rollback/idempotency adversary, operator experience; an API doc -> consistency, consumer ergonomics, a breaking-change adversary. Never give the adversary a weaker model than the rest of the panel; when available, a different model family on the panel buys uncorrelated blind spots.
独立视角可三角定位真相，其余为规模调整。默认三个视角：质量（首先检查规范符合性——缺失/多余/误解——然后检查正确性）、适用性（真实用户、边缘场景、集成情况）、反对方（必须反对）。根据风险等级调整规模——小型低风险任务片段配2名评审者，高风险不可逆任务配5个视角——从工件的实际风险面选择视角。示例：数据迁移脚本存在数据丢失和部分失败风险→选择转换正确性视角、回滚/幂等性反对方视角、操作员体验视角；API文档→选择一致性视角、用户易用性视角、破坏性变更反对方视角。绝不能给反对方分配比小组其他成员更弱的模型；若有条件，使用不同系列的模型可获得不相关的盲区。

Verifier prompt skeleton (write each prompt from this)

验证者提示模板（据此编写每个提示）

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; 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.
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; 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.

Records

记录

The deliverable is the ONLY durable artifact a tribunal run produces. Report the verdict, dissents (incl. refuted, verbatim), caveats (fixed | deferred + reason), and panel-round counts in your closing summary — and fold them into the PR description or commit message when one exists. Never leave loose files in the tree. If a run genuinely needs working files (a running ledger across many slices, temp fixtures), put them ALL inside a single gitignored 
.tribunal/
directory and never commit it; nothing else is written. Never silently drop a caveat.
交付成果是评审法庭流程产生的唯一持久工件。在最终总结中报告裁决结果、异议（包括被反驳的原文）、附加条件（已修复 | 延期+理由）及评审轮次——若存在PR描述或提交信息，需将这些内容纳入其中。切勿在目录中遗留零散文件。若流程确实需要工作文件（跨多个任务片段的运行账本、临时 fixtures），需将所有文件放入单个被git忽略的
.tribunal/
目录中，且绝不提交；不得写入其他内容。切勿默默忽略附加条件。

Plan vetting (same machinery, earlier)

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

Before executing a non-trivial plan, run it past three independent lenses: will it work (are the checks specific?), can the doer follow it, is it the cheapest sufficient path. 2-of-3 approval proceeds; otherwise merge the critiques into exactly ONE refinement pass, re-vet once, then escalate. Vetting freezes the criteria the panel later audits.
在执行非 trivial 的计划前，需通过三个独立视角进行审核：计划是否可行（检查是否具体？）、执行者能否遵循、是否为成本最低的可行方案。获得2/3的批准即可执行；否则将评审意见合并为一次精确的优化，重新审核一次，随后升级上报。审核会冻结后续评审小组将审计的准则。

Platforms

平台适配

With parallel subagents, dispatch the panel as parallel calls in one message — separate agents, real independence. Without parallel dispatch, run each role as its own sequential fresh-context session (still distinct agents), enforcing the wall by what each session receives. One agent playing every role forfeits the triangulation benefit — measured equal to no panel at all (a weak model self-simulating a panel scores at its solo floor); use only when no separate-session option exists, and label the verdict "single-context (no independence)".
End-to-end example: worked-example.md. Failure catalogue: anti-patterns.md.
若具备并行子Agent，可将小组作为并行调用在一条消息中指派——独立Agent，真正实现隔离。若无并行指派能力，可将每个角色作为独立的顺序全新上下文会话执行（仍为不同Agent），通过控制每个会话接收的内容来维持上下文隔离。单个Agent扮演所有角色会丧失三角验证的优势——效果等同于无评审小组（弱模型自我模拟小组的评分仅相当于其单独执行的最低分）；仅当无独立会话选项时才可使用，并需标记裁决结果为「单一上下文（无独立性）」。
端到端示例：worked-example.md。 故障目录：anti-patterns.md。