create-ai-project 1.20.4 → 1.20.6

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

@@ -43,12 +43,46 @@ Design Doc、UI Spec、PRD、ADR（提供されている場合）を読み込み
 - テストスケルトンが提供されていない場合、Design Docの受入条件に基づくテスト実装タスクを含める
 - 最終フェーズは常に品質保証
 
+**E2Eギャップチェック（全戦略共通）**:
+利用可能なテストスケルトンを確認した後、E2Eスケルトンが不在かチェックする。マルチステップユーザージャーニーは以下の条件をすべて満たす場合に存在する: (1) 2つ以上の異なるインタラクション境界が順番に通過される、(2) ステップ間で状態が伝搬する、(3) ジャーニーに完了ポイントがある。**ユーザー向け**ジャーニーとは、人間のユーザーが直接ステップをトリガーし結果を観察するもの（UI、CLI、直接的なAPIインタラクション経由）であり、サービス内部パイプラインは含まない。
+
+```
+IF E2Eテストスケルトンファイルが提供されていない
+  AND 上流からe2eAbsenceReasonが伝達されていない
+  AND Design DocまたはUI Specにユーザー向けマルチステップジャーニーが含まれる
+THEN 作業計画書ヘッダーに追記:
+  ⚠ E2E Gap: この機能にはユーザー向けマルチステップジャーニーが含まれますが、
+  E2Eテストスケルトンが提供されていません。最終フェーズ前に
+  acceptance-test-generatorでE2Eテスト候補を評価することを検討してください。
+  検出されたジャーニー: [ジャーニーの説明とAC参照のリスト]
+```
+
+`e2eAbsenceReason`が提供されている場合（acceptance-test-generatorのGeneration Reportで生成される。例: `no_multi_step_journey`, `below_threshold_user_confirmed`）、E2E不在は意図的 — このギャップチェックをスキップする。
+
+このチェックは戦略AまたはBのどちらが選択されていても適用される。統合テストスケルトンのみの提供はE2Eカバレッジを意味しない。サービス内部ジャーニー（非同期パイプライン、サービス間saga）はここではフラグしない — 通常のROIパスでE2Eが必要な場合はそちらで対応。
+
 **フェーズ構成**: Design Docの実装アプローチに基づいて選択。詳細はdocumentation-criteriaスキルのフェーズ分割基準を参照。plan-templateのOption A（垂直）またはOption B（水平）に従う。ハイブリッドの場合はOption Aをベースに、必要に応じて水平基盤フェーズを追加する。
 
-### 5. 完了条件付きタスクの定義
+### 5. DD技術要件のタスクへのマッピング
+
+提供されたDesign Docをセクションごとにスキャンする。以下のカテゴリテーブルをチェックリストとして、該当する項目を抽出する:
+
+| カテゴリ | 抽出対象 |
+|---|---|
+| impl-target | 作成・変更が必要なコンポーネント、関数、データ構造 |
+| connection-switching | 統合ポイント、依存関係の配線、切替方式 |
+| contract-change | インターフェース変更、データコントラクト変更、境界を越えるフィールドの伝搬 |
+| verification | 検証手法、テスト境界、統合検証ポイント、統合ポイント一覧の検証方式列 |
+| prerequisite | マイグレーション手順、セキュリティ対策、環境セットアップ |
+
+抽出した各項目をカバーするタスクにマッピングする。専用タスクでカバーしても、より包括的なタスクに内包してもよいが、マッピングは必ず明示すること。マッピング結果は計画テンプレートの設計-計画トレーサビリティ表に、上記左列のカテゴリ値を使用して記録する。
+
+カバーするタスクがない項目はギャップステータスを`gap`とし、備考に理由を記載する。**トレーサビリティ表に`gap`が1件でも含まれる場合、計画書はドラフト状態とする。** ドラフトとして出力するが、ユーザーが各ギャップを確認するまで確定しない。理由なしのギャップ（備考が空）はエラーとして扱い、カバーするタスクを追加するか理由を記載してから進める。
+
+### 6. 完了条件付きタスクの定義
 各タスクについて、Design Docの受入条件から完了条件を導出。3要素の完了定義（実装完了、品質完了、統合完了）を適用。
 
-### 6. 作業計画書の作成
+### 7. 作業計画書の作成
 documentation-criteriaスキルの計画テンプレートに従って作業計画書を記述。フェーズ構成図とタスク依存関係図（mermaid）を含める。
 
 ## Input Parameters
@@ -72,7 +106,7 @@ documentation-criteriaスキルの計画テンプレートに従って作業計
 2. **更新**: 各フェーズ完了時に進捗更新（チェックボックス）
 3. **削除**: 全タスク完了後、ユーザー承認を得て削除
 ## 出力方針
