execute

実行

計画された作業の1フェーズを実行します。

入力：

• アクティブな実行時フェーズシート（state/.../phases/phase-NN.md）
• plan.toml / plan.md
• design.md（設計の正本）
• slice-nnn.md（対象範囲）

プロセス

1. アクティブなフェーズの開始条件（EN-）が満たされていることを確認します。
2. コーディングの前に、design.md、plan.toml、実行時フェーズシートを読みます。シートがまだ記入されていない場合は、先に /phase-plan を実行します。確認済みの入力、前提、緊張関係がまだ明らかになっていない場合は、/preflight を使用します。
3. 最初に変更する予定の具体的なファイルまたはコンポーネントを特定し、深く読み込んだり編集したりする前に、それらのパスを対象に /retrieve-memory を実行して、対象範囲に関する注意点やパターンを早期に把握します。
4. 実装に進む前に、ステータスが実態と一致していることを確認します。
   • 最初のフェーズを開始する場合 → まだであれば、スライスを移動します：doctrine slice status <id> started（番号のみ）。
   • doctrine slice phase を使ってフェーズを in_progress に切り替えます（lib:reference/using-doctrine.md を参照）。これにより、適合性の境界が自動的に記録されます。ハンドラーがフェーズシートに code_start_oid = HEAD を記録します。追加の呼び出しは不要です。バインディングは、すでに実行している状態遷移に伴って行われます。（ディスパッチ調整コンテキストでは、ファネルのビートが記録を担うため、自動的にスキップされます。）
5. フェーズのタスクを小さくまとまりのある単位で実装します。TDD のレッド／グリーン／リファクタリングに従い、失敗するテストを書き、合格させてからリファクタリングします。些細な実装ではなく、振る舞いをテストします。進めながら、テスト用ヘルパーやフィクスチャを作成し、改善します。
6. 意味のある単位が完了するたびに、/harvest を実行します。
7. その単位で、今後の検索に役立つ永続的な注意点、パターン、またはサブシステムの事実が得られた場合は、次に進む前に /record-memory を実行します。
8. 作業を進めながらリントを実行し（cargo clippy、警告ゼロ）、ツリーがビルド可能な状態を保ちます。
9. リポジトリのコミットポリシーに従います。スライス ID を付けた小さなコミットを頻繁に行います（例：feat(SL-NNN): …）。クリーンなツリーを優先し、.doctrine/** のワークフロー変更を古い未コミットのまま放置しないでください。
10. /preflight または実装中に、未解決の設計上の曖昧さ、予期しない障害、トレードオフ、またはポリシーの曖昧さが明らかになった場合は、独断で先に進まずに作業を止めて /consult を実行します。
11. 作業の進行に合わせて実行時フェーズシートを最新の状態に保ちます。作成済みの plan.toml / plan.md に進捗を記録してはいけません（保存場所に関するルールです）。
12. フェーズの準備完了を宣言する前に、検証ゲート（doctrine check gate：リント＋テスト＋フォーマット）を実行し、変更したサブシステムとメモをもう一度確認して、記録漏れのメモ候補がないか確認します。フェーズ終了時には、コードレビューのスキルにある ## Cadence に従ってフェーズ単位のレビューを実施するか検討します。遵守基準を下回る場合はデフォルトで実施し、トリップワイヤーに該当する場合は必須です。
13. 終了条件（EX-）と検証（VT-、さらにエージェント／人間による VA-／VH- モードがあればそれら）を満たしたら、doctrine slice phase を使ってフェーズを completed に切り替えます。これにより、適合性の境界が閉じられます。ハンドラーが code_end_oid = HEAD を記録し、祖先／マージ以外のガードを適用して、フェーズの行をスライスのアーム中立レジストリにアップサートします。これは決定的な処理であり、クリティカルパス上にあります。「あわせて記録することを忘れない」ための手順ではありません。slice record-delta は手動の代替手段に限られます（範囲の修正、またはバインディング前のフェーズのブートストラップ）。その後、次のフェーズがある場合は /phase-plan に引き継ぎ、スライスの全フェーズが完了している場合は doctrine slice status <id> audit と /audit に引き継ぎます。

オプション：ソロ分離（オプトイン）

デフォルトの実行はツリー内で行われます。分離が要求されない限り、上記のパスは変更されません。

オプトインのみ — 自動では実行されません。 ユーザーまたは計画が分離を明示的に要求した場合にのみ、そのフェーズを専用のワークツリーフォークで実行します。その注記がない場合は、ツリー内で実装します。

分離が要求された場合は、実装を始める前（つまりステップ 5 の前）に、次の指定で /worktree を呼び出します。

• mode = solo、allow_work_in_place = true（サンドボックスで拒否された場合、solo はツリー内での実行に切り替わる場合があります）。
• branch = slice/SL-NNN-slug（スコープ内のスライス ID を指定します。例： slice/SL-NNN-<slug>）。耐久性のある ID に基づくワークツリーディレクトリを指定します （.worktrees/SL-NNN）。

/worktree は検出、作成手順（doctrine worktree fork）、プロビジョニング、起動ガード、グリーンベースラインを処理します。戻り値のフォークブランチが成果物です。

クリーンな直接書き込みエントリーポイントであることを確認します。 ソロの /execute は独自のオーケストレーターです。ここではワーカーモードは使用しません（それは /dispatch の処理経路です）。ワーカーであるかどうかはプロセスの属性です。このシェルで DOCTRINE_WORKER が設定されている場合、doctrine を介した作成書き込みはすべて作業途中で拒否されます。TDD ループの前に、これが未設定であることを確認します（doctrine worktree status に解決済みのモードが表示されます）。設定されている場合は解除してください。ディスク上に消去すべき古い状態はありません。

フォーク内で TDD ループ（ステップ 5～12）を実行します。グリーンになったら、フォークを調整ブランチに取り込みます。land を呼び出せるのは /execute だけです。

doctrine worktree land --fork slice/SL-NNN-slug   # merge --no-ff, ancestry preserved (NEVER squash)
doctrine worktree gc   --fork slice/SL-NNN-slug   # reap the spent fork once the oracle proves it landed

land／gc がこのように動作する理由については、 lib:reference/dispatch-mechanics.md の「The import severs ancestry — so "did it land?" needs a patch-id oracle」と「The squash blind spot」を参照してください。

成果

• フェーズの目標が追跡可能な証拠とともに実装され、グリーンで完了しています。
• 実装中、フェーズのステータスが完了時だけでなく、実態と一致しています。
• 実行全体を通して、メモと永続的な記憶が最新の状態に保たれています。