raichominev/concilium

Concilium — クロスモデル敵対的レビュー

第二の、異なるモデルがユーザー（またはあなた）の主張を敵対的にレビューします。異なるモデル系統は異なる盲点を持つという点が価値です。レビュアーは提案（PROPOSE）を行い、呼び出し側のセッションが承認（RATIFY）します。どちらかの側の確信を証拠の代わりにしてはいけません。

Claude Codeから指揮を執るように設計されています — Opus 5とFable 5はどちらも第一級の承認席です（ブラインド結果予測ベンチマークで椅子の同等性が測定されています。任意のClaudeモデルがループを駆動できますが、承認者はこの2つのうちの1つであるべきです）。GPT側（codex経由のsol/terra/5.5）は独立した調査と機械的実行を行います — このクロスファミリーの席は耐荷重性があります。同じ系統の椅子が共同で見逃すものを測定可能な形で捉えます。

前提条件（環境ごとに一度確認）

1. codex login status → 「Logged in using ChatGPT」と表示される必要があります（サブスクリプションOAuth — APIキーは不要であり、サブスクリプションをAPIキーとして使用することはできません。プロキシ/ルーターブリッジは試さないでください）。

2. 利用可能なモデルを確認する：codex debug models または ~/.codex/models_cache.json。モデルが「requires a newer version of Codex」とエラーを出す場合は、codex update を実行して再試行してください。

3. 新しい環境で初めて使用する場合は、評決を信頼する前にキャリブレーションブートストラップ（references/setup.md）を実行してください。既知の真理推論テスト、次に1つの簡単な実タスク、最後に（オプションで）ティアモデルを選択するための直接対決を行います。

4. Kimi席 — 実験的かつオプトイン。デフォルトラウンドの一部にはなりません。 ユーザーが明示的に第三の系統を要求した場合にのみ追加してください。2つのトランスポートがあり、それぞれに独自のラッパーがあります：

   • Kimi Desktop（Windows）。 scripts/concilium-review-kimi.ps1 は、アプリにバンドルされたdaimonランナーを自身のElectron環境で駆動します。デスクトップアプリのインストールとサインインが必要です。
   • Kimi Code CLI（Linux/macOS/Windows）。 scripts/concilium-review-kimi.sh は、クロスプラットフォームでMITライセンスのCLIを駆動します — ヘッドレス kimi -p とデバイスコードOAuthにより、コンテナや使い捨てVMに適しています（動作例：references/isolated-guest-vmware.md）。⚠ プリントモードはすべてのツール呼び出しをデフォルトで自動承認するため、そこでの分離は予防策ではなく前提条件です。⚠ 常に --model を渡してください：CLIの組み込みデフォルトはフラッグシップよりも古い世代であり、出力にその名前は記載されません。

   codexよりもキャリブレーションされていますが、不安定です。また、分離に関しては弱いです。パス、モデル、サンドボックス、および注意点については、references/setup.md と 落とし穴 #18–21 を参照してください。

ティアマトリックス（デフォルトは現在のモデル — インストールごとに上書き可能）

ティア	デフォルト	努力度	使用目的
研究	フラッグシップ（例：gpt-5.6-sol）	最大	オープンレビューラウンド、敵対的検証
機械	前フラッグシップ（例：gpt-5.5）	中	既知の主張を1回のプローブで検証
ランナー	低コストティア（例：gpt-5.6-terra）	低	実行と報告：スクリプトの実行、インポートの監視

研究ティアのラッパーは、すべての席でデフォルトで最大に設定されます。努力度の語彙は異なり、正確に把握する価値があります。codexは none · minimal · low · medium · high · xhigh · max を受け入れます（測定済み — APIはこれ以外を拒否し、enumを名前として返します）。kimi席は low · high · max を受け入れます。

