dispatch

Dispatch（ルーター）

隔離されたサブプロセスのワーカーを通じて、スライスの各フェーズを完了まで進めます。 あなたはオーケストレーターであり、唯一の書き込み担当者です。ワーカーが実行を担います。

開始時に宣言: 「dispatch スキルを使用して、隔離されたワーカーを通じて各フェーズを進めます。」

外側のループ

1. dispatch setup --slice <N> --dir <path> — 調整用ワークツリーを作成または再開します。 Claude ハーネスでは、--dir はプロジェクトルート内を指す必要があります（慣例は .dispatch/SL-<n>）。ルート外のディレクトリは安全側に倒して失敗します。他のハーネスでは、 強制されているルート外の隔離を維持します。
2. 調整担当者が自身で作成した書き込み（スライスのステータス、メモリ、監査記録）を dispatch commit --slice N -m <msg> -- <path>… でコミットします（パス指定は必須）。 生の git commit は決して実行しないでください。
3. dispatch plan-next --slice <N> — 次に実行可能なフェーズを見つけます。ファイルが重複しない場合は、並列バッチを計画します。
4. /dispatch-spawn を使ってワーカーを起動します。すべてのハーネスで、隔離されたサブプロセス経由の単一の経路を使います（preferred-subprocess-harness の選択が組み込まれるまでは、既定で pi ハーネスを使います）。
5. 各フェーズを自分で取り込み、コミットし、境界を記録し、検証して、フェーズを completed に切り替え、フォークを破棄します（下記参照）。
6. 終了処理: slice verify-vt <id>（VT ゲート、調整ツリー）→ 成功したら dispatch sync --prepare-review を実行 → 調整用ワークツリーを削除 → 監査

バッチごと

ベースがクリーンであることの前提条件（起動前、変更を加えない）。 B を取得する前、 またはワーカーを起動する前に、また調整用フォークを作成するために分岐する前に main 上で、ベースがクリーンであることを証明します。

doctrine check prove     # fmt-check + lint; asserts, never fixes

RED のベースは、ワーカーの検出結果とは異なるベースの不具合です。これからフォークしようとしているツリーが、すでにフォーマットされていないか、リントでエラーになっていることを意味します。運用担当者側で修正してください。自分でフォーマットしてコミットするか、分離された準備用ワークツリーを使います。決してワーカーの差分に混ぜたり、自動修正したりしないでください。汚れたベースから起動されたワーカーは、RED を引き継いで自分が引き起こしていない不具合のために取り込み時に停止するか、RED を不正に取り繕うことになります。この処理は、ここでの通常のバッチ処理（ホットパス）でバッチごとに一度だけ実行します（証明処理をもう一度実行するのは、後述の取り込み後ゲートだけです。二重に実行しないでください）。

起動前に B = git rev-parse HEAD を取得し、続いて B 時点の調整ツリーで回帰ベースラインを取得します。

doctrine check regression capture --base "$B"     # suite @ B; no-op on cache hit

この取得と検証差分の両方で、フィルター状態を正規化します。 自分の環境で DOCTRINE_WORKER が未設定であることを確認し、実際の再ビルドを強制します。これにより、取得と差分のテスト実行とテスト選択が同一になります。ツリーが同じだけでは不十分です。DOCTRINE_WORKER が漏れていると実行されるテストが変わり、キャンセル特性が損なわれます（その場合、フィンガープリントの不一致はキャッシュミスとなるため、正直に再取得します。ベースラインを汚染することはありません）。

ワーカー自身の報告は参考情報にすぎません。信頼するのは、自分で行った検証の結果だけです。

フェーズの取り込み: 次の順で自分が進める

ワーカーが返すのは、コミットされていない作業ツリーです（実際の git ディレクトリは隔離環境内で読み取り専用のため、ワーカーはコミットできません）。取り込みは自分で行います。worktree import --from-worktree → 調整用コミットを1つ作成 → slice record-delta --commit <S> → フェーズの検証を実行 → slice phase --status completed → フォークを破棄、の順です。各手順の仕組みと拒否時の動作については /dispatch-spawn に記載されています。以下の手順は個々のフェーズではなく、バッチに属するものです。

ファネルオラクル — バインドされたフォークのみ

