ralplan

Ralplan（コンセンサス計画のエイリアス）

Ralplan は、Autopilot が $deep-interview と $ultragoal の間で使用する標準のコンセンサス計画ステージです。Planner、Architect、Critic による計画と、そのレビューのライフサイクルを RALPLAN-DR 構造化審議（デフォルトは short モード、高リスク作業には deliberate モード）で進めて記録します。ローカルのライフサイクル証跡はホストが発行するセキュリティ上の権限ではありませんが、実行可能な計画と逐次レビューの証跡が永続化された後も、Ultragoal への通常の進行は到達可能なままでなければなりません。ホストの出所情報が欠けていても、Ralplan を終端状態にしたり、cancel、clear、recovery をブロックしたりしてはなりません。

使い方

$ralplan "task description"

スタンドアロンの Advisory 計画は明示的なオプトインです：

$ralplan --advisory "task description"

Advisory は同じ逐次の Planner → Architect → Critic レビューのライフサイクルを実行し、計画と両方のレビュー成果物を正確なバイト列と、トラッカーに裏付けられた 1 回の反復に紐付けてから、active:false を付けて呼び出し元に戻します。これは協調的なワークフローの一時停止であり、セキュリティの防壁や権限システムではありません。PreToolUse の許可/ブロック判定は決して出力せず、ホストのコンセンサスゲートを完了させず、実行を承認せず、無関係なホストの動作を抑制することもありません。終端状態には、コンセンサスゲート、ホスト検証、実行への引き継ぎについて、省略せず明示的な false の値を含めなければなりません。後から具体的で肯定的な実行要求があった場合は、権限を永続化せず、終端証跡を書き換えず、自動的な引き継ぎも作成しない、非権威的なルーティング文脈を生成することがあります。引用、コード、例、ドキュメント、質問、モーダルな要求、否定、曖昧な承認は、引き続き分類器上の否定例のままです。approved+proven には、完全なライフサイクルのダイジェストと書き込み後の再検証が必要です。管理上の放棄は追記のみで、準備済みまたはコミット済みのジャーナルについては冪等であり、元のクローズアウトジャーナルを書き換えずに、バイト単位で紐付けられた別個の管理イベントを記録します。実際の強制には、ユーザーが発行できない面における、ホストが発行し、ホストが検証した明示的な受領証またはケイパビリティが必要です。ローカルの Advisory ファイル、プロンプト、セッション/スレッドのフィールド、トラッカーの記録、HERDR の可観測性では、これを代替できません。Darwin では、各 Advisory 証跡成果物は固定ディレクトリリーダーによって 128 KiB に制限されます。その他のサポート対象プラットフォームでは最大 8 MiB まで許可されます。

フラグ

• --interactive：主要な判断ポイント（ステップ 2 の草案レビューとステップ 6 の最終承認）でユーザーへの確認を有効にします。このフラグがない場合、ワークフローは Planner → Architect → Critic のループを完全自動で実行し、確認を求めずに最終計画を出力します。
• --deliberate：高リスク作業のために deliberate モードを強制します。事前分析（3 つのシナリオ）と、拡張されたテスト計画（unit/integration/e2e/observability）を追加します。このフラグがなくても、リクエストが高リスクを明示的に示している場合（auth/security、移行、破壊的変更、本番インシデント、コンプライアンス/PII、公開 API の破壊）には、deliberate モードが自動的に有効になることがあります。
• --advisory：スタンドアロン専用です。Autopilot、Pipeline、Team、Ralph、Ultragoal、実行系フラグ、または不明なフラグとは組み合わせられません。有効化には、正規のセッション、ルートスレッド、ターンの識別子が必要です。

オントロジー重視のレビュー

要件の意味論、分類体系、プロンプト/仕様設計、ポリシーの区別、またはカテゴリ別リスクのアーキテクチャについては、architect ロールエージェントの読み取り専用レビューを助言的な証拠として引用してください。その指摘は、明示的に使用された場合に計画や後続の証拠に反映され得ますが、$ralplan 自体は Architect→Critic のライフサイクル証跡のみを記録し、助言的なレビューが永続的な実行の承認になることはありません。

