計画実行

概要

事前承認済みの計画を厳密に遵守し、スコープ、順序、検証に従って実行します。計画を生きた文書として扱い、実行が進むにつれて進捗、発見、決定、成果を記録します。

入力は通常以下の形式です: execute-plan docs/plans/YYMMDD-HHmm-<plan-slug>/SUMMARY.md

実行中に計画を再設計しないでください。曖昧さまたは障害が現れた場合は、停止して質問してください。

ワークフロー

ステップ 1: 初期化

1. 計画の場所を特定

   • 計画パスが存在し、読み取り可能であることを確認します。
   • ディレクトリが提供されている場合は、その中から SUMMARY.md を探します。

2. 実行コンテキストを読み込む

   • 共有コンテキスト読み込みプロトコルに従ってプロジェクトコンテキストを読み込みます。
   • 計画のフェーズファイル、コンテキスト/オリエンテーションノート、依存関係、受け入れ基準、べき等性/回復ノート、決定ログ、未解決の質問を確認します。
   • 古い計画に生きた計画セクション（Progress、Surprises & Discoveries、Decision Log、Outcomes & Retrospective）がない場合は、計画が明確である場合、実行前にそれらのセクションを追加します。

3. 実行モードを選択（明確なルール）

   • デフォルトモード: バッチ
   • 次のいずれかが当てはまる場合はインタラクティブを使用します:
     • 高リスク変更（認証、支払い、マイグレーション、セキュリティ重要なロジック）
     • 不可逆的な操作（データマイグレーション、破壊的なスクリプト）
     • 受け入れ基準が不明確
     • ユーザーが明示的にチェックポイントをリクエスト
   • モードが不明確な場合は、1 回質問してユーザーの選択で進めます。

4. 次の保留中フェーズを検索

   • 最初の [ ] フェーズ
   • ない場合は、最初の [-] フェーズ
   • 保留中/進行中のフェーズが残っていない場合は、最終検証に進みます。

5. 重要な計画の正当性チェック

   • 各フェーズに以下を確認:
     • 明確な目的
     • ファイルターゲット
     • 検証コマンド
     • 観察可能な受け入れ基準
   • 観察可能な受け入れ基準がないが、明示的なフェーズ検証と終了基準から推論できる場合は、実行前にそれをフェーズに追加します。
   • 本質的な詳細が欠けている、または矛盾している場合は、停止して説明をリクエストします。

ステップ 2: フェーズごとのループ実行

各フェーズを順番に実行:

1. 完了済みをスキップ

   • ステータスが [x] の場合は、次のフェーズに進みます。

2. 進行中としてマーク

   • 変更を加える前に、フェーズステータスを [-] に更新します。
   • SUMMARY.md に、フェーズ開始を説明するタイムスタンプ付き Progress エントリを追加します。

3. 正確に実行

   • そのフェーズで定義されたタスクのみを実装します。
   • 承認なしにスコープを拡大しないでください。
   • フェーズを満たす最小限のコードを書きます。推測的な機能なし、単一用途コードの抽象化なし、不可能なシナリオのエラーハンドリングなし。以下のシンプルさ優先と手術的な変更ルールを参照してください。
   • 実装が重大な発見を明かした場合は、それを SUMMARY.md の Surprises & Discoveries に記録します。
   • スコープ内にとどまるために決定が必要な場合は、その決定と根拠を Decision Log に記録してから続行します。

4. フェーズを検証

   • 計画からフェーズ固有の検証コマンドを実行します。
   • 最低限、タッチされたファイルに関連する関連テスト/チェックを実行します。
   • SUMMARY.md の Progress またはフェーズの要求された証拠位置に簡潔な検証証拠を記録します。

5. 障害を処理

   • 検証が失敗した場合:
     • フェーズスコープ内で焦点を絞った修正を試みます。
     • 検証を再実行します。
   • まだ失敗している、またはルート原因がスコープ外の場合は、停止して障害を報告します。

6. 完了としてマーク

   • 検証がパスした後にのみ、フェーズステータスを [x] に更新します。
   • タイムスタンプ付き Progress エントリを、そのフェーズの検証結果と変更ファイルを含めて追加します。