lib:reference/dispatch-mechanics.md § The funnel record、およびそれが ドライバーとなる場合を参照してください。

仕組みはそのまま維持され、変更はありません。行が存在する場合に規定される内容は次のとおりです。

kind	規定内容
spawn	ファネル行はまだありません — /dispatch-spawn に引き継ぎます（スクリプト呼び出しのため、next はリテラルを出力しません）
await-worker	フォークは準備済みです。ワーカーが戻るまで待ちます
import	ワーカーの差分を取り込みます（dispatch_import、MCP のみ）
verify	フェーズのテストスイートを実行し、証跡を取り込みます（doctrine dispatch verify、CLI）
reverify-stale	合格時の証跡が現在の先端を表していません — テストスイートを再実行します
triage-verify-failure	RED の証跡です — 判断が必要な段階であり、コマンドはありません。何よりも先にトリアージします
conclude	フェーズの境界を確定します（dispatch_conclude_phase）
reap	使用済みのフォークを削除します（dispatch_reap）
all-reaped	フェーズのファネルが完了しました — doctrine dispatch status --slice <N> に引き継ぎます

ファイルが競合しない並列フェーズでは、指示は常に1つです。どこかで RED の証跡があれば、まずトリアージします（テストスイートは coord-tree 全体を対象とします）。待機中のフェーズが実行可能なフェーズを抑止することはなく、ほかの進行中フェーズは各段階の detail に示されます。

lib:reference/dispatch-mechanics.md §§ "Two altitudes" および "A refusal is the recovery procedure" を参照してください。

バッチ単位の段階

• Verify のリグレッション検査。 verify の段階で、doctrine check regression diff --base "$B" も実行します（S 時点のテストスイート。capture と同じ正規化済みフィルター状態）。new ∪ changed（どのテストバイナリ／環境で表面化するかにかかわらず、スライスのリグレッション）または実行不能な状態（コンパイルエラー／パニック／フォーマット変更は無言の合格ではなく、必ず停止）の場合、0 以外で終了します。persistent（B と S で同じキーと同じ署名）は許容される環境由来のアーティファクトです。空でないベースラインは環境由来としてごまかさず、修正が必要な trunk の警告として表示されます。停止時には、名前が示された new／changed のキーが問題の箇所です。これ以上の切り分けは不要です。現在の合格済みセットを baseline-<B'> として引き継ぐ方法は、保留中のコスト最適化です。通常運用では引き続き再 capture します。
• Import の prove ゲート。 worktree import --from-worktree はコミットを行わず、プロセス内で拒否して停止する prove ゲート（インポート後のツリーに対する doctrine check prove）を実行します。フォーマット未適用または lint が RED の差分があれば、lib:reference/dispatch-mechanics.md に従ってインポートを停止します（取り込むか拒否するかであり、決して書き換えません）。ここでの RED は WORKER 差分の欠陥であり、上記の spawn 前の BASE の欠陥とは別です。
• レジストリへの書き込み。 コードのコミット後、doctrine slice record-delta <SL> PHASE-NN --commit <S> が、コミットに紐付いた [S^,S] の行をプライマリツリーの適合性レジストリに書き込みます（対称な台帳の導出は保留中です。仕組みについては /dispatch-spawn を参照）。「記録も忘れずに」という手作業ではありません。Conclude の段階にある完全性ゲートは、取り込み済みのフェーズに行がない場合、以下のように停止します。
• フェーズごとのレビュー。 import と conclude の間で、コードレビュースキルの ## Cadence に従い、取り込まれた差分のレビュー要否を判断します。準拠度が基準を下回る場合は既定で実施し、いずれかのトリップワイヤー（テストの削除、Deviations: NONE、免除済み／検証不能な VT、スコープ外への変更）に該当する場合は必須です。
• ナレッジは確認済みコミットに続くものであり、それに先行してはいけません。

競合、HEAD の移動、または作成者ツリーへの変更があった場合は、報告して停止してください。自動で解決してはいけません。

引き継ぎの頻度

コミット済みの境界で引き継ぎます。handover_after バッチ（既定値 5）に達した後、またはレビュー済み差分の累積行数が handover_delta（既定値 2000）に達した後の、いずれか早い時点で実施します。

