v-implementing

v-implementing

v-planning が作成した、承認済みの DAG 構造の計画を実装します。計画は、root.md とノードごとの step-<n>.md で構成されるディレクトリです。あなたの役割はトポロジカルスケジューラーとして動作することです。各タイミングで、依存関係がすべて完了しているステップを見つけ、準備ができたステップごとに 1 つのサブエージェントを並列で起動し、完了を待ってから繰り返します。DAG の処理がすべて終わったら、グローバル検証を実行します。

これは implementing の並列版です。オーケストレーションモデルは同じです（サブエージェントが作業し、メインセッションが調整します）。異なるのはスケジューラーだけです。

作業上の合意事項

ユーザーへの質問はすべて AskUserQuestion を使用してください。規約については desplega:ask-user を参照してください。チャットで箇条書きの質問を直接することは避けてください。

読み取り、調査、検証の作業はすべてサブエージェントを通じて行ってください。生のツール出力をメインセッションに出さないでください。デフォルトでは run_in_background: true を使用します。以下のファンアウトスケジューラーは、この仕組みに基づいています。

自律モード（以下を参照）によって、進捗確認の頻度が決まります。質問には常に AskUserQuestion を使用してください。

ファイルレビューはデフォルトで有効です。ステップ（またはウェーブ）で重要な変更が反映されたら、インラインフィードバックを得るために /file-review:file-review <path> を実行してください（Autopilot の場合のみ省略できます）。

自律モード

モード	動作
Autopilot	一時停止せずに DAG の処理を完了します。ブロッカーまたは失敗したステップがある場合のみ停止します。
Critical（デフォルト）	並列ステップの各ウェーブが完了するたびに一時停止し、次のウェーブを開始する前に手動検証を待ちます。
Verbose	ウェーブ内であっても、個々のステップが完了するたびに一時停止します。

初期設定の質問

計画を把握した後、スケジューラーループを開始する前に、実装に固有の詳細を確認します（Autopilot では省略します）。

1. ブランチ／ワークツリーの設定

現在のブランチを確認します：git branch --show-current。次に、wts プラグインがインストールされているか確認します（利用可能なスキルに wts:wts があるかを調べます）。

wts がインストールされている場合は、AskUserQuestion を使用します。

質問	選択肢
"You're on <current-branch>. Where would you like to implement?"	1. 現在のブランチで続行、2. 新しいブランチを作成、3. wts ワークツリーを作成

wts がインストールされていない場合は、ワークツリーの選択肢を省きます。

2. コミット戦略

AskUserQuestion を使用します。

質問	選択肢
"How would you like to handle commits during parallel implementation?"	1. 各ステップの完了後にコミット（推奨）、2. 最後にコミット（単一コミット）、3. 進行に応じて判断する

「各ステップの完了後にコミット」が選択された場合は、ステップの手動検証が通った後に、[step-N] <step name> という形式でコミットを作成します。

3. オーケストレーションモード（Workflow ツールが利用可能な場合のみ）

質問	選択肢
"Run the DAG waves as Workflow scripts? (deterministic scheduling, parallel steps as agent() calls)"	1. はい — Workflow ウェーブ、2. いいえ — エージェントのファンアウト（デフォルト）

「はい」は、Workflow ツールが必要とする明示的なオプトインです。オプトインした場合、以下のスケジューラーループの各ウェーブは 1 つの Workflow スクリプトとして実行されます。つまり、準備ができたステップごとに 1 つの agent() 呼び出しを行う parallel() です。model／effort は desplega:delegate-work に従います。それ以外はすべて変わりません。ステップエージェントは引き続き step-running の契約（原子的な frontmatter の取得、3 分類の検証）に従い、自律モードの一時停止ポイントは Workflow 呼び出しの間に置かれ、呼び出しの内部には置かれません。Autopilot ではこれらの質問を省略するため、オプトインは行われません。ユーザーが事前にワークフローを許可していない限り、エージェントのファンアウトを使用してください。

4. コードレビューのモード