-ファイル出力は即座に実行（実行時点で承認済み）。
+ファイル出力は即座に実行（実行時点で承認済み）。**例外**: トレーサビリティ表に`gap`が含まれる場合は、計画書をドラフトとして出力し、各ギャップについてユーザー確認を得てから確定する。
 
 ## タスク設計の重要原則
 
@@ -220,6 +254,9 @@ Design Docの技術的依存関係と実装アプローチに基づいてフェ
 ## 品質チェックリスト
 
 - [ ] Design Doc（複数時は各Doc）の整合性確認
+- [ ] 設計-計画トレーサビリティ表の完成（DDの全技術要件がカテゴリ分類・マッピング済み）
+  - [ ] 理由なしの`gap`がないこと
+  - [ ] 理由ありの`gap`は計画承認前にユーザー確認を実施
 - [ ] Design Docから検証戦略を抽出し計画書ヘッダーに記載
 - [ ] フェーズ構成が実装アプローチと整合（垂直 → 価値単位フェーズ、水平 → レイヤーフェーズ）
 - [ ] 早期検証ポイントをPhase 1に配置（検証戦略で指定されている場合）

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

@@ -145,9 +145,14 @@ Invoke quality-fixer routed by task filename pattern:
 - `description`: "Final quality assurance"
 - `prompt`: "Final quality assurance for test files added in this workflow. Run all tests and verify coverage."
 
-**Expected output**: `approved` (true/false)
+**Expected output**: `status` (approved/stub_detected/blocked)
+
+Check quality-fixer response:
+- `stub_detected` → Return to Step 4 with `incompleteImplementations[]` details, then re-execute Steps 4→5→6→7
+- `blocked` → Escalate to user
+- `approved` → Proceed to Step 8
 
 ### Step 8: Commit
 
-On `approved: true` from quality-fixer:
+On `approved` from quality-fixer:
 - Commit test files with appropriate message using Bash

package/.claude/commands-en/build.md

@@ -85,9 +85,13 @@ For EACH task, YOU MUST:
      - `approved` → Proceed to step 4
    - `readyForQualityCheck: true` → Proceed to step 4
 4. **INVOKE quality-fixer**: Execute all quality checks and fixes (cross-layer: see Layer-Aware Agent Routing)
-5. **COMMIT on approval**: After `approved: true` from quality-fixer → Execute git commit
+5. **CHECK quality-fixer response**:
+   - `stub_detected` → Return to step 2 with `incompleteImplementations[]` details
+   - `blocked` → STOP and escalate to user
+   - `approved` → Proceed to step 6
+6. **COMMIT on approval**: Execute git commit
 
-**CRITICAL**: Monitor ALL structured responses WITHOUT EXCEPTION and ENSURE every quality gate is passed.
+**CRITICAL**: Parse every sub-agent response for status fields. Execute the matching branch in the 4-step cycle. Proceed to next task only after quality-fixer returns `approved`.
 
 ## Sub-agent Invocation Constraints
 

package/.claude/commands-en/diagnose.md

@@ -2,7 +2,7 @@
 description: Investigate problem, verify findings, and derive solutions
 ---
 
-**Command Context**: Diagnosis flow to identify root cause and present solutions
+**Command Context**: Diagnosis flow to identify failure points and present solutions
 
 Target problem: $ARGUMENTS
 
@@ -64,10 +64,10 @@ Confirm from rule-advisor output:
 ```
 Problem → investigator → verifier → solver ─┐
                  ↑                          │
-                 └── confidence < high ─────┘
+                 └── coverage insufficient ─┘
                       (max 2 iterations)
 
-confidence=high reached → Report
+coverage sufficient → Report
 ```
 
 **Context Separation**: Pass only structured JSON output to each step. Each step starts fresh with the JSON data only.
@@ -94,19 +94,20 @@ Invoke investigator using Agent tool:
     Affected area: [What broke]
     Shared components: [Commonalities between cause and effect]
 
-**Expected output**: Evidence matrix, comparison analysis results, causal tracking results, list of unexplored areas, investigation limitations
+**Expected output**: pathMap (execution paths per symptom), failurePoints (faults found at each node), impactAnalysis per failure point, unexplored areas, investigation limitations
 
 ### Step 2: Investigation Quality Check
 
 Review investigation output:
 
 **Quality Check** (verify JSON output contains the following):
-- [ ] `comparisonAnalysis` is present and `normalImplementation` is not null (comparison target found) OR explicitly recorded as "no working implementation found"
-- [ ] `causalChain` for each hypothesis reaches a stop condition (code change / design decision / external constraint)
-- [ ] `causeCategory` for each hypothesis is one of: typo / logic_error / missing_constraint / design_gap / external_factor
+- [ ] `pathMap` exists with at least one symptom, and each symptom has at least one path with nodes listed
+- [ ] Each failure point has: `location`, `upstreamDependency`, `symptomExplained`, `causalChain` (reaching a stop condition), `checkStatus`, `evidence` with a `source` citing a specific file or location
+- [ ] Each failure point has `comparisonAnalysis` (normalImplementation found or explicitly null)
+- [ ] `causeCategory` for each failure point is one of: typo / logic_error / missing_constraint / design_gap / external_factor
 - [ ] `investigationSources` covers at least 3 distinct source types (code, history, dependency, config, document, external)
 - [ ] Investigation covers `investigationFocus` items (when provided in Step 0.4)
