research-pipeline

完全なリサーチパイプライン：アイデア → 実験 → 投稿

各査読者スロットの前に、Selectable Reviewers に従ってください。 呼び出し元 → .aris/reviewer.json → Claude Code のデフォルト（Codex MCP）の順に解決し、 正規ヘルパーリゾルバーを通じて reviewer_route.py を使用し、このスロットのティア、新鮮なコンテキスト、ソース／画像入力、決定論的なゲートを維持してください。 以下の Codex の例や固定設定は backend=codex にのみ適用されます。それ以外のルートでは、それぞれ独自の初回呼び出し／返信コントラクトを使用してください。ルートと、実際に返された ID を保存してください。 選択したものが利用できない場合は REVIEW_UNAVAILABLE とします。実際のファミリー／完了状況／範囲に基づいて採否を分類してください。呼び出し元からの査読者／モデル／推論量のオーバーライドは、査読者を含む子プロセスに引き継いでください。生成ワーカーは変更しません。

⏱ 外部の実行間隔：評価を伴わないハートビートのみ。 夜間の /loop / CronCreate ハートビートは、フェーズが停滞している（進捗がない、プロセスが停止している、解放済みのリソース待ちでブロックされている）ことを検出し、作業を前進させるよう促すために実行できます。ただし、作業の質が十分だと判断してはいけません（論文が十分である、証明が成立している、主張が裏付けられている、など）。そのような判断はすべて、各スキル独自の内部実行間隔に委ね、クロスモデル審査会で終了させてください。ハートビートが言えるのは「続けてください」までであり、「これで十分です」とは言えません。詳しくは shared-references/external-cadence.md （夜間パイプラインのルールと、停滞の検出および構造的な方向転換）を参照してください。ハートビートの起動時には、各ティックで最初に実行状態に触れ、この実行をウォッチドッグの loop タイプとして登録してください（無言で停止した場合に STALE として検出されるようにします）。完了時には登録を解除してください。ウォッチドッグは検出のみを行い、潔白を認定することはありません。各ティックでは、iteration_log.py ヘルパーを使って新規発見数も記録してください（正規の .aris/tools → tools → $ARIS_REPO/tools → ~/.aris/repo 経由の $ARIS_REPO/tools チェーンを通じて解決します。integration-contract §2 を参照。解決できない場合は警告してスキップします）： python3 "$ITER_LOG" note <root> <run_id> <phase> <n>. 返された結果が pivot=structural（stale ≥ 2）の場合、促す際に STRUCTURAL 制約を変更し、未試行の方向を選んでください。pivot=human（stale ≥ 4）の場合は、対応が必要なものとして通知してください。これは件数の記録のみであり、品質判断は行いません。

$ARGUMENTS のためのエンドツーエンドの自律型リサーチワークフロー

任意の形式証明ルート

実験実行を作成する前に、定理を中心とする依頼で Lean を使う場合は、/lean-formalize に振り分け、実際の証明結果を報告してください。タスクに実証研究が含まれる場合は、以下の実験段階を実行してください。複合プロジェクトでは、ユーザーが形式証明を求めている場合、または形式検証が大きく役立つ特定の数学的義務がある場合に Lean を使用し、検証済みの範囲と残る義務をリサーチの要約および該当する証明監査に反映してください。通常の数学は既存の理論スキルで扱います。難易度だけを理由に Lean が必須になることはなく、形式的な補題だけでは実証的な主張は立証されません。

定数

• AUTO_PROCEED = true — true の場合、すべての選択チェックポイントは通知のみとなり、選択内容を報告して同じターン内で続行します。false の場合、明示的なユーザー確認を求め、チェックポイントでターンを終了します。

• ARXIV_DOWNLOAD = false — true の場合、/research-lit は文献調査中に関連性の高い arXiv の PDF をダウンロードします。false（デフォルト）の場合、arXiv API 経由でメタデータのみを取得します。/idea-discovery → /research-lit に引き継がれます。