質問	選択肢
"Run an automatic code review after each wave?"	1. 各ウェーブ後に 2 軸の自動レビュー（推奨）、2. 最後にのみ実施（DAG の処理完了後に 1 回レビュー）、3. オフ — 自分でレビューする

Autopilot では質問を省略し、各ウェーブ後の自動レビューをデフォルトにします。

はじめに

計画ディレクトリのパスが指定された場合：

1. root.md を省略せずにすべて読む（limit／offset なし）。次の項目を把握します：概要、現在の状態、目指す最終状態、実装アプローチ、全体の検証。
2. すべての step-<n>.md のフロントマターを読み、依存関係グラフ（id、depends_on）を作成します。ステップ本文を先に読む必要はありません。サブエージェントが読みます。
3. DAG を検証します：
   • 循環がないこと
   • すべての depends_on ID に対応するステップファイルが存在すること
   • 少なくとも 1 つのステップで depends_on: [] が指定されていること（そうでないと何も開始できません）
4. root.md のフロントマターを status: in-progress に設定します。
5. ステップごとに 1 件の項目を含む TodoWrite リストを作成し、各項目を pending に設定します。
6. **再開のサポート：**ステップ本文にすでに - [x] のチェックボックスがある場合（またはユーザーが追加したフロントマターに status: completed と記載されている場合）は、その内容を信頼し、そのステップを done として扱います。

パスが指定されていない場合は、AskUserQuestion で尋ねます。

スケジューラーループ

スケジューラーは、各ステップのフロントマターにある status（ready | claimed | done）と depends_on を読み取ります。フロントマターの status フィールドが唯一の信頼できる情報源です。同じ計画ディレクトリ上で複数のオーケストレーターインスタンスが連携し、各 desplega:step-running サブエージェントは作業前にステップをアトミックに確保します。

while any step has status != done:
    ready = [step for step in steps
             if step.status == "ready"
             and all(dep.status == "done" for dep in step.depends_on)]
    if not ready:
        # DAG drained, OR every remaining undone step is claimed by another worker
        if any step has status == claimed: wait for in-flight claims to resolve
        else: report stuck (likely cycle or unrecoverable failure)
        continue
    fan out each step in `ready` as a parallel `desplega:step-running` sub-agent
    wait for the wave to complete
    review reports; step-running has already updated frontmatter
        (status: done on success, status: ready on retry-able failure, status: claimed if held for investigation)
    if Critical mode: pause for manual verification of newly-completed steps
    if any failed: stop and ask user how to proceed

ステップのサブエージェントを起動する

Agent ツールを run_in_background: true で使用し、desplega:step-running を呼び出します。次の情報を渡します：

• ステップのパス：step-<n>.md のフルパス
• 計画ディレクトリ：親計画ディレクトリのフルパス
• エージェント ID：このサブエージェント固有の ID（例：オーケストレーターのセッション ID + ステップ ID + タイムスタンプ）。step-running はこれをアトミックな確保と確保の古さの検出に使用します。
• 計画レベルのコンテキスト（任意）：root.md の簡単な概要。step-running は root.md を自身で再読み込みするため、これは往復を減らすためのものです。

step-running が担当する処理：

• アトミックな確保（フロントマターを status: ready から status: claimed, assignee: <agent-id>, claimed_at: <ts> に書き換え）
• 3 つの区分による検証（自動検証、自動 QA、QA ドキュメントの特定）
• 終了ステータスへの遷移（成功時は status: done、再試行可能な失敗時は status: ready）
• 結果の報告

オーケストレーター自身はステップの作業を行わず、委任します。サブエージェントの契約全体については desplega:step-running を参照してください。

実行役の振り分け：desplega:delegate-work スキルが利用可能な場合は、step-running サブエージェントを既定とせず、そのルーティングマトリクスに従って各ステップの実行役を選びます。ステップによっては Codex のバリアント（並列スライスごとに 1 つの worktree）や、特定の Claude モデル階層に振り分けられる場合があります。変更されるのは実行役の選択のみです。スケジューラー、フロントマターによる確保プロトコル、その他ここで定めるすべての動作は変わりません。ステップが Codex に振り分けられた場合、通常 step-running が行うフロントマターの記録管理はオーケストレーターが担当します（Codex は計画ファイルを編集してはなりません）。