インタラクティブモードでの使い方

$ralplan --interactive "task description"

動作

GPT-5.6 ガイダンスとの整合

共有ワークフローガイダンスのパターンを使用します。成果物を先に示すフレーミング、複数ステップの計画時に簡潔な可視的更新を出すこと、アクティブなワークフローブランチに対するローカルのオーバーライド、根拠に基づく計画と検証の期待値、明示的な停止ルール、適切な規模の実装/PRD の形、そして安全で可逆的なステップの自動継続を用います。確認を求めるのは、重大、破壊的、認証情報を必要とする、外部の本番環境に関わる、または好みに依存する分岐の場合のみです。

このスキルは独自のコンセンサスランタイムを実行します。存在しない Plan コンセンサスモードには委譲しません:

omx ralplan run --task <arguments> [--session <id>]

コンセンサスワークフローは次のとおりです:

1. Planner は適応的な計画(タスクの範囲に合わせた規模とし、正確に5ステップにはしないこと)と、レビュー前のコンパクトな RALPLAN-DR サマリー を作成します。現在の [main] と [planner] の動作: 単独の $ralplan は、呼び出し元またはランタイムが専用の planner ルーティングレコードを提供しない限り、アクティブなメインの計画レーンが作成してもかまいません。$autopilot の内部では、ステートフィールド planning_routing.owner:"planner" は、初期の Planner のドラフト作成と分解に専用の [planner] を使う必要があることを意味します。[main] が低コスト/ミニでない場合でも、.omx-config.json の agentModels.planner を設定すると特定の planner モデルを選択でき、複雑な Autopilot の計画では専用の planner 所有を強制します。RALPLAN-DR サマリーには次が含まれます:
   • 原則(3〜5個)
   • 意思決定の推進要因(上位3個)
   • 実行可能な選択肢(2つ以上)と、有利な点/不利な点の範囲を限定した記述
   • 実行可能な選択肢が1つだけ残る場合は、代替案を無効とする明示的な根拠
   • 慎重モードのみ: 事前検死(3つのシナリオ)と拡張テスト計画(ユニット/統合/E2E/可観測性)
2. ユーザーフィードバック (--interactive のみ): --interactive が設定されている場合、構造化された質問 UI(tmux にアタッチされている場合は omx question、tmux 外でネイティブの構造化入力が利用可能な場合はそれ)を使い、レビュー前にドラフト計画と 原則/推進要因/選択肢のサマリー を提示します(レビューに進む / 変更を要求 / レビューをスキップ)。それ以外の場合は、自動的にレビューに進みます。

ネイティブのロールルーティング事前確認: キーワードルーティングによって Ralplan が既に選ばれている場合でも、それは権限ではありません。ネイティブのタスクサーフェスが role_routing_unavailable を報告し、かつこのワークフローが適応型 Ralplan の Planner、Architect、Critic の権限、適応型のロールインテント、または適応型のコンセンサス権限を使おうとする場合にのみ、omx ralplan preflight --json を実行します。unsupported_documented_leader_proof の場合は、その適応型権限を使う前に停止し、文書化されたルートの証明を持つ Codex サーフェスを使うか、レビュー済みの代替ワークフローを使用してください。ルートの identity は、session_id、文書化されていない thread_id、セッション/ポインター/トランスクリプト/cwd の状態、子データの不在、またはプロンプトのラベルから推測しないでください。通常のネイティブの計画、ライフサイクル、状態、ステータス、ヘルス、HUD、ランタイム、セットアップ、インストール、同期、および無関係な委譲は、この事前確認の境界の外にあり、既存の制御によって引き続き管理されます。

