ralph

/ouroboros:ralph

バックグラウンドの evolve_step ジョブを使った、MCP が管理する Ralph ループです。「巨石は決して止まりません。」

使用方法

ooo ralph --lineage-id <lineage_id>
/ouroboros:ralph --lineage-id <lineage_id>

ouroboros_ralph ツールがループを管理します（再実装しないでください）。1 つのバックグラウンドジョブで evolve_step の生成を繰り返し、QA 合格、収束、終端の進化アクション、キャンセル、または max_generations に達するまで実行します。ルーターのディスパッチでは、名前付きの --lineage-id オプションのみを読み取り、後続のテキストは読み取りません。

手順

MCP ツールの読み込み（スキーマ遅延への対処）

Ouroboros ツールは遅延読み込みされる場合があり、あるターンで読み込まれたスキーマが次のターンまでにアンロードされることがあります。各 ouroboros_* 呼び出しの直前に、アクティブなランタイムのツール検出機能を使って読み込んでください。ouroboros_ralph、ouroboros_job_wait、ouroboros_job_status、ouroboros_job_result、ouroboros_cancel_job には "+ouroboros ralph job" を、ouroboros_session_signal_targets と ouroboros_session_signal には "+ouroboros session signal" を、ouroboros_record_conductor_decision には "+ouroboros conductor decision" を指定します。スキーマが読み込まれていないツールを呼び出すと、「Invalid tool parameters」エラーが発生します。ツールがすでに呼び出し可能な場合、検出は何もせず、空の結果が返されるのが正常です。ツールが実際に存在しない場合は処理を中止し、Ralph には Ouroboros MCP ランタイムが必要であることをユーザーに伝えてください。

1. リネージ入力を準備する

• リネージを続行する：ユーザーが既存の lineage_id を指定して続行を希望する場合は、その ID を再利用し、更新された Seed が提供されない限り seed_content は省略します。
• Seed YAML から新規実行する：新しい lineage_id（ralph-<short-slug>-<uuid> など）とともに、seed_content として使用します。1 つの Seed に対する別々の実行が衝突しないよう、Seed、インタビュー、セッションの ID をリネージ ID として再利用しないでください。
• 自然言語のみのリクエスト：生のテキストを seed_content や手書きの Seed YAML として渡さないでください。まず ooo interview と ooo seed を実行する（またはコンテキスト内の検証済み Seed を再利用する）うえで、新しい lineage_id を使って開始します。入力がない場合、ツールはジョブの代わりに入力方法の案内を返します。

2. Ralph を開始する

ouroboros_ralph を呼び出し、lineage_id、seed_content（新しいリネージの第 1 世代）、execute（デフォルトは true）、parallel（デフォルトは true）、skip_qa（デフォルトは false）、判明している場合は project_dir、および max_generations（デフォルトは 10 で、これが上限です。リクエストがあった場合にのみ小さくします）を指定します。

3. 開始応答を処理する

• ジョブが開始された場合（response.meta.job_id が存在する場合）：response.meta.cursor を保持し、次のように報告します。

  [Ralph] Started background loop: <job_id>
  Lineage: <lineage_id>
  Live view: <dashboard_url, or `ouroboros tui open`>
  
  A read-only observer will post meaningful progress, attention, and terminal
  events here. This conversation remains available for other safe work.
  

• オブザーバーへの引き継ぎ：response.meta.job_observer がない場合は、最終的な `` コンテンツセンチネルから復元します。正規の v1 検証に合格し、ジョブの識別情報が表示されている開始レシートと一致しない限り、処理を続行しません。また、ツールや引数を再構成する目的では決して使用せず、識別アンカーとしてのみ使用します。ホストが独立した子セッションをサポートしている場合は、読み取り専用のオブザーバーをちょうど 1 つ起動し、契約を変更せずに渡します。ジョブの待機・結果呼び出しとカーソルは、オブザーバーのみが管理します。メインセッションは、ユーザーとの会話、明示的に要求されたオンデマンドのステータス確認、ユーザーが要求したキャンセルを引き続き担当します。オブザーバーがアクティブな間、メインセッションは同じジョブをポーリングしてはいけません。要件の明確化、読み取り専用のレビュー、または無関係な隔離済みワークツリーでの作業は行えます。Ralph のワークスペースに書き込む前に、アクティブなワーカーとの競合がないか確認してください。

  • wait 呼び出しや親によるジョブステータスのポーリングは、起動には当たりません。子の稼働 ID／パスが返るまでは、オブザーバーがいると主張してはいけません。具体的な起動および待機の仕組みについては、契約の host_lifecycle とランタイムの orchestrate_subagents ガイダンスに従ってください。子からの投稿が親にキューイングされるだけで、すでに終了した親ターンをランタイムが再開できない場合は、オブザーバーがアクティブな間、ホストの子待機プリミティブを使って親ターンを開いたままにし、待機時間は最大 60 秒とします。重要な更新を伝えたうえで、終端状態になるまで再度待機します。
  • ユーザー入力によって待機が中断された場合は、その入力に対応してから待機を再開します。ただし、ユーザーがライブ監視の停止を求めた場合、または依頼内容を変更した場合は除きます。その場合は中継ループのみを終了し、永続化されたジョブは実行中のままにして、次のターンまたは明示的なステータス確認で追いつけることを案内します。オブザーバーの子が失敗、キャンセルされた場合、または終端サマリーに達する前に終了した場合も、無期限に待機する代わりに同じフォールバックを使用します。中継ループは Ouroboros ジョブをポーリングしたり、カーソルを管理したりしてはいけません。
  • 起動に失敗した場合、ライブ中継を約束してはいけません。デタッチされたワーカーは stdio ターンの終了後も実行を続け、メインセッションは次のやり取りまたは明示的なステータス要求時に、永続イベントから状況を確認します。

