auto-review-loop

自動レビュー・ループ：自律的な研究の改善

🔒 このスキルを /loop、/schedule、または CronCreate でラップしないでください。 すでに内部でループ（レビュー → 修正 → 再レビュー）しており、レビュアーは 1 つの threadId（codex-reply）で各ラウンドのメモリを保持します。外部タイマーを設定すると、各回で最初から再実行されます — 新しい threadId が割り当てられ、レビュアーのメモリがリセットされます — 成果物の変更ではなく、壁時計の時刻に基づいて判定が下されます。新しいシグナルはゼロなのに、トークンコストは全額発生します。何かをスケジュールしたい場合は、その前にある外部の待機時間（実験の完了後 → その後に一度だけ実行）をスケジュールしてください。shared-references/external-cadence.md を参照してください。

自律的に反復します：レビュー → 修正を実装 → 再レビュー。独立したレビュアーがポリシーで承認された肯定的な評価を下すか、MAX_ROUNDS に達するまで続けます。

コンテキスト：$ARGUMENTS

定数

• MAX_ROUNDS = 4
• POSITIVE_THRESHOLD: score >= 6/10 AND verdict ∈ {"ready", "almost"} — 両方を満たす必要があります。これは、実際に適用される Phase-E の STOP CONDITION と完全に一致します。verdict の語彙は {"ready", "almost", "not ready"} です（スコアが高くても verdict が "not ready" の場合、ループは停止しません）。以前の記述では or と古い verdict の集合（"accept"/"sufficient"/"ready for submission"）が使われていましたが、これは内部的な矛盾でした。AND 形式が正式な指定です。
• REVIEW_DOC: review-stage/AUTO_REVIEW.md（累積ログ） (レガシープロジェクトでは ./AUTO_REVIEW.md にフォールバックします)
• REVIEWER_MODEL = gpt-6-astra — Codex バックエンドのデフォルトモデルです。OpenAI モデルである必要があります（例：gpt-6-astra、gpt-6.1-sol）。Manual バックエンドではユーザーが選択したモデルを使用します。異なるファミリー（OpenAI、Anthropic、Google、DeepSeek、Moonshot/Kimi、Qwen）の認識済みモデルである必要があります。
• REVIEWER_BACKEND — インラインまたはプロジェクトでバックエンドが選択されていない場合、auto として開始します。Step -1 では、最初のレビューに対して、ネイティブマーカー／チャレンジのプローブを2回の呼び出しで正確に1回実行します。バインドされた Copilot CLI ルートセッションでは copilot-native（組み込みの補完用 rubber-duck サブエージェント）を使用し、バインドされていないホスト、または Copilot 以外のホストでは、従来の codex デフォルトを維持します。インラインまたはプロジェクトで codex、antigravity/gemini、grok、claude-code、oracle-pro、agy、manual のいずれかを選択すると、プローブは省略されます。明示的に — reviewer: copilot と指定すると、互換性のある copilot --agent 駆動モードと、後続の Codex/manual ファイナライザーが維持されます。ネイティブ経路では、ホストセッションイベントから実際のモデル ID を両方取得するため、COPILOT_CLI や呼び出し元が指定する --executor-model は不要です。shared-references/reviewer-routing.md を参照してください。
• OUTPUT_DIR = review-stage/ — レビュー段階のすべての出力先です。存在しない場合はディレクトリを作成します。
• HUMAN_CHECKPOINT = false — true の場合、各ラウンドのレビュー後（Phase B）に一時停止し、スコアと弱点をユーザーに提示します。Phase C に進む前にユーザーの入力を待ちます。ユーザーは、提案された修正を承認する、独自の変更指示を提示する、特定の修正をスキップする、またはループを早期終了することができます。false（デフォルト）の場合、ループは完全に自律的に実行されます。
• COMPACT = false — true の場合、(1) セッション復旧時に完全なログを解析する代わりに EXPERIMENT_LOG.md と findings.md を読み込み、(2) 各ラウンドの後に重要な所見を findings.md に追記します。
• REVIEWER_DIFFICULTY = medium — レビュアーの敵対的な度合いを制御します。レベルは3段階です：
  • medium（デフォルト）：現在の動作です。MCP ベースのレビューで、レビュアーにどのコンテキストを見せるかはエグゼキューターが制御します。
  • hard：Reviewer Memory（レビュアーがラウンドをまたいで独自の疑念を追跡します）と Debate Protocol（エグゼキューターが反論し、レビュアーが裁定します）を追加します。
  • nightmare：hard のすべてに加え、選択されたレビュアーがリポジトリを直接読み取ります（Codex 経路では codex exec）（エグゼキューターはレビュアーに見える内容をフィルタリングできません）。さらに Adversarial Verification（コードが主張と一致しているかをレビュアーが独立して確認します）を追加します。
• RENDER_HTML = true — true（デフォルト）の場合、ループ終了時に /render-html を使って review-stage/AUTO_REVIEW.md を HTML に自動変換します。--no-review を使用します（ループ自体がクロスモデルレビューであり、HTML は構造を変換したものです）。スキップするには false を設定するか、— render html: false を渡します。

⚠️ Nightmare と Manual の非互換性：REVIEWER_BACKEND = manual かつ REVIEWER_DIFFICULTY = nightmare の場合、次のメッセージを表示して停止します： "difficulty: nightmare requires direct repository access and is not compatible with --reviewer: manual. Use difficulty: hard, or select a file-reading reviewer."

💡 上書き：/auto-review-loop "topic" — compact: true, human checkpoint: true, difficulty: hard

レビュアーの呼び出し規約

レビューを開始する前に、レビュー担当の選択を解決してください。呼び出し時の — reviewer: → プロジェクトの .aris/reviewer.json → ホストのデフォルトの順に確認します。reviewer_route.py を --host claude-code --tier regular（または実際の Copilot ホスト）で使用し、integration-contract.md §2 および reviewer-backends.md に従って解決してください。インラインとプロジェクトの両方でバックエンドが選択されていない場合に限り、以下の自動ホストプロトコルに進みます。設定が無効な場合は REVIEW_UNAVAILABLE です。ホストのデフォルトを決定した後、そのバックエンドに対してプロジェクトのモデル／エフォートを解決してください。モデルオプションを別のプロバイダーに引き継いではいけません。

解決したルート、cwd、セッション ID を REVIEW_STATE.json に保存し、再開時に復元してください。要求されたモデル／報告されたモデルと実際のエフォートも含めます。プロバイダー／モデル／固定セッションオプションが変更された場合は、新しいセッションが必要です。ルートのないレガシー状態では、以下の既存のバックエンド復旧手順に従います。明示されたレビュー担当の指示は、子レビュー スキルに引き継いでください。以下の Codex のピン留め設定／例は Codex に適用されます。

レビュー担当を呼び出す際は、REVIEWER_BACKEND に応じて分岐してください。

REVIEWER_BACKEND ∈ {antigravity, grok, claude-code} の場合： reviewer-backends.md で選択された初回／返信プロトコルに従い、同じ実質的なプロンプト、成果物のパス、メモリを使用してください。cwd はレビュー入力を含むディレクトリに設定します。Medium／hard では新しいセッションを開始してから継続し、nightmare では選択したルート上で、以下の完全な Nightmare 検証プロンプトを使い、成果物を読み込む新しい敵対的レビューセッションを開始します。実際のコード／結果を検査しなければなりません。実行担当者の報告を読むだけでは不十分です。通常のセッションと nightmare のセッションの ID は分けてください。反論には、異議のあるレビューを行ったセッションを使用します。すべての呼び出しで、正常な完了と必要な範囲を確認してください。ディスパッチ前に完了状態、範囲、報告された識別情報をリセットし、前のラウンドから引き継がないでください。レビューが利用できない、または不完全な場合は REVIEW_UNAVAILABLE とします。

インラインでもプロジェクト設定でもレビュー担当バックエンドが指定されていない場合： REVIEWER_BACKEND を auto に設定します。最初のラウンドの Step -1 で、正規の4層ヘルパーチェーンを使って copilot_native_evidence.py を解決してください。新しいバインディング <run_id>_r<round>_review_<8-random-hex> を生成し、marker を呼び出して待機した後、challenge を2つの独立したルート Bash 呼び出しとして呼び出します。Copilot の Bash 呼び出し間では変数が共有されないため、両方の呼び出しにバインディングのリテラル値と解決済みの具体的なヘルパーパスを指定してください。challenge がバインドされた場合は、REVIEWER_BACKEND を copilot-native に設定し、同じ challenge を初回レビューに使用します。Phase A では、2回目のアクティベーション challenge を実行しないでください。現在の Copilot ルートセッションがバインドされていないために終了コード 3 となった場合は、codex を使用します。明示されたレビュー担当の指示がある場合、このプローブは実行しません。ヘルパーがない場合、ネイティブでの受け入れは利用できません。外部バックエンドが利用可能であることを確実に確認できる場合に限り Codex を使用し、それ以外は REVIEW_UNAVAILABLE を出力してください。

REVIEWER_BACKEND = copilot-native の場合： challenge の nonce と、ホストが報告した実行担当モデルを読み取ってください。ホストのネイティブ task ツールを agent_type: rubber-duck で呼び出します。サブプロセスを開始せず、レビュー担当モデルも指定しないでください。プロンプトには、単独の行として正確な ARIS_REVIEW_NONCE=<nonce>、成果物／差分のパス、出力契約、および（ラウンド 2 以降は）review-stage/REVIEWER_MEMORY.md を含めます。実行担当者の要約や修正の経緯は含めません。タスクの完了後、copilot_native_evidence.py verify を呼び出して、証拠と生の応答の成果物を作成してください。検証では、リンクされた rubber-duck のライフサイクルが正常に完了したこと、およびホストが報告したモデルファミリーが既知で互いに異なることを確認しなければなりません。 エビデンスを review_gate.py --native-evidence と save_trace.sh --backend copilot-native --native-evidence の両方に渡します。条件を満たすネイティブの肯定判定は、そのまま終了して構いません。外部ファイナライザーは不要です。ネイティブの否定判定の場合は、次のラウンドで新しいマーカー／チャレンジ／サブエージェントを使って続行します。判定を伴うネイティブ呼び出しはすべて、ハードモードの反論判定も含めて、一意の <run_id, round, purpose> アーティファクトセットを使用し、チャレンジを正確に1つ含める必要があります。エビデンスがない場合、ファミリーが同一または不明な場合、エビデンスの形式が不正な場合、古い場合、または一致しない場合は、判定として扱いません。ネイティブの相補的なディスパッチを利用できない場合は、利用可能であることが明確に確認できる反対ファミリーのバックエンドにのみフォールバックします。Anthropic／Google のエグゼキューターの場合は Codex、OpenAI のエグゼキューターの場合は、OpenAI 以外のモデルを報告する手動レビューにフォールバックします。それ以外の場合は REVIEW_UNAVAILABLE を出力します。プロトコルの全文： shared-references/reviewer-routing.md。

