create-ai-project 1.20.9 → 1.22.0

package/.claude/agents-ja/acceptance-test-generator.md

@@ -71,7 +71,7 @@ Phase 1から有効な各ACについて:
 
 2. **テストレベルを分類**:
    - 統合テスト候補（機能レベルの相互作用）
-   - E2Eテスト候補（ユーザージャーニー）
+   - E2Eテスト候補 — レーンはPhase 3で割り当てる（モックで検証可能なUIジャーニーは `fixture-e2e`、実サービス間の挙動を必ずアサートする必要がある場合は `service-integration-e2e`）
    - Property-basedテスト候補（Property注釈付きAC → 統合テストファイルに配置）
 
 3. **メタデータを付与**:
@@ -97,12 +97,18 @@ Phase 1から有効な各ACについて:
 3. **Push-Down解析**:
    ```
    ユニットテスト可能？ → 統合/E2Eプールから削除
-   既に統合テスト作成済み？ → マルチステップユーザージャーニーの一部ならE2E候補として残す（integration-e2e-testingスキルの定義参照）
-   既に統合テスト作成済みかつマルチステップジャーニーでない？ → E2Eプールから削除
+   既に統合テスト作成済みかつin-processで検証可能？ → E2Eプールから削除
    ```
-4. **ROIで並び替え**（降順）
+4. **レーン割り当て**（E2E候補のみ）:
+   - モックバックエンド/フィクスチャ駆動の状態で検証可能なUIジャーニーは、デフォルトで `fixture-e2e` を割り当てる
+   - 検証が実サービス間の挙動に依存する場合のみ `service-integration-e2e` に昇格させる。以下のいずれかを必ずアサートする必要がある場合に該当:
+     - 実DB書き込みでデータが永続化する（例: 検証対象の実データベースに行が挿入/更新される）
+     - 下流サービスが実イベント/メッセージを受信する（例: トピックpublish、キューenqueue、webhookコール）
+     - 外部サービスが期待ペイロードを伴う実APIコールを受信する
+     - サービス間のトランザクション整合性（例: 2フェーズコミット、saga補償）
+5. **レーン内でROI降順に並び替え** — これが唯一のランキングステップ。Phase 4の予算強制はこのランク済みリストを再ソートせずにそのまま消費する。
 
-**出力**: ランク付け・重複排除済み候補リスト
+**出力**: ランク付け・重複排除済み候補リスト（E2E候補にはレーンが割り当てられている）。
 
 ### Phase 4: 過剰生成制限
 
@@ -110,28 +116,38 @@ Phase 1から有効な各ACについて:
 
 **機能あたりの上限**:
 - **統合テスト**: 最大3件
-- **E2Eテスト**: 最大1-2件、内訳:
-  - 1件の予約スロット（ROIに関わらず必ず出力）: 機能に**ユーザー向け**マルチステップユーザージャーニーが含まれる場合（integration-e2e-testingスキルの定義と分類を参照）
+- **fixture-e2e**: 最大3件。予約スロット（機能に**ユーザー向け**マルチステップユーザージャーニー — integration-e2e-testingスキルの定義参照 — が含まれる場合の最高ROIジャーニー候補）はROIに関わらず出力する。予約スロット以外の追加スロットは ROI ≥ 20 を要求（フロアを下回る場合は意図的に未消化のまま残す）
+- **service-integration-e2e**: 最大1-2件、内訳:
+  - 1件の予約スロット（ROIに関わらず必ず出力）: 予約されたジャーニーの正しさが、fixture-e2eでは検証できない実サービス間の挙動に依存する場合
   - 追加最大1件: ROI > 50が必要
 
 **選択アルゴリズム**:
 
 ```
-1. E2E予約スロットの確保:
+1. fixture-e2e予約スロットの確保:
    機能にユーザー向けマルチステップユーザージャーニーが含まれる場合
-   → 最高ROIのジャーニー候補に1件のE2Eスロットを予約
-   （この予約候補はROI閾値に関わらず出力される）
-
-2. 残りの候補をROIで並び替え（降順）
-
-3. Property-basedテストは上限計算から除外し全て選択
-
-4. 上限設定内でトップNを選択:
+   → 最高ROIのジャーニー候補に1件のfixture-e2eスロットを予約
+
+2. service-integration-e2e予約スロットの確保（必要な場合のみ）:
+   予約されたジャーニーの検証が以下のいずれかを必要とする場合:
+     - 実DB書き込みでデータが永続化する
+     - 下流サービスが実イベント/メッセージを受信する
+     - 外部サービスが期待ペイロードを伴う実APIコールを受信する
+     - サービス間のトランザクション整合性
+   → そのジャーニーに1件のservice-integration-e2eスロットを予約
+
+3. 候補リスト（Phase 3のステップ5でレーン内ROI降順に並び替え済み）を走査し、
+   予算内で選択:
    - 統合: 最高ROIのトップ3を選択
-   - E2E（予約分を除く追加分）: ROIスコア > 50の場合のみ最大1件追加
+   - fixture-e2e（予約分を除く追加分）: ROI ≥ 20 を満たす範囲で残予算まで選択
+   - service-integration-e2e（予約分を除く追加分）: ROI > 50 の場合のみ最大1件追加
+
+4. Property-basedテストは上限計算から除外し全て選択（このステップは順序非依存
+   — 1〜3の予約スロット選択やROIベース選択に影響を与えず、本アルゴリズム内
+   どの時点で実行しても結果は変わらない）
 ```
 
-**出力**: 最終テストセット
+**出力**: 最終テストセット（各E2E候補にレーンが割り当てられている）。
 
 ## 出力フォーマット
 
@@ -147,7 +163,7 @@ Phase 1から有効な各ACについて:
 
 ```typescript
 // [機能名] Integration Test - Design Doc: [ファイル名]
-// 生成日時: [日付] | 枠使用: 2/3統合, 0/2 E2E
+// 生成日時: [日付] | 枠使用: 2/3 integration, 0/3 fixture-e2e, 0/2 service-integration-e2e
 
 import { describe, it } from '[検出されたテストフレームワーク]'
 
@@ -170,24 +186,49 @@ describe('[機能名] Integration Test', () => {
 })
 ```
 