• プラグインへの委任（response.meta.status == "delegated_to_plugin"、job_id が None）：子セッションがループを担当します。ジョブ ID なしでジョブツールを呼び出してはいけません。子セッションの結果を終端状態として扱い、完了またはエラーの状態と系譜 ID を要約します。

4. 監視（ポーリング担当者のみ）

デフォルトの担当者はオブザーバーです。独立した子セッションが存在せず、かつユーザーがライブ監視を明示的に依頼した場合に限り、メインセッションでこのループを実行してください。それ以外の場合は、次のターンで状況を確認してください。次の処理を同時に実行してはいけません。

• 長時間ポーリングには ouroboros_job_wait(job_id, cursor, timeout_seconds=120, stream="linked", wait_for="attention_or_ac_change") を使用します。 待機またはステータスの応答を受け取るたびに、cursor = response.meta.cursor に更新します。
• 状況をすばやく確認するには ouroboros_job_status(job_id) を使用します。
• ジョブが終了状態になったら ouroboros_job_result(job_id) を使用します。
• ユーザーから停止またはキャンセルを指示された場合は ouroboros_cancel_job(job_id) を使用します。

中継ルール：変更ごとに1～2行で伝えます。attention_required と、拒否された配信または確実性のない配信は、ただちに知らせます。Synapse の queued と、ランタイムで適用が確認された applied を区別します。ハートビート、生のツール出力、コマンド、モデルの推論を転送してはいけません。実行設定、AC の数と並列レベル、最初にスケジュールされた AC、確認済みの AC 完了状況を報告します。後続の世代でモデルやハーネスが切り替わる可能性があるため、「現在は～を使用して実行中です」と伝えます。lineage.generation.started に ac_focus が含まれる場合は、active_ac_descriptions をもとに、その世代でやり直している内容と、凍結状態にある AC の数を報告します（例：「Gen 7：5件中2件の AC を再作業中、3件は以前の PASS の証拠に基づき凍結」）。含まれていない場合、またはすべての AC がアクティブな場合は、AC グラフ全体を実行中と伝えます。検証コマンドや期待される出力を引用してはいけません。

ライブ AC について読み取り専用の質問を受けたり、ユーザーが意図を追加したりした場合は、実行状況を監視し、内部 ID を尋ねずに該当する AC を選んで ouroboros_session_signal_targets を呼び出します。質問や確約には mode="inform" を使用し、このモードでは fallback_mode を省略します。実装の調整には contract_effect="additive"、source="user"、mode="redirect"、明示的な fallback_mode="after_turn" を使用し、正確に確認できたガードを指定して ouroboros_session_signal 経由で送信します。共有ゴール、AC、制約、または非ゴールを変更する場合は、承認済みの共有後継が必要です。

これらは英語の正式なホスト指示です。これらの指示と中継内容はすべて、ユーザーとの会話で使われている言語に合わせて自然に表現してください。

RFC #1392 状態ブレッドクラムのフッター

最終応答の末尾に、◆ <現在の状態> → 次：<推奨アクション> の形式で、正確に1行を追加してください。利用できる場合は ouroboros_session_status でライブセッションの状態を確認し、そうでない場合はこのスキルの実際の結果から状態を判断します。Step N of M のような直線的なフッターは使用しないでください。次のステップが実際に選択肢となる場合は、2～3個の選択肢を示します。

5. 終了時

ポーリング担当者はジョブの結果を取得してから、次のように対応します。

• 成功／収束：最終世代、QA の判定、worktree_path や worktree_branch があればそれらを要約します。Ralph の lineage_id は実行時の session_id ではありません。別の実行から実際の実行セッション ID を取得できた場合に限り、ooo evaluate <session_id> を提案します。
• 最大世代数／失敗：停止理由を要約し、ooo unstuck、ooo interview、または対象を絞った Ralph の再試行を提案します。
• キャンセル：キャンセルされたことを確認し、後から調べられるようジョブ ID を保持します。

アクティブコンダクターの判断ポリシー

attention_required には、短時間で完了する読み取り専用の検証を最大1件だけ使用します。ホストに検証機能がない場合は、証拠を提示し、変更を加えてはいけません。それ以外の場合は、VERIFY → recommended_host_actions に基づいて DECIDE → ouroboros_record_conductor_decision で selected を LOG → メニューに記載された登録済みツールだけを ACT → completed、failed、または declined のいずれか1つの結果を LOG の順で実行します。Ralph がコンダクターの指示を適用できるのは、最初で唯一の、範囲が限定された後継世代（max_generations=1）に限られ、かつ指示が決定論的で、要件を緩和しない場合だけです。承認済みの共有契約を、黙って再試行したり緩めたりしてはいけません。