REVIEWER_BACKEND = copilot の場合： --executor-model を必須とします： 指定されていない場合は REVIEW_UNAVAILABLE を出力します。 --executor-model からエグゼキューターのファミリーを特定します（reviewer-routing.md を参照）。 ルーターが反対ファミリーのプロファイルを選択します：

• executor_family=openai → profile="aris-reviewer-claude" (anthropic)
• executor_family=anthropic → profile="aris-reviewer-openai" (openai)
• executor_family=google → profile="aris-reviewer-openai" (openai, default cross)
• executor_family=unknown → REVIEW_UNAVAILABLE（フェイルクローズ）。 プロファイルファイルが .github/agents/<profile>.agent.md に存在することを確認します。 ファイルが存在しない場合は REVIEW_UNAVAILABLE を出力します。 model: フィールドを読み込んで REVIEWER_MODEL に格納し、そのモデル文字列から reviewer_family を導出して、executor_family と異なることを確認します。同じ値をサブプロセスの --model に渡します。呼び出し元が指定したファミリーラベルや、Auto セッションでプロファイルのみを指定する方法を決して信用しないでください。 ID の保証： --executor-model は呼び出し元が宣言するルーティング入力であり、実行時の証明ではありません。executor_model_source: caller-declared、導出された family_relation、および independence_verified: unverified を記録します。異なるモデル文字列のペアを、独立性が検証済みであるとして扱ってはなりません。 機能ゲート： copilot --help に --model、--effort、および --allow-tool が記載されている必要があります。記載されていない場合は REVIEW_UNAVAILABLE を出力します。 **Copilot CLI で文書化されている形式の copilot --agent サブプロセスを使用し、**選択したプロファイル、--model "$REVIEWER_MODEL"、--effort xhigh、および各レビュー呼び出しの --allow-tool=read を指定します。 複数ラウンド： 各ラウンドでは、同じプロファイルを使って新しい copilot --agent 呼び出しを行います。レビュアーの記憶は review-stage/REVIEWER_MEMORY.md アーティファクトを介して引き継ぎます。 copilot CLI を利用できない場合、そのドライブラウンドでは REVIEW_UNAVAILABLE を出力します。別のトランスポートにひそかに置き換えてはなりません。後続の Copilot による肯定判定には、別途文書化された Codex／手動レビューのファイナライザーが引き続き必要です。 copilot の契約全文については shared-references/reviewer-routing.md を参照してください。

REVIEWER_BACKEND = codex の場合： 新しいレビュー用スレッドには mcp__codex__codex を使用します。 フォローアップラウンドには mcp__codex__codex-reply を使用します（threadId を再利用します）。

REVIEWER_BACKEND = manual の場合： 新しいレビュー用スレッドには、次の内容で mcp__manual_review__review を使用します。 prompt: [Codex に送る場合とまったく同じプロンプト] config: {"model_reasoning_effort": "xhigh", "executor_model": "", "require_reviewer_model": true} 返された threadId を保存します。 フォローアップラウンドには、次の内容で mcp__manual_review__review_reply を使用します。 threadId: [保存した manual-review の threadId] prompt: [フォローアッププロンプト] config: {"model_reasoning_effort": "xhigh", "executor_model": "", "require_reviewer_model": true} 判定を伴う手動レビューの応答は、必ず Reviewer-Model: <exact-model-id> で始めなければなりません。そのモデル ID から reviewer_family を導出します。ID がない場合、不明な場合、または同じファミリーの場合は、承認判定に使用できません。必須のエスカレーションでは、推測せずに REVIEW_UNAVAILABLE を出力します。 プロンプトの忠実性：手動レビュータスクは、Codex が受け取るテキストと完全に同一でなければなりません。転送時に追加できるのは、必須の Reviewer-Model: 応答形式の指示だけです。 レビューのトレースは、すべてのバックエンドに適用されます。ネイティブトレースには、呼び出し側が宣言したモデル情報ではなく、再検証済みのホストイベント成果物の情報が記録されます。

状態の永続化（コンパクトリカバリー）

長時間実行されるループでは、コンテキストウィンドウの上限に達し、自動圧縮が実行されることがあります。これに備えるため、各ラウンドの後に状態を review-stage/REVIEW_STATE.json に保存します。

{
  "run_id": "run_20260713_a1b2c3d4",
  "round": 2,
  "threadId": null,
  "reviewer_profile": "rubber-duck",
  "reviewer_backend": "copilot-native",
  "executor_model": "claude-sonnet-4.6",
  "executor_model_source": "host-session-event",
  "executor_family": "anthropic",
  "requested_reviewer_model": null,
  "reported_reviewer_model": "gpt-5.5",
  "reviewer_model_source": "host-session-event",
  "reviewer_family": "openai",
  "family_relation": "different",
  "identity_assurance": "host_event_verified",
  "independence_verified": true,
  "native_evidence_id": "cne_0123456789abcdef0123456789abcdef",
  "native_evidence_path": "review-stage/COPILOT_NATIVE_run_20260713_a1b2c3d4_ROUND_2_REVIEW.evidence.json",
  "requires_external_acquittal": false,
  "status": "in_progress",
  "difficulty": "medium",
  "last_score": 5.0,
  "last_verdict": "not ready",
  "pending_experiments": ["screen_name_1"],
  "timestamp": "2026-03-13T21:00:00"
}

• run_id — 呼び出しごとにグローバルで一意です。新規開始時に run_<YYYYMMDD>_<8-char-hex> として生成されます（例：run_20260713_a1b2c3d4）。ラウンドごとの書き込みを通じて保持されます。再開時は、状態ファイルから変更せずに読み取ります。これにより、すべてのラウンド状態、レビュアーメモリーへの追記、無罪判定のレシートが1つの実行に結び付けられ、以前の呼び出しで完了した古い状態が、現在の実行の無罪判定チェックに混入するのを防ぎます。

REVIEWER_BACKEND が copilot-native の場合は、証拠 ID／パスと、ホストイベントから導出された実行者／レビュアーのモデル、ファミリー、ソースを保存します。各ラウンドは新しいラバーダックサブエージェントであり、新しい証拠成果物が作成されます。子エージェントのハンドルは永続化されません。互換性モードの copilot の場合は、reviewer_profile、要求されたモデル、呼び出し側が宣言した実行者モデル、independence_verified: "unverified"、外部ファイナライザーの義務を保持します。codex の場合は、その MCP の threadId を保存します。manual の場合は、threadId と報告されたレビュアーの ID を保存します。再開時は reviewer_backend を使って継続方法を選択し、requires_external_acquittal を保持します。

各 Phase E の終了時（ラウンドの記録後）にこのファイルを書き込みます。毎回上書きしてください。保持するのは最新ラウンドの状態だけです。同じ実行内では、上書き後も run_id フィールドを変更せずに保持しなければなりません。

完了時（肯定的な評価、または最大ラウンド数に達した場合）は、"status": "completed" を設定し、後続の呼び出しで完了済みのループが誤って再開されないようにします。

追記専用の外部最終判定者レシート

Copilot の経路で判定が外部バックエンドに引き渡された場合（互換性レビューで肯定的な結果が出た後、または判定前のネイティブディスパッチが失敗した後）は、review-stage/ACQUITTAL_LOG.jsonl に追記専用の最終判定者ログを維持します。各行には、その実行を完了した Codex または手動のレビュアーを記録します。ネイティブのラバーダックラウンドが正常に完了した場合、このレシートは不要であり、書き込まれません。そのエビデンスサイドカーが受け入れ記録となります。互換性を保つため、従来のファイル名を維持します。

{"run_id":"run_20260713_a1b2c3d4","round":3,"backend":"codex","effort":"xhigh","verdict":"ready","score":7.5,"executor_model":"claude-sonnet-4-5","executor_model_source":"caller-declared","executor_family":"anthropic","reviewer_model":"gpt-6-astra","reviewer_model_source":"requested","reviewer_family":"openai","family_relation":"different","identity_assurance":"caller_declared","independence_verified":"unverified","trace_id":"auto-review-loop/2026-07-13_run03","timestamp":"2026-07-13T14:22:00Z"}

ルール（遵守必須）：

ルール	詳細
追記専用	削除、切り詰め、行の上書きは一切しないでください。>> のみを使用します。
書き込み可能な担当者	round_requires_external_acquittal が true だった場合に、xhigh の労力レベルで実行する codex または manual のラウンドのみが書き込みます。Copilot のレビューやディスパッチが最終判定者の行を直接書き込むことはありません。
書き込みのタイミング	Phase E の終了時に、ポリシーで承認された最終判定者がスコア >= 6 かつ判定 ∈ {"ready", "almost"} を返した後に書き込みます。通常のデフォルト Codex 実行では、このサイドカーは不要です。
run_id の紐付け	各行に現在の run_id とラウンドを記録し、Copilot から最終判定者への移行を監査できるようにします。
トレースの紐付け	trace_id は .aris/traces/ 内の実際のトレース成果物を参照する必要があります。レシート内の source と family の各フィールドは、そのトレースと完全に一致していなければなりません。
身元の誠実な申告	モデル文字列から family_relation を再導出しますが、各ソースは保持してください。現在の呼び出し元申告型の実行者 ID では、identity_assurance: "caller_declared" と independence_verified: "unverified" を記録します。異なる文字列を独立した証明に格上げしてはいけません。
上書き禁止	REVIEW_STATE.json は各ラウンドで上書きされます（最新の状態のみ）。ACQUITTAL_LOG.jsonl は決して上書きされません。永続的な累積記録です。

この仕組みの理由： REVIEW_STATE.json は各ラウンドで上書きされます。このログは、互換性レビューの判定やネイティブ実行の失敗だけでは処理が終了しなかったことを示す証拠を保持します。一方、copilot-native の判定が正常に出た場合は、ホストイベントのエビデンスサイドカーを使用します。

出力プロトコル

すべての出力ファイルで、次の共通プロトコルに従ってください。

