mo-orchestrate-orca

Orca を通じて機能をオーケストレーションする

ユーザーが mo-orchestrate-orca を指定した場合にのみ開始してください。一般的な実装、計画、レビューの依頼では、このライフサイクルは開始しません。

Feature lifecycle、 Backend contract、 Portable review protocol、 Orca native mechanics、 確認済みの外部作業のルーティング、 方法論へのフィードバック、 目的とアーキテクチャの契約をすべて読んでください。Orca バイナリを 1 つ解決し、それに対応するバージョンの空でない orchestration と orca-cli ガイドを読んでください。

ユーザーがオーケストレーションを依頼したセッションが、オーケストレーターです。orchestrator ロールが未設定でも開始は妨げられません。また、このセッションで使うモデルを尋ねる理由にもなりません。--force と別のモデル世代の使用は禁止です。ロールのアイドル状態が方法論のしきい値未満であることが確認できている間は、そのロールのターミナルを起動したままにし、しきい値を超えたら新しいセッションを優先してください。

ロールの選択内容は、同梱の scripts/mo-models.mjs --show --project <root> を使って読み取ってください。ユーザーが承認した値との完全一致を必須とし、モデル、作業量、配置、姿勢に関するフォールバックは選択しないでください。プロバイダー固有の認証、アカウントの最新状態、実際の起動 1 回を確認し、要求された ID と実効 ID が一致していることを確かめてください。タスクのバイト列を渡すのは、通常のエージェントプロンプトが公開情報として確認できた後に限ります。UI やシェルを信用してはいけません。

タイトルには <feature>:orchestrator、<feature>:executor、<feature>:review:<vendor>、<feature>:e2e:<n> を使用してください。Run、task、Dispatch、terminal の ID は、状態ストアではなく推論の中で正確に保持してください。アクターを起動する前に、プロジェクトの登録情報とリソースを記録してください。すべてのアクターは同じ Orca プロジェクト内にとどめてください。クリーンアップの対象は、厳密にそのアクターが所有する差分に限ります。

このライフサイクルは通常のシェルからも実行されます。配置を決める述語は 1 つだけです。ターミナル自身のハンドルを使います。ORCA_TERMINAL_HANDLE が設定されており、orca terminal read --terminal "$ORCA_TERMINAL_HANDLE" --screen --json で読み取り可能なら内部です。変数が設定されていないか、その読み取りが拒否された場合は外部です。シェルがどこにあるかは、配置を判断する別の指標ではありません。登録済みの worktree 内にあるディレクトリがターミナルを所有することはなく、Orca が作成したターミナルは、どのディレクトリからでもハンドルを保持します。ハンドルを指定しないターミナル読み取りは、呼び出し元のターミナルではなく、worktree にフォーカスされているターミナルを解決します。また、--terminal が受け付けるのは実行時に発行されたハンドルだけで、相対的な語句は受け付けません。これらのどちらも配置の判断には使いません。その場合の worktree セレクターには id:<repo>::<path> または path:<path> を使い、current や active は使いません。Run は --from なしで作成し、待機には check --run <id> --wait を使い、コーディネーターのタイトルは設定しません。このセッションを監視する watchdog がない場合は、制限を受け入れたことを一度だけ伝えてください。人間が戻るまで、制限に達した時点で作業は停止します。その後は続行してください。watchdog をユーザーが求めた場合に限り、watchdog ヘルパー、jq、flock を確認してください。それらがない場合は、その時点で通常の型付きギャップとして扱います。watchdog の起動は引き続き人間の判断が必要な境界です。一時的な仕様、ブリーフの草稿、中間コーディネーターファイルは、プロジェクトの .orca/ に置いてください。.orca/ が無視対象でない場合は、追跡対象のパスに一時ファイルを書き込まず、needs_attention を返してください。 準備状況に関する質問に答えられないプロジェクトは準備が整っておらず、このスキルで整えることもできません。scripts/mo-knowledge-layer.mjs --candidate <sha> を使って、すべての正確な SHA のナレッジレイヤーを読み取り、その1行を保持してください。not_enabled は、プロジェクトに完了させるナレッジレイヤーがないことを意味します。G0、GC、G1、G2 から MO-BACKLOG/1 の完了証明だけを削除してください。G1 と G2 のリモートヘッドの一致、G2 の CI 証拠、その他すべてのゲートは引き続き適用されます。needs_attention — MO-BACKLOG/1 コマンド、papercut ドキュメント、または識別子履歴ゲートが、これらを備えていたか、部分的に宣言していたプロジェクトで欠けている状態 — は、ヘルパーが出力した理由と missing= フィールドをそのまま添えて報告します。セットアップスキルを実行するかどうかは、引き続き人間自身が決めます。インテーク移行による書き込みを始める前に、コミット済みの HEAD のレイヤーを読み取ってください。これにより、needs_attention のリクエストでは仕様書、台帳、エグゼキューターを残さずに終了できます。