-- [ ] Each hypothesis has at least 1 entry in `supportingEvidence` with a `source` field citing a specific file or location
+- [ ] All nodes on mapped paths have been checked (no path was abandoned after finding the first fault)
 
 **If quality insufficient**: Re-run investigator specifying missing items explicitly:
 - `prompt`: |
@@ -135,48 +136,59 @@ Invoke verifier using Agent tool:
 - `description`: "Verify investigation results"
 - `prompt`: "Verify the following investigation results. Investigation results: [Investigation JSON output]"
 
-**Expected output**: Alternative hypotheses (at least 3), Devil's Advocate evaluation, final conclusion, confidence
+**Expected output**: Coverage check (missing paths, unchecked nodes), Devil's Advocate evaluation per failure point, failure point evaluation with finalStatus, coverage assessment
 
-**Confidence Criteria**:
-- **high**: No uncertainty affecting solution selection or implementation
-- **medium**: Uncertainty exists but resolvable with additional investigation
-- **low**: Fundamental information gap exists
+**Coverage Criteria**:
+- **sufficient**: Main paths traced, all critical nodes checked, each failure point individually evaluated
+- **partial**: Main paths traced, some nodes unchecked or some failure points at blocked/not_reached
+- **insufficient**: Significant paths untraced, or critical nodes not investigated
 
-### Step 4: Solution Derivation (solver)
+### Step 4: Coverage Gate
+
+Check verifier's `coverageAssessment`:
+
+- **sufficient** → Proceed to Step 5 (solver)
+- **partial or insufficient** → Return to Step 1 with unchecked areas identified by verifier as investigation targets
+  - Maximum 2 additional investigation iterations
+  - After 2 iterations without reaching sufficient, present user with options:
+    - Continue additional investigation
+    - Proceed to solver at current coverage level (user accepts risk of incomplete diagnosis)
+
+### Step 5: Solution Derivation (solver)
+
+**Prerequisite**: coverageAssessment=sufficient (or explicit user approval to proceed with partial/insufficient)
 
 Invoke solver using Agent tool:
 - `subagent_type`: "solver"
 - `description`: "Derive solutions"
-- `prompt`: "Derive solutions based on the following verified conclusion. Causes: [verifier's conclusion.causes]. Causes relationship: [causesRelationship: independent/dependent/exclusive]. Confidence: [high/medium/low]"
-
-**Expected output**: Multiple solutions (at least 3), tradeoff analysis, recommendation and implementation steps, residual risks
+- `prompt`: |
+    Derive solutions based on the following verified failure points.
 
