tribunal

Tribunal

オーケストレーターは何も構築せず、自ら採点することもありません。作業を切り分け、別の実行者に割り当て、別の検証者を招集し、証拠に基づいて裁定します。価値をもたらすのは、次の3つの振る舞いです。単独の確認では見過ごされてそのまま出荷されてしまう問題を、明示された失敗シナリオとして検出する敵対的な再確認、局所的に修正できる欠陥には「すべてを書き直す」ではなく ITERATE を下し、合格点であっても検証済みの証拠によってのみ判定を覆す調整された評決、そして主張より先に証拠をという原則です。新たな再現確認なしに「完了」とはせず、反証された主張は除外し、決して平均には含めません。開始時に次のように宣言します。「Tribunal パターンで実行します：実行者 -> 検証者パネル -> 合意。」

使用する場面

出荷後の欠陥による損失が、パネルを招集するコストを上回る、複数の要素から成る成果物や重大な成果物に使用します。些細な編集、1つの検証コマンドですべてを証明できるもの、通常のコードレビュー（変更を改善するための対話ではなく、凍結された成果物を事前に宣言された基準に照らして独立に測定し、出荷の可否を裁定するもの）には使用しません。Tribunal を入れ子にすることは決してありません。どの役割も、自らの出力に対してこのプロトコルを実行してはなりません。

ループ

1. 実装前に受け入れ基準と検証コマンドを凍結し、それらから採点項目、重み、合格目標を導き出します。再審査でも同じルーブリックを使えるよう記録します。適用されるスキル（成果物の構築や評価の方法に影響するもの。例：production-grade）を特定し、その基準を受け入れ基準に組み込みます。Tribunal スキル自体や、純粋なオーケストレーションスキルは含めません。検証のみの開始（成果物がすでに存在する場合）では、元の依頼から基準を作成します。成果物から逆算してはなりません。基準を凍結し、ステップ3から開始します。
2. 完全な作業範囲の仕様を貼り付けたうえで（「計画ファイルを読んで」と指示するのではなく）、適用されるスキルを明記し、それらを読み込むよう指示して、オーケストレーターとは別の実行者エージェントを起動します。production-grade などを読み込みます。指定されたスキルを読み込めない場合、実行者はその旨を伝え、作業を続行しません。オーケストレーターが成果物を作成または編集した場合、独立して検証できる成果物は存在せず、実行は単一のコンテキストに集約されます。実行者は実装し、検証コマンドを実行し、成果物を永続化します。つまり、実行者のセッション終了後も存続するよう、コミット、プッシュ、または公開します。そして、差分の要約、出力の逐語記録、取得可能な成果物のアドレス、およびステータスを以下の表からちょうど1つ報告します。アドレスのない DONE は DONE ではありません。
3. 報告を実際の差分と照合し、コンテキストを隔離した状態で、パネルを並行して招集します。
4. consensus-mechanics.md に従って裁定し、評決、異論、注意事項、ラウンド数を台帳に記録します。
5. SHIP -> 次のスライスへ進みます。ITERATE -> 指摘事項を新しい実行者向けの修正リストにし、新しい検証者で全項目を再採点するパネルを開きます。以前の指摘事項はリスクとして扱います。

不変条件（裁量の余地は小さく、これがこのスキルの本質です）