ネイティブのロールルーティング規則: ネイティブサーフェスが agent_type のロールルーティングを公開している場合は、agent_type をインストール済みの OMX ロールに設定し、OMX の作業では決して省略しないでください。公開していない場合(role_routing_unavailable)は、agent_type を捏造しないでください。レビュー済みの正確な Codex リリース 0.144.5、0.145.0、0.146.1、0.148.0-alpha.5 では、適応型 Ralplan の Planner、Architect、Critic、ロールインテント、およびコンセンサスの権限は、文書化されたルートの証明がないため利用できません。それ以外のバージョンは不明として扱われ、安全側に失敗します。プロンプトのロールラベルや推測されたキャリアによってルーティングを黙って弱めないでください。その権限には、文書化されたルートの証明を持つ Codex サーフェスを使うか、レビュー済みの代替ワークフローを使用してください。omx ralplan role-intent write を直接実行する試みは、機械的な理由 unsupported_documented_leader_proof によって拒否されます。 3. Architect がアーキテクチャの妥当性をレビューし、最も強力な反対論（steelman antithesis）、少なくとも1つの実在するトレードオフの緊張関係、そして可能な場合は統合案（synthesis）を提示する必要があります。ステップ4の前に完了を待ってください。 これは、後続の役割固有の Architect サブエージェントとして起動し、タスクの完全な記述、コンテキストスナップショット、PRD/テスト仕様のパス、関連する先行の指摘事項を渡してください。検証されていないレビュアーのアイデンティティや、即興で作成した短いレビュアー用プロンプトで代用しないでください。deliberate モードでは、Architect は原則違反を明示的に指摘する必要があります。 4. Critic が品質基準に照らして評価します。ステップ3の完了後にのみ実行してください。これは、後続の役割固有の Critic サブエージェントとして起動し、タスクの完全な記述、コンテキストスナップショット、PRD/テスト仕様のパス、完了済みの Architect レビューを渡してください。Architect サブエージェントに Critic のゲートを実行させないでください。また、検証されていないレビュアーのアイデンティティや、即興で作成した短いレビュアー用プロンプトで代用しないでください。Critic は、原則と選択肢の一貫性、公正な代替案、リスク軽減策の明確さ、検証可能な受け入れ基準、具体的な検証手順を強制しなければなりません。deliberate モードでは、Critic は事前検死（pre-mortem）またはテスト計画の拡張が欠落している、または不十分な場合にこれを却下しなければなりません。 5. 再レビューループ（最大5回の反復）: Critic の判定が APPROVE 以外（ITERATE または REJECT）の場合は、必ず以下の完全な閉ループを実行しなければなりません。 a. Architect と Critic のフィードバックを収集する b. Planner と共に計画を修正する c. Architect レビューに戻る d. Critic 評価に戻る e. Critic が APPROVE を返すか、5回の反復に達するまでこのループを繰り返す f. 5回の反復後も APPROVE が得られない場合は、最良のバージョンをユーザーに提示する 6. Critic の承認後、実行可能な状態の計画成果物と、順次実施された Architect→Critic の証跡を永続化してください。スタンドアロンの対話型 Ralplan では、要求された将来の実行レーンを提示してください。Autopilot 内では、既存の明示的な $autopilot 呼び出しにより、その定義上の次段階である $ultragoal への監督付きの移行が承認されます。同じセッションとレビューサイクルに紐づく、Autopilot が所有する ralplan_execution_handoff を永続化してください。 7. ralplan_execution_handoff を {authorized: true, reason, authorized_at, session_id, review_cycle, source: "autopilot"|"user"} で記録してください。source:"autopilot" は、現在のフェーズが ralplan である監督付きのアクティブな Autopilot 実行に対してのみ有効です。ホストによる合意の権限を主張するものではありません。 8. 永続化された計画、順次の承認、および紐づけられた実行ハンドオフが存在した後に、$ultragoal へ移行してください。Ralplan 内で直接実装しないでください。