-**Completion condition**: confidence=high
+    Confirmed failure points: [verifier's conclusion.confirmedFailurePoints]
+    Refuted failure points: [verifier's conclusion.refutedFailurePoints]
+    Failure point relationships: [verifier's conclusion.failurePointRelationships]
+    Impact analysis: [investigator's impactAnalysis]
+    Coverage assessment: [sufficient/partial/insufficient]
 
-**When not reached**:
-1. Return to Step 1 with uncertainties identified by solver as investigation targets
-2. Maximum 2 additional investigation iterations
-3. After 2 iterations without reaching high, present user with options:
-   - Continue additional investigation
-   - Execute solution at current confidence level
+**Expected output**: Multiple solutions (at least 3), tradeoff analysis, recommendation and implementation steps, residual risks
 
-### Step 5: Final Report Creation
+### Step 6: Final Report Creation
 
-**Prerequisite**: confidence=high achieved
+**Prerequisite**: solver completed (Step 5)
 
 After diagnosis completion, report to user in the following format:
 
 ```
 ## Diagnosis Result Summary
 
-### Identified Causes
-[Cause list from verification results]
-- Causes relationship: [independent/dependent/exclusive]
+### Identified Failure Points
+[Confirmed failure points from verification results]
+- Per failure point: location, symptom explained, finalStatus
 
 ### Verification Process
-- Investigation scope: [Scope confirmed in investigation]
+- Path coverage: [Paths traced and nodes checked]
 - Additional investigation iterations: [0/1/2]
-- Alternative hypotheses count: [Number generated in verification]
+- Coverage assessment: [sufficient/partial/insufficient]
 
 ### Recommended Solution
 [Solution derivation recommendation]
@@ -201,9 +213,9 @@ Rationale: [Selection rationale]
 
 ## Completion Criteria
 
-- [ ] Executed investigator and obtained evidence matrix, comparison analysis, and causal tracking
+- [ ] Executed investigator and obtained pathMap, failurePoints, and impactAnalysis
 - [ ] Performed investigation quality check and re-ran if insufficient
-- [ ] Executed verifier and obtained confidence level
+- [ ] Executed verifier and obtained coverage assessment
 - [ ] Executed solver
-- [ ] Achieved confidence=high (or obtained user approval after 2 additional iterations)
+- [ ] Achieved coverageAssessment=sufficient (or obtained user approval after 2 additional iterations)
 - [ ] Presented final report to user

package/.claude/commands-en/front-build.md

@@ -85,9 +85,13 @@ For EACH task, YOU MUST:
      - `approved` → Proceed to step 4
    - `readyForQualityCheck: true` → Proceed to step 4
 4. **INVOKE quality-fixer-frontend**: Execute all quality checks and fixes
-5. **COMMIT on approval**: After `approved: true` from quality-fixer-frontend → Execute git commit
+5. **CHECK quality-fixer-frontend response**:
+   - `stub_detected` → Return to step 2 with `incompleteImplementations[]` details
+   - `blocked` → STOP and escalate to user
+   - `approved` → Proceed to step 6
+6. **COMMIT on approval**: Execute git commit
 
-**CRITICAL**: Parse every sub-agent response for status fields. Execute the matching branch in the 4-step cycle. Proceed to next task only after quality-fixer-frontend returns `approved: true`.
+**CRITICAL**: Parse every sub-agent response for status fields. Execute the matching branch in the 4-step cycle. Proceed to next task only after quality-fixer-frontend returns `approved`.
 
 ## Sub-agent Invocation Constraints
 

package/.claude/commands-en/front-plan.md

@@ -43,13 +43,19 @@ Invoke acceptance-test-generator using Agent tool:
 - If UI Spec exists: `prompt: "Generate test skeletons from Design Doc at [path]. UI Spec at [ui-spec path]."`
 - If no UI Spec: `prompt: "Generate test skeletons from Design Doc at [path]."`
 
-Pass integration test file path and E2E test file path to work-planner according to subagents-orchestration-guide "acceptance-test-generator → work-planner" section.
+Pass integration test file path, E2E test file path (or null), and e2eAbsenceReason to work-planner according to subagents-orchestration-guide "acceptance-test-generator → work-planner" section.
 
 ### Step 3: Work Plan Creation
 Invoke work-planner using Agent tool:
 - `subagent_type`: "work-planner"
 - `description`: "Work plan creation"
-- `prompt`: "Create work plan from Design Doc at [path]. Integration test file: [integration test path from step 2]. E2E test file: [E2E test path from step 2]. Integration tests are created simultaneously with each phase implementation, E2E tests are executed only in final phase."
+- If test skeletons were generated in Step 2:
+  - When `generatedFiles.e2e` is not null:
+    `prompt`: "Create work plan from Design Doc at [path]. Integration test file: [integration test path]. E2E test file: [E2E test path]. Integration tests are created simultaneously with each phase implementation, E2E tests are executed only in final phase."
+  - When `generatedFiles.e2e` is null:
+    `prompt`: "Create work plan from Design Doc at [path]. Integration test file: [integration test path]. No E2E test skeletons were generated (reason: [e2eAbsenceReason]). Integration tests are created simultaneously with each phase implementation."
+- If test skeletons were not generated:
+  `prompt`: "Create work plan from Design Doc at [path]."
 
 - Follow subagents-orchestration-guide Prompt Construction Rule for additional prompt parameters
 - Present work plan to user for review. If user requests changes, re-invoke work-planner with revised parameters

package/.claude/commands-en/implement.md

@@ -77,7 +77,10 @@ Following "Autonomous Execution Task Management" in subagents-orchestration-guid
      - `approved` → Proceed to step 3
    - Otherwise → Proceed to step 3
 3. **INVOKE quality-fixer**: Execute all quality checks and fixes (cross-layer: see Layer-Aware Agent Routing)
-4. **COMMIT on approval**: After `approved: true` → Execute git commit
+   - `stub_detected` → Return to step 1 with `incompleteImplementations[]` details
+   - `blocked` → Escalate to user
+   - `approved` → Proceed to step 4
+4. **COMMIT on approval**: Execute git commit
 
 ### Security Review (After All Tasks Complete)
 
@@ -90,9 +93,10 @@ After all task cycles finish, invoke security-reviewer before the completion rep
 
 ### Test Information Communication
 After acceptance-test-generator execution, when invoking work-planner (subagent_type: "work-planner"), communicate:
-- Generated integration test file path
-- Generated E2E test file path
-- Explicit note that integration tests run with implementation, E2E tests run after all implementations
+- Generated integration test file path (from `generatedFiles.integration`)
+- Generated E2E test file path or null (from `generatedFiles.e2e`)
+- E2E absence reason (from `e2eAbsenceReason`, when E2E is null)
+- Explicit note that integration tests are created simultaneously with implementation, E2E tests are executed after all implementations (when E2E path is provided)
 
 ## Execution Method
 

package/.claude/commands-en/plan.md

@@ -46,7 +46,10 @@ Follow subagents-orchestration-guide skill strictly and create work plan with th
    - `subagent_type`: "work-planner"
    - `description`: "Work plan creation"
    - If test skeletons were generated in Step 2:
-     `prompt`: "Create work plan from Design Doc at [path]. Integration test file: [integration test path from step 2]. E2E test file: [E2E test path from step 2]. Integration tests are created simultaneously with each phase implementation, E2E tests are executed only in final phase."
+     - When `generatedFiles.e2e` is not null:
+       `prompt`: "Create work plan from Design Doc at [path]. Integration test file: [integration test path]. E2E test file: [E2E test path]. Integration tests are created simultaneously with each phase implementation, E2E tests are executed only in final phase."
+     - When `generatedFiles.e2e` is null:
+       `prompt`: "Create work plan from Design Doc at [path]. Integration test file: [integration test path]. No E2E test skeletons were generated (reason: [e2eAbsenceReason]). Integration tests are created simultaneously with each phase implementation."
    - If test skeletons were not generated:
      `prompt`: "Create work plan from Design Doc at [path]."
 

package/.claude/commands-en/update-doc.md

@@ -121,6 +121,9 @@ prompt: |
   doc_type: design-doc
   document_path: [path from Step 1]
   Verify the updated Design Doc against current codebase.
+
+  Verification focus: Pay special attention to literal identifier referential
+  integrity in the updated sections (paths, endpoints, type names, config keys).
 ```
 
 **Store output as**: `$CODE_VERIFICATION_OUTPUT`

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

@@ -145,9 +145,14 @@ Agentツールでintegration-test-reviewerを呼び出す:
 - `description`: "最終品質保証"
 - `prompt`: "このワークフローで追加されたテストファイルの最終品質保証。全テストを実行しカバレッジを確認。"
 
-**期待される出力**: `approved` (true/false)
+**期待される出力**: `status` (approved/stub_detected/blocked)
+
+quality-fixerレスポンスチェック:
+- `stub_detected` → `incompleteImplementations[]`の詳細を添えてStep 4に戻し、Steps 4→5→6→7を再実行
+- `blocked` → ユーザーにエスカレーション
+- `approved` → Step 8へ
 
 ### ステップ8: コミット
 
-quality-fixerから`approved: true`の場合:
+quality-fixerから`approved`の場合:
 - Bashで適切なメッセージを付けてテストファイルをコミット

package/.claude/commands-ja/build.md

@@ -85,9 +85,13 @@ Agentツールでtask-decomposerを呼び出す:
      - `approved` → ステップ4へ
    - `readyForQualityCheck: true` → ステップ4へ
 4. **quality-fixer実行**: 全品質チェックと修正を実行（レイヤー横断時: レイヤー別エージェントルーティング参照）
-5. **承認後コミット**: quality-fixerの`approved: true`確認後 → git commitを実行
+5. **quality-fixerレスポンスチェック**:
+   - `stub_detected` → `incompleteImplementations[]`の詳細を添えてステップ2に戻す
+   - `blocked` → 停止してユーザーにエスカレーション
+   - `approved` → ステップ6へ
+6. **承認後コミット**: git commitを実行
 
-**重要**: 例外なく全ての構造化レスポンスを監視し、全ての品質ゲートが通過することを確保。
+**重要**: 例外なく全ての構造化レスポンスを監視し、全ての品質ゲートが通過することを確保。quality-fixerが`approved`を返すまで次のタスクに進まない。
 
 ## サブエージェント呼び出し時の制約
 

package/.claude/commands-ja/diagnose.md

@@ -2,7 +2,7 @@
 description: 問題を調査し、検証を経て解決策を導出する
 ---
 
-**コマンドコンテキスト**: 問題の根本原因を特定し、解決策を提示するための診断フロー
+**コマンドコンテキスト**: 問題の障害点を特定し、解決策を提示するための診断フロー
 
 対象問題: $ARGUMENTS
 
@@ -64,10 +64,10 @@ rule-advisorの出力から以下を確認：
 ```
 問題 → investigator → verifier → solver ─┐
                  ↑                        │
-                 └── 信頼度high未達 ──────┘
+                 └── カバレッジ不十分 ────┘
                       (最大2回)
 
-信頼度high達成 → レポート
+カバレッジ十分 → レポート
 ```
 
 **コンテキスト分離**: 各ステップには構造化JSON出力のみを渡す。思考過程は引き継がない。
@@ -94,19 +94,20 @@ Agentツールでinvestigatorを呼び出す:
     影響箇所: [何が壊れたか]
     共通コンポーネント: [原因変更と影響箇所の共通点]
 
-**期待される出力**: 証拠マトリクス、比較分析結果、因果追跡結果、未探索領域のリスト、調査の限界
+**期待される出力**: pathMap（症状ごとの実行パス）、failurePoints（各ノードで発見された障害点）、障害点ごとのimpactAnalysis、未探索領域のリスト、調査の限界
 
 ### ステップ2: 調査品質判定
 
 調査出力を確認：
 
 **品質チェック**（出力JSONに以下が含まれているか）:
-- [ ] `comparisonAnalysis`が存在し、`normalImplementation`がnullでない（比較対象が見つかった）、または「正常動作する実装が見つからなかった」と明示的に記録されている
-- [ ] 各仮説の`causalChain`が停止条件に到達（コード変更で対処可能 / 設計判断レベル / 外部制約）
-- [ ] 各仮説の`causeCategory`が以下のいずれか: typo / logic_error / missing_constraint / design_gap / external_factor
+- [ ] `pathMap`が少なくとも1つの症状を含み、各症状に少なくとも1つのパスとノードが列挙されている
+- [ ] 各障害点に`location`、`upstreamDependency`、`symptomExplained`、`causalChain`（停止条件に到達）、`checkStatus`、具体的なファイルや場所を引用した`source`を持つ`evidence`が含まれている
+- [ ] 各障害点に`comparisonAnalysis`が含まれている（normalImplementationが見つかった、または明示的にnull）
+- [ ] 各障害点の`causeCategory`が以下のいずれか: typo / logic_error / missing_constraint / design_gap / external_factor
 - [ ] `investigationSources`が少なくとも3つの異なるソースタイプ（code, history, dependency, config, document, external）をカバー
 - [ ] ステップ0.4で提供した`investigationFocus`の項目が調査に含まれている
-- [ ] 各仮説の`supportingEvidence`に具体的なファイルや場所を引用した`source`フィールドを持つエントリが最低1つある
+- [ ] マッピングされたパス上の全ノードがチェック済み（最初の障害点発見後にパスが放棄されていない）
 
 **品質不足の場合**: 不足項目を明示してinvestigatorを再実行:
 - `prompt`: |
@@ -135,48 +136,59 @@ Agentツールでverifierを呼び出す:
 - `description`: "調査結果の検証"
 - `prompt`: "以下の調査結果を検証してください。調査結果: [調査のJSON出力]"
 
-**期待される出力**: 代替仮説（最低3つ）、Devil's Advocate評価、最終結論、信頼度
+**期待される出力**: カバレッジチェック（未探索パス、未チェックノード）、障害点ごとのDevil's Advocate評価、finalStatusを含む障害点評価、カバレッジ評価（`coverageAssessment`）
 
-**信頼度の判定基準**:
-- **high**: 解決策の選択・実装に影響する不確実性がない
-- **medium**: 不確実性があるが、追加調査で解消可能
-- **low**: 根本的な情報不足がある
+**カバレッジの判定基準**:
+- **十分（`sufficient`）**: 主要パスが追跡済み、全重要ノードがチェック済み、各障害点が個別に評価済み
+- **部分的（`partial`）**: 主要パスは追跡済みだが、一部ノードが未チェックまたは一部障害点がblocked/not_reached
+- **不十分（`insufficient`）**: 重要なパスが未追跡、または重要ノードが未調査
 
-### ステップ4: 解決策導出（solver）
+### ステップ4: カバレッジゲート
+
+verifierのカバレッジ評価（`coverageAssessment`）を確認:
+
+- **十分** → ステップ5（solver）へ進む
+- **部分的または不十分** → verifierが特定した未チェック領域を調査対象としてステップ1に戻る
+  - 追加調査は最大2回まで
+  - 2回の追加調査後もsufficientに到達しない場合、ユーザーに選択肢を提示：
+    - 追加調査を継続
+    - 現在のカバレッジレベルでsolverに進む（不完全な診断のリスクをユーザーが承認）
+
+### ステップ5: 解決策導出（solver）
+
+**前提**: カバレッジ評価が十分（`coverageAssessment=sufficient`）、または部分的/不十分でのユーザー承認
 
 Agentツールでsolverを呼び出す:
 - `subagent_type`: "solver"
 - `description`: "解決策の導出"
-- `prompt`: "以下の検証済み結論に基づいて、解決策を導出してください。原因: [verifierのconclusion.causes]。原因の関係性: [causesRelationship: independent/dependent/exclusive]。信頼度: [high/medium/low]"
-
-**期待される出力**: 複数の解決策（最低3つ）、トレードオフ分析、推奨案と実装ステップ、残存リスク
+- `prompt`: |
+    以下の検証済み障害点に基づいて、解決策を導出してください。
 
-**完了条件**: 信頼度がhigh
+    確認済み障害点: [verifierのconclusion.confirmedFailurePoints]
+    反証済み障害点: [verifierのconclusion.refutedFailurePoints]
+    障害点の関係性: [verifierのconclusion.failurePointRelationships]
+    影響分析: [investigatorのimpactAnalysis]
+    カバレッジ評価: [sufficient/partial/insufficient]
 
-**未達の場合**:
-1. solverが特定した不確実性を調査対象としてステップ1に戻る
-2. 追加調査は最大2回まで
-3. 2回の追加調査後も未達の場合、ユーザーに選択肢を提示：
-   - 追加調査を継続
-   - 現在の信頼度で解決策を実行
+**期待される出力**: 複数の解決策（最低3つ）、トレードオフ分析、推奨案と実装ステップ、残存リスク
 
-### ステップ5: 最終レポート作成
+### ステップ6: 最終レポート作成
 
-**前提**: 信頼度highを達成している
+**前提**: solver完了（ステップ5）
 
 診断完了後、以下の形式でユーザーに報告：
 
 ```
 ## 診断結果サマリー
 
-### 特定された原因
-[検証結果の原因リスト]
-- 原因の関係性: [independent/dependent/exclusive]
+### 特定された障害点
+[検証結果の確認済み障害点]
+- 障害点ごと: location、symptomExplained、finalStatus
 
 ### 検証プロセス
-- 調査範囲: [調査で確認した範囲]
+- パスカバレッジ: [追跡したパスとチェックしたノード]
 - 追加調査回数: [0/1/2回]
-- 代替仮説数: [検証で生成した数]
+- カバレッジ評価: [sufficient/partial/insufficient]
 
 ### 推奨する解決策
 [解決策導出の推奨案]
@@ -201,9 +213,9 @@ Agentツールでsolverを呼び出す:
 
 ## 完了条件
 
-- [ ] investigatorを実行し、証拠マトリクス・比較分析・因果追跡を取得した
+- [ ] investigatorを実行し、pathMap・failurePoints・impactAnalysisを取得した
 - [ ] 調査品質チェックを行い、不足があれば再実行した
-- [ ] verifierを実行し、信頼度を取得した
+- [ ] verifierを実行し、coverageAssessmentを取得した
 - [ ] solverを実行した
-- [ ] 信頼度highを達成した（または2回の追加調査後にユーザー承認を得た）
+- [ ] coverageAssessment=sufficientを達成した（または2回の追加調査後にユーザー承認を得た）
 - [ ] 最終レポートをユーザーに提示した

package/.claude/commands-ja/front-build.md

@@ -84,10 +84,14 @@ Agentツールでtask-decomposerを呼び出す:
      - `needs_revision` → `requiredFixes`を添えてステップ2に戻る
      - `approved` → ステップ4へ
    - `readyForQualityCheck: true` → ステップ4へ
-4. **quality-fixer-frontend実行**: 全品質チェックと修正を実行
-5. **承認後コミット**: quality-fixer-frontendの`approved: true`確認後 → git commitを実行
-
-**重要**: 全てのサブエージェントレスポンスのstatusフィールドをパースし、4ステップサイクルの対応ブランチを実行。quality-fixer-frontendが`approved: true`を返すまで次のタスクに進まない。
+4. **quality-fixer-frontend実行**: 全品質チェックと修正を実行（レイヤー横断時: レイヤー別エージェントルーティング参照）
+5. **quality-fixer-frontendレスポンスチェック**:
+   - `stub_detected` → `incompleteImplementations[]`の詳細を添えてステップ2に戻す
+   - `blocked` → 停止してユーザーにエスカレーション
+   - `approved` → ステップ6へ
+6. **承認後コミット**: git commitを実行
+
+**重要**: 全てのサブエージェントレスポンスのstatusフィールドをパースし、4ステップサイクルの対応ブランチを実行。quality-fixer-frontendが`approved`を返すまで次のタスクに進まない。
 
 ## サブエージェント呼び出し時の制約
 

package/.claude/commands-ja/front-plan.md

@@ -43,13 +43,19 @@ Agentツールでacceptance-test-generatorを呼び出す:
 - UI Specあり: `prompt: "[パス]のDesign Docからテストスケルトンを生成。UI Specは[ui-specパス]。"`
 - UI Specなし: `prompt: "[パス]のDesign Docからテストスケルトンを生成。"`
 
-統合テストファイルパスとE2Eテストファイルパスを、subagents-orchestration-guideの「acceptance-test-generator → work-planner」セクションに従いwork-plannerに渡す。
+統合テストファイルパス、E2Eテストファイルパス（またはnull）、およびe2eAbsenceReasonを、subagents-orchestration-guideの「acceptance-test-generator → work-planner」セクションに従いwork-plannerに渡す。
 
 ### Step 3: 作業計画書作成
 Agentツールでwork-plannerを呼び出す:
 - `subagent_type`: "work-planner"
 - `description`: "作業計画書作成"
-- `prompt`: "[パス]のDesign Docから作業計画を作成。統合テストファイル: [ステップ2の統合テストパス]。E2Eテストファイル: [ステップ2のE2Eテストパス]。統合テストは各フェーズ実装と同時に作成、E2Eテストは最終フェーズでのみ実行。"
+- ステップ2でテストスケルトンを生成した場合:
+  - `generatedFiles.e2e`がnullでない場合:
+    `prompt`: "[パス]のDesign Docから作業計画を作成。統合テストファイル: [ステップ2の統合テストパス]。E2Eテストファイル: [ステップ2のE2Eテストパス]。統合テストは各フェーズ実装と同時に作成、E2Eテストは最終フェーズでのみ実行。"
+  - `generatedFiles.e2e`がnullの場合:
+    `prompt`: "[パス]のDesign Docから作業計画を作成。統合テストファイル: [ステップ2の統合テストパス]。E2Eテストスケルトンは生成されませんでした（理由: [e2eAbsenceReason]）。統合テストは各フェーズ実装と同時に作成。"
+- テストスケルトンを生成しなかった場合:
+  `prompt`: "[パス]のDesign Docから作業計画を作成。"
 
 - subagents-orchestration-guideのPrompt Construction Ruleに従い追加パラメータを構成
 - 作業計画書をユーザーに提示しレビューを受ける。変更要望があればwork-plannerを修正パラメータで再実行

package/.claude/commands-ja/implement.md

@@ -77,7 +77,10 @@ subagents-orchestration-guideスキルの「自律実行中のタスク管理」
      - `approved` → ステップ3へ
    - それ以外 → ステップ3へ
 3. **quality-fixer実行**: 全品質チェックと修正を実行（レイヤー横断時: レイヤー別エージェントルーティング参照）
-4. **承認後コミット**: `approved: true`確認後 → git commitを実行
+   - `stub_detected` → `incompleteImplementations[]`の詳細を添えてステップ1に戻す
+   - `blocked` → ユーザーにエスカレーション
+   - `approved` → ステップ4へ
+4. **承認後コミット**: `approved`確認後 → git commitを実行
 
 ### Security Review（全タスク完了後）
 
@@ -90,9 +93,10 @@ subagents-orchestration-guideスキルの「自律実行中のタスク管理」
 
 ### テスト情報の伝達
 acceptance-test-generator実行後、work-planner（subagent_type: "work-planner"）呼び出し時には以下を伝達：
-- 生成された統合テストファイルパス
-- 生成されたE2Eテストファイルパス
-- 統合テストは実装と同時、E2Eは全実装後に実行する旨の明示
+- 統合テストファイルパス（`generatedFiles.integration`から取得）
+- E2Eテストファイルパスまたはnull（`generatedFiles.e2e`から取得）
+- E2E不在理由（`e2eAbsenceReason`、E2Eがnullの場合）
+- 統合テストは実装と同時に作成、E2Eテストは全実装完了後に実行（E2Eパスが提供された場合）
 
 ## 実行方法
 

package/.claude/commands-ja/plan.md

@@ -46,7 +46,10 @@ description: 設計書から作業計画書を作成し計画承認を取得
    - `subagent_type`: "work-planner"
    - `description`: "作業計画書作成"
    - ステップ2でテストスケルトンを生成した場合:
-     `prompt`: "[パス]のDesign Docから作業計画を作成。統合テストファイル: [ステップ2の統合テストパス]。E2Eテストファイル: [ステップ2のE2Eテストパス]。統合テストは各フェーズ実装と同時に作成、E2Eテストは最終フェーズでのみ実行。"
+     - `generatedFiles.e2e`がnullでない場合:
+       `prompt`: "[パス]のDesign Docから作業計画を作成。統合テストファイル: [ステップ2の統合テストパス]。E2Eテストファイル: [ステップ2のE2Eテストパス]。統合テストは各フェーズ実装と同時に作成、E2Eテストは最終フェーズでのみ実行。"
+     - `generatedFiles.e2e`がnullの場合:
+       `prompt`: "[パス]のDesign Docから作業計画を作成。統合テストファイル: [ステップ2の統合テストパス]。E2Eテストスケルトンは生成されませんでした（理由: [e2eAbsenceReason]）。統合テストは各フェーズ実装と同時に作成。"
    - テストスケルトンを生成しなかった場合:
      `prompt`: "[パス]のDesign Docから作業計画を作成。"
 

package/.claude/commands-ja/update-doc.md

@@ -121,6 +121,9 @@ prompt: |
   doc_type: design-doc
   document_path: [ステップ1のパス]
   更新されたDesign Docを現在のコードベースに対して検証する。
+
+  検証の重点: 更新されたセクション内のリテラル識別子の参照整合性
+  （パス、エンドポイント、型名、設定キー）に特に注意して検証すること。
 ```
 
 **出力を保存**: `$CODE_VERIFICATION_OUTPUT`