1. コンテキストの壁。 4 つの役割、4 つの別個のセッションです。オーケストレーター（作業を分割し、割り当て、裁定し、台帳を管理します。成果物の内容は一切作成せず、自らスコアを付けることもありません）、実行担当者、各検証担当者です。1 つのエージェントが 2 つの役割を兼ねてはいけません（コンテキストの共有は盲点の共有につながり、三角測量ができなくなります。これこそが要点です）。実行担当者が先に作業を完了し、その後、検証担当者が並行して作業します。各検証担当者が受け取るのは、正確に次のものだけです。確定済みの基準、取得可能なアドレスによる成果物（コミット SHA、ブランチ、または別のサンドボックスにいる検証担当者が自分で取得できる URI）と、インラインで提示された差分（または文書とその前バージョン）。単なる作業ツリーのパスでは不十分です。実行担当者のセッション内でしか解決できず、セッション終了とともに失われるためです。また、参照資料、検証コマンドを実行する権限、既知のリスク、実際に使用するスキル（名前を明示し、読み込めるようにする）も受け取ります。検証担当者は、実行担当者の推論や自己評価、設計の根拠、他の検証担当者の第 1 ラウンドでの見解や身元、予想スコアや過去のスコアを決して受け取りません。共通の標準を明示することは壁を破ることではありません。壁によって伏せられるのは実行担当者の推論とスコアであり、全員が評価される基準ではありません。
2. 証拠へのひも付け。 高いスコアには、成果物からの逐語的な引用が必要です。失敗の主張には、ファイル名と行番号、またはコマンド出力が必要です。証拠のない指摘は破棄します。合意形成の計算を行う前に、オーケストレーターは判定を左右するすべての引用を成果物と仕様に照らして grep します。逐語的に見つからない引用があれば、その指摘を破棄します。事実に反すると確認されたスコアは除外し、反証された異論として記録します。証拠に基づいて裁定し、意見の相違を平均して消し去ってはいけません。
3. 明示的な反対意見。 パネルのメンバーの少なくとも 1 人は反対しなければなりません。出荷に反対する最も強い根拠を、失敗シナリオとして明示してください（どの入力で、どのような誤った挙動が起こるか）。攻撃の観点は、隠れた前提、バグを覆い隠す過剰設計、制約の欠落、変更による逸脱のリスク、仕様の不備、構成要素の脆弱さです。一般論にとどまる懐疑論には価値がなく、破棄します。まずすべての非難を仕様の文面と照合して確認し、仕様が要求する挙動を決して問題として指摘してはいけません。いずれかのメンバーが挙げた正確性または安全性に関するシナリオが反論されていない場合、黙って却下してはいけません。明示して、ESCALATE してください。
4. 基準は成果物より先に確定します。実装前に確定するか、検証のみのモードでは元の依頼から定めます。
5. 最新の検証出力なしに完了を主張してはいけません。 「通るはず」は証拠ではありません。エージェントが報告した成功は、実際の成果物と差分に照らして確認します。
6. 反復には上限を設けます。 スライスごとにパネルラウンドは最大 3 回（各ラウンドで新しい検証担当者を起用）、これとは別に実行担当者への作業割り当て回数の上限を設けます（デフォルトは 5 回、複雑さに応じて調整）。いずれかの上限に達したら、証拠一式を揃えて人間に ESCALATE します。両方のカウンターは引き継ぎ情報または永続的な台帳に記載し、オーケストレーターのコンテキストだけに置いてはいけません。割り当てのたびに、ラウンド番号と残りの予算を明示します。オーケストレーターの再起動やコンテキストのリセットで忘れられる上限は、上限とは言えません。その場合、実行は無期限にパネルを再実施してしまいます。

実行担当者のステータス	オーケストレーターの対応
DONE	差分が存在すること、コマンドが実行されたこと、報告されたアドレスが解決できることを確認します。取得可能なアドレスがない DONE は NEEDS_CONTEXT として扱い、成果物を取得可能な状態にするため差し戻します。その後、パネルを実施します。
DONE_WITH_CONCERNS	正確性またはスコープに関する懸念は、パネルの前に解消します。所見は記録して先に進みます。
NEEDS_CONTEXT	不足しているコンテキストを補い、同じモデルに再度割り当てます。
BLOCKED	次の順に対処します。コンテキストを追加する、より高性能なモデルを使う、スライスを分割する、人間にエスカレーションする。同じモデルに何も変更せず再試行してはいけません。コンテキスト、モデル、タスクの規模のうち、少なくとも 1 つを変更します。
判定	トリガー
---	---
SHIP	全体スコアが目標以上で、ブロックされた次元がない場合。
SHIP_WITH_CAVEATS	注意事項の範囲［目標 − 0.10，目標）内で、ブロック要因ではない注意事項のみがある場合。ビルド中は ITERATE のトリガーとなります。各注意事項を修正して再検証するか、理由を記録して先送りにします。最終判定として出せるのは、人間が受け入れた場合のみです。
ITERATE	注意事項の範囲を下回る場合、解消されていないブロック要因がある場合（正確性または安全性の欠陥を指摘している、具体的な修正方法や記録済みの先送りがない）、または、ブロックされた次元の原因がすべて特定済みで列挙可能な修正である場合（全体スコアに関係なく）。修正リストが必須です。Math が判定を決めます。ただし、検証済み（反証されていない）の失敗シナリオがある場合は、それが優先されます。
BLOCK	欠陥群が構造的な場合、つまり列挙可能な個別修正ではなく再設計が必要な場合、または続行が危険な場合です。スコアが低いという理由だけで BLOCK になることはありません。過半数がブロックされた次元でも、原因がすべて個別修正であれば、修正リストを必須とする ITERATE です。
ESCALATE	膠着状態、反駁されていない反対シナリオ、または予算切れの場合です。オーケストレーターのみが使用でき、パネルの推奨としては決して使用しません。

キャリブレーション：BLOCK は構造的な判定です。健全なアーキテクチャにおいて、深刻な欠陥が多数あっても、それぞれが個別修正で対応できるなら BLOCK ではなく ITERATE となります。深刻度は修正の優先順位を決めますが、判定クラスは決めません。ブロックされた次元（過半数が 3 以下）は、合格した全体スコアを SHIP として通すことは決してありません。原因が個別に修正可能なら、全体スコアが目標以上であっても、必須の修正リストを伴う ITERATE となります。構造的な原因がある場合にのみ BLOCK となります。BLOCK を出す前に整合性を確認してください。報告書であらゆる欠陥を個別に修正可能と説明しているなら、BLOCK は証拠と矛盾するため、ITERATE を出してください。1 人のメンバーの低いスコアは、記録された異議であり、ブロック要因ではありません。

パネル構成（成果物ごとに導出）

独立した視点で三角測量を行い、真実に近づけます。それ以外は規模に応じて調整します。既定の 3 つの視点は、品質（仕様準拠を最優先し、欠落／過剰／誤解を確認した後、正確性を確認）、目的適合性（実際の利用者、エッジケース、統合）、敵対者（反対意見を述べることが必須）です。リスクに応じて規模を調整します。リスクの低い小さな範囲ならレビュー担当者 2 人、取り返しのつかない高リスクのものなら 5 つの視点とし、成果物が実際に持つリスク要因から視点を選びます。例：データ移行スクリプトには、データ損失と部分的な失敗のリスクがあります。そのため、変換の正確性、ロールバック／冪等性の敵対的検証、オペレーターの使いやすさを確認します。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/ 内に置き、決してコミットしないでください。それ以外のものは書き込まないでください。注意事項を黙って削除してはいけません。

計画の審査（同じ仕組みを事前に実施）

重要な計画を実行する前に、独立した 3 つの視点で審査します。計画は機能するか（チェックは具体的か）、実行者が手順に従えるか、十分な結果を得られる最も低コストの方法かを確認します。3 つのうち 2 つが承認すれば進めます。それ以外の場合は、批評をまとめてちょうど 1 回の改善を行い、再審査を 1 回実施してからエスカレーションします。審査によって、その後パネルが監査する基準を固定します。

プラットフォーム

並列サブエージェントを使う場合は、1つのメッセージでパネルを並列呼び出しとしてディスパッチし、それぞれを独立したエージェントにしてください。並列ディスパッチを使わない場合は、各役割を個別の新しいコンテキストセッションで順番に実行し（それぞれ別のエージェントを使用）、各セッションに渡す情報を制限することで境界を保ってください。1つのエージェントにすべての役割を担当させると、三角測量の利点が失われ、パネルを使わない場合と同等になります（弱いモデルでパネルを自己シミュレーションしても、単独時の下限と同じスコアになります）。別々のセッションを使えない場合に限ってこの方法を使用し、判定には「single-context (no independence)」と明記してください。

切り離されたオーケストレーション（実行が1回のターンを超えて続く、または中断される場合）：ランタイムの待機プリミティブによってオーケストレーターのターンが終了する場合、そのプリミティブに渡されるものはすべて記録用であり、コミュニケーションではありません。まだ誰にも何も伝わっていません。再開したオーケストレーターがそれを書き込んだオーケストレーターとは限らないため、引き継ぎには成果物のアドレス、ラウンド番号、残りの予算を含めてください。再開時には、次の動きを決める前に、依頼者が実際に何を受け取ったかを確認してください。実行が終了しても、配信されたことにはなりません。

エンドツーエンドの例：worked-example.md。 失敗事例一覧：anti-patterns.md。