-### E2Eテストファイル
+### E2Eテストファイル群
+
+レーンごとに**別ファイル**で生成する: fixture-e2eは `*.fixture-e2e.test.[ext]`、service-integration-e2eは `*.service-e2e.test.[ext]`。各出力ファイルには下流エージェント（work-planner、task-decomposer、executor）が正しくルーティングできるよう `@lane:` ヘッダを必ず付与する。
+
+**fixture-e2e の例**（モックバックエンドによるUIジャーニー、インフラなしでCI実行可能）:
 
 ```typescript
-// [機能名] E2E Test - Design Doc: [ファイル名]
-// 生成日時: [日付] | 枠使用: 1/2 E2E
-// テスト種別: End-to-End Test
-// 実装タイミング: 全機能実装完了後
+// [機能名] fixture-e2e - Design Doc: [ファイル名]
+// 生成日時: [日付] | 枠使用: 1/3 fixture-e2e
+// @lane: fixture-e2e
 
 import { describe, it } from '[検出されたテストフレームワーク]'
 
-describe('[機能名] E2E Test', () => {
-  // ユーザージャーニー: 完全な購入フロー（閲覧 → カート追加 → チェックアウト → 決済 → 確認）
-  // ROI: 119 (BV:10 × Freq:10 + Legal:10 + Defect:9) | 予約スロット: マルチステップジャーニー
-  // 検証: 商品選択から注文確認までのエンドツーエンドユーザー体験
+describe('[機能名] fixture-e2e', () => {
+  // ユーザージャーニー: モック決済バックエンドでのカート → チェックアウト → 確認
+  // ROI: 64 | 予約スロット: マルチステップジャーニー
+  // 検証: 各ステップ後の UI 遷移と観測可能な状態（モックは固定レスポンスを返す）
   // @category: e2e
+  // @lane: fixture-e2e
+  // @dependency: full-ui (mocked backend)
+  // @complexity: medium
+  it.todo('ユーザージャーニー: モック決済でのカートから確認までのフロー')
+})
+```
+
+**service-integration-e2e の例**（起動済みローカルスタックに対する検証、最終フェーズのみ）:
+
+```typescript
+// [機能名] service-integration-e2e - Design Doc: [ファイル名]
+// 生成日時: [日付] | 枠使用: 1/2 service-integration-e2e
+// @lane: service-integration-e2e
+
+import { describe, it } from '[検出されたテストフレームワーク]'
+
+describe('[機能名] service-integration-e2e', () => {
+  // ユーザージャーニー: 実DB永続化と下流イベント発行をアサートする購入完了
+  // ROI: 119 | 予約スロット: 実サービス間挙動が必要
+  // 検証: 注文行がDBに挿入される、OrderCreatedイベントが発行される、領収書メールがキューに積まれる
+  // @category: e2e
+  // @lane: service-integration-e2e
   // @dependency: full-system
   // @complexity: high
-  it.todo('ユーザージャーニー: 閲覧から確認メールまでの商品購入完了')
+  it.todo('ユーザージャーニー: 購入完了で注文が永続化され下流イベントが発行される')
 })
 ```
 
@@ -208,49 +249,71 @@ it.todo('[AC番号]-property: [不変条件を自然言語で記述]')
 
 生成完了時は以下のJSON形式で報告。詳細なメタ情報はテストスケルトンファイル内のコメントに含まれており、後工程でファイルを読んで抽出する。
 
-**E2Eテストが出力される場合:**
+**全レーンが出力される場合:**
 ```json
 {
   "status": "completed",
   "feature": "payment",
   "generatedFiles": {
     "integration": "tests/payment.int.test.[ext]",
-    "e2e": "tests/payment.e2e.test.[ext]"
+    "fixtureE2e": "tests/payment.fixture-e2e.test.[ext]",
+    "serviceE2e": "tests/payment.service-e2e.test.[ext]"
+  },
+  "budgetUsage": {
+    "integration": "2/3",
+    "fixtureE2e": "1/3",
+    "serviceE2e": "1/2"
   },
-  "budgetUsage": { "integration": "2/3", "e2e": "1/2" },
-  "e2eAbsenceReason": null
+  "e2eAbsenceReason": { "fixtureE2e": null, "serviceE2e": null }
 }
 ```
 
-**E2Eテストが出力されない場合:**
+**fixture-e2eのみ出力される場合（実サービス間依存なし）:**
 ```json
 {
   "status": "completed",
-  "feature": "payment",
+  "feature": "checkout-ui",
   "generatedFiles": {
-    "integration": "tests/payment.int.test.[ext]",
-    "e2e": null
+    "integration": "tests/checkout.int.test.[ext]",
+    "fixtureE2e": "tests/checkout.fixture-e2e.test.[ext]",
+    "serviceE2e": null
+  },
+  "budgetUsage": {
+    "integration": "1/3",
+    "fixtureE2e": "1/3",
+    "serviceE2e": "0/2"
   },
-  "budgetUsage": { "integration": "2/3", "e2e": "0/2" },
-  "e2eAbsenceReason": "no_multi_step_journey"
+  "e2eAbsenceReason": { "fixtureE2e": null, "serviceE2e": "no_real_service_dependency" }
 }
 ```
 
-**統合テストも出力されない場合:**
+**どのE2Eレーンも該当しない場合:**
 ```json
 {
   "status": "completed",
   "feature": "config-update",
   "generatedFiles": {
-    "integration": null,
-    "e2e": null
+    "integration": "tests/config.int.test.[ext]",
+    "fixtureE2e": null,
+    "serviceE2e": null
+  },
+  "budgetUsage": {
+    "integration": "1/3",
+    "fixtureE2e": "0/3",
+    "serviceE2e": "0/2"
   },
-  "budgetUsage": { "integration": "0/3", "e2e": "0/2" },
-  "e2eAbsenceReason": "no_multi_step_journey"
+  "e2eAbsenceReason": { "fixtureE2e": "no_multi_step_journey", "serviceE2e": "no_multi_step_journey" }
 }
 ```
 
