vibe-plan-execution

Vibe Plan Execution

概要

具体的な実装計画をスライスごとに実行し、動作を独自に作り出さず、現在の証拠と矛盾した時点で停止します。計画が定めるのはスコープと意図であり、既知の問題がある実装の詳細ではありません。具体的な計画がない場合は、コーディングを始める前に計画策定に戻ってください。このスキルでは計画の作成やレビューは行いません。

影響と書き込みの境界

フェーズで宣言された影響クラスと境界が許可する範囲を超えて、何も書き込まないでください。

• フェーズの本文で宣言された影響クラスを適用してください。このパッケージでより厳しい制限が定められている場合は、そちらを優先します。
• 読み取り専用：チャットで報告します。ファイルを編集せず、状態を変更するコマンドを実行せず、ステージング、コミット、タグ付け、プッシュ、バージョン変更、データの削除、サービスの起動は決して行いません。ユーザーが保存用の成果物を明示的に求めた場合に限り、ファイルを書き込みます。
• 成果物限定：フェーズが所有する成果物と、本文で宣言された補助パス（確認済みの計画への所見や意思決定の記録など）のみを作成または更新し、それらはワーキングツリーに残します。
• 成果物限定のフェーズでは、実行可能な動作の実装、実装としてのコードやテストの編集、別のフェーズの成果物の作成、リリース作業、またはその成果物を同一ターン内の実装の根拠として扱うことは決して行いません。
• 状態変更あり：宣言されたスコープ内でのみ、最小の検証可能な単位で編集とコマンド実行を行います。ユーザーが選択しない限り、その他のパス、既存の変更、ランタイム状態や外部状態には触れません。
• これらの制限は、ファイルツールだけでなく、シェルコマンド（リダイレクト、sed -i、tee、mv、cp、rm、git checkout --）にも適用されます。書き込みを拒否した場合は境界による停止として報告し、別のツールを使って再試行してはなりません。
• 取り消し不能な操作や外部に影響する操作は、それぞれ個別に同意を得て行います。

このフェーズが宣言するスコープは、バインドされた計画で許可される現在のスライスを、まとまりのある最小のテスト可能な単位として実装することに加え、「永続的な記録」に記載された意思決定記録と調査結果レポートです。また、このスライスが作成する使い捨てのルートも対象です。必要な内容が保存されている使い捨てのルートを削除することはこのスコープ内であり、破壊的なクリーンアップにはあたりません。

チャットの言語

ユーザー向けチャット文の言語は、成果物の言語とは別に、次の順序で決定します。

1. チャット、応答、または出力の言語について、今回のユーザーが明示した指示。
2. VIBE_CHAT_LANGUAGE。ja や pt-BR などの言語名またはBCP47タグで、読み取り可能であるか、このリクエストに対してユーザーが設定したもの。値が空または無効な場合は未設定として扱います。
3. ユーザーが現在使用している会話言語、またはこのワークフロー内で最後に明確に使われた言語。
4. 英語。

• ユーザーが言語の契約として明示しない限り、成果物、ファイルの内容、パス、コマンド、コード、スキルの呼び出し、ホストラッパーのテキストからチャットの言語を推測してはなりません。
• ユーザーから翻訳を求められない限り、パス、コマンド、識別子、環境変数、ロケールタグ、メッセージキー、製品名、コードは原文のままにします。

また、証拠ラベルと計画の見出しも原文のままにします。

永続的な記録

フェーズの開始時に、docs/decisions/README.md と docs/reports/findings/README.md（またはリポジトリの既存のインデックス）を確認し、この作業単位にパス、タグ、または主題が一致する項目がないか調べます。該当する項目を適用する場合、確定した意思決定を記録する場合、調査結果を先送りする場合、またはいずれかを次の工程に引き渡す場合は、その前に references/durable-records.md を読みます。このフェーズでは、docs/decisions/ と docs/reports/findings/（またはリポジトリの既存の記録ディレクトリ）に書き込むことができます。

計画の情報源

編集を始める前に計画を1つ紐付け、最初の進捗報告でその名前を示します。ファイルの場合はパスを、それ以外の場合はタイトルを記載します。ローカルに計画の成果物がある場合は、それを読みます。チャットの要約はあくまで案内用です。成果物に従い、要約に追加または矛盾する内容があれば指摘します。現在のスライスの範囲、受け入れ基準、対象外事項、検証方法、リスク、続行条件を読みます。動作一覧、同等性分析、復旧の証拠、選定した失敗パターンの確認など、リスクの高いセクションも契約の一部です。前提条件が引き続き当てはまるのに古くなっている、または欠落している場合は、計画上の問題であり、証明の水準を下げる許可にはなりません。確認するまでは、ユーザーの主張を意図として扱います。