努力度は第二の系統の代わりにはなりません — 制御下で測定済み。 1つの席（gpt-5.6-sol）を同じ14項目の予測パケットに対して、low/medium/high/xhigh/maxおよび同じ努力度のレプリケートを加えた6回実行した結果：同じ努力度での2回の実行で10/14をカバーしましたが、異なる努力度のペアでは平均8.9でそれを超えることはありませんでした。6回のアンサンブル全体でも10/14にしか達せず、2回実行のノイズフロアと等しく、1つのcodex+kimiペアと同等でした。精度は努力度に対して単調ではありませんでした（high 9、max 9、xhigh 7、medium 7、low 7）が、壁時間は8倍に増加しました（21秒→166秒）。4項目はすべての努力度のすべての実行で見逃されました — そしてクロスファミリー席はそのうちの2つを捉えました。努力度を変えても同じ盲点を再サンプリングするだけです。盲点を動かすのは異なる系統です。 カバレッジが必要なら、計算量ではなくファミリーを追加してください。-Mechanical は意図的なダウングレードであり、medium に留まります。

ランナータスクはレビューではありません — ラッパーをスキップして、codexを直接呼び出してください： codex exec -m <cheap-model> -c model_reasoning_effort=low [-s read-only unless it writes] "<task>" < /dev/null 直接の非対話型呼び出しでは常にstdinを閉じてください（bashでは < /dev/null、PowerShellでは $null | codex …）— 開いた非TTYのstdinはcodexを「Reading additional input from stdin...」で永久にブロックし、孤立したプロセスは親シェルのタイムアウトを生き延びます（落とし穴 #10、ラッパーは免疫があります — stdinをパイプ経由で渡します）。

レビューの実行

バンドルされたラッパーを使用してください。ラッパーは共有レビューコントラクトを references/contract.md から読み込みます（単一の真実の情報源 — 反証プローブ、代替説明、注意点、評決提案、スキーマ/エンコーディングルール。コントラクトはそこで編集してください、スクリプト内では決して編集しないでください）。また、出所スタンプを追加します。両方のラッパーは機能的に同一です。プラットフォームに応じて選択してください：

Linux / macOS（bash）：

• クレーム：scripts/concilium-review.sh claim "<claim>"
• diff：scripts/concilium-review.sh diff [base-branch]
• 環境変数による設定：MODEL、EFFORT、MECHANICAL=1（メカニカルティア）、REPO_DIR、PROJECT_RULES（ルールファイルパス）。
• クローン後の初回使用：chmod +x scripts/concilium-review.sh。

Windows（PowerShell 5.1+）：

• クレーム：powershell -ExecutionPolicy Bypass -File scripts/concilium-review.ps1 -Claim "<claim>" [-Mechanical] [-RepoDir <path>] [-ProjectRules <file>]
• diff：... -Diff [-Base <branch>] — -RepoDir のワーキングツリーdiffをレビューします。

Kimi第三系統席 — 実験的、オプトイン。 デフォルトラウンドの一部ではありません。ユーザーが第三の系統を明示的に要求した場合のみ追加してください。2つのラッパーがあり、同じコントラクトと同じ5つのブロックを持ちます： concilium-review-kimi.sh（クロスプラットフォームCLI、環境変数で設定 — そこでは MODEL が必須）および concilium-review-kimi.ps1（Windowsデスクトップランナー）。

デスクトップラッパーは同じ -Claim/-Diff/-RepoDir/-ProjectRules/-PriorRounds インターフェースに加えて、-Model（デフォルト k3-agent）、-Effort（low|high|max）、-RawPrompt（コントラクトなし、キャリブレーションプローブ用）を受け付けます。2つの席固有の違いがあり、両方とも測定済みです：CLAUDE.md の自動ブリッジングはここではデフォルトでOFF — 注入は確実に Connection error. で実行を停止させるため、-AutoRules によるオプトインとなっています。代わりに -ProjectRules <file> を使用してレビュアーにコンテキストを与えてください。また、その終了コードは決して信頼しないでください — その失敗でも終了コード0で終了するため、5つのブロックを確認してください。複数行のプロンプトはこのラッパーを経由する必要があります。bashから直接 kimi-daimon --prompt を呼び出すと、argvが壊れます（落とし穴 #18–19）。

この席にはサンドボックスがありません — 使い捨てのコピーを与えてください。 -SandboxFrom <dir> は、ツリーを一時ディレクトリにコピーし（.git、仮想環境、秘密情報のようなファイルを除外）、そこでエージェントを実行し、作成/変更/削除されたものを正確に出力し、-KeepSandbox が指定されていない限りコピーを削除します。デフォルトでこれを使用してください。これが何を保証するかを明確にしてください：workDirは境界ではありません — その外部のカナリアが絶対パスで読み取られ、そのまま返されました（落とし穴 #20）。したがって、これは爆発半径の制御と監査証跡であり、封じ込めではありません。マシン上のマテリアルがプロバイダーに到達してはならない場合は、OSレベルで分離してください（ACLを持つ別のアカウント、またはVM）。