重要: ステップ3と4は、役割固有のサブエージェントとして必ず順次実行しなければなりません。両方のエージェント呼び出しを同じ並列バッチで発行しないでください。後続の Architect の結果を待ってから、後続の Critic を呼び出してください。完了した承認はローカルのライフサイクル証跡を確立するにすぎず、永続的な実行ゲートを満たすことはできません。

計画と実行の境界

$ralplan は計画モードです。ralplan がアクティブで、明示的な実行ハンドオフがアクティブでない間は、実装を目的とした書き込みツールは対象外です。Ralplan はリポジトリを調査してよく、書き込みは .omx/context/、.omx/plans/、.omx/specs/ などの計画成果物と、必要な .omx/state/ の記録に限られます。

正規のフローは次のとおりです。

$ralplan -> local Architect→Critic lifecycle evidence -> bound execution handoff -> $ultragoal

いかなる実行レーンを開始する前にも、ralplan は終了状態の計画ステート（complete、paused、failed、または入力待ち）と、以下の永続的なハンドオフ記録を出力しなければなりません。合意された計画から、同じ ralplan セッション内で直接コードの編集に進まないでください。

永続的なコンセンサス引き継ぎ契約

.omx/plans/prd-*.md と .omx/plans/test-spec-*.md が存在するだけでは、Ralplan が完了したことにはならず、スキップ可能でも、実行可能な状態でもありません。これらのファイルは計画成果物であり、コンセンサスの証拠ではありません。

Autopilot、Ultragoal、Team、または実装へ引き継ぐ前に、以下を区別した永続的な引き継ぎレコードを保存してください。

• planning_artifacts：PRD/テスト仕様のパス。
• ralplan_architect_review：承認の判定を含む、完了した Architect レビュー。
• ralplan_critic_review：承認の判定を含む、完了した Critic レビュー。Architect レビューの後にのみ記録します。
• ralplan_execution_handoff：{authorized: true, reason: "<rationale>", authorized_at: "<ISO timestamp>", session_id: "<current session>", review_cycle: <matching lifecycle cycle>, source: "autopilot"|"user"} を保存します。Autopilot が発行できるのは、自身が監督する ralplan フェーズに対してのみです。単独で実行する Ralplan では source:"user" を使用します。
• ralplan_consensus_gate.complete：順次行われた Architect と Critic の承認の後に、ライフサイクルの完了を記録します。これはホストによるセキュリティの保証ではありません。ローカルで作成された JSON/env/プロンプト/トラッカー/トランスクリプト/受領書形式の証拠を、ホストが発行した権限として説明してはなりません。

Architect が不在またはブロックされている場合は、ワークフローを Architect レビューの段階に留めるか、そのブロッカーを報告してください。Critic が不在、ブロックされている、または非承認の場合は、ワークフローを Critic/再レビューの段階に留めるか、最大反復回数の結果を報告してください。両方のレビューが承認された後、対応する ralplan_execution_handoff が永続的に保存されている場合にのみ実行を開始します。既存の計画/テスト仕様ファイルだけでは、Ralplan を省略したり実行したりする許可にはなりません。

コンセンサスモードの詳細については、Plan スキルの完全なドキュメントに従ってください。

Goal モードのフォローアップ提案

有効な ralplan_execution_handoff によって実行が許可された場合、調整された Team 実行とあわせて、プロダクト向けの goal モードの提案を含めてください。要求されたレーンを記録し、ホストが発行した権限を主張せずに引き継ぎを保存してください。

• $ultragoal — 既定の goal モードのフォローアップ。実装や、順次完了の追跡を伴う耐久性のある Codex/OMX ゴールとして扱うべき一般的な目標指向のフォローアップ計画向けです。
• $autoresearch — 計画が問い、文献・参考資料の収集、評価者によるリサーチ、または教授/批評家型のリサーチ成果物を中心とする場合のリサーチプロジェクト向けフォローアップです。（$autoresearch-goal は OMX 0.21 でサンセットスタブに移行されました。）
• $performance-goal — 計画が速度、レイテンシ、スループット、メモリ、ベンチマーク、その他の測定可能なパフォーマンス作業を中心とする場合の最適化/パフォーマンス向けフォローアップです。