-**契約**: `generatedFiles.integration`と`generatedFiles.e2e`は常にキーとして存在する。値は生成された場合はファイルパス文字列、未生成の場合は`null`。`e2eAbsenceReason`はE2Eが出力された場合は`null`、そうでなければ`no_multi_step_journey`または`below_threshold_user_confirmed`のいずれか。
+**契約**: `generatedFiles.{integration,fixtureE2e,serviceE2e}` は常にキーとして存在する。値は出力された場合はファイルパス文字列、未出力の場合は`null`。`e2eAbsenceReason` は `fixtureE2e` と `serviceE2e` のキーを持つオブジェクトであり、レーンごとの許容値は以下のとおり:
+
+| レーン | 許容値 |
+|------|-------|
+| `e2eAbsenceReason.fixtureE2e` | `null`（レーン出力済み）\| `no_multi_step_journey` \| `below_threshold_user_confirmed` |
+| `e2eAbsenceReason.serviceE2e` | `null`（レーン出力済み）\| `no_multi_step_journey` \| `below_threshold_user_confirmed` \| `no_real_service_dependency` |
+
+`no_real_service_dependency` は service-integration-e2e 専用 — ジャーニーが fixture-e2e で完全に検証可能で、service-integration-e2e が不要であることを示す。fixture-e2e レーンはこの reason 値を出力しない。
 
 ## 制約と品質基準
 
@@ -262,7 +325,7 @@ it.todo('[AC番号]-property: [不変条件を自然言語で記述]')
 - テスト上限設定内に収める；重要テストに上限超過の場合は報告
 
 **品質基準**:
-- ROIランキングに基づき上限内でテストを選択（統合: ROIトップ3、E2E: ユーザー向けジャーニーの予約スロット + ROI > 50の追加分）
+- ROIランキングに基づき上限内でテストを選択（統合: ROIトップ3、fixture-e2e: ジャーニーの予約スロット + ROI ≥ 20を満たす範囲で残予算まで、service-integration-e2e: 実サービス間挙動が必要な場合の予約スロット + ROI > 50の追加最大1件）
 - 振る舞い優先フィルタリングを厳格に適用
 - 重複を排除（Grepで既存テストをチェック）
 - 依存関係を明示
@@ -273,12 +336,13 @@ it.todo('[AC番号]-property: [不変条件を自然言語で記述]')
 ### 自動処理可能
 - **ディレクトリが存在しない**: 検出されたテスト構造に従い適切なディレクトリを自動作成
 - **高ROI統合テストなし**: 有効な結果 - "全ACがROI閾値未満または既存テストでカバー済み"と報告
-- **E2Eテストなし（マルチステップジャーニーなし）**: 有効な結果 - "マルチステップユーザージャーニー未検出、E2Eテスト対象外"と報告
+- **両E2Eレーンで出力なし（マルチステップジャーニーなし）**: 有効な結果 - "マルチステップユーザージャーニー未検出、fixture-e2eおよびservice-integration-e2eは対象外"と報告
+- **fixture-e2eは出力されたがservice-integration-e2eは出力されない（実サービス間依存なし）**: 有効な結果 - "ジャーニーがモックバックエンドに対するE2E検証で十分。service-integration-e2eの不在理由は `no_real_service_dependency`"と報告
 - **重要テストが上限超過**: ユーザーに報告
 
 ### エスカレーション必須
 1. **重大**: ACが存在しない、Design Docが存在しない → エラー終了
-2. **高**: 上限適用後にE2Eテストが出力されなかったが、機能にユーザー向けマルチステップジャーニーが含まれる → "機能にユーザー向けマルチステップジャーニーが含まれるがE2Eテストが出力されませんでした。評価したジャーニー候補: [ROIスコア付きリスト]。E2Eなしで進めてよいか確認してください。"とエスカレーション（注: このエスカレーションはPhase 4の予約スロットが適用されなかった場合のみ発火する。予約スロット候補が存在する場合はそれが出力され、このエスカレーションは発火しない）
+2. **高**: 上限適用後にいずれのE2Eレーンでもテストが出力されなかったが、機能にユーザー向けマルチステップジャーニーが含まれる → レーン別に "機能にユーザー向けマルチステップジャーニーが含まれるがfixture-e2eもservice-integration-e2eも出力されませんでした。レーン別に評価したジャーニー候補: [レーンごとのROIスコア付きリスト]。E2Eカバレッジなしで進めてよいか確認してください。"とエスカレーション（注: このエスカレーションはPhase 4のいずれの予約スロットも適用されなかった場合のみ発火する。いずれかのレーンで予約スロット候補が存在する場合はそれが出力され、当該レーンに対しては発火しない）
 3. **高**: 全ACフィルタ済みだが機能がビジネスクリティカル → ユーザー確認必要
 4. **中**: クリティカルユーザージャーニー（ROI > 90）に上限不足 → オプション提示
 5. **低**: 複数解釈可能だが影響軽微 → 解釈を採用 + レポートに注記
@@ -308,5 +372,5 @@ it.todo('[AC番号]-property: [不変条件を自然言語で記述]')
 - **実行後**:
   - 選択されたテストの完全性
   - 依存関係の妥当性検証
-  - 統合テストとE2Eテストが別ファイルに生成
+  - 統合テスト・fixture-e2e・service-integration-e2eが別ファイルに生成（各E2Eファイルに `@lane:` ヘッダ付き）
   - 生成レポートの完全性

package/.claude/agents-ja/task-decomposer.md

@@ -72,18 +72,26 @@ implementation-approachスキルで決定された実装戦略パターンに基
      - タスク間の情報共有ポイントの特定
 
 3. **全体設計書の作成**
-   - `docs/plans/tasks/_overview-{計画書名}.md` に全体設計を記録
+   - `docs/plans/tasks/_overview-{plan-name}.md` に全体設計を記録
    - 各タスクの位置づけと関連性を明確化
    - 設計意図と注意事項を文書化
 
 4. **タスクファイルの生成**
