run

/ouroboros:run

Ouroboros ワークフローエンジンを通じて Seed 仕様を実行します。

Usage

/ouroboros:run [seed_file_or_content]

トリガーキーワード：「ouroboros run」、「execute seed」

How It Works

1. 入力：Seed の YAML コンテンツを直接指定するか、.yaml ファイルへのパスを指定します
2. 検証：Seed が解析され、検証されます（goal、constraints、acceptance criteria、ontology）
3. 実行：オーケストレーターが PAL ルーティングを使用してワークフローを実行します
4. 進捗：セッションの追跡を通じてリアルタイムで進捗が更新されます
5. 結果：合格／不合格のステータスを含む実行サマリー
6. 検証ステータス：実行のみの結果は、ooo evaluate <session_id> による正式な3段階の検証が行われるまで executed_unverified です

Instructions

ユーザーがこのスキルを呼び出した場合：

MCP ツールの読み込み（最初に必ず実行）

Ouroboros MCP ツールは、多くの場合、使用前に明示的な読み込みが必要な遅延ツールとして登録されています。先にこの手順を必ず実行してください。

1. 実行 MCP ツールを見つけて読み込むため、アクティブなランタイムのツール検出機能を使用します。

   tool discovery query: "+ouroboros execute"
   

2. 通常、ツール名には mcp__plugin_ouroboros_ouroboros__ というプレフィックスが付きます（例：ouroboros_execute_seed、ouroboros_session_status）。ランタイムのツール検出が完了すると、ツールを呼び出せるようになります。
3. ツールを呼び出せる場合（すでに公開されている場合、または検出によって読み込まれた場合）は、以下の手順に進みます。すでに公開されているツールに対する検出結果が空でも問題ありません。Ouroboros MCP サーバーが存在せず、ツールが本当に利用できない場合に限り、Fallback セクションに進みます。

重要：この手順を省略しないでください。ツールがすぐに確認できないという理由だけで、MCP ツールが利用できないと判断しないでください。ほとんどの場合、MCP ツールは遅延ツールとして利用可能であり、先に読み込む必要があります。

最重要 — 遅延スキーマのガード（「Invalid tool parameters」を防止）： このスキルでは、複数のターンにわたって実行 MCP を呼び出します。各ターンは新しいツールコンテキストで実行されます。あるターンで読み込んだ遅延ツールのスキーマが、次のターンでも読み込まれているとは限りません。現在のターンでスキーマが読み込まれていない状態で実行 ouroboros_* MCP ツールを呼び出すと、ランタイムはサーバーに到達する前に 「Invalid tool parameters」 で呼び出しを拒否します。 したがって、このスキルで実行 MCP を呼び出す直前に必ず毎回、tool discovery query: "+ouroboros execute" を再実行して、ouroboros_start_execute_seed、ouroboros_job_wait、ouroboros_ac_tree_hud、ouroboros_job_result を含む実行ツール群を再読み込みしてください（冪等であり、すでに読み込み済みの場合は何も行いません）。一致するツールが読み込み結果に含まれず、ツールも呼び出し可能な状態でない場合（すでに公開されているツールに対する空の読み込み結果は、ツールがないことを意味せず、想定された何もしない動作です）、失敗する呼び出しを再試行せず、記載されているフォールバックに切り替えてください。

Execution Steps

1. git ワークフローを検出します（コードを変更する前に実施します）。

   • プロジェクトの CLAUDE.md を読み、git ワークフローの設定を確認します
   • PR ベースのワークフローが検出され、現在 main／master ブランチにいる場合：
     • フィーチャーブランチ ooo/run/<session_id> を作成します
     • コードの変更はすべてこのブランチに加えます
   • 設定がない場合：現在のブランチを使用します（後方互換性を維持）