耐久性のあるゴール追跡には $ultragoal を、調整された並列実装には $team を使用してください。併用する場合、Ultragoal が台帳を管理し、Team はチェックポイントに対応可能な実行証拠を返します。 利用可能なエージェント種別の一覧を使って、明示的な役割/人員配置、レーンごとの推論ガイダンス、具体的な起動のヒント（並列配信が正当化される場合は omx team を含む）、および今後の受領書で認可された実行経路に対するチーム検証の責任を作成してください。

事前コンテキストの取り込み

コンセンサス計画または実行への引き継ぎの前に、根拠のあるコンテキストスナップショットが存在することを確認してください。

1. リクエストからタスクのスラッグを導出します。
2. 利用可能な場合は、.omx/context/{slug}-*.md にある最新の関連スナップショットを再利用します。
3. 存在しない場合は、UTC の YYYYMMDDTHHMMSSZ 形式のタイムスタンプを使って .omx/context/{slug}-{timestamp}.md を作成し、次の内容を記載します。
   • タスクの記述
   • 望ましい成果
   • 既知の事実・根拠
   • 制約
   • 不明点・未解決の問題
   • 想定されるコードベース上の接点
4. あいまいさが依然として高い場合は、まず既存コードベース（brownfield）の事実を収集します。omx explore は非推奨です。単純な読み取り専用のリポジトリ調査には通常のリポジトリ調査ツールやサブエージェントを使用し、明示的にシェルで取得できる読み取り専用の根拠が必要な場合にのみ omx sparkshell を使用してください。その後、作業を続ける前に $deep-interview --quick <task> を実行します。
5. 計画が公式ドキュメント、バージョンを考慮したフレームワークのガイダンス、ベストプラクティス、または外部依存関係の動作に依存する場合は、$best-practice-research を範囲を限定された根拠のラッパーとして使用し、計画の引き継ぎを確定する前に、公式・上流の調査を researcher に自動的に委任してください。これにより、実行がリポジトリ内の記憶だけから始まることを防ぎます。
6. 以前の $autoresearch 実行が存在する場合は、その承認済みの成果物を計画の根拠として扱います。$autoresearch-goal の過去の成果物は、互換性のための入力としてのみ読み込んでください。ユーザーが継続的な調査の自動化を明示的に要求した場合を除き、Autoresearch を最終的なアーキテクチャやランタイムのコンポーネントとして含めないでください。そうでない場合は、その根拠を $ralplan の ADR、リスク、検証手順に統合してください。

この取り込みが完了するまで、実行モードへの引き継ぎは行わないでください。やむを得ず先に進む場合は、リスクのトレードオフを明示的に文書化してください。

ルーティングの境界

通常の範囲が限定されたタスクは、templates/AGENTS.md に記載された直接実行レーンにとどまります。 明示的なワークフローのリクエストは、キーワードレジストリ（src/hooks/keyword-registry.ts）とそれを担当するスキルの契約に従います。このカードは別個の有効化テーブルを定義しません。 Ralplan が有効になったら、上記の計画・実行およびコンセンサスの引き継ぎ要件を維持してください。「とにかくやって」という会話上の指示は、必要なレビューの根拠の代わりにはなりません。

シナリオ例

良い例: ワークフローに明確な次のステップがある状態で、ユーザーが continue と入力します。作業を再開したり同じ質問を繰り返したりせず、現在の作業の流れを続けてください。

良い例: ユーザーが出力の形式や後続の提供ステップ（例：make a PR）だけを変更します。それまでの矛盾しないワークフロー上の制約を維持し、更新を局所的に適用してください。

悪い例: ユーザーが continue と入力したのに、ワークフローが調査を最初からやり直したり、不足している検証・根拠を集める前に停止したりします。