-   - 命名規則: `{計画書名}-task-{番号}.md`
-   - レイヤー別命名（計画が複数レイヤーにまたがる場合）: `{計画書名}-backend-task-{番号}.md`, `{計画書名}-frontend-task-{番号}.md`
-   - レイヤーはタスクの対象ファイルパスから判定（technical-specスキルのプロジェクト構造定義を参照）
-   - 例: `20250122-refactor-types-task-01.md`, `20250122-auth-backend-task-01.md`, `20250122-auth-frontend-task-02.md`
+
+   命名は subagents-orchestration-guide「Layer-Aware Agent Routing」のレイヤールーティング規約に従う。素の `{plan-name}-task-*.md` 形式は `task-executor`（backend）に排他的にルーティングされ、frontendタスクには使用してはならない。
+
+   | 計画分類 | タスクファイル名 | ルーティング先 |
+   |---------|---------------|--------------|
+   | 単層 **backend** | `{plan-name}-task-{number}.md`（推奨）または `{plan-name}-backend-task-{number}.md` | `task-executor` + `quality-fixer` |
+   | 単層 **frontend** | `{plan-name}-frontend-task-{number}.md`（必須 — 素の `*-task-*` 形式はbackend予約） | `task-executor-frontend` + `quality-fixer-frontend` |
+   | 複層（backend + frontendをまたぐ） | `{plan-name}-backend-task-{number}.md` と `{plan-name}-frontend-task-{number}.md`（タスクスライスごとにレイヤー別に1ファイルずつ） | ファイル名のレイヤーセグメントごと |
+
+   レイヤーはタスクの対象ファイルパスから判定する（technical-specスキルのプロジェクト構造定義を参照）。
+
+   例: `20250122-refactor-types-task-01.md`（backend単層）、`20250122-dashboard-frontend-task-01.md`（frontend単層）、`20250122-auth-backend-task-01.md` + `20250122-auth-frontend-task-02.md`（複層）。
    - **フェーズ完了タスクの自動生成（必須）**:
      - 作業計画書の「Phase X」表記を基準に、各フェーズ最終タスクの後に生成
-     - ファイル名: `{計画書名}-phase{番号}-completion.md`
+     - ファイル名: `{plan-name}-phase{number}-completion.md`
      - 内容: 全タスク完了チェックリスト、テストスケルトンファイルパスを検証用に記載
      - 判断基準: 計画書に「Phase」という文字列があれば必ず生成
      - **Phase 0（環境セットアップ）**: 作業計画にPhase 0の`@category: e2e-setup`タスクが含まれる場合、これらは環境セットアップタスク（seed data、auth fixture、serviceモック）であり、通常の実装タスクとは異なる。実装指向ではなくセットアップ指向の調査対象（既存の設定ファイル、環境スクリプト、fixtureパターン）で分解する
@@ -105,8 +113,11 @@ implementation-approachスキルで決定された実装戦略パターンに基
    |---|---|
    | 既存コードの修正 | 修正対象の既存実装ファイル、そのテスト、関連するDesign Docセクション |
    | 新規コンポーネント/機能 | 同一レイヤー/ドメインの隣接実装、Design Docのインターフェース契約 |
+   | フロントエンドコンポーネント実装 | UI Specのコンポーネントセクション（作業計画書の「UI Specコンポーネント → タスクマッピング」が引用するセクション見出しを使用）、Design Docのインターフェース契約、同一レイヤーの隣接コンポーネント |
+   | フロントエンド統合 / fixture-e2eテスト | UI Specのコンポーネントセクション（状態×表示マトリクスとインタラクション定義の表を含む）、実装済みのコンポーネントコード、フィクスチャデータファイル |
    | テスト実装 | テストスケルトンのコメント/アノテーション、テスト対象コード、実際のAPI/認証フロー |
    | E2E環境セットアップ | 現在の環境設定（起動スクリプト、docker-compose等）、seed scripts、既存のfixtureパターン、アプリケーション認証フロー |
+   | パッケージ間境界の実装 | 作業計画書のConnection Mapに記載された境界の両側（オーナーモジュールと期待されるシグナル）、両者間のコントラクト定義 |
    | バグ修正 / リファクタリング | 影響を受けるコードパス、関連テストカバレッジ、エラー再現コンテキスト |
    | 振る舞いの置換・リライト | 置換対象の既存実装、その観察可能な出力、Design Docの検証戦略セクション |
 
@@ -116,6 +127,8 @@ implementation-approachスキルで決定された実装戦略パターンに基
    - ファイルパスは具体的に: `src/orders/checkout`, `docs/design/payment.md` — 「注文モジュール」「関連コード」ではなく
    - ファイル内の特定セクションが対象の場合はサーチヒントを付与: `docs/design/payment.md (§ Payment Flow)` or `src/orders/checkout (processOrder関数)`
    - タスクにテストスケルトンが存在する場合は必ず Investigation Targets に含める
+   - 作業計画書に「UI Specコンポーネント → タスクマッピング」表が含まれる場合、該当行のコンポーネントセクションをそのタスクに伝播する（後述の「UI Spec伝播」参照）
+   - 作業計画書にConnection Mapが含まれる場合、このタスクの対象ファイルに関連する境界行を伝播する（後述の「Connection Map伝播」参照）
 
 7. **実装方針の一貫性**
    実装サンプルを含める場合は、作業計画書の元となったDesign Docの実装方針に完全準拠すること
@@ -136,6 +149,29 @@ implementation-approachスキルで決定された実装戦略パターンに基
    - **検証レベル**: implementation-approachスキルに従いL1/L2/L3を選択
 3. **調査対象**: 検証に必要なリソースを含める（例: 比較対象の既存実装、スキーマ定義、seed dataのパス）
 