2. ユーザーが Seed のコンテンツまたはファイルパスを指定したか確認します。

   • ファイルパスの場合：Read ツールでファイルを読み込みます
   • インライン YAML の場合：そのまま使用します
   • どちらもない場合：会話履歴から最近生成された Seed を確認します

   新規に開始する前に、ユーザーが効率性の方針をすでに選択していない場合は、期待する成果を基準に次のどちらかを尋ねます。

   • 効率重視の実行 — 並列化／分割した作業を効率よく開始し、復旧が必要な場合にのみ実行ルートを強化します。efficiency_mode="adaptive" と frugality_assurance="observe" を送信します。
   • 品質優先の実行 — 子作業を親の開始時のティアに維持します。efficiency_mode="quality_first" と frugality_assurance="off" を送信します。 frugality_assurance="strict" は、証明に余分な作業を費やす可能性があるため、別個の明示的なオプトインです。効率的な実行が選択されたというだけの理由でこれを有効にしないでください。再開時に再度尋ねないでください。サーバーは永続化されたポリシーを復元し、再開時の変更の試みを拒否します。

3. ouroboros_start_execute_seed でバックグラウンド実行を開始します:

   Tool: ouroboros_start_execute_seed
   Arguments:
     seed_content: <the seed YAML>
     efficiency_mode: <adaptive or quality_first>
     frugality_assurance: <observe, off, or explicit strict>
     max_iterations: 10    (or as specified by user)
   

   デフォルトでは model_tier を省略し、ランタイムが自動的に選択するようにします。ユーザーがティアを明示的に要求した場合にのみ model_tier: <user choice> を含めます。これは job_id、session_id、execution_id を返して即座に戻ります。

4. 既存のセッションを再開する場合は、session_id を含めます:

   Tool: ouroboros_start_execute_seed
   Arguments:
     seed_content: <the seed YAML>
     session_id: <existing session ID>
   

