[Feature] strategy_formulation_spec.md の「フェーズ分割の原則」に、構造移設・新規モジュール作成タスク群の早期検証規定を追加

[BlueEventHorizon]

背景 / コンテキスト

forge-review feature の27タスク計画を評価中、GROUP-003（TASK-014〜018、beefy plugin への物理分離5タスク）が「4タスク連続で build_check: skip、最後の1タスクのみ on_group_complete」という構成だと判明した。これは「最小の動作確認可能な単位（TASK-015: beefy:review SKILL 新設）が完成した時点でも、それが実際に動作するかを確認せずに次の移設（TASK-016〜017）を積み重ねてしまう」リスクを含む。strategy_formulation_spec.md Step 4「フェーズ分割の原則」には、この種の早期検証を強制する規定がない。

ユーザーストーリー

forge を使って実装計画を立てる開発者として、複数タスクにまたがる構造移設・新規モジュール作成を計画する際に、最小の動作確認可能な単位が完成した時点で早期検証を行うよう仕様書自体が導いてほしい。なぜなら、検証を最終タスクまで先送りすると、土台となるタスクの誤りが後続タスクに積み重なり、発覚時の手戻りコストが増大するため。

受け入れ基準

• strategy_formulation_spec.md Step 4「フェーズ分割の原則」に、「フェーズ内が複数タスクの構造移設・新規モジュール作成で構成される場合、最後のタスクまで検証を先送りしない」旨の原則が追加されていること
• 追加された原則が、最小の動作確認可能な単位（多くはグループ内の最初の1〜2タスク）の完成時点で検証ポイントを設けることを具体的に指示していること
• task_execution_spec.md の build_check フィールド説明に、グループ内全タスクを skip にして最終タスクのみ on_group_complete にする構成の妥当性条件（最小動作単位の早期検証が別途確保されている場合に限る）が明記されていること

代替案 / 補足

forge-review 計画自体の GROUP-003 を今回の教訓に基づいて組み直すことも代替・追加対応として検討可能だが、本 Issue は forge 本体のルール改訂（一般化）をスコープとする。

[BlueEventHorizon]

トリアージ結果: SDD（エントリポイント: /forge:start-plan）

/anvil:triage-issue による判定の申し送り（監査記録）。

判定

• 要件の確定性: 確定 — 受け入れ基準 3 点が具体的で、追加すべき原則の内容（早期検証ポイントの設置・全 skip 構成の妥当性条件）が対話なしに一意に読み取れる。
• 設計判断の残余: なし — 既存仕様書への規範追記であり、類似 PR（fix(forge): enforce YAML contract for {feature}_plan.yaml #112, [Fix] next-spec-id のブランチスキャンから is-ancestor フィルタを撤廃 (#196) #199）で確立された「規範 + 重大度カタログ」の追記パターンを踏襲できる。アーキテクチャ変更・新概念の導入はない。
• リスクゲート: 該当（条件 3） — 実測で編集を要するファイルが 3 以上: strategy_formulation_spec.md（Step 4 原則追加）、plan_principles_spec.md（build_check 妥当性条件 + 重大度カタログ）、plan_format.md（build_check フィールド説明の補記の可能性）、plugins/forge/toc/rules/rules_toc.yaml（ToC 再生成）。条件 1（後戻り困難な実害）: No — git で可逆な文書変更。条件 2（サイレント破壊）: No — 追記型の規範変更で PR レビューで可視。

推奨ワークフロー

• feature 要否: 不要（既存文書直接編集） — 変更対象は forge 内蔵文書（配布物＝実装側）のみ。プロジェクト側の要件定義書・設計書（DES-019 / DES-027 はフェーズ分割を抽象参照するのみ）に変更は不要のため、additive_development_spec.md §1 の適用条件（既存の要件定義書・設計書に変更が必要）を満たさない。

重要な指摘（受け入れ基準の齟齬）

受け入れ基準 3 点目は「task_execution_spec.md の build_check フィールド説明」を対象とするが、task_execution_spec.md に build_check フィールドの説明は存在しない。実体は plan_principles_spec.md「タスクグループ」節と plan_format.md（enum 定義）にある。また task_execution_spec.md は「executor は検証要件の判定ロジックを持たない（オーケストレータが判定して指示する）」という設計境界を持つため、同文書への build_check 意味論の追記は境界違反になる。妥当性条件の追記先は plan_principles_spec.md（＋必要なら plan_format.md）とすべき。計画策定時にこの読み替えを前提とすること。

調査結果（4 カテゴリ）

• 関連仕様書:
  • plugins/forge/docs/strategy_formulation_spec.md (kind: local_path) — 改訂対象（Step 4 フェーズ分割の原則）
  • plugins/forge/docs/plan_principles_spec.md (kind: local_path) — 改訂対象（タスクグループ節・重大度カタログ）
  • plugins/forge/docs/plan_format.md (kind: local_path) — build_check enum 定義（補記候補）
  • plugins/forge/docs/task_execution_spec.md (kind: local_path) — Issue 記載の対象だが build_check 説明は不在（上記齟齬参照）
  • docs/specs/forge/design/DES-027_plan_strategy_phase_adr.md (kind: local_path) — 戦略フェーズ導入の設計判断（変更不要、整合確認用）
  • docs/specs/forge/design/DES-019_create_plan_workflow_design.md (kind: local_path) — 計画ワークフロー設計（変更不要、整合確認用）
• ルール文書:
  • docs/rules/document_writing_rules.md (kind: local_path) — タグ・見出し・現在状態記述の規約
  • docs/rules/forge_doc_access_principle.md (kind: local_path) — forge 内蔵 docs は直接参照
  • docs/rules/implementation_guidelines.md (kind: local_path) — SKILL.md/文書はテスト例外、version ファイル編集禁止
• 類似 PR: fix(forge): enforce YAML contract for {feature}_plan.yaml #112（plan.yaml 契約を docs/SKILL 横断で強制 — 仕様書規範追記の同型）/ [Fix] next-spec-id のブランチスキャンから is-ancestor フィルタを撤廃 (#196) #199（plan_principles_spec.md・task_execution_spec.md 改訂を含む fix）/ [Feature] no-fork-skill ADR (REQ-006 / DES-032) — fork 型 SKILL 廃止と Agent 化の要件・設計 (Issue #127, F-1) #135（forge 内蔵仕様の要件・設計改訂）
• 既存コード: 該当なし（文書のみの改訂。付随作業として forge ToC 再生成は ローカル skill update-forge-toc を使用）

次のアクション

/forge:start-plan で本 Issue を入力に実装計画を策定することを推奨（起動はユーザー判断）。