+## UI Spec伝播
+
+作業計画書に「UI Specコンポーネント → タスクマッピング」表が含まれる場合、各実装タスクにコンポーネント参照を以下のように伝播する:
+
+1. **タスクIDで照合**: マッピング表の各行について、「カバーするタスク」列に記載されたタスクを特定する
+2. **Investigation Targetsに1行ずつ追加**: タスクの Investigation Targets セクションに、マッチしたコンポーネントごとに1行追加する。形式は `[ui-specパス] (§ [コンポーネント見出し]<状態ヒント>)` で、`<状態ヒント>` は行に具体的な状態が列挙されている場合のみ付加する。
+
+   - 状態が列挙されていない場合: `docs/ui-spec/foo-ui-spec.md (§ コンポーネント: AlertCard)`
+   - 状態が列挙されている場合: `docs/ui-spec/foo-ui-spec.md (§ コンポーネント: AlertCard — default + loading + error 状態を検証)`
+
+   これがエントリ全体である — 別行で括弧書きを追加してはならない。状態ヒントは同じ行の一部とする。
+3. **1行 → 1つ以上のタスク**: 1コンポーネントが複数タスクに分割される場合、同じ行をそれぞれのタスクに伝播する
+4. **未提供の場合はスキップ**: 作業計画書に「UI Specコンポーネント → タスクマッピング」表がない場合は、本伝播ステップをスキップする
+
+## Connection Map伝播
+
+作業計画書にConnection Map表が含まれる場合、各実装タスクに境界の文脈を以下のように伝播する:
+
+1. **タスクIDで照合**: Connection Mapの各行について、「カバーするタスク」列に記載されたタスクを特定する
+2. **Investigation Targetsに追加**: 境界の両側のオーナーモジュールのファイルパスを、マッチした各タスクの Investigation Targets に追加する
+3. **タスク本文に「Boundary Context」ノートを追加**: Connection Mapの行から境界識別子と期待されるシグナルをそのまま記録する。executorは、実装が生み出すべき観測可能な証拠を把握できる。
+4. **未提供の場合はスキップ**: 作業計画書にConnection Mapがない場合は、本伝播ステップをスキップする
+
 ## 品質保証メカニズムの伝播
 
 作業計画書ヘッダーに Quality Assurance Mechanisms テーブルが含まれる場合、以下のルールで各タスクに伝播する:
@@ -152,7 +188,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 ## 全体設計書テンプレート
 
 ```markdown
-# 全体設計書: [計画書名]
+# 全体設計書: [plan-name]
 
 生成日時: [日時]
 対象計画書: [計画書ファイル名]
@@ -214,7 +250,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 📋 タスク分解完了
 
 計画書: [ファイル名]
-全体設計書: _overview-[計画書名].md
+全体設計書: _overview-[plan-name].md
 分解したタスク数: [数]個
 
 全体最適化の結果:

package/.claude/agents-ja/ui-spec-designer.md

@@ -103,6 +103,8 @@ skills: documentation-criteria, frontend-typescript-rules, project-context
 - [ ] プロトタイプ提供時: プロトタイプが`docs/ui-spec/assets/`に配置されている
 - [ ] 未確定事項の全TBDに担当者と期限がある
 - [ ] UI Specの全要件がPRD要件と整合している
+- [ ] **コンポーネント見出しの一意性**: 全コンポーネントが、UI Spec内でテキストとして一意なセクション見出しの下に記述されている。形式は`## Component: [ComponentName]`（画面の下にネストする場合は`### Component: [ComponentName]`）。下流エージェント（work-planner Step 5a、task-decomposerのUI Spec伝播）はコンポーネントを見出しテキストの完全一致で参照するため、重複や言い換えがあると伝播チェーンが破綻する。
+  - **曖昧性回避ルール**: 2つのコンポーネントが同じベース名を持つ場合（例: 同じ`AlertCard`をバナーバリアントとインラインバリアントとして描画する）、各見出しを一意にするために括弧付きの修飾子を付加する: `Component: AlertCard (Banner variant)` と `Component: AlertCard (Inline variant)`。最終チェックで一意性を検証する: すべての`Component: `見出しを抽出し、重複がゼロであることを確認する
 
 ## 重要な設計原則
 

package/.claude/agents-ja/work-planner.md

@@ -44,22 +44,36 @@ Design Doc、UI Spec、PRD、ADR（提供されている場合）を読み込み
 - 最終フェーズは常に品質保証
 
 **E2Eギャップチェック（全戦略共通）**:
-利用可能なテストスケルトンを確認した後、E2Eスケルトンが不在かチェックする。マルチステップユーザージャーニーは以下の条件をすべて満たす場合に存在する: (1) 2つ以上の異なるインタラクション境界が順番に通過される、(2) ステップ間で状態が伝搬する、(3) ジャーニーに完了ポイントがある。**ユーザー向け**ジャーニーとは、人間のユーザーが直接ステップをトリガーし結果を観察するもの（UI、CLI、直接的なAPIインタラクション経由）であり、サービス内部パイプラインは含まない。
+利用可能なテストスケルトンを確認した後、2つのE2Eレーン（fixture-e2e、service-integration-e2e — integration-e2e-testingスキル参照）を独立してチェックする。マルチステップユーザージャーニーは以下の条件をすべて満たす場合に存在する: (1) 2つ以上の異なるインタラクション境界が順番に通過される、(2) ステップ間で状態が伝搬する、(3) ジャーニーに完了ポイントがある。**ユーザー向け**ジャーニーとは、人間のユーザーが直接ステップをトリガーし結果を観察するもの（UI、CLI、直接的なAPIインタラクション経由）であり、サービス内部パイプラインは含まない。
 
 ```
-IF E2Eテストスケルトンファイルが提供されていない
-  AND 上流からe2eAbsenceReasonが伝達されていない
-  AND Design DocまたはUI Specにユーザー向けマルチステップジャーニーが含まれる
-THEN 作業計画書ヘッダーに追記:
-  ⚠ E2E Gap: この機能にはユーザー向けマルチステップジャーニーが含まれますが、
-  E2Eテストスケルトンが提供されていません。最終フェーズ前に
-  受入テスト生成へ差し戻してE2Eテスト候補を評価する。
-  検出されたジャーニー: [ジャーニーの説明とAC参照のリスト]
+fixture-e2e gap:
+  IF fixture-e2eスケルトンが提供されていない
+    AND e2eAbsenceReason.fixtureE2eが伝達されていない
+    AND Design DocまたはUI Specにユーザー向けマルチステップジャーニーが含まれる
+  THEN 作業計画書ヘッダーに追記:
+    ⚠ fixture-e2e Gap: この機能にはユーザー向けマルチステップジャーニーが含まれますが、
+    fixture-e2eスケルトンが提供されていません。UI実装フェーズの前に、受入テスト生成
+    へ差し戻して fixture-e2e 候補を評価する。
+    検出されたジャーニー: [ジャーニーの説明とAC参照のリスト]
+
+service-integration-e2e gap:
+  IF service-integration-e2eスケルトンが提供されていない
+    AND e2eAbsenceReason.serviceE2eが伝達されていない
+    AND Design Docがジャーニーに実サービス間検証（複数サービスをまたぐデータ永続化、
+        トランザクション整合性、外部サービスコントラクト）を要求する
+  THEN 作業計画書ヘッダーに追記:
+    ⚠ service-integration-e2e Gap: この機能はサービス境界をまたぎ、正しさが
+    実サービス間挙動に依存しますが、service-integration-e2eスケルトンが
+    提供されていません。
+    検出された境界: [境界の記述とAC参照のリスト]
 ```
 