5. 推奨される監視スタンス: 観測を 1 つの子セッションに委任します。

   ジョブ開始時の TUI 表示 (RFC #1392):

   job_id、session_id、execution_id が返された後、実行やオブザーバーの委任を遅らせることなく、ライブビューを一度だけ表示します:

   • response.meta.dashboard_url が存在する場合は、それを主要なライブビューとして表示します。

   • 読み込まれた Ouroboros 設定に execution.tui_autolaunch: true (またはレガシーのトップレベル tui_autolaunch: true) が存在する場合は、無条件に ouroboros tui open を実行し、ダッシュボードについて短い 1 行で言及します。

   • それ以外の場合は、新しいターミナルで ouroboros tui open を使って TUI を開けることを一度だけ言及します。開くことを提案しますが、回答を待って実行をブロックしないでください。このセッションでの回答を記憶し、提案を繰り返さないでください。

   • ユーザーが承諾した場合は、ouroboros tui open を実行します。

   • 環境がヘッドレス、SSH、またはサポート外であるために ouroboros tui open が手動コマンドを報告する場合は、そのコマンドを一度だけ伝えて続行します。

   • ダッシュボードは外部オブザーバーです。どのチャットセッションが MCP ポーリングを所有するかは変更しません。

   ID が返された後、次の短いハンドオフのみを出力します:

   Execution started in background.
   Job ID: <job_id>
   Session ID: <session_id>
   Execution ID: <execution_id>
   Live view: <dashboard_url, or `ouroboros tui open`>
   Runtime/harness: <response.meta.runtime_backend>
   LLM backend: <response.meta.llm_backend>
   Efficiency: <response.meta.efficiency_mode>
   Frugality assurance: <response.meta.frugality_assurance>
   
   Observation: <confirmed read-only child observer, or durable catch-up mode>.
   With a confirmed observer, meaningful progress, attention, and completion
   events will be posted here. Without one, the run still survives this turn
   and I will catch up from durable events on your next message or status request.
   This conversation stays available while the run continues.
   We can refine requirements, inspect or review code, or work on an unrelated
   task in an isolated worktree. I will check for active-worker conflicts before
   editing this run's workspace.
   For full details later: `ouroboros_ac_tree_hud(session_id=<session_id>)`
   

   response.meta.job_observer が存在し、ホストに独立した子/サブエージェントセッションプリミティブがある場合は、オブザーバーセッションを正確に 1 つ生成し、そのオブジェクトを変更せずに渡します。Codex は明示的なネイティブサブエージェント委任を必要とし、Claude Code は 1 つの Task/Agent 子を使用します。オブザーバーは次のことを行う必要があります:

   • Codex では、ネイティブの spawn_agent プリミティブを task_name="run_observer" で正確に 1 回呼び出し、子メッセージに response.meta.job_observer を変更せずに含めます。wait 呼び出しは生成ではありません。

   • オブザーバーが接続されたと言う前、または開始ターンを終了する前に、生成結果がライブの子 ID/パスを返すことを要求します。

   • 読み取り専用を維持します: リポジトリの編集、実行制御、ワーカーのファンアウトは行いません。

   • ジョブカーソルを排他的に所有し、各オブザーバーツール呼び出しの直前に遅延 MCP スキーマを再読み込みします。

   • 宣言された引数で宣言された wait.tool を呼び出し、レスポンスメタからローカルカーソルを更新し、終端まで繰り返します。

   • 終端ステータス後に宣言された result.tool を呼び出します。

   • 1 つの簡潔な最終サマリーを返す前に、連鎖する正式な評価を含め、follow_result_job_keys で指定されたジョブ ID をフォローします。

   • ホストが子から親へのメッセージをサポートし、状態が意味のある形で変化する場合にのみ、まばらな進捗通知を送信します。

   オブザーバーが所有している間、メインセッションは同じジョブをポーリングしてはいけません。ユーザーとの会話を続けたり、要件を洗練したり、読み取り専用の検査/レビューを実行したり、明示的なステータス/制御リクエストを処理したり、分離されたワークツリーで無関係のタスクに取り組んだりすることができます。アクティブな実行のワークスペースに書き込む前に、ワーカーファイルとの重複を確認するか、作業を分離してください。プラグインモードがすでに実行全体を委任しているために job_id が存在しない場合は、代わりにそのプラグイン子のライフサイクルに従ってください。 Codex では、確定済みオブザーバーにも親リレーループが必要です。 spawn_agent が稼働中の子 ID/パスを返したら、最大 60 秒の wait_agent 呼び出しで親ターンを開いたままにします。子の send_message は メールボックスイベントをキューに入れるだけで、すでに終了した親ターンを 起こすことはできません。意味のあるオブザーバーの更新をリレーし、子が 終端サマリーを返すまで再度待機します。ユーザー入力が待機を中断する ことがあります。その場合はそれを処理し、ユーザーがライブ観察の停止を 求めたり、アクティブなリクエストを置き換えたりしない限り、オブザーバーが アクティブなままリレーループを再開します。その後、リレーループのみを 終了し、永続ジョブは実行したままにして、次ターンまたは明示的なステータス によるキャッチアップを提案します。オブザーバーの子が失敗した場合、 キャンセルされた場合、または終端サマリーの前に終了した場合は、無期限に 待機するのではなく、同じフォールバックを使用します。 この待機ループは、Ouroboros ジョブツールを呼び出したり、オブザーバーの カーソルを奪い合ったりしてはなりません。

   オブザーバーのメッセージは、トランスクリプトではなくイベントとして 処理します:

   • phase_changed / progress_advanced: 最大 1〜2 行の簡潔な内容でリレー します。生ログではなく、構造化されたサブタイプを解釈します:
     • run_configuration: 現在のランタイム/ハーネス、判明している場合は 開始モデルまたはティア、効率モード、および節約保証を述べます。正確な モデルがまだ判明していない場合は、最初のルーティングイベントで報告 されると伝えます。
     • execution_plan: AC の総数、依存関係/並列レベルの総数、作業を並列で 実行できるかどうか、および最初にスケジュールされた AC の概要を述べます。
     • discovery_summary: AC が調査している対象の範囲とその目的を述べます。 検索クエリ、生のコマンド、推論を決して開示しないでください。
     • level_started / level_completed: どの並列レベルがアクティブまたは 完了したか、および意味のある成功/失敗の件数を述べます。
     • ac_routing / harness_changed: 「現在〜で実行中」と述べ、初期 ルーティングまたは実際のモデル/ティア/ハーネスの変更のみを報告します。
     • ac_verified: 完了した AC とその簡潔な保証エビデンスを報告します。
   • attention_required: ブロッカーまたは保留中の決定を直ちに表面化し、 人間の判断が必要な場合にのみユーザーに尋ねます。
   • terminal: 最終結果と、あれば連鎖する評価を取得/提示します。
   • Synapse の .queued / .delivering: 該当する AC に保留中または 要求済みのインテントシグナルがあることを述べ、有効な境界を示します。 まだ適用済みとは主張しないでください。
   • Synapse の .applied / .completed: ランタイムで証明された適用を確認 し、存在する場合は範囲が限定された AC の返信をリレーします。
   • Synapse の .rejected / .delivery_uncertain: 直ちに表面化し、AC が 方針を変更したと決して主張しないでください。
   • 変化のないハートビートと生のツール出力は抑制します。

   すべてのリレーは、ユーザーの現在の会話言語でレンダリングします。イベント コードと有効モードの値は、正確な診断が役立つ場合にのみ変更せずに保ちます。 これらは英語の正規ホスト命令です。事実は、アクティブな会話言語で自然に 言い換えてください。

   この所有権の分担は、SOL クラスのモデルのデフォルトです: メインモデルが 1 回の開始ハンドオフを実行し、小さな分離されたコンテキストが反復的な 待機/結果の状態機械を所有します。

   子の作成が利用できない場合、失敗した場合、または稼働中の子を返さない 場合は、オブザーバーが存在すると主張したり、ライブのプロアクティブな メッセージを約束したりしないでください。デタッチされたワーカーは stdio MCP ターンを越えて存続します。進捗は永続的であり、次の親ターンまたは 明示的なステータスリクエストでキャッチアップされるとユーザーに伝えます。 ユーザーがライブ監視を明示的に求めた場合にのみターンを開いたままにし、 その場合は以下のフォールバックを使用します。

6. フォールバック: メインセッションでの低トークンリレーループ。 response.meta.job_observer が存在せず、ホストに独立した子セッションのプリミティブがなく、ユーザーが現在のターン中に監視を続けるよう明示的に依頼した場合に限り、これを使用してください。委任されたオブザーバーと並行して実行しないでください。それ以外の場合は安全にターンを終了し、次の親ターンで同じカーソルから再開してください。

   定期的な監視には、ouroboros_ac_tree_hud を繰り返し実行するのではなく、ouroboros_job_wait を使用してください。ツールのメタペイロードから、最新のカーソルと前回の進捗カウンターを保持してください。

   このループは、ハーネスやモデルで扱いやすいよう意図的に設計されています。

   • response.meta を信頼できる情報源として扱ってください。
   • カウント、ステータス、カーソルを得るために response.text を解析しないでください。
   • response.text は、人が読める現在のメッセージのヒントとしてのみ使用してください。
   • ローカルの監視状態はすべて、単純なスカラー変数に保持してください。
   • 変化したレスポンスごとに、短い中継メッセージを最大1件だけ送信してください。
   • 終端ステータスになったら、必ず ouroboros_job_result を実行して処理を続けてください。

   cursor = <cursor from start/status response, or 0>
   prev_status = "running"
   prev_phase = null
   prev_ac_completed = 0
   prev_sub_ac_completed = 0
   prev_message = null
   
   loop:
     Tool: ouroboros_job_wait
     Arguments:
       job_id: <job_id from step 3>
       cursor: <cursor>
       timeout_seconds: 180
       view: "summary"
       stream: "linked"
       wait_for: "attention_or_ac_change"
   
     cursor = response.meta.cursor
   
     if response.meta.changed is false:
       # Do not narrate unless the user explicitly asked for heartbeat updates.
       continue
   
     status = response.meta.status
     phase = response.meta.current_phase
     ac_completed = response.meta.ac_completed
     ac_total = response.meta.ac_total
     sub_ac_completed = response.meta.sub_ac_completed
     sub_ac_total = response.meta.sub_ac_total
     # The metadata field names remain legacy-compatible; relay them to users as Task/Subtask progress.
     message_hint = first non-empty non-metadata line from response.text, or null
   
     # Build one short relay update from structured fields.
     if status in ["completed", "failed", "cancelled", "interrupted"]:
       print terminal_relay(status, phase, ac_completed, ac_total, sub_ac_completed, sub_ac_total)
       break
   
     if ac_completed > prev_ac_completed:
       print task_progress_relay(phase, ac_completed, ac_total, sub_ac_completed, sub_ac_total, message_hint)
     elif sub_ac_completed > prev_sub_ac_completed:
       print subtask_progress_relay(phase, ac_completed, ac_total, sub_ac_completed, sub_ac_total, message_hint)
     elif phase != prev_phase or status != prev_status:
       print phase_or_status_relay(status, phase, ac_completed, ac_total, sub_ac_completed, sub_ac_total)
     elif message_hint != prev_message:
       print current_work_relay(phase, ac_completed, ac_total, sub_ac_completed, sub_ac_total, message_hint)
   
     prev_status = status
     prev_phase = phase
     prev_ac_completed = ac_completed or prev_ac_completed
     prev_sub_ac_completed = sub_ac_completed or prev_sub_ac_completed
     prev_message = message_hint or prev_message
   

   注：

   • timeout_seconds: 180 は、MCP 呼び出しが最大3分間ブロックすることを意味します。これにより、煩雑なポーリングを避けつつ、ライブ中継に必要な頻度でメインセッションを利用できます。
   • 非常に長いジョブや、ユーザーがハートビートのみを希望している場合は、view: "compact" を使用してください。生のツール出力には、job_x | running | AC 3/17 のような旧形式のテキストが含まれる場合があります。その場合は、Task の進捗としてユーザーに中継してください。
   • 通常の監視には view: "summary" を使用してください。ジョブメッセージに加え、旧形式の ac_completed／sub_ac_completed メタデータフィールドから算出した Task／Subtask のカウントが含まれます。
   • 詳細なジョブステータスをユーザーが求めた場合に限り、view: "full" を使用してください。

   中継スタイルの例：

   • 進行中：Deliver は Task 1/3、Subtask 12/16 まで進んでいます。現在は Subtask 3 の回帰テストに取り組んでいます。
   • レベル更新：並列レベル 1/1 が完了し、Task の進捗は 3/3 に進みました。
   • 完了：実行が終了しました。最終的なジョブ結果を取得しています。

   他のハーネス／モデル向けの中継出力の要件：

   • 更新内容は、1～2文または簡潔な1行にしてください。
   • phase、Task の完了数／総数、Subtask の完了数／総数がある場合は含めてください。
   • 現在の作業内容のヒントは、変化した場合に限り含めてください。
   • 通常の中継出力にタスクツリー全体を含めないでください。
   • 生の JSON、生のメタデータダンプ、変化のないカーソル行の繰り返しを含めないでください。
   • 終端ステータスは、completed、failed、cancelled、interrupted のいずれかを明示してください。

   ユーザーが生のステータスを求めない限り、生のツール出力全体を貼り付けないでください。 ツールが提示していない限り、推測による ETA を追加しないでください。

   Synapse の意図の精緻化： 実行中にユーザーが追加の実装意図を示した場合、対象の選定はメインセッションが担います。内部の AC／セッション ID をユーザーに尋ねないでください。

   各 Synapse 呼び出しの直前に、tool discovery query: "+ouroboros session signal" を実行して、遅延読み込みされるスキーマを再読み込みしてください。

   1. 開始結果またはオブザーバーの契約から execution_id を取得し、 ouroboros_session_signal_targets(execution_id=...) を呼び出します。
   2. 必要に応じて、ユーザーの意図を各ターゲットの ac_content、表示パス、 および現在の HUD アクティビティと照合します。有効なターゲットが 1 つであれば、 そのまま選択できます。ターゲットが複数ある場合は、明らかに関連性の高いものが 1 つだけ ある場合に限り選択します。本当に判断がつかない場合にのみ、ユーザーの言語で短く確認します。
   3. 実装への追加的な調整では、選択したターゲットの正確なスコープ／試行／実行ガードを指定して、 contract_effect="additive"、source="user"、mode="redirect"、 fallback_mode="after_turn" を指定し、 ouroboros_session_signal を呼び出します。ターゲットの検出時に expected_contract_version が提供された場合は、その値をコピーし、このユーザーの ターンに対して一意で安定した冪等性キーを 1 つ作成します。ターゲットが古くなっている場合は、 ID をユーザーに尋ねずに、1 回だけ再検出します。
   4. ユーザーが AC に読み取り専用の質問をする場合、または実装の変更ではなく保証を求める場合は、 mode="inform" と contract_effect="additive" を使用し、リダイレクト時にのみ有効な fallback_mode は完全に省略します。ランタイムが対応していれば、Synapse はツールを使わない 返信ターンを実行します。完了イベントから上限付きの返信を伝えます。
   5. 選択した AC と、返された有効なモードをユーザーに伝えます。反映されたと伝えるのは、 オブザーバーの .applied または .completed を待ってからにします。

   承認済みの目標、AC、制約、または非目標を変更するために Synapse を使用してはいけません。 これらの変更には、承認済みの共有後継契約または置換契約が必要です。

   アクティブな Conductor の注意への対応： recommended_host_actions が正式なアクションメニューです。変更を伴うツール呼び出しを 独自に考案してはいけません。

   1. 提供されたエビデンス ID を使い、短時間だけ有効な読み取り専用ホスト子プロセスを 最大 1 つ実行して検証します。ホストに検証プリミティブがない場合は、注意事項を示して、 変更を行う前に停止します。
   2. 順序付きメニューからアクションを選択します。後継アクションを検討する前に、 エンジンが所有する再試行／ルーティングを完了させる必要があります。
   3. ACT の前に、ouroboros_record_conductor_decision を通じて phase="selected" を記録します。実行モードで仕様を変更する場合は、ユーザーの明示的な 承認を得て、その承認の証跡を紐付けます。
   4. メニューに現在登録されている MCP ツールが明記されている場合にのみ ACT を実行します。 是正のための後継処理では、ユーザーが共有仕様の変更を承認していない限り、 承認済みの契約を維持する必要があります。
   5. completed、failed、declined のいずれか 1 つの最終結果を記録します。 Conductor のアクションが失敗しても、黙って再試行してはいけません。

7. ouroboros_ac_tree_hud は、手動での詳細確認または異常チェックにのみ使用します。

   通常のポーリングループでは、ツリー HUD 全体を呼び出してはいけません。

   次の対象を絞った呼び出しを使用します。

   # Explicit short HUD, useful for a one-off check
   Tool: ouroboros_ac_tree_hud
   Arguments:
     session_id: <session_id>
     cursor: <cursor>
     view: "summary"
   
   # Lowest-token one-line HUD
   Tool: ouroboros_ac_tree_hud
   Arguments:
     session_id: <session_id>
     cursor: <cursor>
     view: "compact"
   
   # Full tree only when user asks "show details", progress looks stuck,
   # or debugging requires seeing the task/subtask structure.
   Tool: ouroboros_ac_tree_hud
   Arguments:
     session_id: <session_id>
     cursor: <cursor>
     view: "tree"
     max_nodes: 30
   

   明示的なコンパクト表示／サマリー表示で返される unchanged cursor=<cursor> は、 何もしない結果として扱います。ユーザーがハートビートメッセージを明示的に求めていない限り、 その内容を説明してはいけません。

8. ポーリングの担当側で ouroboros_job_result を使って最終結果を取得します。

   委任されたオブザーバーはデフォルトの経路でこの呼び出しを実行します。メインセッションは、 ステップ 6 のフォールバック経路でのみ実行します。

   Tool: ouroboros_job_result
   Arguments:
     job_id: <job_id>
   

9. 実行結果をユーザーに提示します。

   • 成功／失敗のステータスを表示します
   • 後でステータスを確認できるよう、セッション ID を表示します
   • 実行の概要を表示します

10. 実行後の QA と正式な評価（自動）： ouroboros_start_execute_seed は、実行が成功すると自動的に QA を実行します。 QA の判定結果は、最終ジョブ結果のテキストに含まれます。この QA チェックは 正式な 3 段階評価ではありません。chained_evaluate_job_id を返すサーバーでは、 成功した実行によって、別個の上限付きバックグラウンドジョブとして正式な評価が すでにキューに登録されています。 スキップするには、ツールに skip_qa: true を渡します。 最終実行結果のメタに chained_evaluate_job_id が含まれている場合:

• 現在のポーリングオーナーがそのジョブ ID で処理を続行します
• 終了ステータス後に ouroboros_job_result でその判定を取得します
• final_approved: true の場合は APPROVED と表示します。それ以外の場合は未承認と表示し、評価結果から失敗した AC または失敗理由を列挙します
• evaluate ジョブが失敗またはタイムアウトした場合は、実行の成功はそのまま維持し、手動リトライとして Next: ooo evaluate <session_id> を表示します

chained_evaluate_job_id が存在しない場合は、従来のパスをそのまま維持します:

• PASS: Next: ooo evaluate <session_id> for formal 3-stage verification
• REVISE: 差分/提案を表示し、続けて Next: Fix the issues above, then ooo run to retry -- or ooo unstuck if blocked
• FAIL/ESCALATE: Next: Review failures above, then ooo run to retry -- or ooo unstuck if blocked

フォールバック (MCP サーバーなし)

MCP サーバーが利用できない場合は、ユーザーに次のように伝えます:

Ouroboros MCP server is not configured.
To enable full execution mode, run: /ouroboros:setup

Without MCP, you can still:
- Use /ouroboros:interview for requirement clarification
- Use /ouroboros:seed to generate specifications
- Manually implement the seed specification

例

User: /ouroboros:run seed.yaml

[Reads seed.yaml, validates, starts background execution]

Background execution started.
Job ID: job_a1b2c3d4e5f6
Session ID: orch_x1y2z3
Execution ID: exec_m1n2o3

[Relay]
In progress: Deliver is at Task 1/3 and Subtask 12/16.
Current work is finishing the workflow routing Subtask.

[Relay]
Level update: parallel level 1/1 has finished, and Task progress advanced to 3/3.
Execution is complete. Fetching the final job result now.

[Fetching final result...]

Result:
  Seed Execution SUCCESS
  ========================
  Session ID: orch_x1y2z3
  Goal: Build a CLI task manager
  Duration: 45.2s
  Messages Processed: 12
  Verification Status: executed_unverified
  Formal Evaluation: NOT evaluated by the 3-stage evaluator

  Next: `ooo evaluate orch_x1y2z3` for formal 3-stage verification

  # Newer server path:
  Verification Status: evaluation_enqueued
  Chained Evaluation Job ID: job_eval987
  [Poll ouroboros_job_wait/job_status, then fetch ouroboros_job_result]
  Formal Evaluation Verdict: APPROVED

RFC #1392 ステートパンくずフッター

最終レスポンスは、必ずちょうど 1 行のパンくずフッター行で終わらせる必要があります:

◆ <current state> → next: <recommended action>

<current state> は、その MCP プロジェクションが利用可能な場合は ouroboros_session_status を通じてライブセッション状態から導出します。それ以外の場合は、このスキルの実際の結果から導出します。Ouroboros は進化的ループであるため、直線的な Step N of M フッターを決して使用しないでください。次のアクションが本当に選択肢である場合は、next: 句に 2〜3 個の正直な選択肢を列挙してください。パンくず行はレスポンスの最終行でなければなりません。