ブラインドラウンドの場合、同じ多孔性からのリスクは損傷ではなく汚染です：実際のツリーに迷い込んだエージェントが答えを見つける可能性があり、ラウンドは静かにブラインドではなくなります。-WatchPaths <a,b,c> を追加してください — 読み取り禁止でなければならないもの（実際のリポジトリ、結果ログ、解答鍵）のNTFS最終アクセス時刻をスナップショットし、実行中に読み取られたものを報告します。両方向の既知のエスケープに対して検証済みです。信頼する前に落とし穴 #21 を読んでください。特に、同じチェックの列挙ベースのバージョンが、実際にエスケープした実行でも「クリーン」と報告した理由についてです。

運用ルール（それぞれは測定された障害です — 理由は references/pitfalls.md にあります）：

• 最初の呼び出しから、バックグラウンドでフル約10分のタイムアウトで実行してください。 実際のレビューは高努力度で5～15分以上かかります。フォアグラウンドのタイムアウトでは、レビューはプローブ途中で強制終了されます。
• タイムアウトしたセッションを再開するよりも、新しいセッションを優先してください。 長い再開チェーンはコンテキスト圧縮に直面します — レビュアーの初期の注意深い読書は、最終的で結果を左右するステップの前に、損失のある要約で圧縮されます。
• 絶対にベア再開をしないでください。 codex exec resume は、モデルとサンドボックスをユーザーのconfig.tomlのデフォルトに静かにリセットします。再開する必要がある場合（またはセッション途中でモデルを切り替えたい場合）、すべてを再固定してください： codex exec resume -m <model> -c sandbox_mode="read-only" -c model_reasoning_effort=<tier> <session-id> - フラグは位置引数のセッションIDの前に置きます。重要なのは sandbox_mode です — -c sandbox=... は静かに無視され、resumeには -s フラグはありません。クロスモデルの再開はコンテキストを保持します。
• レビュアーはチャットボットではなくフルエージェントです — 読み取り専用サンドボックスはファイル書き込みをブロックしますが、読み取りコマンドやDBのSELECTはブロックしません。レビューするすべてのものは第二のモデルのプロバイダーに送信されます。
• 進捗をライブで監視し、盲目的に待たないでください — そして正しいストリームを監視してください。 コントラクト（ルール9）により、レビュアーは作業中に STATUS: の一行メッセージを出力し、codexは徐々に書き込みます — しかし、ストリームは分割されています（ライブで検証済み）：1> out 2> err の場合、最終的な5つのブロックはstdoutに出力されますが、ストリーミング転写（バナー、STATUS行、ツール呼び出し）はstderrに出力されます。進捗 + 失敗シグネチャを監視するには、tail/monitorをstderrに向けてください。評決を読むにはstdoutを読んでください。注意点：PowerShellの 1>/2> リダイレクトはUTF-16を書き込むため、grepする前に適宜デコードするか（またはUTF-8強制ステップを経由してリダイレクトする）必要があります。
• ブラインドラウンドには、指示ではなく構造的な分離が必要です。 ラウンドがプライミングされていない必要がある場合（ブラインド評価、リクエストテンプレートごとのフレーミング上重要なブラインドファーストパス）、自動ルールのブリッジングをOFFにして（-NoAutoRules / NO_AUTO_ROLES=1）、クリーンなディレクトリでレビュアーを実行してください：プロジェクトコンテキストを保持し、「パケットのみから答えるように」指示されたモデルでも、そのコンテキストを測定可能な形で使用します（落とし穴 #16–17）。

承認プロトコル（呼び出し側セッションの役割）

レビュアーは5つのブロックを返します：PROBE / ALT / CAVEAT / VERDICT-PROPOSAL / PHASE-LOG。 中継または実行する前に：