-`e2eAbsenceReason`が提供されている場合（受入テストのGeneration Reportで生成される。例: `no_multi_step_journey`, `below_threshold_user_confirmed`）、E2E不在は意図的 — このギャップチェックをスキップする。
+「伝達されていない」分岐は、上流の計画フローがテストスケルトン生成自体をスキップしたシナリオ — その場合、不在理由フィールド自体がwork-plannerに渡されないため、ギャップチェックは依然として走る。acceptance-test-generatorの契約により、スケルトンが生成された場合は `e2eAbsenceReason.<lane>` は null、生成されなかった場合は契約に列挙された文字列となる — どちらもフィールドは「伝達された」状態であり、ギャップ警告は発火しない。
 
-このチェックは戦略AまたはBのどちらが選択されていても適用される。統合テストスケルトンのみの提供はE2Eカバレッジを意味しない。サービス内部ジャーニー（非同期パイプライン、サービス間saga）はここではフラグしない — 通常のROIパスでE2Eが必要な場合はそちらで対応。
+レーンの`e2eAbsenceReason`が文字列値（例: `no_multi_step_journey`、`below_threshold_user_confirmed`、`no_real_service_dependency` — レーンごとの許容値はacceptance-test-generatorを参照）を持つ場合、当該レーンの不在は意図的 — そのレーンのギャップチェックをスキップする。
+
+このチェックは戦略AまたはBのどちらが選択されていても適用される。統合テストスケルトンのみの提供はE2Eカバレッジを意味しない。サービス内部ジャーニー（非同期パイプライン、サービス間saga）は予約スロットルールではフラグしない — 通常のROIパスを通じた service-integration-e2e は依然として候補となり得る。
 
 **フェーズ構成**: Design Docの実装アプローチに基づいて選択。詳細はdocumentation-criteriaスキルのフェーズ分割基準を参照。plan-templateのOption A（垂直）またはOption B（水平）に従う。ハイブリッドの場合はOption Aをベースに、必要に応じて水平基盤フェーズを追加する。
 
@@ -79,6 +93,39 @@ THEN 作業計画書ヘッダーに追記:
 
 カバーするタスクがない項目はギャップステータスを`gap`とし、備考に理由を記載する。**トレーサビリティ表に`gap`が1件でも含まれる場合、計画書はドラフト状態とする。** ドラフトとして出力するが、ユーザーが各ギャップを確認するまで確定しない。理由なしのギャップ（備考が空）はエラーとして扱い、カバーするタスクを追加するか理由を記載してから進める。
 
+### 5a. UI Specコンポーネントのタスクへのマッピング（UI Spec提供時）
+
+入力にUI Specが含まれる場合、コンポーネントと状態を実装タスクへマッピングする。task-decomposerは下流ステップでこのマッピングを読み込み、各タスクのInvestigation Targetsに反映する — このステップを行わないとUI Specがexecutorまで届かない。
+
+UI Specに記述された各コンポーネントについて:
+1. UI Specに記載されているとおりのセクション見出しを特定する（見出しが参照キー — ui-spec-designerの見出し一意性ルールを参照）
+2. 実装がカバーすべき状態（default / loading / empty / error / partial）を特定する
+3. 当該コンポーネントまたはそのテストを実装する本計画内のタスクを特定する
+
+マッピング結果は **「UI Specコンポーネント → タスクマッピング」表**（plan-template参照）に記録する。コンポーネント1件につき1行。カバーするタスクがないコンポーネントは設計-計画トレーサビリティと同じく `gap` としてユーザー確認を要求する。
+
+### 5b. パッケージ間境界のタスクへのマッピング（実装がランタイム/デプロイ境界をまたぐ場合）
+
+実装がランタイムまたはデプロイ境界をまたぐ場合、Connection Mapを作成してtask-decomposerが境界の文脈を各タスクに伝播できるようにする。
+
+**境界がConnection Mapの対象となるのは、以下の条件をすべて満たす場合のみ**:
+- 両側が別プロセス、別サービス、または別ランタイムで動作する（例: Webクライアント ↔ HTTPサーバ、サービスA ↔ サービスB（ネットワーク経由）、フロントエンドバンドル ↔ バックエンドハンドラ）
+- 両者間でシリアライズされたコントラクトが交わされる（HTTPリクエスト/レスポンス、メッセージエンベロープ、RPC、イベントペイロード）
+- 一方の障害がもう一方で観測可能なシグナルを生む（ステータスコード、フィールド欠落、タイムアウト、メッセージドロップ）
+
+**除外 — 以下はConnection Map対象外**:
+- 同一monorepo内での兄弟ユーティリティ、型定義、共有定数のimport（in-process、シリアライズコントラクトなし）
+- 同一ランタイム内のレイヤリング（例: handler → usecase → repository）
+- 同一成果物にコンパイル/バンドルされるソースコード依存
+
+該当する境界それぞれについて:
+1. 境界を特定する（例: `web → API gateway`、`service-A → service-B`、`frontend → shared client → backend handler`）
+2. 両側のオーナーモジュール/パッケージを特定する
+3. 境界が機能していることを裏付ける期待されるシグナルを特定する（例: スキーマXに一致するHTTP 200、トピックYへのメッセージpublish、テーブルZへの行挿入）
+4. 境界の両側を実装するタスクを特定する
+
+マッピング結果は **「Connection Map」表**（plan-template参照）に記録する。該当する境界がない場合は本セクションを丸ごと省略する。
+
 ### 6. 完了条件付きタスクの定義
 各タスクについて、Design Docの受入条件から完了条件を導出。3要素の完了定義（実装完了、品質完了、統合完了）を適用。
 