• 計画に記載された「Reserved decisions」の行は、指定された範囲内でのみ完了します。その行を通じて、範囲、基準、テスト、リスク、手順を変更してはなりません。
• 続行条件がブロック中または条件付きの場合は、まずその条件を満たします。それでも実装するよう求められても、条件を満たしたことにはなりません。
• スライスが具体的であるためには、目標、範囲、受け入れ確認項目、検証方法、実装方針が必要です。不足している要素が動作、証明、データ、権限、契約、UXに影響する可能性がある場合、独自に補うのではなく計画に戻ります。その際は、計画項目、不足している証拠、再開に必要なものを報告します。
• 計画の契約が最後に確認または紐付けた時点から変更されている場合、明確なユーザー権限または改訂権限がある変更に限り、影響を受けるセクションを読み直したうえで再度紐付けます。それ以外の場合は、計画の改訂を求めて停止します。進捗台帳の編集はステータスであり、契約を変更する権限にはなりません。
• 指定された項目が見つからない場合は、計画を1つだけ紐付け直せるのは、指定された計画の台帳が示す計画など、その項目を所有する計画が厳密に1つだけの場合に限ります。その場合は両方のパスを明示します。

証拠クラス

判断の根拠となるすべての主張に、4つの証拠クラスのいずれかを付けます。

• 判断の根拠となる主張とは、範囲、実現可能性、動作、検証、リスク、作業順序、コミットの許可、または作業を続行できるかどうかに影響する主張です。
• Primary source：公式または上流のドキュメント、仕様、ソースコード、ユーザー提供の資料、または正常に動作することが確認済みの過去の実装。
• Local investigation：このワークスペースから確認できるもの。ファイル、設定、スキーマ、ログ、既存のテスト、変更を加えないコマンドの出力、再現された動作。
• Unproven：記憶、推論、二次情報または未確認の主張、古いドキュメント、アクセス不足、仮説。
• Accepted risk：影響の説明を受けたうえでユーザーが明示的に進行を選択した Unproven の項目、または紐付けられた計画で受容済みと記録されている項目。
• これらのクラスの名称や定義を変更してはなりません。パッケージ独自の文章で、互いに重複しないラベルや鮮度の修飾語を追加することはできます。

このフェーズでは、2つのラベルを追加します。Plan（紐付けられた計画、仕様、受け入れ基準、またはタスクリストに記載された内容）と、Local evidence（コード、テスト、設定、スキーマ、ログを確認するか、チェックを実行して現在のワークスペースで検証した内容）です。実装で根拠として使用できるのは、Accepted-Risk Semanticsで認められている Plan、Local evidence、Primary source、Accepted risk のみです。編集を行わない応答でも、判断の根拠となる主張にはラベルを付けます。

実行ループ

1. バインド セクションを Plan Sources に登録してください。計画または指示が同意を要する作業に関わる場合は、最初の編集の前に Startup Consent Preflight を実行し、その操作に必要な同意判断が不足している場合は、それぞれについて操作前に確認してください。

2. 編集前に検証してください。 対象のスライスに関わるファイル、テスト、設定、スキーマを調査し、依拠する計画上の事実と機能依存関係を再確認してください。外部 API やその他の変動しやすい事実は、公式ドキュメントまたは上流ソースと照合してください。必要な調査を実施できない場合は、そのブロッカーの時点で停止し、スライスのコードやテストを作成しないでください。証拠が計画された手順と矛盾する場合は、Plan Validity Gate を実行してください。

3. 現在のスライスだけを実装してください。 ローカルの慣例を再利用し、将来のフェーズ、隣接するクリーンアップ、および通常の使用で到達可能な障害、データ損失、セキュリティ、権限、コアパスのリスクを解消するものでない限り、必須とされていない機能、オプション、ガード、修正を含めないでください。除外したものは報告書に明記してください。レビュアーの提案は必須ではありません。計画された作業の追加、スキップ、範囲縮小、置き換えを求める場合は、計画で冗長とされたテストも含め、逸脱にあたります。その対応を行う前に Plan Deviation Gate を実行してください。計画でアトミックとされているスライス（内部では未完了、最後に完了状態になる）は、検証ゲートまで到達するのに十分なセッション時間とコンテキストの余裕がある場合にのみ開始してください。そうでない場合は、直前の検証済みチェックポイントで停止し、そこで開始しない判断を記録してください。セッションに収まるようスライスを分割してはいけません。

4. 実証してください。 計画の検証と、リポジトリに関連する lint、型、ビルドの各チェックで実証してください。メトリクスが証拠となるのは、必要な結果と既知の不具合があるベースラインを区別できる場合のみです。まずベースラインを記録し、すでに合格している場合は停止して、Plan Validity Gate を通じて検証方法を修正してください。広範なテストスイートが合格しても、計画された受け入れチェックが未実施または未実行のスライスは完了しません。計画されたランタイム受け入れチェックでは、フォーカスを奪わず、入力を注入せず、テスト対象のアプリの範囲を超えてキャプチャしないことが同じ基準のテストに使えるとすでに検証されている方法（ヘッドレス実行など）があれば、そちらを優先してください。そうでなければ、その影響だけを理由に確認を求めたり延期したりせず、計画どおりに実行してください。既存の同意とスコープの境界は引き続き適用されます。

   • 各ゲートの終了ステータスを個別に保持してください。切り詰めるフィルターにゲートのステータスを担わせたり、後続ゲートの成功で失敗を隠したりしてはいけません。
   • 名前が挙げられた凍結済みベースラインの各クラスについて、今回検証済み、名前を明示した後続ゲートに延期、または担当者と残存リスクを伴う手動のみの未解決事項のいずれかとして整理してください。実測実行後に意図的な編集を加えた場合は、最終バイト列で該当する実測ゲートを再実行するか、正確な差分を記録してください。静的な再実行では実測による証明は延長されません。

5. レビュー：サマリーの作成、次のスライスへの着手、またはコミットの前に、検証済みのスライスを実装後レビューゲートでレビューします。

6. チェックポイントを完了する：スライスが作成したワークツリー、クローン、スクラッチコピー、プライベートビルドルートについて、必要とするものがなくなったら削除します（計画上、後続のスライスで使用する予定があるものは引き続き必要ですが、使用する可能性があるだけのものは該当しません）。作業に必要なものをそれらから保存したうえで、内容の照合が済んでいないものは保持します。既存のImplementation progress台帳を更新し、次にコミット選択のもとでユニットのコミットを選択します。計画の対象外である既存の動作の不具合により検証が妨げられる場合は、既存機能の修正引き継ぎに従って、該当するスライスをブロックとして停止します。

7. 報告：バインドされた計画、スライス、検証とその結果（スイートのステータスと受け入れ範囲をそれぞれ記載し、チェックをスキップした場合はその理由と残存リスクも記載）、レビュー方式と指摘事項の処置、逸脱またはブロッカー、作成したコミット、保持した使い捨てルートとそのサイズおよび理由、スライスが作成したものではないが孤立させた、または未使用と判断したビルド出力ルート（サイズと削除コマンドを添え、削除するかどうかはユーザーに判断してもらいます。依頼されていない削除は決して行わず、回答を待たずに作業を進めます）、および計画の残りの手順を報告します。コミット済みチェックポイントについては、各チェックポイントを通過させたコミット前の検証を示します。また、スライスが依拠する未検証の前提として受け入れたものがあれば、再確認のきっかけとともに次に引き継ぎます。

コミットの選択

コミットを選択できるのは、ユーザーからの明示的な依頼、紐づけられた計画項目、またはワークフロー自身が確認したチェックポイントのみです。