• 出力バージョニングプロトコル — まずタイムスタンプ付きファイルを書き込み、その後、固定名のファイルにコピーします
• 出力マニフェストプロトコル — すべての出力を MANIFEST.md に記録します
• 出力言語プロトコル — プロジェクトの言語設定に従います

ワークフロー

初期化

1. review-stage/REVIEW_STATE.json があるか確認します（見つからない場合は、旧パスの ./REVIEW_STATE.json を確認します）。
   • どちらのパスにも存在しない場合：新規開始（通常のケースです。この機能が導入される前の動作と同じです）
     • run_id を生成します：run_<YYYYMMDD>_<8-char-hex>（例：run_20260713_a1b2c3d4）。date +%Y%m%d と8文字のランダムな16進数を使用します。この run_id はすべてのラウンドの書き込みで維持され、この呼び出しに対する無罪判定レシートを紐付けます。
   • 存在し、status が "completed" の場合：新規開始（前回のループは正常に完了しています。ただし、ACQUITTAL_LOG.jsonl のエントリーは、それぞれ独自の run_id を持つ監査証跡として保持され、現在の実行の停止ゲートでは有効ではありません）
     • この呼び出し用に新しい run_id を生成します。
   • 存在し、status が "in_progress" で、timestamp が24時間より前の場合：新規開始（停止または放棄された実行の古い状態です。ファイルを削除してやり直します）
     • 新しい run_id を生成します。
   • 存在し、status が "in_progress" で、timestamp が24時間以内の場合：再開
     • 状態ファイルを読み込み、run_id、round、threadId（または Copilot バックエンド用の証拠／プロファイルのフィールド）、reviewer_backend、last_score、pending_experiments を復元します。
     • 旧形式との後方互換性：状態ファイルに reviewer_backend がない場合は、codex をデフォルトとします（Copilot 登場前の状態では、このフィールドが記録されていませんでした）。requires_external_acquittal がない場合は、false をデフォルトとします。旧形式でデフォルトの Codex を使用する実行に、Copilot のファイナライザーのより厳格な状態を引き継いではなりません。状態ファイルに run_id がない場合（run_id 導入前の状態）は、新しい run_id を生成し、次のように記録します：「No run_id in legacy state file; assigned run_<...> for this resume.」
     • 前のラウンドの全コンテキストを復元するため、review-stage/AUTO_REVIEW.md を読み込みます（見つからない場合は ./AUTO_REVIEW.md を確認します）。
     • pending_experiments が空でない場合は、それらが完了しているか確認します（例：画面セッションを確認します）。
     • 次のラウンドから再開します（round = 保存された round + 1）。
     • reviewer_backend を使って続行方法を判断します：codex の場合は codex-reply、copilot-native の場合は新たにマーカー／チャレンジ／ラバーダック／証拠のサイクルを実施、互換用 copilot の場合は保存されたプロファイル／モデルで新しい copilot --agent サブプロセスを起動、manual の場合は manual_review_reply を使用します。
     • 「コンテキストの圧縮から復元しました。ラウンド N から再開します。」と記録します。
2. プロジェクトの概要ドキュメント、メモリファイル、過去のレビュー文書を読み込みます。COMPACT = true で圧縮ファイルがある場合：コンテキストウィンドウを節約するため、review-stage/AUTO_REVIEW.md 全体と生ログの代わりに findings.md と EXPERIMENT_LOG.md を読み込みます。
3. 最近の実験結果を読み込みます（出力ディレクトリとログを確認します）。
4. 過去のレビューから、現在の弱点と未解決の TODO を特定します。
5. ラウンドカウンターを 1 に初期化します（状態ファイルから復元した場合を除きます）。
6. ヘッダーとタイムスタンプを付けて review-stage/AUTO_REVIEW.md を作成または更新します。
7. インラインまたはプロジェクトのレビューバックエンドが指定されていない新規実行の場合は、REVIEWER_BACKEND を auto に初期化します。Round 1 の Step -1 で有効化を実行し、その同じチャレンジをレビューに使用します。インラインまたはプロジェクトでレビューバックエンドが選択されている場合は、選択されたバックエンドを初期化して有効化を省略します。環境に基づく推測は使用しないでください。

ループ（MAX_ROUNDS まで繰り返します）

Step -1 — 自動バックエンドを解決し、ネイティブチャレンジを1つ準備します：

• REVIEWER_BACKEND が auto の場合、ネイティブヘルパーを解決し、ルートの marker 呼び出しを1回実行した後、ルートの challenge 呼び出しを1回実行します。バインディングには <run_id>_r<round>_review_<8-random-hex> を使用し、出力先には review-stage/COPILOT_NATIVE_<run_id>_ROUND_<round>_REVIEW.challenge.json を指定します。 バインドされたチャレンジでは REVIEWER_BACKEND を copilot-native に設定し、 NATIVE_CHALLENGE をそのパスに設定します。終了コード3／未バインドの場合は REVIEWER_BACKEND を codex に設定します。それ以外の失敗には、フェイルクローズの機能ルールを適用します。
• REVIEWER_BACKEND がすでに copilot-native の場合（後続ラウンドまたは再開した実行の場合）、同じ実行スコープの命名パターンで、新しいマーカー／チャレンジのペアを1つ作成し、NATIVE_CHALLENGE を設定します。未バインドまたは無効なチャレンジを判定として扱ったり、暗黙に別のラベルを付けたりしてはいけません。
• 明示的な外部バックエンドまたは互換バックエンドの場合、このステップでは何もしません。

ここで作成したチャレンジを Phase A で使用します。**同じレビューに対して、別のマーカー／チャレンジを実行してはいけません。**実行スコープのファイル名は追記専用の監査識別子です。古い実行の証拠を再利用するために --replace を指定してはいけません。

Step 0 — 現在のラウンドの状態をスナップショットします： Step -1 で auto を解決した後、round_backend = <current REVIEWER_BACKEND> および round_requires_external_acquittal = <current requires_external_acquittal, default false> を設定します。これらの変数は、現在のラウンドに実際に適用されたバックエンドと義務を示します。Phase B.5.1 で互換性対応によるエスカレーション（copilot → codex/manual）が後から発生した場合、スナップショットはエスカレーション前の値を保持し、次のラウンドに向けた状態は更新されます。ネイティブのディスパッチ失敗は、レビューが行われていないため別扱いとなります。Phase A に指定されているとおり、レビュアーを呼び出す前に両方のスナップショットを外部フォールバック値に置き換えます。ネイティブ呼び出しに成功した場合、ファイナライザーの義務は設定されません。Phase E では、ファイナライザーの受領記録を文書化または書き込む際に、結果として得られたスナップショットのみを使用します。

Phase A：レビュー

REVIEWER_BACKEND と REVIEWER_DIFFICULTY に従ってルートを選択します。

antigravity、grok、または claude-code の場合は、前述の呼び出し規約を使用し、以下のプロンプトをそのまま保持します。選択した呼び出しを完了し、生の応答と実際に報告されたモデルを保存してから、Phase B に進みます。別のルートを選択した後で、Codex、Copilot、または codex exec にフォールバックしてはいけません。

REVIEWER_BACKEND = copilot-native の場合、新しいネイティブサイクルを1回実行します。

1. Step -1 で作成した NATIVE_CHALLENGE を使用します。このラウンドで作成された、実行スコープの ..._ROUND_<round>_REVIEW.challenge.json 成果物である必要があります。 ここで 2 つ目のマーカー／チャレンジを発行しないでください。
2. 返された nonce を読み取ります。ホストの Task ツールを agent_type: rubber-duck、新しい名前、1 行目が ARIS_REVIEW_NONCE=<nonce> と完全に一致するプロンプトで呼び出します。クレーム、メソッド／コード、 生の結果、差分／現在の入力、レビュー担当者のメモへのパスを指定し、実行担当者の要約は渡さないでください。 Score: X/10 と Verdict: ready | almost | not ready をそれぞれ 1 つだけ提示し、優先順位付きの弱点／最小限の修正／メモリの更新も求めます。モデルの オーバーライドは渡さないでください。Copilot の補完的な戦略によってモデルが選択されます。
3. Task の完了後、新しいルート Bash 呼び出しで python3 "<resolved-helper>" verify --challenge "$NATIVE_CHALLENGE" --output "review-stage/COPILOT_NATIVE_<run_id>_ROUND_<round>_REVIEW.evidence.json" --response-output "review-stage/COPILOT_NATIVE_<run_id>_ROUND_<round>_REVIEW.response.md" を実行します。Phase B では、抽出された応答成果物のみを使用します。
4. Exit 10（同一／不明なファミリー）、ライフサイクルの未完了、無効な応答、または補完モデルを利用できない場合は、レビューとして扱いません。reviewer-routing.md の反対ファミリーへのフォールバック表を適用します。いずれも利用可能であると確認できない場合は、 REVIEW_UNAVAILABLE を出力します。スラッシュプロンプト、 copilot --agent rubber-duck、または汎用サブエージェントを使って rubber-duck を模倣しないでください。証拠取得前のディスパッチ失敗は、証拠なしで --backend copilot-native --status error として記録し、その後、実際のフォールバックを別途記録します。このエラートレースは停止ゲートでの判定権限を持ちません。フォールバックの前に、 copilot_native_evidence.py validate-challenge --challenge "$NATIVE_CHALLENGE" を実行し、その出力からのみ EXECUTOR_MODEL を取得します。その後：
   • Anthropic／Google の実行モデルと、利用可能な Codex の組み合わせの場合、外部呼び出しの前に REVIEWER_BACKEND と round_backend の両方を codex に設定します。
   • OpenAI の実行モデルと、既知の非 OpenAI モデルを報告する手動レビュー担当者の組み合わせの場合、外部呼び出しの前に両方の値を manual に設定します。
   • どちらのフォールバックでも round_requires_external_acquittal=true を設定し、NATIVE_EVIDENCE をクリアして、検証済みの実行モデルとフォールバックで解決したレビュー担当者モデルを review_gate.py に渡します。これにより、異なるファミリーを再導出して適用する、より厳格な外部ファイナライザーの分岐が意図的に使用されます。外部呼び出しで利用可能なレビューが返されない場合は、 REVIEW_UNAVAILABLE を出力します。 REVIEWER_BACKEND = copilot の場合、宣言された実行者 ID に基づいて、最初に反対ファミリーへのルーティングを強制します。

• --executor-model <model> パラメーターが必須です。指定されていない場合 → REVIEW_UNAVAILABLE。停止します。
• executor_model から executor_family を導出します。
  • モデル名に gpt、o1、o3、o4、chatgpt が含まれる場合 → openai
  • モデル名に claude、sonnet、opus、haiku が含まれる場合 → anthropic
  • モデル名に gemini が含まれる場合 → google
  • それ以外 → unknown
• executor_family が unknown の場合 → REVIEW_UNAVAILABLE（fail closed）。停止します。
• これはアテステーションではなくルート選択として扱います。executor_model_source: caller-declared を保存します。導出された family_relation: different は、将来、安定したランタイムシグナルによって親実行者モデルが独立して証明されない限り、independence_verified: unverified のままにします。
• ルーターは反対ファミリーのプロファイルを選択します。
  • openai → "aris-reviewer-claude"（anthropic、クロスファミリーを強制）
  • anthropic → "aris-reviewer-openai"（openai、クロスファミリーを強制）
  • google → "aris-reviewer-openai"（openai をデフォルトとして使用）
• プロファイルファイルが .github/agents/<profile>.agent.md に存在することを確認します。 存在しない場合 → REVIEW_UNAVAILABLE。停止します。
• プロファイルの最初の frontmatter にある model: の値を読み取り、そのファミリーを導出して、既知であり executor_family と異なることを確認します。そうでない場合は fail closed します。
• copilot --help に --model、--effort、--allow-tool が表示されることを確認します。 古い CLI、またはバージョンが固定されていない CLI は REVIEW_UNAVAILABLE です。
• 以下の Codex MCP 呼び出しを、copilot --agent サブプロセスを使うように変更します（Copilot CLI の公式な形式）。
  • mcp__codex__codex を copilot --agent "<profile>" --model "<parsed-model>" --effort xhigh --allow-tool=read --prompt "..." に置き換えます。
  • 各ラウンドでは、新しい copilot --agent 呼び出しを同じプロファイルで実行し、ラウンド間の状態を保持するアーティファクトとして review-stage/REVIEWER_MEMORY.md を使用します。
  • プロンプトテキストと Review Tracing は Codex のパスと同一です。
  • copilot CLI を利用できない場合 → REVIEW_UNAVAILABLE（MCP へのフォールバックなし）。
  • REVIEWER_DIFFICULTY = nightmare の場合、Copilot をスキップします（nightmare では Codex exec が必要です）。REVIEW_UNAVAILABLE を出力します。 shared-references/reviewer-routing.md を参照してください。

REVIEWER_BACKEND ∈ {codex, manual} の場合： 上記の Reviewer Calling Convention に従い、バックエンド固有の MCP 呼び出しを使用します。プロンプトテキストはバックエンドにかかわらず同じです。

Medium（デフォルト） — MCP Review

選択したバックエンドを使用して、包括的なコンテキストを独立したレビュアーに送信します。

codex バックエンドの場合：

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    [Round N/MAX_ROUNDS of autonomous review loop]

    Review the work directly from its artifacts — executor notes are not
    evidence, so read the files yourself rather than trusting my framing:
    - Claims / paper draft: <path>
    - Methods / code under review: <path(s)>
    - Raw results (verbatim files, not a summary): <path(s)>
    - Changed since last round: <changed-file paths> — read the diff, not my description

    Please act as a senior ML reviewer (NeurIPS/ICML level). Start from the
    assumption that the work is broken somewhere — your job is to find where.
    Be adversarial. Trust nothing the author tells you — verify everything
    yourself.

    1. Score this work 1-10 for a top venue
    2. List remaining critical weaknesses (ranked by severity)
    3. For each weakness, specify the MINIMUM fix (experiment, analysis, or reframing)
    4. State clearly: is this READY for submission? Yes/No/Almost

    Be brutally honest. If, after genuinely trying to break it, the work holds
    up and is ready, say so clearly.

    === SCOPE LIMITS (these bound what you PROPOSE, never what you look for) ===
    Report anything that is actually wrong here — including a rare-looking case, if
    this repo actually produces it. Then keep the fix in scope:
    1. This is a RESEARCH-WORKFLOW tool, not a security paper. Verification is
       welcome; over-defense is not. Assume a cooperating operator on their own
       machine — a malicious local user is NOT in the threat model.
    2. Do NOT propose SHA / hash / content-fingerprint / digest-binding schemes.
       Reporting a real defect in hashing code that already exists is fine.
    3. NO speculative machinery: do not add feature flags, migration frameworks,
       compat layers, wrappers, pins, or similar mechanisms unless evidence shows
       a current repo defect they fix or an explicit existing invariant they must
       preserve. "Load-bearing", "compatibility", and "not scaffolding" are labels,
       not evidence. Point to the failing path/artifact or invariant, and check the
       proposal's factual premises, such as whether a named package version exists.
    4. NO corner-case obsession: exotic encodings, symlink races, RTL text and
       millisecond races are out of scope unless you can show the case arises here.
    5. Where a rubric or checklist is genuinely needed, do not over-mechanize
       judgement. A clear sentence a human reads beats a scored table nobody
       maintains.
    Exception: code that runs remote commands, starts a network service, or installs
    an MCP server runs on the user's machine with their credentials — trust-boundary
    findings there are in scope and the default is strict.
    Say plainly when something is correct. Do not manufacture findings.

manual バックエンドの場合： mcp__manual_review__review を使用し、上記の prompt テキストと config: {"model_reasoning_effort": "xhigh", "executor_model": "<actual executor model>", "require_reviewer_model": true} を渡します。返された threadId を保存します。

2 ラウンド目以降の場合は、保存した threadId を使用して mcp__codex__codex-reply（codex）または mcp__manual_review__review_reply（manual）を使用します。

Hard — MCP Review + Reviewer Memory

medium と同じですが、プロンプトの先頭に Reviewer Memory を追加します。選択したバックエンドを使用します。

codex バックエンドの場合：

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    [Round N/MAX_ROUNDS of autonomous review loop]

    ## Your Reviewer Memory (persistent across rounds)
    [Paste full contents of review-stage/REVIEWER_MEMORY.md here]

    IMPORTANT: You have memory from prior rounds. Check whether your
    previous suspicions were genuinely addressed or merely sidestepped.
    The author (the executor model) controls what context you see — be skeptical
    of convenient omissions.

    Review directly from the artifacts (paths below) — read the files yourself:
    - Claims / methods / code: <path(s)>
    - Raw results: <path(s)>
    - Changed since last round: <changed-file paths> (read the raw diff)

    Please act as a senior ML reviewer (NeurIPS/ICML level).
    1. Score this work 1-10 for a top venue
    2. List remaining critical weaknesses (ranked by severity)
    3. For each weakness, specify the MINIMUM fix
    4. State clearly: is this READY for submission? Yes/No/Almost
    5. **Memory update**: List any new suspicions, unresolved concerns,
       or patterns you want to track in future rounds.

    Be brutally honest. Actively look for things the author might be hiding.

    === SCOPE LIMITS (these bound what you PROPOSE, never what you look for) ===
    Report anything that is actually wrong here — including a rare-looking case, if
    this repo actually produces it. Then keep the fix in scope:
    1. This is a RESEARCH-WORKFLOW tool, not a security paper. Verification is
       welcome; over-defense is not. Assume a cooperating operator on their own
       machine — a malicious local user is NOT in the threat model.
    2. Do NOT propose SHA / hash / content-fingerprint / digest-binding schemes.
       Reporting a real defect in hashing code that already exists is fine.
    3. NO speculative machinery: do not add feature flags, migration frameworks,
       compat layers, wrappers, pins, or similar mechanisms unless evidence shows
       a current repo defect they fix or an explicit existing invariant they must
       preserve. "Load-bearing", "compatibility", and "not scaffolding" are labels,
       not evidence. Point to the failing path/artifact or invariant, and check the
       proposal's factual premises, such as whether a named package version exists.
    4. NO corner-case obsession: exotic encodings, symlink races, RTL text and
       millisecond races are out of scope unless you can show the case arises here.
    5. Where a rubric or checklist is genuinely needed, do not over-mechanize
       judgement. A clear sentence a human reads beats a scored table nobody
       maintains.
    Exception: code that runs remote commands, starts a network service, or installs
    an MCP server runs on the user's machine with their credentials — trust-boundary
    findings there are in scope and the default is strict.
    Say plainly when something is correct. Do not manufacture findings.

Nightmare — Codex Exec（GPT がリポジトリを直接読み取る）

REVIEWER_BACKEND = codex の場合、 このリポジトリの直接レビューには codex exec を使用します。新しい MCP ルートでは、上記の指定に従って新しいファイル読み取りセッションを使用し、同じ検証要件を適用します。

codex exec "$(cat <<'PROMPT'
You are an adversarial senior ML reviewer (NeurIPS/ICML level).
This is Round N/MAX_ROUNDS of an autonomous review loop.

## Your Reviewer Memory (persistent across rounds)
[Paste full contents of review-stage/REVIEWER_MEMORY.md]

## Instructions
You have FULL READ ACCESS to this repository. The author (the executor model) does NOT
control what you see — explore freely. Your job is to find problems the
author might hide or downplay.

DO THE FOLLOWING:
1. Read the experiment code, results files (JSON/CSV), and logs YOURSELF
2. Verify that reported numbers match what's actually in the output files
3. Check if evaluation metrics are computed correctly (ground truth, not model output)
4. Look for cherry-picked results, missing ablations, or suspicious hyperparameter choices
5. Read NARRATIVE_REPORT.md or review-stage/AUTO_REVIEW.md for the author's claims — then verify each against code

OUTPUT FORMAT:
- Score: X/10
- Verdict: ready / almost / not ready
- Verified claims: [which claims you independently confirmed]
- Unverified/false claims: [which claims don't match the code or results]
- Weaknesses (ranked): [with MINIMUM fix for each]
- Memory update: [new suspicions and patterns to track next round]

Be adversarial. Trust nothing the author tells you — verify everything yourself.

=== SCOPE LIMITS (these bound what you PROPOSE, never what you look for) ===
Report anything that is actually wrong here — including a rare-looking case, if
this repo actually produces it. Then keep the fix in scope:
1. This is a RESEARCH-WORKFLOW tool, not a security paper. Verification is
   welcome; over-defense is not. Assume a cooperating operator on their own
   machine — a malicious local user is NOT in the threat model.
2. Do NOT propose SHA / hash / content-fingerprint / digest-binding schemes.
   Reporting a real defect in hashing code that already exists is fine.
3. NO speculative machinery: do not add feature flags, migration frameworks,
   compat layers, wrappers, pins, or similar mechanisms unless evidence shows
   a current repo defect they fix or an explicit existing invariant they must
   preserve. "Load-bearing", "compatibility", and "not scaffolding" are labels,
   not evidence. Point to the failing path/artifact or invariant, and check the
   proposal's factual premises, such as whether a named package version exists.
4. NO corner-case obsession: exotic encodings, symlink races, RTL text and
   millisecond races are out of scope unless you can show the case arises here.
5. Where a rubric or checklist is genuinely needed, do not over-mechanize
   judgement. A clear sentence a human reads beats a scored table nobody
   maintains.
Exception: code that runs remote commands, starts a network service, or installs
an MCP server runs on the user's machine with their credentials — trust-boundary
findings there are in scope and the default is strict.
Say plainly when something is correct. Do not manufacture findings.
PROMPT
)" --skip-git-repo-check 2>&1

主な違い： nightmare モードでは、GPT がコード、結果ファイル、ログを独立して読み取ります。Claude が GPT に見せる内容をフィルタリングしたり選別したりすることはできません。これは、実際の論文と補足資料を読む敵対的なレビュアーに最も近いものです。

フェーズ B：評価の解析

重要： レビュアーからの完全な生レスポンスをそのまま保存してください（フェーズ E で使うため、変数に格納します）。copilot-native の場合、必ずエビデンスヘルパーが抽出したレスポンス成果物を使用してください。実行者がコピーしたテキストは使用しないでください。破棄したり要約したりしないでください。生テキストが一次記録です。

次に、構造化フィールドを抽出します。

• スコア（数値、1～10）
• 判定（「ready」／「almost」／「not ready」）
• 対応項目（修正事項の優先順位付きリスト）

フェーズ B.5：レビュアーメモリの更新

評価を解析した後、正規のメモリ成果物 review-stage/REVIEWER_MEMORY.md に追記します。Copilot の両バックエンドはラウンド間の継続性をこのファイルに依存しています（各ネイティブサブエージェントまたは互換サブプロセスは毎回新規に起動します）。そのため、REVIEWER_DIFFICULTY にかかわらず更新を実行します。プロジェクトルートへのフォールバックは禁止です。最初の追記より前に review-stage/ を作成してください。

# Reviewer Memory

## Round 1 — Score: X/10

### Raw Reviewer Response (verbatim)
[Paste the COMPLETE raw reviewer response here — never summarized or curated by the executor.]

### Memory Update
[Reviewer's own memory update section, if provided — verbatim.]
- **Suspicion**: [what the reviewer flagged]
- **Unresolved**: [concerns not yet addressed]
- **Patterns**: [recurring issues the reviewer noticed]

---

## Round 2 — Score: X/10

### Raw Reviewer Response (verbatim)
[Paste the COMPLETE raw reviewer response here.]

### Memory Update
- **Previous suspicions addressed?**: [yes/no for each, with reviewer's judgment]
- **New suspicions**: [...]
- **Unresolved**: [carried forward + new]

---

ルール：

• 追記のみ。削除や切り詰めは絶対に行わないでください。 このファイルはレビュアーが管理する監査記録です。実行者は、過去のラウンドの内容を要約、編集、整理してはなりません。このラウンドにおけるレビュアーの完全な生レスポンスをそのまま追記し、その後、レビュアーがメモリ更新を提示した場合はそのセクションを追記します。
• 各ラウンドの追記には、レビュアー自身の言葉を使います。レビュアーのレスポンスに「Memory update」セクションが含まれる場合は、それをそのまま ## Round N — Memory Update サブセクションとして、生レスポンスの後にコピーします。
• 次のラウンドのフェーズ A では、このファイルをレビュアーに渡します。これはレビュアーの永続メモリです。
• レビュアーを呼び出す前に、毎回ファイルの SHA-256 ハッシュを記録し、--memory-hash を指定して save_trace.sh に渡します。トレースでその呼び出し時に使われたメモリを証明できるよう、追記後のバージョンではなく、呼び出しに渡す状態のメモリ（呼び出し前の成果物）をハッシュ化してください。
• ラウンドごとにスコアが低下した場合、新たなメモリ行を書くだけで済ませないでください。まず .aris/traces/ にある両ラウンドの生の .response.md ファイルを比較し、判定が変わった正確な基準を特定してください（shared-references/review-tracing.md § トレースを使ったデバッグ を参照）。メモリファイルは要約であり、トレースはエビデンスです。

フェーズ B.5.1：停止評価ゲート

これは候補となる遷移を計算するものであり、即時終了ではありません。フェーズ B.6 でハード／ナイトメアの反論が行われた場合は、それを完了させ、フェーズ E の前に最終判定からゲートを再計算してください。停止／レシートの成功を確定できるのはフェーズ E だけです。それ以前に肯定判定が出ても、保留中の反論やナイトメア検証をスキップすることはできません。

停止条件 — 今回のラウンドで実際に実行されたバックエンドである round_backend に基づいて分岐してください。先を見越した REVIEWER_BACKEND では分岐しないでください。review_gate.py の実行可能な遷移テーブルを使用し、shared-references/integration-contract.md §2 に記載された正規のヘルパーチェーンを通じて解決してください。JSON の decision フィールドと next_backend フィールドが正式な値です。ヘルパーを解決または実行できない場合は REVIEW_UNAVAILABLE を出力してください。遷移を独自に推測してはなりません。

完了したラウンドごとにゲートを一度呼び出します。モデル文字列だけを渡してください。ヘルパーが内部でファミリーを導出するため、呼び出し元が指定するファミリーラベルは受け付けません。バックエンドの利用可否は、現在のホストのツール構成から確実に判断する必要があります。どちらの最終処理も、デフォルトでは利用不可として扱います。

cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" || exit 1
if [ -z "${ARIS_REPO:-}" ] && [ -f .aris/installed-skills.txt ]; then
    ARIS_REPO=$(awk -F'\t' '$1=="repo_root"{print $2; exit}' .aris/installed-skills.txt 2>/dev/null) || true
fi
if [ -z "${ARIS_REPO:-}" ] && [ -f "$HOME/.aris/repo" ]; then
    ARIS_REPO=$(cat "$HOME/.aris/repo" 2>/dev/null) || true
fi
REVIEW_GATE=".aris/tools/review_gate.py"
[ -f "$REVIEW_GATE" ] || REVIEW_GATE="tools/review_gate.py"
[ -f "$REVIEW_GATE" ] || { [ -n "${ARIS_REPO:-}" ] && REVIEW_GATE="$ARIS_REPO/tools/review_gate.py"; }
[ -f "$REVIEW_GATE" ] || REVIEW_GATE=""
[ -n "$REVIEW_GATE" ] || { echo "REVIEW_UNAVAILABLE: review_gate.py not resolved" >&2; exit 1; }

GATE_REVIEWER_MODEL="${REPORTED_REVIEWER_MODEL:-${REQUESTED_REVIEWER_MODEL:-${REVIEWER_MODEL:-}}}"
# New routes require this call's reported identity, never the requested alias.
case "$round_backend" in
  antigravity|grok|claude-code) GATE_REVIEWER_MODEL="${REPORTED_REVIEWER_MODEL:-}" ;;
esac
GATE_ARGS=(
  --round-backend "$round_backend"
  --score "$SCORE"
  --verdict "$VERDICT"
  --executor-model "${EXECUTOR_MODEL:-}"
  --reviewer-model "$GATE_REVIEWER_MODEL"
)
case "$round_backend" in
  antigravity|grok|claude-code)
    GATE_ARGS+=(--review-status "${REVIEW_STATUS:-error}")
    [[ "${REVIEW_COMPLETED:-false}" != true ]] || GATE_ARGS+=(--review-completed)
    [[ "${REVIEW_SCOPE_COMPLETE:-false}" != true ]] || GATE_ARGS+=(--review-scope-complete)
    ;;
esac
if [[ "$round_backend" == "copilot-native" ]]; then
  [[ -n "${NATIVE_EVIDENCE:-}" ]] || {
    echo "REVIEW_UNAVAILABLE: native round has no evidence artifact" >&2
    exit 1
  }
  GATE_ARGS+=(--native-evidence "$NATIVE_EVIDENCE")
fi
if [[ "$round_requires_external_acquittal" == "true" ]]; then
  GATE_ARGS+=(--requires-external-acquittal)
fi
if [[ "${CODEX_AVAILABLE:-false}" == "true" ]]; then
  GATE_ARGS+=(--codex-available)
fi
if [[ "${MANUAL_AVAILABLE:-false}" == "true" ]]; then
  GATE_ARGS+=(--manual-available)
fi
if [[ "${MANUAL_IDENTITY_REPORTED:-false}" == "true" ]]; then
  GATE_ARGS+=(--manual-identity-reported)
fi
GATE_JSON=$(python3 "$REVIEW_GATE" "${GATE_ARGS[@]}") || {
  echo "REVIEW_UNAVAILABLE: review gate execution failed" >&2
  exit 1
}

GATE_JSON を JSON として解析してください。ヘルパーの説明文である reason から遷移を推測してはなりません。review_unavailable 判定は終端です。escalate または continue の場合は next_backend と requires_external_acquittal を次の処理に引き継ぐ状態にコピーしてください。成功終了の経路に進むのは stop の場合のみです。

• **Antigravity/Grok/Claude Code：**報告された実際のモデル、呼び出しの成功状態、確認済みの完了範囲を使用します。モデルファミリーが不明、またはレビューが未完了の場合は review_unavailable を返します。否定的な判定では処理を続行します。条件を満たす肯定的な判定では、ゲートが返す same-family / provisional または cross-family / accepted をもって停止できます。それらの値を永続化してください。トランスポート名からファミリーを判定することはできません。
• **Codex のデフォルト互換性（round_backend = codex、round_requires_external_acquittal = false）：**スコア >= 6 かつ判定 ∈ {"ready", "almost"} の場合、この Copilot 統合より前とまったく同じように停止します。実行者の識別情報は参考用のトレースメタデータであり、存在しない場合もあります。有効なデフォルト Codex の肯定的な判定を REVIEW_UNAVAILABLE に変えてはいけません。この経路では外部最終判定のレシートは書き込まれません。
• **既存の Oracle/Agy 経路：**Copilot 最終判定状態の外で明示的に選択された場合、条件を満たす肯定的な判定は Copilot 導入前と同じ停止動作を維持します。requires_external_acquittal=true の状態では有効な代替手段ではありません。この状態で許可されるのは Codex/manual のみです。
• **明示的な manual バックエンド：**肯定的な判定でも、応答に正確な Reviewer-Model: ヘッダーが必要です。識別情報がない場合は REVIEW_UNAVAILABLE です。
• **ネイティブ Copilot ラウンド（round_backend = copilot-native）：**証拠アーティファクトは必須であり、ゲートによって再検証されます。応答から導出された Score/Verdict は CLI のフィールドと一致する必要があります。条件を満たす肯定的な判定では identity_assurance: host_event_verified を伴う decision: stop が返され、否定的な判定では copilot-native で continue が返されます。外部最終判定状態は設定されません。
• **互換 Copilot 駆動ラウンド（round_backend = copilot）：**この経路でループが停止することはありません。否定的な判定では互換 Copilot で処理を続行します。肯定的な判定では decision: escalate が返され、requires_external_acquittal: true が設定され、呼び出し元が宣言した実行者ファミリーに基づいて次のバックエンドが選択されます。
  • anthropic または google → 利用可能な場合は Codex、そうでなければ manual。
  • openai → manual のみ（Codex は同じファミリー）。
  • unknown、またはポリシーで承認された最終判定者がいない場合 → REVIEW_UNAVAILABLE。
• **外部最終判定ラウンド（round_requires_external_acquittal = true）：**モデル文字列から既知の異なるファミリーが導出された場合に限り、Codex/manual は条件を満たす肯定的な判定で停止できます。manual では報告されたモデルヘッダーも必要です。これはルートの一貫性をフェイルクローズで保つものであり、実行者の独立した証明ではありません。identity_assurance: caller_declared と independence_verified: "unverified" を記録してください。最終判定が否定的な場合は、義務を維持したまま同じ最終判定バックエンドで処理を続行します。

互換 Copilot によるエスカレーション時は、REVIEW_STATE.json の将来のラウンドに適用される reviewer_backend と requires_external_acquittal を更新します。Phase E のため、round_backend と round_requires_external_acquittal は変更しないでください。最終判定者が条件を満たす肯定的な判定を返したら、将来のラウンドに適用されるフラグを false に設定して停止します。ACQUITTAL_LOG.jsonl は追記専用の監査レシートであり、後続の互換 Copilot の判定によるループ停止を可能にする入力として使ってはいけません。ネイティブの証拠は直接評価され、このログを参照することはありません。

この評価は Phase B.5 の後に実行されるため、終了前に終端ラウンドのメモが必ず review-stage/REVIEWER_MEMORY.md に追加されます。

フェーズ B.6：ディベートプロトコル（hard モードと nightmare モードのみ）

REVIEWER_DIFFICULTY = medium の場合は、完全にスキップしてください。

レビューを解析した後、実行者には反論の機会が与えられます。

ステップ 1 — 実行者の反論：

レビュー担当者が指摘した弱点ごとに、実行者は構造化された回答を作成します。

### Rebuttal to Weakness #1: [title]
- **Accept / Partially Accept / Reject**
- **Argument**: [why this criticism is invalid, already addressed, or based on a misunderstanding]
- **Evidence**: [point to specific code, results, or prior round fixes]

実行者の反論に関するルール：

• 正直であること — 証拠を捏造したり、結果を偽って伝えたりしてはいけません
• レビューの事実誤認を指摘できます（レビュー担当者によるコードの読み違い、誤った指標など）
• 弱点が対象範囲外である、または対応に不合理な労力が必要であると主張できます
• 1 ラウンドあたりの反論は最大 3 件です（異議を唱える影響の大きいものを選んでください）

ステップ 2 — 反論に対するレビュー担当者の裁定：

実行者の反論をレビュー担当者に返し、裁定を求めます。

antigravity／grok／claude-code の hard モードまたは nightmare モードでは： 保存済みのレビューセッションの継続プロトコルを使用し、同じ反論と証拠を提示します。この裁定が完了していることと対象範囲を確認し、未加工の応答を保存します。停止の決定を永続化する前に、更新後の Score／Verdict と実際のモデルを使ってゲートを再実行します。

Hard モード — 反論のステップには選択したバックエンドを使用します：

copilot-native の場合： 新しいマーカー／チャレンジを実行し、新しいネイティブの rubber-duck Task を呼び出します。review-stage/REVIEWER_MEMORY.md、未加工のレビュー応答、review-stage/ROUND_${ROUND}_REBUTTAL.md へのパスを渡し、引用されたファイルを自ら確認したうえで、更新後の Score／Verdict を返すよう求めます。この Verdict を含む裁定について、実行ごとに個別の ..._ROUND_<round>_REBUTTAL.challenge.json、.evidence.json、.response.md 成果物を使って検証します。停止ゲートとトレースには、（ディベート前の証拠ではなく）この証拠を使用します。

compatibility copilot の場合： 同じプロファイルと review-stage/REVIEWER_MEMORY.md のコンテキストを使って、新しい copilot --agent サブプロセスを実行します。

# Store the generated rebuttal as data; never paste memory/rebuttal text into
# a heredoc body, because either may contain a line matching its delimiter.
MEMORY_FILE="review-stage/REVIEWER_MEMORY.md"
REBUTTAL_FILE="review-stage/ROUND_${ROUND}_REBUTTAL.md"
[[ -f "$MEMORY_FILE" && -f "$REBUTTAL_FILE" ]] || {
  echo "REVIEW_UNAVAILABLE: missing memory or rebuttal artifact" >&2
  exit 1
}
PROMPTFILE="$(mktemp)" || { echo "REVIEW_UNAVAILABLE: mktemp failed" >&2; exit 1; }
trap 'rm -f "$PROMPTFILE"' EXIT
{
cat <<'ARIS_REBUTTAL_HEADER'
[Rebuttal ruling — same reviewer]

## Your Memory From Previous Rounds
ARIS_REBUTTAL_HEADER
cat -- "$MEMORY_FILE"
cat <<'ARIS_REBUTTAL_MIDDLE'

The author rebuts your review:
ARIS_REBUTTAL_MIDDLE
cat -- "$REBUTTAL_FILE"
cat <<'ARIS_REBUTTAL_FOOTER'

For each rebuttal, rule:
- SUSTAINED (author's argument is valid, withdraw this weakness)
- OVERRULED (your original criticism stands, explain why)
- PARTIALLY SUSTAINED (revise the weakness to a narrower scope)

Then update your score if any weaknesses were withdrawn.
Include a Memory Update section at the end of your response.
ARIS_REBUTTAL_FOOTER
} > "$PROMPTFILE"
copilot --agent "$REVIEWER_PROFILE" --model "$REVIEWER_MODEL" \
  --effort xhigh --allow-tool=read --prompt "$(cat "$PROMPTFILE")"

codex の場合：

mcp__codex__codex-reply:
  threadId: [saved]
  # inherits the thread's model/effort — do not re-send
  prompt: |
    The author rebuts your review:

manual の場合： 同じ threadId とプロンプトを使って mcp__manual_review__review_reply を使用します。

プロンプトの内容：

    The author rebuts your review:

    [paste executor's rebuttal]

    For each rebuttal, rule:
    - SUSTAINED (author's argument is valid, withdraw this weakness)
    - OVERRULED (your original criticism stands, explain why)
    - PARTIALLY SUSTAINED (revise the weakness to a narrower scope)

    Then update your score if any weaknesses were withdrawn.

Nightmare モード（codex exec）：

codex exec "$(cat <<'PROMPT'
You are the same adversarial reviewer. The author rebuts your review:

[paste executor's rebuttal]

VERIFY the author's evidence claims yourself — read the files they reference.
Do NOT take their word for it.

For each rebuttal, rule:
- SUSTAINED (verified and valid)
- OVERRULED (evidence doesn't check out or argument is weak)
- PARTIALLY SUSTAINED (partially valid, narrow the weakness)

Update your score. Update your memory.
PROMPT
)" --skip-git-repo-check 2>&1

ステップ 3 — 裁定に基づくスコアと対応項目の更新：

• SUSTAINED の弱点：対応項目から削除します
• OVERRULED：そのまま維持します
• PARTIALLY SUSTAINED：対象範囲を修正します

ディベートの記録全文を、そのラウンドの項目の下にある review-stage/AUTO_REVIEW.md に追記します。

人間によるチェックポイント（有効な場合）

HUMAN_CHECKPOINT = false の場合は、このステップ全体をスキップしてください。

HUMAN_CHECKPOINT = true の場合、レビュー結果を提示してユーザーの入力を待ちます。

📋 Round N/MAX_ROUNDS review complete.

Score: X/10 — [verdict]
Top weaknesses:
1. [weakness 1]
2. [weakness 2]
3. [weakness 3]

Suggested fixes:
1. [fix 1]
2. [fix 2]
3. [fix 3]

Options:
- Reply "go" or "continue" → implement all suggested fixes
- Reply with custom instructions → implement your modifications instead
- Reply "skip 2" → skip fix #2, implement the rest
- Reply "stop" → end the loop, document current state

ユーザーの応答を待ち、その入力を解析します。

• 承認（"go"、"continue"、"ok"、"proceed"）：提案された修正をすべて適用してフェーズ C に進みます
• カスタム指示（その他のテキスト）：フェーズ C への追加または代替の指針として扱います。適切にレビュー担当者の提案と統合します
• 特定の修正をスキップ（"skip 1,3"）：該当する修正を対応リストから削除します
• 停止（"stop"、"enough"、"done"）：ループを終了し、終了処理に進みます

Feishu 通知（設定されている場合）

スコアを解析した後、~/.claude/feishu.json が存在し、mode が "off" でないことを確認します。

• review_scored 通知を送信します：「Round N: X/10 — [verdict]」と上位 3 件の弱点を含めます
• interactive モードで Verdict が "almost" の場合：チェックポイントとして送信し、続行するか停止するかのユーザー返信を待ちます
• 設定がない場合、または mode が off の場合：完全にスキップします（何もしません）

フェーズ C：修正の実装（停止しない場合）

各対応項目について、優先度の高い順に実施します。

1. コード変更：実験スクリプト、モデルコード、解析スクリプトを作成／変更します
2. 実験の実行：SSH と screen／tmux を介して GPU サーバーにデプロイします
3. 解析：評価を実行し、結果を収集して、図／表を更新します
4. ドキュメント：プロジェクトのメモとレビュー文書を更新します

優先順位付けのルール：

• 過剰な計算リソースを必要とする修正はスキップします（手動での後続対応として記録してください）
• 利用できない外部データ／モデルを必要とする修正はスキップします
• どちらも懸念に対応できる場合は、新しい実験よりも、再構成や解析を優先します
• 指標の追加は必ず実施します（低コストで大きな効果があります）

Phase D: 結果を待つ

実験を開始した場合：

• リモートセッションの完了状況を監視します
• 出力ファイルとログから結果を収集します
• トレーニング品質チェック — W&B が設定されている場合は、/training-check を実行してトレーニングが正常だったこと（NaN、発散、停滞がないこと）を確認します。W&B を利用できない場合は、何もせずにスキップします。品質に問題があれば、次のレビューラウンドで指摘します。

Phase E: ラウンドを記録する

review-stage/AUTO_REVIEW.md に追記します：

## Round N (timestamp)

### Assessment (Summary)
- Score: X/10
- Verdict: [ready/almost/not ready]
- Key criticisms: [bullet list]

### Reviewer Raw Response

<details>
<summary>Click to expand full reviewer response</summary>

[Paste the COMPLETE raw response from the reviewer here — verbatim, unedited.
This is the authoritative record. Do NOT truncate or paraphrase.]

</details>

### Debate Transcript (hard + nightmare only)

<details>
<summary>Click to expand debate</summary>

**Executor Rebuttal:**
[paste rebuttal]

**Reviewer Ruling:**
[paste ruling — SUSTAINED / OVERRULED / PARTIALLY SUSTAINED for each]

**Score adjustment**: X/10 → Y/10

</details>

### Actions Taken
- [what was implemented/changed]

### Results
- [experiment outcomes, if any]

### Status
- [continuing to round N+1 / stopping]
- Difficulty: [medium/hard/nightmare]

review-stage/REVIEW_STATE.json を書き込みます。現在の run_id、ラウンド、threadId、解決済みの route/session/cwd、要求されたモデルと報告されたモデル／実際の effort、完了状況／スコープ、独立性／受け入れ状況、スコア、判定、reviewer_backend、requires_external_acquittal、保留中の実験を記録します。run_id フィールドは初期化時の値から変更せずに維持しなければなりません。ラウンドごとに再生成してはいけません。

antigravity、grok、または claude-code で肯定的な停止となった場合は、この run／ラウンド／バックエンド、実際のモデル／effort、スコア／判定、ゲートの独立性／受け入れ状況、実際の trace パスを含むレシートを ACQUITTAL_LOG.jsonl に1件追記します。これはこのラウンドの監査記録であり、後続ラウンドの受け入れを許可する入力ではありません。暫定的な停止は、暫定として明記したままにします。以下の既存の Copilot ファイナライザーのレシートは別のもので、変更しません。

状態ファイルのバックエンドラベル： REVIEW_STATE.json の reviewer_backend フィールドは、記録対象のラウンドではなく、次のラウンドの継続メカニズム（再開時に使用）を制御します。Phase E では：

• round_backend（ステップ 0 のラウンド開始時にスナップショットした値）を使って、AUTO_REVIEW.md の記録に今回のラウンドを示します（例：「Reviewer backend: copilot-native」）。
• round_requires_external_acquittal を使って、今回のラウンドが Copilot 起動のファイナライザーだったかを判定します。状態ファイルの requires_external_acquittal には、次のラウンドに適用される今後の義務を書き込みます。
• REVIEW_STATE.json の reviewer_backend には、次のラウンドを制御する値を書き込みます。これは、（a）エスカレーションがなければ現在のラウンドのバックエンドと同じ値、または（b）Phase B.5.1 で設定したエスカレーション先のバックエンドです。この今後の値を示すフィールドに round_backend を代入してはいけません。
• エスカレーションがなければ、round_backend == reviewer_backend となります（自明に安全です）。
• ネイティブラウンドでは、native_evidence_id、native_evidence_path、両方のホストイベントのモデル ID／ソース、family_relation: different、および identity_assurance: host_event_verified を保持します。これらのフィールドを文章から転記してはいけません。

round_backend ∈ {codex, manual} かつ round_requires_external_acquittal = true かつ score >= 6 かつ verdict ∈ {"ready", "almost"} の場合： 外部ファイナライザーの行を review-stage/ACQUITTAL_LOG.jsonl に1件追記します：

{"run_id":"<current-run_id>","round":<N>,"backend":"<codex|manual>","effort":"xhigh","verdict":"<ready|almost>","score":<score>,"executor_model":"<from-trace>","executor_model_source":"caller-declared","executor_family":"<derived-from-executor_model>","reviewer_model":"<from-trace-or-manual-Reviewer-Model>","reviewer_model_source":"<requested|backend-reported>","reviewer_family":"<derived-from-reviewer_model>","family_relation":"different","identity_assurance":"caller_declared","independence_verified":"unverified","trace_id":"<skill>/<YYYY-MM-DD>_run<NN>","timestamp":"<ISO8601>"}

>>（追記）を使い、> は決して使わないでください。モデル文字列から両方のファミリーを再判定し、不明または同一ファミリーの組み合わせは拒否します。ただし、モデルソースと保証の各フィールドは、格上げせずにそのまま転記します。trace_id は .aris/traces/ からの相対パスである実際の trace ディレクトリパス（例：auto-review-loop/2026-07-13_run01）でなければならず、save_trace.sh の RUN_ID 形式（スキル名のサブディレクトリ接頭辞付きの <YYYY-MM-DD>_run<NN>）と一致させます。合成した trace_... 識別子を捏造してはいけません。

findings.md に追記します（COMPACT = true の場合）：今回のラウンドの主な各指摘につき1行：

- [Round N] [positive/negative/unexpected]: [one-sentence finding] (metric: X.XX → Y.YY)

ラウンドカウンターを増やして、Phase A に戻ります。

終了処理

ループが終了したとき（肯定的な評価を得た場合、または最大ラウンド数に達した場合）：

1. review-stage/REVIEW_STATE.json の "status": "completed" を更新します
2. 最終的な概要を review-stage/AUTO_REVIEW.md に書き込みます
3. 結論をもとにプロジェクトのメモを更新します
4. review-stage/AUTO_REVIEW.md の ## Method Description セクションに手法／パイプラインの説明を書き込みます。最終的な手法、そのアーキテクチャ、データフローについて、簡潔な1～2段落で説明します。これを Workflow 3 の /paper-illustration への入力として使用し、アーキテクチャ図を自動生成できるようにします。
5. 結果から主張を生成します — /result-to-claim を呼び出して、review-stage/AUTO_REVIEW.md の実験結果を論文用の構造化された主張に変換します。出力先：CLAIMS_FROM_RESULTS.md。これにより Workflow 2 から Workflow 3 への橋渡しを行い、/paper-plan が主張を一から抽出する代わりに、検証済みの主張を直接使用できるようにします。/result-to-claim がインストールされていない場合は、この手順をスキップします（CLAIMS_FROM_RESULTS.md は生成されず、従来どおり /paper-plan が説明文から主張を抽出します）。ファイルや判定結果を捏造してはなりません。実行されたものの、出力が verdict: REVIEW_UNAVAILABLE で始まる場合は、そのファイルをそのまま保持し（上書きや言い換えを行わず）、主張が未評価であることを AUTO_REVIEW.md に記録します。後続の論文作成ステージでは、これらを検証済みとして扱ってはなりません。
6. 肯定的な評価を得られないまま最大ラウンド数で停止した場合：
   • 残っている障害を列挙します
   • それぞれに必要な作業量を見積もります
   • 手動で続行するか、別の方針に切り替えるかを提案します
7. Feishu 通知（設定されている場合）：最終スコアの推移表とともに pipeline_done を送信します
8. HTML ビューをレンダリングします（RENDER_HTML = true の場合。デフォルト）：累積レビューのログに対して /render-html を呼び出します。

   /render-html "review-stage/AUTO_REVIEW.md" --no-review --state review-stage/REVIEW_STATE.json
   

   --state を明示的に渡します（ヘルパーはサイドカーを自動検出しません）。REVIEW_STATE.json が存在しない場合は --state フラグを省略します。HTML はソースの SHA256 を埋め込んだ状態で review-stage/AUTO_REVIEW.html に出力されます。ブロッキングではありません：/render-html が失敗した場合は、エラーを記録して続行します。HTML は利便性のためのものであり、終了の必須条件ではありません。RENDER_HTML = false の場合はスキップします。

主要なルール

• 大きなファイルの処理：ファイルサイズが原因で Write ツールが失敗した場合は、すぐに Bash（cat << 'EOF' > file）を使ってチャンク単位で書き込むよう再試行してください。ユーザーに許可を求めてはいけません。何も言わずに実行してください。

• Codex バックエンド：すべてのスレッドの最初の呼び出しで、model: gpt-6-astra と config: {"model_reasoning_effort": "xhigh"} を固定してください。reviewer-routing.md にあるとおり、xhigh はこのループの標準ティアであり、最大ではありません。ultra は一度限りの詳細監査スキル向けで、各ラウンドの処理により時間とコストがかかります。このループのティアを引き上げないでください。応答はスレッドの設定を引き継ぐため、変更するには新しいスレッドが必要です。明示的な機能エラーが発生した場合に限り、機能フォールバックの手順に従ってください。

• **ネイティブ Copilot は、証拠に基づいて受け入れを判断するバックエンドです。**レビュアーモデルは固定しません。Copilot が補完的なラバーダックモデルを選択し、ヘルパーがホストイベントから実際の異なるファミリー間のペアを検証します。ネイティブで肯定的な結果が得られた場合、外部の最終確認者は不要です。

• **明示的な互換モードの Copilot は、実行専用のままです。**その copilot --agent 呼び出しでは、プロファイルのモデル、xhigh、読み取り専用アクセスを固定し、追跡可能な Codex または手動の最終確認者が必要です。呼び出し元が申告したIDは未検証のままです。

• threadId（codex/manual）、新しい証拠のパス／ID（copilot-native）、または reviewer_profile（互換モードの copilot）を保存し、適切な継続方法を使用してください。

• **幻覚を防ぐ引用：**修正時に参考文献を追加する場合、BibTeX を絶対に捏造しないでください。/paper-write と同じ DBLP → CrossRef → [VERIFY] の手順を使用してください：（1）curl -s "https://dblp.org/search/publ/api?q=TITLE&format=json" → キーを取得 → curl -s "https://dblp.org/rec/{key}.bib"、（2）見つからない場合は、curl -sLH "Accept: application/x-bibtex" "https://doi.org/{doi}"、（3）どちらも失敗した場合は、% [VERIFY] を付けてください。記憶を頼りに BibTeX を生成してはいけません。

• 正直に記載してください。否定的な結果や失敗した実験も含めてください。

• 肯定的なスコアを得るために、弱点を隠してはいけません。

• 再レビューの前に修正を実装してください（修正すると約束するだけではいけません）。

• 諦める前に徹底的に試してください — レビュアーの懸念を「対応不能」とする前に、（1）少なくとも2つの異なる解決策を試す、（2）実験の問題ならハイパーパラメーターを調整するか、代替ベースラインを試す、（3）理論上の問題なら、より弱い結果や代替の論拠を示す、（4）その後に限り、範囲を限定して譲歩し、影響を明確にしてください。最初の試みで決して諦めないでください。

• 実験に30分以上かかる場合は、実験を開始し、待っている間にほかの修正を進めてください。

• すべてを記録してください。レビュー記録は、それだけで内容が完結するようにしてください。

• 最後だけでなく、各ラウンドの後にプロジェクトのメモを更新してください。

ラウンド2以降のプロンプトテンプレート

選択したバックエンドを使用してください。*copilot-native の場合：*新しい実行スコープの REVIEW 成果物一式を使い、マーカー／チャレンジ／ラバーダック／証拠のサイクルを新たに実施します。その際、review-stage/REVIEWER_MEMORY.md と現在の入力へのパスを指定してください。*互換モードの copilot の場合：*同じプロファイルとメモリ成果物を使い、新しい copilot --agent サブプロセスを起動します。*codex の場合：*保存した threadId を使って mcp__codex__codex-reply を実行します。*manual の場合：*保存した threadId を使って mcp__manual_review__review_reply を実行します。antigravity/grok/claude-code の場合：reviewer-backends.md に記載された、保存済みルートの継続ツールと固定セッションオプションを使用し、変更ファイルと生の結果の入力も同じものを使います。Claude の cwd/tools も繰り返し指定してください。

Copilot サブプロセスを呼び出す前に、Bash、echo、ヒアドキュメント、生成されたシェル代入ではなく、Write ツールを使って review-stage/CURRENT_REVIEW_INPUTS.md を上書きしてください。そのファイルには、変更したパス、差分の成果物／範囲、結果のパスを、静的なラベルの下に正確に記載してください。リポジトリのパスは信頼できないデータです。この成果物内のバイト列をシェルソースに組み込んではいけません。以下の固定ファイル名だけをシェルテンプレートの値として使用してください。

[For copilot:]

# ARIS_ROUND2_COPILOT_BEGIN
# Dynamic values were written with the Write tool; shell only reads them as data.
MEMORY_FILE="review-stage/REVIEWER_MEMORY.md"
ROUND_INPUT_FILE="review-stage/CURRENT_REVIEW_INPUTS.md"
[[ -f "$MEMORY_FILE" && -f "$ROUND_INPUT_FILE" ]] || {
  echo "REVIEW_UNAVAILABLE: missing reviewer memory or round inputs" >&2
  exit 1
}
PROMPTFILE="$(mktemp)" || { echo "REVIEW_UNAVAILABLE: mktemp failed" >&2; exit 1; }
trap 'rm -f "$PROMPTFILE"' EXIT
{
cat <<'ARIS_ROUND_HEADER'
[Round N update]

## Your Memory From Previous Rounds
ARIS_ROUND_HEADER
cat -- "$MEMORY_FILE"
cat <<'ARIS_ROUND_STATE'

Since your last review these files changed — read them yourself; do not
take my word for what changed or whether it worked:
ARIS_ROUND_STATE
cat -- "$ROUND_INPUT_FILE"
cat <<'ARIS_ROUND_INSTRUCTIONS'

Please re-score and re-assess. Are the remaining concerns addressed?
Same format: Score, Verdict, Remaining Weaknesses, Minimum Fixes.

=== SCOPE LIMITS (these bound what you PROPOSE, never what you look for) ===
Report anything that is actually wrong here — including a rare-looking case, if
this repo actually produces it. Then keep the fix in scope:
1. This is a RESEARCH-WORKFLOW tool, not a security paper. Verification is
   welcome; over-defense is not. Assume a cooperating operator on their own
   machine — a malicious local user is NOT in the threat model.
2. Do NOT propose SHA / hash / content-fingerprint / digest-binding schemes.
   Reporting a real defect in hashing code that already exists is fine.
3. NO speculative machinery: do not add feature flags, migration frameworks,
   compat layers, wrappers, pins, or similar mechanisms unless evidence shows
   a current repo defect they fix or an explicit existing invariant they must
   preserve. "Load-bearing", "compatibility", and "not scaffolding" are labels,
   not evidence. Point to the failing path/artifact or invariant, and check the
   proposal's factual premises, such as whether a named package version exists.
4. NO corner-case obsession: exotic encodings, symlink races, RTL text and
   millisecond races are out of scope unless you can show the case arises here.
5. Where a rubric or checklist is genuinely needed, do not over-mechanize
   judgement. A clear sentence a human reads beats a scored table nobody
   maintains.
Exception: code that runs remote commands, starts a network service, or installs
an MCP server runs on the user's machine with their credentials — trust-boundary
findings there are in scope and the default is strict.
Say plainly when something is correct. Do not manufacture findings.

At the end of your review, include a Memory Update section — this will
be passed back to you next round.
ARIS_ROUND_INSTRUCTIONS
} > "$PROMPTFILE"
copilot --agent "$REVIEWER_PROFILE" --model "$REVIEWER_MODEL" \
  --effort xhigh --allow-tool=read --prompt "$(cat "$PROMPTFILE")"
# ARIS_ROUND2_COPILOT_END

[For codex:] mcp__codex__codex-reply:
  threadId: [saved from round 1]
  # inherits the thread's model/effort — do not re-send
  prompt: |
    [Round N update]

    Since your last review these files changed — read them yourself; do not
    take my word for what changed or whether it worked:
    - Changed files: <paths>
    - Raw diff: <path, or the `git diff` range>
    - Updated raw results: <result-file paths> (verbatim files, not a pasted table)

    Please re-score and re-assess. Are the remaining concerns addressed?
    Same format: Score, Verdict, Remaining Weaknesses, Minimum Fixes.

    === SCOPE LIMITS (these bound what you PROPOSE, never what you look for) ===
    Report anything that is actually wrong here — including a rare-looking case, if
    this repo actually produces it. Then keep the fix in scope:
    1. This is a RESEARCH-WORKFLOW tool, not a security paper. Verification is
       welcome; over-defense is not. Assume a cooperating operator on their own
       machine — a malicious local user is NOT in the threat model.
    2. Do NOT propose SHA / hash / content-fingerprint / digest-binding schemes.
       Reporting a real defect in hashing code that already exists is fine.
    3. NO speculative machinery: do not add feature flags, migration frameworks,
       compat layers, wrappers, pins, or similar mechanisms unless evidence shows
       a current repo defect they fix or an explicit existing invariant they must
       preserve. "Load-bearing", "compatibility", and "not scaffolding" are labels,
       not evidence. Point to the failing path/artifact or invariant, and check the
       proposal's factual premises, such as whether a named package version exists.
    4. NO corner-case obsession: exotic encodings, symlink races, RTL text and
       millisecond races are out of scope unless you can show the case arises here.
    5. Where a rubric or checklist is genuinely needed, do not over-mechanize
       judgement. A clear sentence a human reads beats a scored table nobody
       maintains.
    Exception: code that runs remote commands, starts a network service, or installs
    an MCP server runs on the user's machine with their credentials — trust-boundary
    findings there are in scope and the default is strict.
    Say plainly when something is correct. Do not manufacture findings.

レビューのトレース

各レビュー担当者の呼び出し（copilot-native 用の task(agent_type=rubber-duck)、選択された MCP 呼び出し、または互換性のある copilot --agent サブプロセス）の後、shared-references/review-tracing.md（ポリシー C — フォレンジック。決して黙って省略しない）に従ってトレースを保存してください。ネイティブ呼び出しでは、必ず --backend copilot-native --native-evidence "$NATIVE_EVIDENCE" を渡してください。ヘルパーが再検証し、応答と実際のモデルの組み合わせを提供します。唯一の例外は、エビデンスが存在する前にネイティブのディスパッチが失敗した場合です。その場合は、エビデンスを指定せず、--backend copilot-native --status error --fallback-reason <reason> を指定してトレースし、その後、実際にフォールバックしたレビュー担当者を別途トレースしてください。正規のチェーンを通じて解決した save_trace.sh を使用してください。このフォレンジックヘルパーにアクセスできない場合に限り、同じスキーマを直接書き込んでください。--- trace:（デフォルトは full）に従ってください。新しい MCP ルートでは、要求されたモデルと報告されたモデル、実際のエフォート、スコープ／完了状況、判定を含めてください。トレースヘルパーの完了／スコープフラグは、それらを確認してから使用してください。エラーはエラーとしてトレースしてください。ゲートによるファミリー基準の受け入れ判定と、下流への提出準備状況は別々に保持してください。

停止ゲートの状態遷移テスト

正規の遷移表は ARIS リポジトリの tools/review_gate.py（実行時にはヘルパーチェーンを通じて review_gate.py として解決）にあり、tests/test_review_gate.py で網羅されています。必須のケースは次のとおりです。

1. デフォルトの Codex が肯定的 → 実行者のモデル ID が不明でも stop（後方互換性）。
2. スコアが高くても not ready → continue。
3. 検証済みのネイティブ Copilot が肯定的 → stop。identity_assurance=host_event_verified。
4. ネイティブが否定的 → copilot-native で continue。エビデンスの欠落／無効／不一致 → REVIEW_UNAVAILABLE。
5. 宣言された Anthropic／Google の実行者のもとで、互換性のある Copilot が肯定的 → Codex に escalate し、requires_external_acquittal=true を設定。
6. 宣言された OpenAI の実行者のもとで、互換性のある Copilot が肯定的 → 手動レビューに escalate。同じファミリーであるため、Codex は禁止。
7. 互換性のある Copilot が否定的 → 互換性のある Copilot で continue。
8. 実行者ファミリーが不明、最終レビュー担当者が利用不可、最終レビュー担当者が同じファミリー、または Reviewer-Model: のない手動レビュー担当者 → REVIEW_UNAVAILABLE。
9. ファミリーが既知で異なると宣言された最終レビュー担当者が肯定的 → stop。ただし、ID 保証は caller_declared／unverified のまま。

ACQUITTAL_LOG.jsonl は追記専用の互換性ドライブ監査出力としてテストされています。ネイティブの終了判定では決して参照されません。