@@ -87,6 +134,8 @@ THEN 作業計画書ヘッダーに追記:
 - **`scale: medium` / `scale: large`**: documentation-criteria スキルの **plan-template** に従って作業計画書を記述。フェーズ構成図とタスク依存関係図（mermaid）を含める。
 - **`scale: small`**: documentation-criteria スキルの **task-template** に従って単一タスクファイルを出力（後述「scale 別の出力モード」を参照）。フェーズ構成図・タスク依存関係図はスキップ。タスクファイルの `## Implementation Steps` セクションが実行を駆動する。
 
+`scale: medium` / `scale: large` の場合、計画書ヘッダーには `Implementation Readiness: pending` の行を必ず含める。マーカーの契約: 値は `pending`（初期。本エージェントが設定）、`ready`（検証完了、残存ギャップなし）、`escalated`（検証完了、残存ギャップあり）の3つのいずれか。`pending` から先へマーカーを昇格させるプロデューサと、実行前にマーカーを読むコンシューマは、本エージェントの外側で扱われる外部オーケストレーションの関心事である。
+
 ## Input Parameters
 
 - **mode**: `create`（デフォルト）| `update`
@@ -143,10 +192,11 @@ THEN 作業計画書ヘッダーに追記:
 #### Phase 0: テスト準備（単体テストのみ）
 前工程から提供されたテスト定義のうち、単体テストを基にRed状態のテストを作成。
 
-**テスト実装タイミング**:
+**テスト実装タイミングと配置**:
 - 単体テスト: Phase 0でRed → 実装時にGreen
-- 統合テスト: 実装完了時点で作成・即実行（Red-Green-Refactor不適用）
-- E2Eテスト: 最終Phaseで実行のみ（Red-Green-Refactor不適用）
+- 統合テスト: 該当機能の実装完了時点で作成・即実行（フェーズタスクに「[機能名] 実装と統合テスト作成」のように含める）
+- fixture-e2eテスト: UI機能フェーズと並行して作成・実行（フェーズタスクに「[機能名] UI実装と fixture-e2e 作成」のように含める）。インフラ準備なしにCIで実行可能。
+- service-integration-e2eテスト: 最終フェーズでのみ実行（ローカルスタックに依存し、タスクサイクル内で回すには重すぎる傾向がある）
 
 #### メタ情報の活用
 テスト定義に含まれるメタ情報（@category, @dependency, @complexity等）を分析し、
@@ -192,22 +242,29 @@ Design Docの受入条件を基に、段階的に品質を確保。
 
 #### Step 3: E2EスケルトンからのEnvironment Prerequisites抽出
 
-E2Eテストスケルトンが提供された場合、2段階で環境前提条件をスキャンする:
+E2Eテストスケルトンが提供された場合、2段階で環境前提条件をスキャンする。fixture-e2eとservice-integration-e2eは前提条件の形が大きく異なるため、以下のレーン別ルールを適用する。
 
-**Stage 1: 前提条件パターンの検出** — 全E2Eスケルトンをスキャンし、検出した全前提条件を列挙:
-- seed data、テストユーザー、サブスクリプション、特定のDB状態に言及する`Preconditions:`または`Arrange:`コメントアノテーション
-- auth/loginセットアップコードと組み合わされた`@dependency: full-system`
+**Stage 1: 前提条件パターンの検出** — 各E2Eスケルトン（`@lane`ヘッダで該当レーンを把握）をスキャンし、検出した全前提条件を列挙:
+- seed data、テストユーザー、フィクスチャ、特定のUI/DB状態に言及する`Preconditions:`または`Arrange:`コメントアノテーション
+- フィクスチャローダーまたはAPIモックハンドラ（MSWのルートハンドラ — fixture-e2e）と組み合わされた`@dependency: full-ui (mocked backend)`
+- auth/loginセットアップコード（service-integration-e2e）と組み合わされた`@dependency: full-system`
 - 環境変数への参照（`E2E_*`, `TEST_*`）
-- テストコード内のHTTP mock/interceptパターンを必要とする外部サービス参照
+- HTTP mock/interceptパターンを必要とする外部サービス参照
+
+**Stage 2: セットアップタスクの生成** — 検出した各前提条件に対応するPhase 0タスクを作成。レーン別の一般的なカテゴリ:
+
+**fixture-e2e** の場合:
+- **フィクスチャデータ** → 「[機能]のUI状態用フィクスチャデータファイルの作成」
+- **モックバックエンド** → 「fixture-e2e用 MSW ハンドラの設定（プロジェクトのAPI面に対するブラウザランタイムのモック）」
+- **ブラウザハーネス** → 「fixture-e2e用のPlaywrightハーネス設定（ライブサービス不要）」
 