1. 実際のプローブ（クエリ/コマンド）を読んでください、散文の要約だけではなく。
2. 極端な結果は警告です：最初の試行で0%または100%は、通常、発見ではなく、間違った結合キー、間違ったスコープ、または間違ったテーブルを意味します。受け入れる前に、プローブの耐荷重ステップを自分で検証してください。
3. スコープの不一致を確認してください：2つのプローブが異なるスコープで事実上正しい可能性があります（1つのテーブル vs DB全体、1つのソース vs すべてのソース）。数値を比較する前にスコープを指定してください。
4. 反証された / 古い / 不完全を区別してください。 「今日は数値が異なる」ということは、その主張が書かれた時点で間違っていたことを意味しません — 「反証された」と言う前に、履歴/タイムスタンプを確認してください。
5. 最終的な評決タグは自分で割り当ててください：[V-code]（ソースに対して検証済み、ファイル:行を引用）/ [V-db]（読み取り専用クエリ、引用）/ [V-probe]（再実行可能スクリプト）/ [C]（未検証）/ [X]（反証 — 何がそれを置き換えるかを指定）。提案は入力であり、答えではありません。
6. 系統ごとに一致を評価してください。 同一系統の確認（Claudeの椅子がClaudeのオーケストレーターに同意する）は弱い証拠です — 同一系統の椅子は誤った答えを共有することが測定可能であり、独立して同一の誤った推論を生成することもあります。クロスファミリーの確認または反証は、同一系統の投票の数を上回ります。系統を共有する椅子間の多数決で争いを解決しないでください。第三の系統（Moonshot）は実験的なオプトイン席として利用可能です。第三の席は、独立していない限り何も得られません — 頭数ではなく系統で評価してください。また、全会一致のパネルは単に項目が簡単だったことを意味する場合があることに注意してください（setup.md）。

conciliumループ（反復ラウンド）

多くの場合、単一のレビューパスで十分です。しかし、レビュアーのプローブにギャップがある場合、またはあなた（オーケストレーター）が防御可能な根拠に基づいて提案に同意できない場合、1回の交換はconciliumにはなりません — 評議会は審議します。ループは、評決が収束するか、争いが本物であることが証明されるまで、レビューラウンドを実行します。このループはあなた、つまり呼び出し側のClaudeセッションによってオーケストレーションされます — これはプロトコルであり、スクリプトではありません（承認ステップはあなたの判断です。自動化できるものは何もありません）。

各ラウンド：

1. レビューを実行する（ラッパー）→ 5つのブロックを取得 → 上記のプロトコルに従って承認する。
2. ラウンドの結果を決定し、それに応じて行動する：

結果	条件	アクション
収束	プローブの耐荷重ステップを検証し、それが有効である	停止 — 最終タグを発行する。
争い	プローブにギャップ、間違ったスコープがある、または特定の証拠に基づく異議がある	このラウンドのPROBE + あなたの異議をラウンドファイルに書き込む。-PriorRounds/PRIOR_ROUNDS でそれを指すようにして、次のラウンドを実行する。
乾燥	ラウンドが新たな確認可能な証拠を追加しない — レビュアーが再主張するか、CAVEATで新しいパスがないと言う	停止 — 未解決の質問とともに [C]/[POLICY] としてオーナーにエスカレーションする。これは発振防止ガードである。
上限	ラウンド制限（デフォルト3）に達したが収束しない	停止 — 状態を提示してエスカレーションする。真の争いは発見であり、失敗ではない。

設計ルール（これらは落とし穴から直接導かれます）：

• ラウンドごとに新しいセッション — 決して再開チェーンを使わないでください。 このループはまさに落とし穴 #3 が警告する「長いチェーン」です。コンテキストを前方に運ぶには、codex exec resume ではなく、-PriorRounds ファイルを使用してください。各ラウンドはクリーンに開始し、既に試行された内容のコンパクトな要約のみを確認します。
• すべてのラウンドは新しい証拠パスを追加しなければなりません。 コントラクト（ルール8）はこれをレビュアー側で強制します。あなたは自分の側で強制します — 異議は、証拠に裏打ちされているか、具体的で確認可能なギャップを指している場合にのみ、ラウンドに値します。「納得できない」はラウンドではありません。
• 承認者は固定（あなた / Fable）。レビュアーは争いが狭まるにつれてティアを下げることができます。 ラウンド1は研究ティアで行います。機械的な詳細に絞り込まれたら、

（以下、翻訳が切り詰められています）