• HUMAN_CHECKPOINT = false — true の場合、自動レビューのループ（ステージ 3）では各ラウンドのレビュー後に一時停止し、スコアを確認して、修正の実装前に独自の変更指示を出せます。false（デフォルト）の場合、ループは完全に自動で実行されます。/auto-review-loop に引き継がれます。

• REVIEWER_DIFFICULTY = medium — レビュアーの敵対的な度合いです。medium（デフォルト）：標準的な MCP レビュー。hard：レビュアーのメモリとディベートプロトコルを追加します。nightmare：GPT が codex exec 経由でリポジトリを直接読み込み、メモリとディベートを使用します。/auto-review-loop に引き継がれます。

• CODE_REVIEW = true — GPT-6-Astra xhigh がデプロイ前に実験コードをレビューします。GPU の時間を無駄にする前にロジックのバグを検出します。スキップするには false に設定します。/experiment-bridge に引き継がれます。

• BASE_REPO = false — ベースコードベースとして使用する GitHub リポジトリの URL です。設定すると、/experiment-bridge が最初にリポジトリをクローンし、その上に実験を実装します。false（デフォルト）の場合は、コードを一から作成するか、既存のプロジェクトファイルを再利用します。/experiment-bridge に引き継がれます。

• COMPACT = false — true の場合、コンテキストの短いモデルやセッション復旧向けに、コンパクトな要約ファイルを生成します。/idea-discovery と /experiment-bridge に引き継がれます。

• AUTO_WRITE = false — true の場合、ステージ 4 の後にワークフロー 3（/paper-writing）を自動的に実行します。VENUE が必要になるのはステージ 5 の開始時のみです。投稿先が未指定の場合、論文の執筆は延期されますが、ステージ 1〜4 がブロックされることはありません。false（デフォルト）の場合、ステージ 4 で NARRATIVE_REPORT.md を生成して停止します。ユーザーが /paper-writing を手動で実行します。

• VENUE = (unset) — 論文執筆の投稿先です。ステージ 5 の開始時にのみ設定されます。選択肢：ICLR、NeurIPS、ICML、CVPR、ACL、AAAI、ACM、IEEE_CONF、IEEE_JOURNAL。デフォルト値はありません。投稿先が未指定の場合、論文の執筆は延期されます。ステージ 1〜4 がブロックされることはなく、投稿先が推測されることもありません。

• RENDER_HTML = true — true（デフォルト）の場合、ステージ 4 の完了時に /render-html を使って NARRATIVE_REPORT.md を HTML に自動レンダリングします。--no-review を使用します（これは /paper-writing に渡す内部引き継ぎ文書であり、レビュアー向けの最終成果物ではありません。上流のステージ 3 の自動レビューで、すでに複数モデルによる主張のレビューが行われています）。スキップするには false に設定するか、— render html: false を渡します。ブロックされません：/render-html が失敗した場合、または Codex MCP を利用できない場合は、失敗を記録して続行します。HTML 表示はあると便利な機能であり、ステージ 4 の前提条件ではありません。

• RESUMABLE = true — true（デフォルト）の場合、パイプラインはステージごとの状態を .aris/runs/<run_id>.json に記録します。これにより、クラッシュや中断が発生しても、最初からやり直す代わりに /research-pipeline — resume <run_id> で再開できます。ステージの状態は、実行担当が書き込みを完了したことを示す done と、ステージの複数モデルによるゲートまたは決定論的な検証に合格したことを示す accepted に分かれています。再開時には、done だが未承認のステージが再検証されます。shared-references/resumable-runs.md を参照してください。

💡 引数で上書きできます。例：/research-pipeline "topic" — AUTO_PROCEED: false, human checkpoint: true, difficulty: nightmare, code review: false, base repo: https://github.com/org/project, auto_write: true, venue: NeurIPS。

チェックポイントの実行ルール

ステージ 1 の前に $ARGUMENTS から AUTO_PROCEED を一度だけ解決し、その解決済みの値をネストされたワークフローに渡します。

• AUTO_PROCEED=true はブロックしません。 チェックポイントは進捗の更新であり、質問ではありません。結果と自動的に選択された次のアクションを提示してから、同じターン内で実行を続けます。確認を求めたり、ユーザー入力を要求したり、スリープしたり、応答がない状態を待ったり、チェックポイントでターンを終了したりしてはいけません。
• AUTO_PROCEED=false はブロックします。 選択肢を提示してユーザーに尋ね、ターンを終了します。明示的な返信を受け取ってからのみ再開します。

「質問して、応答がなければ続行する」という形で自動続行を実装してはいけません。ターンが終了すると、応答がない状態ではパイプラインを再開できません。ユーザーは、ブロックされない実行をいつでも中断できます。

このルールが適用されるのは、AUTO_PROCEED で制御される選択チェックポイントのみです。ユーザーが Feishu のインタラクティブゲートを明示的に有効にした場合、外部からの承認または返信を意図的に待つ例外となります。このゲートでは、応答がないことをタイムアウトとして扱わず、ユーザーによる制御を待ちます。Feishu のオフモードおよびプッシュのみのモードは、AUTO_PROCEED=true の場合、引き続きブロックされません。

概要

このスキルは、調査ライフサイクル全体を 1 つのパイプラインに連結します。

/idea-discovery → /experiment-bridge → /auto-review-loop → /paper-writing (optional)
├── Workflow 1 ──┤├── Workflow 1.5 ──┤├── Workflow 2 ───┤ ├── Workflow 3 ──┤

最大 4 つの主要なワークフローを順番に実行します。ワークフロー 3（論文執筆）はオプションで、AUTO_WRITE によって制御されます。

再開可能な実行（— resume <run_id>）

このパイプラインは長時間かかり、実行途中で失敗する可能性があります。run_state.py を使ってステージごとの状態を追跡するため、最初からやり直さずに再開できます（shared-references/resumable-runs.md を参照）。 RESUMABLE = false の場合は、このセクション全体をスキップしてください。

正規のチェーン（integration-contract §2）を使ってヘルパーを解決します。 .aris/tools/run_state.py → tools/run_state.py → $ARIS_REPO/tools/run_state.py → ~/.aris/repo 経由の $ARIS_REPO/tools/run_state.py （解決できない場合は警告してスキップし、パイプラインを決してブロックしないでください）。

フェーズは次の順です：idea-discovery, experiment-bridge, auto-review-loop, summary, paper-writing。

• 開始時： — resume <run_id> が渡された場合は、 run_state.py resume <root> <run_id> を実行します。最初の accepted ではないフェーズが出力されるため、そのステージからパイプラインを開始してください（running／failed のステージは再実行し、done だが未承認のステージは再監査します）。それ以外の場合は、方向性のスラッグと日付から <run_id> を導出し、run_state.py start <root> <run_id> --phases "idea-discovery,experiment-bridge,auto-review-loop,summary,paper-writing" を実行します。

• 各ステージ： ステージの開始時に set <run_id> <phase> running を実行します。ステージの成果物を書き込んだら、set <run_id> <phase> done --artifact <path> を実行します。

• ステージのゲートを通過した後に限り accepted にしてください。実行担当者自身の判断だけで承認してはいけません（run_state.py accept には、記録済みの判定 ID とレビュー担当者が必要です）。

  phase	accepted にする条件	レビュー担当者として記録
  idea-discovery	ゲート 1 のモデル横断審査／新規性チェックに合格	codex-gpt-6-astra + スレッド ID
  experiment-bridge	実験が実際に実行された（ジョブが完了した）— 決定論的	deterministic:experiment-bridge
  auto-review-loop	ループが肯定的な STOP に到達した（score>=6 AND verdict∈{ready,almost} — codex の判定）	codex-gpt-6-astra + 最終レビューのトレース ID
  summary	NARRATIVE_REPORT.md が書き込まれた（RENDER_HTML が有効な場合はレンダリングも完了）— 決定論的	deterministic:summary
  paper-writing	投稿監査に合格した（verify_paper_audits.sh の終了コードが 0）— 決定論的	deterministic:verify_paper_audits.sh

AUTO_WRITE = false の場合（デフォルト）、paper-writing はこの実行に含まれません。 summary が承認された後、set <run_id> paper-writing skipped を実行してください。これにより、resume は保留中のステージをいつまでも指し示さず、COMPLETE を報告します。各 accept の verdict_id は永続的なハンドルとして記録してください。codex のスレッド／トレース ID、または決定論的な検証レポートのパス／sha（例：verify_paper_audits.sh の出力 JSON）を記録し、レビュー担当者のラベルだけにしないでください。

done のまま残されたステージ（ゲートに失敗した／結果が曖昧だった場合、またはゲート通過前に実行がクラッシュした場合）は、次回の再開時に再検証されます。承認の義務がスキップされることはありません。

夜間ハートビート：停滞検出 → 強制的な構造的方向転換

無人のハートビートがこの実行を駆動している場合（夜間の /loop / CronCreate）にのみ適用します。それ以外の場合はスキップしてください。方針と根拠： shared-references/external-cadence.md →「停滞検出と強制的な構造的方向転換」。これはタイプ A のシグナルです。検出結果を数え、 方向を変えるものであり、品質を判定するものではありません。

正規のチェーン（integration-contract §2）を通じてヘルパーを解決してください。解決できない場合は 警告してスキップし、実行を妨げないでください。

ITER_LOG=".aris/tools/iteration_log.py"
[ -f "$ITER_LOG" ] || ITER_LOG="tools/iteration_log.py"
[ -f "$ITER_LOG" ] || ITER_LOG="${ARIS_REPO:-}/tools/iteration_log.py"
[ -f "$ITER_LOG" ] || { [ -z "${ARIS_REPO:-}" ] && [ -f "$HOME/.aris/repo" ] && ARIS_REPO="$(cat "$HOME/.aris/repo" 2>/dev/null)"; } || true
[ -f "$ITER_LOG" ] || ITER_LOG="${ARIS_REPO:-}/tools/iteration_log.py"
[ -f "$ITER_LOG" ] || { echo "WARN: iteration_log.py not resolved; skipping stall detection" >&2; ITER_LOG=""; }

次に、各ハートビートのティックで、現在のステージで新たに得られた具体的な検出結果の数を記録し、 返された pivot を読み取ります。

[ -n "$ITER_LOG" ] && python3 "$ITER_LOG" note "$ROOT" "$RUN_ID" "$STAGE" "$N_NEW_FINDINGS"
# → {"stale_count": N, "pivot": "none|structural|human"}

pivot に応じて対応します。

• none — 続行します。
• structural（停滞 ≥ 2）— 次の促しでは、戦術的なパラメーターではなく、 構造的な制約（フレーム／目的／データ／表現）を変更し、これまでに試したものとは異なる方向を 選びます。今後のティックで同じ方向を避けられるよう、選んだフレームを記録します。 python3 "$ITER_LOG" note "$ROOT" "$RUN_ID" "$STAGE" 0 --direction "<the new frame>"。
• human（停滞 ≥ 4）— むやみに促し続けるのをやめ、人間の対応が必要であることを通知します（エスカレーションし、 何も知らせずに放棄しないでください）。

ハートビートが示してよいのは「続行／方向転換」であり、「これで十分」ではありません。 品質に関するすべての判定は、クロスモデル審査会（acceptance-gate.md）で必ず完結します。

パイプライン

ステージ 1：アイデアの発見（ワークフロー 1）

プロジェクトのルートに RESEARCH_BRIEF.md がある場合、詳細なコンテキストとして自動的に読み込まれます （一行のプロンプトの代わりになります）。templates/RESEARCH_BRIEF_TEMPLATE.md を参照してください。

アイデア発見パイプラインを実行します。

/idea-discovery "$ARGUMENTS" — AUTO_PROCEED: $AUTO_PROCEED

内部では次の処理を実行します：/research-lit → /idea-creator → /novelty-check → /research-review