-**Stage 2: セットアップタスクの生成** — 検出した各前提条件に対応するPhase 0タスクを作成。一般的なカテゴリ:
-- **Seed data** → 「E2E seed data scriptの作成（テストユーザー、必要なレコード）」
-- **Auth fixture** → 「アプリケーションのログインフローを使用したE2E auth fixtureの実装」
-- **外部サービスモック** → 「E2Eテスト用の外部サービスモック設定」
-- **環境設定** → 「E2E環境変数の定義とセットアップ手順の文書化」
-- **その他の検出された前提条件** → 検出カテゴリに合わせたセットアップタスクを作成
+**service-integration-e2e** の場合:
+- **Seed data** → 「service-integration-e2e用 seed data script の作成（テストユーザー、必要なレコード）」
+- **Auth fixture** → 「アプリケーションのログインフローを使用した auth fixture の実装」
+- **外部サービススタブ** → 「service-integration-e2e用の外部サービススタブ設定」
+- **環境設定** → 「service-integration-e2e の環境変数定義とローカル起動手順の文書化」
 
-全環境セットアップタスクをPhase 0（実装タスクより前）に配置する。トレーサビリティのため`@category: e2e-setup`を付与。
+全環境セットアップタスクをPhase 0（実装タスクより前）に配置する。トレーサビリティのため`@category: e2e-setup`と対象レーンに対応する`@lane:`を付与する。
 
 #### Step 4: it.todoの構造分析と分類
 
@@ -215,7 +272,8 @@ E2Eテストスケルトンが提供された場合、2段階で環境前提条
    - セットアップ系（Mock準備、測定ツール、Helper等）→ Phase 1に最優先配置
    - 単体テスト（個別機能）→ Red-Green-RefactorでPhase 0から開始
    - 統合テスト → 該当機能実装完了時点で作成・実行タスクとして配置
-   - E2Eテスト → 最終Phaseで実行のみタスクとして配置
+   - fixture-e2eテスト → 該当UI機能実装と並行して作成・実行タスクとして配置
+   - service-integration-e2eテスト → 最終Phaseで実行のみタスクとして配置
    - 非機能要件テスト（性能、UX等）→ 品質保証フェーズに配置
    - リスクレベル（「高リスク」「必須」等の記載）→ 早期フェーズに前倒し
 
@@ -237,7 +295,8 @@ E2Eテストスケルトンが提供された場合、2段階で環境前提条
 ### テスト配置の原則
 **Phase配置ルール**:
 - 統合テスト: 「[機能名]実装と統合テスト作成」のように該当Phaseタスクに含める
-- E2Eテスト: 「E2Eテスト実行」を最終Phaseに配置（実装は不要、実行のみ）
+- fixture-e2eテスト: UI機能フェーズと並行して含める（CIフレンドリーなブラウザハーネスでの作成 + 実行）
+- service-integration-e2eテスト: 「service-integration-e2e 実行」を最終Phaseに配置（実装は不要、ローカルスタックに対する実行のみ）
 
 ### 実装アプローチの適用
 Design Docで決定された実装アプローチと技術的依存関係に基づき、implementation-approachスキルの検証レベル（L1/L2/L3）に従ってタスクを分解する。
@@ -269,6 +328,13 @@ Design Docの技術的依存関係と実装アプローチに基づいてフェ
 - [ ] 設計-計画トレーサビリティ表の完成（DDの全技術要件がカテゴリ分類・マッピング済み）
   - [ ] 理由なしの`gap`がないこと
   - [ ] 理由ありの`gap`は計画承認前にユーザー確認を実施
+- [ ] UI Specコンポーネント → タスクマッピング表の完成（UI Spec提供時）
+  - [ ] UI Specの全コンポーネントにカバーするタスクが存在、または明示的な`gap`理由がある
+  - [ ] コンポーネント参照はUI Specのセクション見出しを完全一致で記載している
+- [ ] Connection Map表の完成（実装が複数のパッケージ/サービスをまたぐ場合）
+  - [ ] 各境界にオーナーモジュールと期待されるシグナルが記載されている
+  - [ ] 各境界の両側に少なくとも1つのカバータスクがマッピングされている
+- [ ] 計画書ヘッダーに `Implementation Readiness: pending` を含める（medium / large のみ）
 - [ ] Design Docから検証戦略を抽出し計画書ヘッダーに記載
 - [ ] Design Docから採用済み品質保証メカニズムを抽出し計画書ヘッダーに記載
 - [ ] フェーズ構成が実装アプローチと整合（垂直 → 価値単位フェーズ、水平 → レイヤーフェーズ）
@@ -277,7 +343,8 @@ Design Docの技術的依存関係と実装アプローチに基づいてフェ
 - [ ] 最終フェーズに品質保証の存在
 - [ ] テストスケルトンファイルパスを対応するフェーズに記載（提供時）
 - [ ] E2E環境前提条件に対応済み（E2Eスケルトンが提供された場合）
-  - [ ] seed data、auth fixture、外部サービスモックのタスクを生成
+  - [ ] fixture-e2e の前提条件: 該当する場合はフィクスチャデータ、モックバックエンド、ブラウザハーネスのタスクを生成
+  - [ ] service-integration-e2e の前提条件: 該当する場合は seed data、auth fixture、外部サービススタブのタスクを生成
   - [ ] 環境セットアップタスクをPhase 0に配置
 - [ ] テスト設計情報の反映（提供された場合のみ）
   - [ ] セットアップタスクが最初のフェーズに配置されている

package/.claude/commands-en/add-integration-tests.md

@@ -168,6 +168,14 @@ Check quality-fixer response:
 On `approved` from quality-fixer:
 - Commit test files with appropriate message using Bash
 
+### Step 9: Final Cleanup
+
+After all task files have been processed and committed, delete the task files this recipe created. Their work is committed; `docs/plans/` is ephemeral working state and is not retained between recipe runs:
+
+- Delete every file matching `docs/plans/tasks/integration-tests-backend-task-*.md` and `docs/plans/tasks/integration-tests-frontend-task-*.md` created during this run
+
+If task files cannot be deleted (filesystem error), report the failure but do not block completion.
+
 ## Scope Boundary for Subagents
 
 Append the following block to every subagent prompt invoked from this recipe: