plan

計画

設計意図を、実行可能なフェーズ計画に落とし込みます。

入力：

• slice-nnn.md（スコープ）
• design.md（正本となる設計リファレンス）
• 既存の plan.toml ／ plan.md（存在する場合）

プロセス

1. スライスのスコープと design.md をあわせて読みます。

2. 計画が設計を先走っていないことを確認します。

   • design.md が存在しない、または空の場合は、停止して /design を実行します。ただし、明示的に別の指示を受けている場合は除きます。
   • design.md が存在していても、現在の依頼やスライスのスコープに対して古くなっている場合は、まず設計を調整します。曖昧な場合はユーザーに確認します。
   • 未解決の設計上の問題の代わりに、計画やフェーズの作成を行ってはなりません。
   • 計画の作成によって重大な設計上の問題が明らかになった場合は、続行する前に /design を実行して設計を改訂または追記します。
   • 設計を信頼する前に、必ず再度 grep を実行してください。 設計が確定したのは執筆時点であり、その後ツリーは変化しています。design.md から、ファイルパス、関数／型名、定数、設定キーなど、grep で検索できる具体的な参照を探し、それぞれを現在のツリー（grep、ls、git show）で確認します。パスが見つからない、ファイルが移動している、またはシンボル名が変更されている場合、設計は古い前提に基づいています。誤ったパスを前提にフェーズシートを作成する前に停止し、/design を実行して調整してください。（具体的な項目が何も記載されていない設計には確認対象がありません。確認に必要なのは、設計が主張している内容だけです。）
   • リサーチの助言を確認し（doctrine slice research <id>）、記憶に頼るのではなく、Thread 2 のホットスポットマップに基づいてスライスのセレクターを作成してください。設計時のセレクターのドライランは、確認工程にすぎません。

3. 計画のひな形を作成します。doctrine slice plan <ID> は plan.toml と plan.md を作成します（既存ファイルがある場合は上書きしません）。ツールはこれらを読み取りますが、書き換えることはありません。自由に手動編集してください。

   設計レビューから引き継がれる指摘事項（暫定）。 フェーズを作成する前に、スライスの設計レビュー RV を開き、route が demonstrate、probe、または control であるすべての指摘を読みます。review show のインデックス表示には route 列があります。各ルート指定済み指摘の回答は -f を付けて読みます。詳細は lib:reference/review-ledger.md の「Route axis」を参照してください。それぞれは、意図的に文章で修正されていない義務事項です。回答には基準案と配置制約が記載されています。案を、基準文中に RV-NNN F-n を含めたうえで、制約を満たす最も早いフェーズの開始条件または終了条件に転記します。転記されていないルート指定のブロッカーは正直に検証できず、未検証のブロッカーがあるとスライスのクローズは拒否されます。転記を検証する仕組みはありません。

4. plan.toml を作成します。順序付けられたフェーズごとに [[phase]] を 1 つ記述します。

   • id は PHASE-NN（ゼロ埋め）です。変更不可で、再利用してはなりません。編集時は追加のみ行い、番号を振り直してはなりません。

   • フェーズの name と objective を記述します。

   • entrance_criteria（EN-n）、exit_criteria（EX-n）、および verification を記述します。検証 ID には検証方法を含めます。テストで検証するものは VT-n、エージェントで検証するものは VA-n、人間が検証するものは VH-n とします。テストでは基準を判断できない場合は VA／VH を使用してください。これにより、後続工程で見落とされずに確認されます。

   • VT の構造化要件（必須）。 すべての VT-n 行には、最低限 test_file と keywords を含めて、VT ゲートが判定に必要な情報を得られるようにしてください。これらがない場合、verify-vt は UNCHECKABLE を返し、プロジェクト全体でゲートが機能しません。この要件は説明文ではなく、TOML の行に記述してください。

     { id = "VT-1",
       expects = "往復ユニットテスト：新しい関数が解析、描画、再解析を行う",
       test_file = "src/your_test.rs",
       keywords = ["your_fn", "your_struct"],
       patterns = ["^\\s*pub fn"],   # 任意：より厳密な行頭固定パターン
       waived = false }
     

     • test_file — キーワードが実際に出現する唯一のファイルです （本番ソース、またはそのフェーズで扱うテストファイル）。この指示では test_file は1つだけ指定し、すべてのキーワードをそのファイルに含める必要があります。 フェーズで変更するファイルか、それを検証するテストファイルのどちらかを選び、 両方は選ばないでください。フェーズの完了後に存在するパスを指定してください。 将来作成するファイルは指定できません。
     • keywords — フェーズの完了後にそのファイルに必ず含まれる、生の部分文字列です。 これは妥当な最低条件です。生ソースに対する単純な部分文字列一致で判定します （コメントや文字列の除去は行いません）。
     • patterns（任意）— より強い言語非依存の形状アサーションを行う、行頭基準の正規表現です。 正規表現は作成者が責任を持って用意します。
     • waived — waived_reason の指定が必須の例外措置です。

     doctrine slice verify-vt <id> は、監査時ではなく、ディスパッチの完了／引き継ぎ時に すべての VT 指示を判定します。キーワードがない test_file は自動的に合格します。 門番としての効力を持たせるのはファイル単体ではなく、キーワードの最低条件です。

   • v1 では specs／requirements は空のままにします（まだレジストリはありません）。スライスに 関連付けがある場合は、ここに型付きキーを書くのではなく、doctrine link で記述します。 lib:reference/using-doctrine.md § エンティティの関連付けを参照してください。

5. plan.md を作成します。根拠と順序を説明する文章です。なぜこのフェーズなのか、 なぜこの順序なのか、なぜこの境界なのかを記述します。保存ルール （lib:reference/using-doctrine.md § ストレージ階層）を守り、クエリ済みデータや 派生データを plan.md に含めないでください。

6. コミットします。

7. 計画を批判的に検討します。仕様不足、前提、曖昧さ、過大な規模、楽観的な見積もり、 検証が必要な点、実装リスクはないでしょうか。それぞれについて、必要な新情報や 導入すべき緩和策を決めます。実装について判明している詳細を踏まえて計画を立ててください。

8. 改訂計画を立て、その概要をユーザーに提示します。その後、改訂に取り組みます。

9. 計画を改訂し、再度コミットします。変更点を要約します。

10. フェーズ追跡を実体化します。doctrine slice phases <ID> は plan.toml から、 状態ツリー内にフェーズごとのシートを作成します。--prune は、計画からなくなったフェーズの 孤立した追跡情報を削除します（破壊的操作です。フェーズを削除する意図がある場合に限ります）。

11. /phase-plan に引き継ぎ、実行の直前に次のフェーズのランタイムフェーズシートを 詳細化します。その後、/execute に進みます。スライスのスコープ、design.md、計画の 内容が一致してから実施してください。引き継ぎ時にライフサイクルの変更を記録します。 doctrine slice status <id> ready（数値のみ）。

成果物

• plan.toml は実行可能な状態で、各フェーズに目的、EN／EX 基準、および 明示的なモード（VT／VA／VH）での検証が含まれています。
• plan.md には根拠と順序が説明されています。
• 各フェーズに、明確な完了基準を備えたランタイムフェーズシートがあります。
• 計画の複雑さやポリシーの曖昧さが明らかになった場合は、作業を停止して /consult に進みます。