enabled の場合、インテーク移行の後、実質的な作業を始める前に、プロジェクトの MO-BACKLOG/1 コマンドを使って G0 から実行します。唯一のホットなエグゼキューターが、プロダクト／仕様書の編集、回帰テスト、不変条件に関するコメント、一貫性のあるコミットをすべて担当します。オーケストレーターはプロダクトコードを調査も編集もしません。エグゼキューターのタスクでは、引き継ぎのたびに手法に沿ったクリーンルームでの自己レビューを求めます。仕様書、差分、候補 SHA だけを受け取るサブエージェントによる PASS、自身の指摘に対する同じホットなサブエージェントによる PASS、そしてあなたまたはレビュー担当者から指摘があった場合は新たなサブエージェントによる PASS が必要です。エグゼキューターからの self_review_unavailable は、そのハーネスによる型付きの回答として受け入れますが、PASS として扱ってはいけません。自己レビューを自分で実行しないでください。

実行全体でブロッキング待機を1つだけ使用します。エグゼキューターのみの場合は 600000 ms、レビュー担当者／E2E が有効な場合は 300000 ms にします。ハンドルを正確に振り分け、完了したイベントバッチを処理し、ナレーションを挟まずに静かなタイムアウトを再設定し、トランスポート障害時の同一アームでの再試行は1回だけ許可します。

最初の詳細なペアと修正のフォローアップには mo-review-orca を呼び出します。検証済みのペアパス／サイズを通じてのみ、変更不可の両レポートをエグゼキューターに渡してください。クリーンアップの前に、正確な Review-Handoff-Ack を待ちます。修正担当のレビュー担当者はホットな状態を維持し、最終レビューには新しい同一 SHA のペアを使用します。公開アップデートには、候補、ペアの判定、執筆者が確定した P0–P3 の合計件数のみを記載します。

Meta-O スキル、リファレンス、スクリプトで確認された摩擦は ISS-16 です。このスキルの metadata.repository で指定されたリポジトリを検索し、一致する項目にコメントするか、サニタイズ済みの Issue を1件作成します。それ以外の場所には決して書き込まないでください。このフィールドがなければ宛先がないため、その所見は needs_attention として人間に伝えます。eval または E2E の実行では、どこにも書き込みません。

スコープ外の技術的な不具合が確認された場合は、同梱の Issue ルーティング判断表を適用します。所有者を検証してからプロジェクト／アップストリームにルーティングし、明示的に完全な上限を指定してオープンとクローズ済みの両方を検索します。その後、同じ制限付きポリシーを使い、プライベートなファイルセーフ本文の最終タイトルと許可リスト内のすべてのフィールドを再読して秘匿化します。ネイティブの gh／glab を使用します。根本原因と所有者が確定している技術的 Issue は事前承認済みです。認証情報、プロダクトに関する異議、サブスクリプション、取り消し不能または不明な影響、ウォッチドッグは、人間が判断する境界です。書き込み結果が不明な場合は、決して再試行しないでください。 プロジェクトで定義された QC を、対象候補と完全に一致するクリーンなチェックアウトでフォアグラウンド実行し、コマンドと終了コードを明記して、該当するシナリオでは mo-e2e を呼び出してください。レビュアーはテスト、リンター、QC を実行しません。ナレッジの収集と実装済み仕様の削除後、対象候補そのものに対して GC を必須としてください。エージェントが作成する MR/PR の直前に G1 を実行し、リモートのソースヘッドとの一致を確認してください。マージの直前に G2 を実行してください。つまり、クローズの証明、リモートヘッド、CI-Coverage/1 covered、およびチェックアウト SHA が対象候補と一致するすべての対象 CI QC ジョブの成功実行を確認し、そのうえでプロバイダーへの書き込みをそのヘッド／必須ポリシーに紐付けてください。その他のカバレッジ結果、実行の欠落や失敗、別のチェックアウト SHA、またはサポートされていない統合の対象候補の証明は needs_attention です。ローカルで証明済みの対象候補は引き渡しますが、CI の証拠がないままエージェントがマージしてはなりません。

QC、ベンダーが異なる最新の PASS レポート 2 件、該当する E2E、およびナレッジレイヤーが enabled の場合は空の GC が、変更されていない同一の完全な SHA に揃った場合にのみ完了としてください。それ以外の場合は、正直に needs_attention を返してください。未確認のレポート、未解決のバックログ、無関係なクリーンアップ、または必須の質問を残したまま完了してはなりません。

Meta-O の呼び出し

• mo-review-orca
• mo-e2e