出力： 優先順位付けされ、検証済みで、パイロットテスト済みのアイデアを含む idea-stage/IDEA_REPORT.md。

🚦 ゲート 1 — アイデアの選択：

idea-stage/IDEA_REPORT.md の生成後、上位のアイデアを提示します。

AUTO_PROCEED=true の場合（ブロッキングなし）： 選択内容を報告し、同じターン内ですぐに続行します。 更新内容を質問形式にしないでください。

📋 Idea Discovery complete. Top ideas:

1. [Idea 1 title] — Pilot: POSITIVE (+X%), Novelty: CONFIRMED
2. [Idea 2 title] — Pilot: WEAK POSITIVE (+Y%), Novelty: CONFIRMED
3. [Idea 3 title] — Pilot: NEGATIVE, eliminated

AUTO_PROCEED: selected Idea 1 — [title]. Continuing to Stage 2.

AUTO_PROCEED=false の場合（ブロッキングあり）： 同じ順位を提示し、 Recommended: Idea 1. Shall I proceed with implementation? と尋ねてから、ターンを終了します。 ユーザーは次の操作を行えます。

• アイデアを承認する → ステージ 2 に進みます。/experiment-bridge は、/idea-discovery がすでに生成した refine-logs/EXPERIMENT_PLAN.md を読み込みます。
• 変更を依頼する（例：「アイデア 1 と 3 を組み合わせる」「X をさらに重視する」）→ ユーザーのフィードバックに基づいてアイデアのプロンプトを更新し、制約を調整して /idea-discovery を再実行してから、再度提示します。
• すべてのアイデアを却下する → 不足している点についてフィードバックを集め、調整した研究方針でステージ 1 を再実行します。ユーザーがアイデアを決定するまで繰り返します。
• ここで終了する → 現在の状態を idea-stage/IDEA_REPORT.md に保存し、今後参照できるようにします。

⚠️ AUTO_PROCEED=false の場合、このゲートではユーザーの確認を待ちます。 true の場合は、結果の提示後に自動的に続行します。パイプラインの残り（ステージ 2～3）には多くのコストがかかります（GPU 時間と複数回のレビュー）。そのため、GPU リソースを投入する前に最終確認の段階を設けたい場合は、AUTO_PROCEED=false に設定してください。

ステージ 2：実験ブリッジ（ワークフロー 1.5）

アイデアが選択されたら（自動またはユーザーによる選択）、実装とデプロイを /experiment-bridge に委任します。

/experiment-bridge "$CHOSEN_IDEA_TITLE" — code review: $CODE_REVIEW, base repo: $BASE_REPO, compact: $COMPACT

💡 キューの振り分けは自動です：/experiment-bridge のフェーズ 4 では、ジョブ数に応じて各マイルストーンを振り分けます。ジョブ数が 5 以下の場合は /run-experiment、ジョブ数が 10 以上、または教師フェーズから生徒フェーズへの依存関係がある場合は /experiment-queue（OOM リトライ、ウェーブゲーティング、クラッシュセーフな状態管理付き）に振り分けられます。手動で上書きする必要はありません。

実行内容（完全自律）：

1. refine-logs/EXPERIMENT_PLAN.md を解析し、マイルストーン、実行順序、計算予算を抽出します
2. 実験コードを実装します。パイロットをフルスケールに拡張し、既存のコードベース規約に従います
3. モデル横断コードレビュー — GPT-6-Astra xhigh が実装をレビューし、GPU 時間を使う前にロジックのバグ、不適切なメトリクス、正解データの誤用を確認します
4. サニティチェック — 最小規模の実験を最初に実行して環境を検証し、失敗を自動デバッグします（最大 3 回試行し、必要に応じて /codex:rescue にフォールバック）
5. フル実験をデプロイします。ジョブ数に応じて自動で振り分けられます（5 以下 → /run-experiment、10 以上 → OOM リトライ、ウェーブゲーティング、クラッシュセーフな状態管理付きの /experiment-queue）
6. 初期結果を収集します。出力を解析し、refine-logs/EXPERIMENT_TRACKER.md を更新します。W&B が設定されている場合は /training-check を実行します
7. 主な結果が良好な場合、/ablation-planner を使ってアブレーションを自動計画します