ベースの鮮度（作業中）

長時間作業を続けると、調整ブランチの下で trunk が進みます。このずれは、マージベースの乖離によって dispatch sync／candidate-create が競合するまで見えません。ずれに気づく場所としては、最も作業を乱すタイミングです。dispatch status はこの状況を表示します（trunk: moved (N commit(s) ahead of fork-point)）。status に進行が表示されたら、dispatch refresh-base --slice <N> を実行します。これはライブの調整ワークツリー内で、現在の trunk を dispatch/<N> にマージし、ベースを早い段階で、適切なコンテキストのもとで進めるため、各競合は1フェーズ分の差分になります。そこで競合が発生した場合は、報告して停止します。調整ツリー内で手動解決してください。自動マージは行いません。

終了

すべてのフェーズが反映されたら、調整ツリーが削除される前に、調整ツリー内で終了手順を実行します：slice verify-vt <id> → 成功したら dispatch sync --prepare-review → 調整ワークツリーのディレクトリを削除（参照は保持）→ slice status <id> audit → 親／ルートから /audit。ステージ2の統合は、監査後に /close が行います。監査前にコードを反映してはいけません。

slice verify-vt <id> は VT の存在／形式ゲートです。調整ツリーの plan.toml を読み込み、VT モードの各基準に必須の test_file と keywords があるか確認します。Fail はゼロ以外の終了コードを返し、引き継ぎを停止します。これを無視して prepare-review に進んではいけません。/consult を使って作成済みの計画を修正または免除してください（必須条件を独断で緩和してはいけません）。その後、再実行します。Uncheckable／Waived は表示されますが、停止条件にはなりません。この処理では fs リーダーで十分です。オーケストレーター（唯一の書き込み担当者）がディスパッチ中に免除事項を dispatch/<slice> にコミットしているため、調整作業ツリーとコミット済みグラフは一致し、prepare-review が投影する内容も同じです。

引き継ぎに含める： verify-vt の VT サマリーブロックと、1行の回帰ステータス（verify ビートの check regression diff から取得）を終了時の出力と /handover パケットに含めます。これにより、ギャップ（UNCHECKABLE／WAIVED を含み、区別して表示）が監査時ではなく引き継ぎ時に見えるようになります。

prepare-review は強制適用される適合性ビートです。参照を投影する前に境界台帳をコミットし、コミット済みの台帳からレジストリー行を導出します（台帳のすべての行をプライマリレジストリーに upsert します。アームに依存しません）。続いて完全性ゲートを実行し、完了済みフェーズにレジストリー行がない場合は bail! します。これにより、監査時にはレジストリーが必ず完全な状態になります。ギャップがあればここで停止し（参照は作成されません）、オペレーターが台帳をコミットするか、record-delta でギャップを記録してから再実行します。

要注意事項

重要：細心の注意を払って読んでください

絶対にしてはいけないこと： ルーティングせずにワーカーを起動すること。ワーカーに .doctrine/／.claude/ を書き込ませること。ワーカーがコミットすると期待すること（ワーカーの .git は読み取り専用です。作業ツリーを取り込みます）。フォーク履歴を再生すること。競合を自動マージすること。計画／設計を自動調整すること（/consult はフォークします）。セッションの main で作業を進めること。終了時に統合すること。成果物の参照を削除すること。インライン実行に切り替えること。着地状態を git の外で手作業で整えること。上記の順序を守ってください。拒否に対して独自の修正を試みること（拒否の文面そのものが手順です）。失われたファネル行を「修復」すること（バインドされていないフォークは行を作成しません）。 ! インライン実行に切り替えてはいけません。/execute を実行しようとしている場合は、STOP。 ! チェーンソーを振り回す酔っぱらいのように git を使ってはいけません。リスクのある操作をしようとしている場合は、STOP。 必ず守ること： ハーネスにかかわらず、/dispatch-spawn を通じてワーカーを起動すること。コンテキストを簡潔に保つこと（レポートの上限を設け、diff は統計情報を先に示す）。各フェーズを文書化された順序で反映し、次のフェーズを開始する前に現在のフェーズを完了すること。自己完結したワーカー用プロンプトを事前に作成すること。確認済みのコミット後にナレッジを記録すること。