ウェーブの完了

ウェーブが終了したら：

1. 各エージェントの報告を確認します。 完了が報告された場合にのみ、ステップを done にします。
2. ウェーブのコードレビューを実行します（レビューが Off でない場合）。ウェーブの統合差分に対して desplega:code-reviewing を呼び出し、Standards 軸と Spec 軸のレビューをバックグラウンドのサブエージェントとして並行実行します（desplega:delegate-work に従って割り当てます）。仕様のソースは、完了したステップの本文と Success Criteria です。重大な指摘があった場合、該当ステップのコミットは保留されます。先に修正して再検証してください。「Only at the end」が選択されていた場合は、DAG の処理が完了してから、全差分を対象にレビューを1回実行します。
3. QA Doc: <path> を処理します。 QA ドキュメントを報告した各ステップについて、そのパスを対象に desplega:qa を呼び出します。ステップ内の Automated QA の項目はサブエージェントがすでに処理しているため、ここではリンクされたドキュメントのみを別途調整します。（QA: n/a の場合は通常どおり進めます。）
4. 手動検証（Autopilot でない場合） — 完了した各ステップの本文から手動検証項目を提示します。ユーザーの確認を待ちます。確認されるまで手動チェックボックスにチェックを入れないでください。
5. コミット（ステップごとのコミットが選択されている場合） — ステップの手動検証に合格した後、コミットを作成します：[step-N] <step name>。
6. 繰り返し — ready を再計算し、次のウェーブを開始します。

失敗と不一致への対応

サブエージェントが failed または blocked を報告した場合、あるいは計画と実際の状況に不一致がある場合：

質問	選択肢
「[step-N] [issue]。どのように進めますか？」	1. ステップを調整する（step-N.md を編集して再試行）、2. 変更せずに再試行する、3. スキップして続行する（ステップを blocked にする）、4. 実行を停止する

Autopilot モードでは、適切に判断し、その決定をステップファイルに記録したうえで、致命的な問題でなければ続行します。

DAG の処理完了後

すべてのステップが done になったら：

1. root.md の Global Verification を実行します。自動チェックにチェックを入れ、手動チェックをユーザーに提示します。
2. root.md のフロントマターで status: completed に設定します。
3. 実装後の監査を提案します：「/verify-plan と /review をプランディレクトリに対して実行しますか？」
4. ステップごとのコミットがオフだった場合は、ここで単一のまとめコミットを作成することを提案します。
5. 作業を GitHub PR として提出する場合：レビューコメントが届いたら、desplega:tackle-gh-comments を使って対応します（スレッドを取得し、指摘を一つずつ確認して修正し、返信して解決済みにし、最後にプッシュします）。

重要なガイドライン

1. 1ステップにつきサブエージェントは1つです。 同じウェーブ内であっても、複数のステップを1つのエージェントにまとめないでください。並列実行が重要です。
2. プラン全体のコンテキストは、すべてのサブエージェントに渡します。 兄弟ステップの本文は渡しません。
3. DAG の正規の情報源はステップのフロントマターです — root.md の表と一致しない場合は、フロントマターを優先します。
4. 再開はステップ単位で機能します。 ユーザーが DAG の途中で /v-implement を再実行した場合、完了済みのステップは完了状態を維持し、未完了のステップのみ再実行します。
5. ユーザーの確認前に手動チェックボックスにチェックを入れないでください — 自動チェックには、サブエージェントまたはオーケストレーターがチェックを入れられます。

レビューの統合

file-review が利用可能で、ユーザーがオプトインした場合：

• 各ステップで重要なコード変更が行われた後、/file-review:file-review <changed-file> を呼び出します。
• ステップを完了とする前に、file-review:process-review でフィードバックに対応します。
• Autopilot ではスキップします。