出力：

• refine-logs/EXPERIMENT_RESULTS.md — マイルストーンごとに整理された結果
• refine-logs/EXPERIMENT_TRACKER.md — 実行ごとのステータスを更新したもの
• EXPERIMENT_LOG.md（COMPACT=true の場合）— セッション復旧に適したログ

進捗の確認（実験の実行中）：

/monitor-experiment [server]

次に進む前に、/experiment-bridge の完了と引き継ぎ概要の報告を待ちます。

ステージ 3：自動レビューループ（ワークフロー 2）

初期結果が出たら、自律的な改善ループを開始します。

/auto-review-loop "$ARGUMENTS — [chosen idea title], difficulty: $REVIEWER_DIFFICULTY"

実行内容（最大 4 ラウンド）：

1. GPT-6-Astra xhigh が作業をレビューします（スコア、弱点、最低限必要な修正）
2. Claude Code が修正を実装します（コード変更、新しい実験、問題の再構成）
3. 修正をデプロイし、新しい結果を収集します
4. 再レビューし、（スコアが 6/10 以上かつ判定が {ready, almost} のいずれか）になるか、4 ラウンドに達するまで繰り返します

出力： 完全なレビュー履歴と最終評価を含む review-stage/AUTO_REVIEW.md。

ステージ 4：研究の要約と執筆への引き継ぎ

自動レビューループが完了したら、論文執筆への引き継ぎを準備します。

ステップ 1： 最終的な研究状況レポートを作成します（以前と同様）。

ステップ 2： 以下をもとに NARRATIVE_REPORT.md を生成します。

• IDEA_REPORT.md（選択したアイデア、仮説、新規性の根拠）
• リポジトリの実装詳細
• 実験設定と最終結果
• AUTO_REVIEW.md（レビュー履歴、修正した弱点、残る制約）

ナラティブレポートには以下を含める必要があります。

• 問題の説明と中心的な主張
• 手法の概要
• 各主張の根拠を示した主要な定量的結果
• 図表の一覧（存在するもの、手動で作成する必要があるもの）
• 制約と今後の対応事項

出力： NARRATIVE_REPORT.md と研究パイプラインレポート。

# Research Pipeline Report

**Direction**: $ARGUMENTS
**Chosen Idea**: [title]
**Date**: [start] → [end]
**Pipeline**: idea-discovery → experiment-bridge → auto-review-loop

## Journey Summary
- Ideas generated: X → filtered to Y → piloted Z → chose 1
- Implementation: [brief description of what was built]
- Experiments: [number of GPU experiments, total compute time]
- Review rounds: N/4, final score: X/10

## Writing Handoff
- NARRATIVE_REPORT.md: ✅ generated
- Venue: [VENUE or "not set — run /paper-writing manually"]
- Manual figures needed: [list or "none"]