• コミットする前に、その根拠を明示してください。現在のユーザーからの依頼、承認済みの紐づけられた計画チェックポイント、またはこのワークフローが自らの確認済みの作業単位に適用するチェックポイントのデフォルトです。いずれもなければコミットせず、変更を作業ツリーに残したことを伝えてください。
• ルーティング、呼び出し、編集許可、都合のよい中断地点、追跡対象の変更、利用可能なコミットワークフローを根拠として扱ってはいけません。コミットの実行自体には、独自のチェックポイントのデフォルトはありません。
• チェックポイントのデフォルト：自己完結した作業単位の実装、検証、レビューが完了し、重要な確認事項への対処も済んだら、別途指示を待たず、その作業単位だけをローカルでコミットしてください。複数の作業単位を未コミットのまま積み上げてはいけません。
• 調査のみ、ブロック中、未変更、失敗、未検証、または作業途中の状態から、何も選択してはいけません。
• その作業単位だけをステージしてください。ワークフローが行っていない既存の変更や、作業単位外のパスは除外してください。その作業単位を他の変更から切り離せない場合は、混在した状態であることを報告し、確認を求めてください。
• 作業単位が作成し、必要とする新規ファイル（ソースやテストなど）は、認証情報や秘密情報を含まない限り、その作業単位に含めます。生成物、作業用ファイル、レポートを含めるのは、明示的に追跡する意図がある場合、または必須の依存関係がある場合に限ります。
• 選択した各コミットは、対象範囲、テストとレビューの証拠、除外対象、提案するコミットメッセージを添えてコミット実行ワークフローに渡してください。ステージング、差分のレビュー、メッセージの受け渡し、コミット後の検証は、そのワークフローが担当します。
• 以前のコミット固有の不具合を修正するために選択した修正は、そのコミットを含むリモート追跡参照、タグ、他のブランチ、またはワークツリーが存在しない場合、確認を求めずにそのコミットへまとめてください。それ以外の場合、またはまとめる処理に失敗した場合は、別途コミットし、その理由を伝えてください。
• そのまとめる処理を除き、プッシュ、amend、リベース、HEADを移動するリセット（soft、mixed、hard）、filter-* による書き換え、スクリプトによる複数コミットの再適用を行う前に、ユーザーから明示的な承認を得てください。コミットの依頼やチェックポイントは、その許可にはなりません。公開済みの履歴は共有されています。
• コミットの依頼やチェックポイントを、リリース、バージョン変更、タグ付け、stash、上記のまとめる処理を超えるsquash、破壊的なクリーンアップ、force-add、新しい成果物を作業単位外で追跡すること、外部への副作用への同意とみなしてはいけません。それぞれ個別の許可が必要です。

例：「ユーザーが今のターンでコミットを依頼した」は根拠になりますが、「ここは区切りとしてよい」は根拠になりません。

例外：現在のコミット禁止指示、コミットを禁じる紐づけられた計画、またはプロジェクトのポリシーがデフォルトを停止する場合は、確認済みの変更を作業ツリーに残し、その理由を報告してください。

計画に Commit checkpoints がある場合はそのチェックポイントに従って作業単位を区切り、ない場合は自然に個別検証できる範囲の境界で区切ってください。ビルド済みまたはデプロイ済みの成果物に対する実行時テストやユーザーテストがチェックポイントの前提条件である場合は、テストした成果物と、そのビルドに使用した入力をコミット時の引き継ぎに含めてください。これにより、一部だけステージされたチェックポイントと照合できます。

受容済みリスクの意味

Unproven の項目が、それに依存する作業を支えられるのは、Accepted risk の場合のみです。

• リスクを受け入れられるのは、影響について説明を受けたうえで人間のユーザーが明示的に選択した場合、または今回の依頼について紐づけられた計画に受容が記録されている場合のみです。代理人、委任先、AI が選んだデフォルト、低リスクという判断による受容は認められません。
• 前提、受容した人と理由、影響範囲、最も早く確認できる方法、再検討のきっかけを、その前提に依存する手順と紐づけて記録してください。その項目は確認済みの事実ではなく、常に Accepted risk のままです。
• 現在の作業を妨げるその他すべての Unproven 項目は、証明作業、質問、またはブロッカーにしてください。現在の作業で必要のない判断は先送りしてください。
• 取り消し不能、破壊的、危険、違法、または認証情報を露出させる操作に、これを使ってはいけません。そのような操作には、証明、安全な代替手段、またはユーザーによる明示的な人間のリスク判断が必要です。

会話でのみ受け入れられたリスクは、それが支える作業範囲を実装する前に、紐づけられた計画に記録してください。

参照資料

• references/execution-workflow-and-quality.md（証明ルール、実装後レビューゲート、進捗台帳）：スライスの証明、レビュー、完了時に読みます。
• references/execution-gates-and-delegation.md（計画逸脱ゲート、計画妥当性ゲート、既存機能の修正引き継ぎ、起動時の同意事前確認、委任）：計画から逸脱または修正する場合、既存動作の不具合に対処する場合、同意の境界を越える場合、または作業を委任する場合に、事前に読みます。