7. 進捗レポート

   • インタラクティブモード: レポートして、次のフェーズの前に確認を待ちます。
   • バッチモード: 簡潔にレポートして、すぐに続行します。

ステップ 3: 最終検証

すべてのフェーズが完了した後:

1. プロジェクト全体の検証

   • 完全な lint/型チェックスイートを実行
   • すべての関連テスト（または計画で必要な場合は完全なテストスイート）を実行
   • 適用可能な場合は、ビルド検証を実行

2. 安定化

   • 実行中に導入された回帰を修正します。
   • 成功またはブロックされるまで失敗したチェックを再実行します。

3. 手動検証チェックポイント

   • ユーザー/手動 QA が必要な場合は、明示的に質問して一時停止します:
     • Verified で受け入れ
     • または、フォローアップの反復のためにフィードバックを提供

4. 成果を更新

   • SUMMARY.md の Outcomes & Retrospective を最終結果、検証サマリー、承認された偏差、フォローアップで完成させます。

ステップ 4: 完了成果物

1. ドキュメントの同期

   • 動作/アーキテクチャ/コードベース期待が変わった場合は、docs アーティファクトを更新します。

2. 実行レポートを作成

   • ファイル: docs/plans/YYMMDD-HHmm-<plan-slug>/EXECUTION-REPORT.md
   • 以下のすべての必須セクションを含めます。

3. 最終ゲートを準備

   • 最終ユーザー確認前にアーカイブしないでください。ユーザーは Need verify を選択でき、実行は同じ計画パスに対して続行する必要があります。

ステップ 5: 最終確認ゲート

完了成果物が完了した後、質問ツールを使用してユーザーに正確に以下のオプションで最終確認を求めます:

• Confirm: End session
• Confirm and Auto commit git
• Need verify

選択されたオプションを次のように処理します:

1. Confirm: End session

   • 計画フォルダを docs/plans/archived/ にアーカイブします。
   • アナウンス: Execution complete. Report archived at docs/plans/archived/YYMMDD-HHmm-<plan-slug>/EXECUTION-REPORT.md.
   • 実行セッションを終了します。

2. Confirm and Auto commit git

   • 計画フォルダを docs/plans/archived/ にアーカイブします。
   • アナウンス: Execution complete. Report archived at docs/plans/archived/YYMMDD-HHmm-<plan-slug>/EXECUTION-REPORT.md.
   • git-commit スキルをトリガーして、自動コミットフローを完了します。
   • コミットが成功した後、実行セッションを終了します。

3. Need verify

   • ユーザーに検証フィードバック/詳細を提供させます。
   • アーカイブしないでください。
   • 実行ループを続行してフィードバックに対処し、必要に応じて検証と完了ステップを再実行します。

実行レポート標準

EXECUTION-REPORT.md は以下のテンプレートを使用する必要があります: references/execution-report-template.md

ルール

• プロジェクト標準を尊重: docs/ および関連プロジェクトドキュメントに従います。
• 計画を厳密に従う: 静かなスコープ変更なし。
• 障害で停止: 欠落した依存関係、矛盾した指示、または説明のない障害。
• 推測なし: 不確かな場合は明確化をリクエストしてください。
• 完了前に検証: 検査がパスするまでフェーズが完了したとしてマークしないでください。
• 計画を生きたままにする: 実行が進むにつれて、SUMMARY.md の進捗、発見、決定、成果を更新します。重要な実行状態をチャット履歴に依存しないでください。
• べき等性: 安全で再実行可能な操作を優先します。
• シンプルさ優先: フェーズの終了基準を満たす最小限のコードを実装します。計画が求める以上の機能なし。単一用途コードの抽象化なし。リクエストされていない構成可能性なし。200 行を書いて 50 行で済む場合は、書き直します。
• 手術的な変更: フェーズが必要とするものだけをタッチします。隣接するコード、コメント、フォーマットを「改善」しないでください。壊れていないものをリファクタリングしないでください。破損していない既存のスタイルに合わせます。_あなたの_変更で孤立したインポート/変数/関数のみを削除します。計画がリクエストしない限り、事前存在の不要なコードを削除しないでください。変更されたすべての行は、フェーズタスクにトレースできる必要があります。
• ワークフローステップをスキップしない: 初期化、フェーズごとの検証、最終検証、レポート作成はすべて必須です。