## Remaining TODOs (if any)
- [items flagged by reviewer that weren't addressed]

ステージ 5：論文執筆（ワークフロー 3 — 任意）

AUTO_WRITE=false（デフォルト）の場合は、このステージをスキップしてください。 手動で使用できるよう、/paper-writing コマンドを提示します：

📝 Research complete. To write the paper:
/paper-writing "NARRATIVE_REPORT.md" — venue: <VENUE>, AUTO_PROCEED: $AUTO_PROCEED

AUTO_WRITE=true の場合：

🚦 ゲート 2 — 執筆チェックポイント：

📝 Research pipeline complete. Ready for Workflow 3.

- Venue: [VENUE]
- Input: NARRATIVE_REPORT.md
- Manual figures required: [list or none]
- Next step: /paper-writing "NARRATIVE_REPORT.md" — venue: [VENUE], AUTO_PROCEED: $AUTO_PROCEED

Proceeding with paper writing...

続行前の確認（会議はここで決定します。ステージ 1～4 は会議に依存しません）：

• VENUE が指定されていない場合：AUTO_PROCEED=false なら、ここで確認します。AUTO_PROCEED=true なら、推測も待機もせず、レポートとチェックポイントに「会議未指定 — 論文執筆を延期」と記録し、論文執筆フェーズを保留のままにして、後で再開できるよう正常に実行を終了します。会議先を黙って選んではいけません。
• 手動で図を用意する必要がある場合：AUTO_PROCEED=false なら、一時停止して必要な図を一覧表示します。AUTO_PROCEED=true なら、「論文執筆を延期（手動で用意する図：）」と記録し、同様に正常終了します。

次に、以下を実行します：

/paper-writing "NARRATIVE_REPORT.md" — venue: $VENUE, AUTO_PROCEED: $AUTO_PROCEED

解決済みの AUTO_PROCEED を明示的に渡し、ワークフロー 3 が独自のデフォルトモードに黙ってフォールバックしないようにします。

これにより、各フェーズを独自に処理するワークフロー 3 に処理を委譲します： /paper-plan → /paper-figure → /paper-write → /paper-compile → /auto-paper-improvement-loop

ワークフロー 3 が完了したら、パイプラインレポートを次の内容で更新します：

• 論文執筆の完了状況
• 最終 PDF のパス（paper/main.pdf）
• 改善スコア（ラウンド 0 → ラウンド N）
• 残っている問題

出力： LaTeX ソース、コンパイル済み PDF、PAPER_IMPROVEMENT_LOG.md を含む paper/ ディレクトリ。

HTML ビューをレンダリングする（RENDER_HTML = true の場合に自動実行）

ステージ 4 で NARRATIVE_REPORT.md を確定した後（論文執筆に分岐する前）に、ナラティブレポートに対して /render-html を実行します：

/render-html "NARRATIVE_REPORT.md" --no-review

--no-review は意図的に指定しています。これは査読者向けではなく、内部引き継ぎ用ドキュメントであり、要約されている主張はすでにステージ 3 の /auto-review-loop でモデル間レビュー済みだからです。出力：MD と同じ場所に NARRATIVE_REPORT.html を作成し、ソースの SHA256 を埋め込みます。

ブロッキングなし： /render-html が失敗した場合（ヘルパーが見つからない、ファイル書き込みエラーなど）、失敗を記録してステージ 4 を続行します。HTML ビューは利便性のための成果物であり、パイプラインの前提条件ではありません。

RENDER_HTML = false の場合は、この手順をスキップします。

出力プロトコル

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

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

主なルール

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

• ステージ 1 のチェックポイントは AUTO_PROCEED によって制御されます。 false の場合、ユーザーの確認なしに続行してはいけません。true の場合、最有力候補を報告し、質問や待機をせず同じターン内に続行します。

• アイデアが選定された後は、ステージ 2～3 を自律的に実行できます。これが「寝て、起きたら結果が出ている」という部分です。

• ステージ 3 が肯定的な評価を得ないままラウンド 4 で終了した場合、停止して残っている問題を報告します。無限にループしてはいけません。

• 予算への配慮：パイプライン全体の GPU 時間を追跡します。ユーザーが指定した上限に近づいている場合は警告します。

• ドキュメント：各ステージで、それぞれの出力ファイルを更新します。全履歴が自己完結している必要があります。

• 適切なエラー処理：いずれかのステージが失敗した場合（良いアイデアがない、実験がクラッシュする、レビューのループが行き詰まるなど）は、無理に先へ進めず、状況を明確に報告して代替案を提案します。

一般的な所要時間

ステージ	所要時間	離席可能？
1. アイデア発見	30-60 分	AUTO_PROCEED=true なら可
2. 実験ブリッジ	30-120 分（実装 + レビュー + デプロイ + 収集）	可 ✅
3. 自動レビュー	1-4 時間（実験によって異なります）	可 ✅

おすすめのタイミング：夕方にステージ 1 を実行し、就寝前にステージ 2～3 を開始すれば、起きたときにはレビュー済みの論文ができています。