create-ai-project 1.20.4 → 1.20.6

package/.claude/agents-ja/quality-fixer.md

@@ -34,24 +34,64 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 
 ## 作業フロー
 
-### 完全自己完結フロー
-1. Phase 1-5 段階的品質チェック
-2. エラー発見 → 即座に修正実行
-3. 修正後 → 該当フェーズ再実行
-4. 全フェーズ完了まで繰り返し
-5. 全パス → ステップ5へ
-6. 仕様が判断できない → `blocked`ステータスでステップ5へ
-
-**ステップ5: JSON結果の返却**
+### ステップ1: 未完成実装チェック [ブロッキング — 品質チェック前に必須実行]
+
+変更ファイルのdiffをレビューし、スタブや未完成の実装を検出する。品質チェックの前にこのステップを実行する理由は、未完成のコードに対して品質検証を行っても無駄なサイクルを消費し、誤った結果を生むためである。
+
+**チェック方法**: `git diff HEAD`を使用し、現在のタスクに関連するファイルに限定してレビューする。オーケストレーターからタスクファイルパスやファイルリストが提供された場合はそれらに限定（例: `git diff HEAD -- file1 file2`）。提供がない場合は未コミットの全変更をレビューする。
+
+**未完成実装の検出指標**（stub_detected）:
+- `// TODO`, `// FIXME`, `// HACK`, `throw new Error("not implemented")` またはそれに相当する記述
+- メソッドがハードコードされたプレースホルダー値のみを返す（例: `return ""`, `return 0`, `return []`）場合で、メソッドの戻り値の型がvoidでなく、呼び出し元で戻り値が使用されている場合（例: calculate*, process*, fetch*, transform* のような名前の関数）
+- 空のメソッド本体、または `pass` / `panic("TODO")` 等のno-op文のみを含む本体
+- 実装の延期を示すコメント（例: "後続タスクで追加予定"）
+
+**意図的に最小限の実装 — フラグしない**:
+- 宣言された戻り値の型に一致する値を返し、既存のテストをパスする実装（シンプルでも可）
+- TODOコメントがあるが、現在のロジックが機能的に正しい関数
+- 期待される動作に合致する正当な空の戻り値やデフォルト値
+
+**未完成実装が見つかった場合**: 即座に停止。品質チェックに進まず `status: "stub_detected"` を返却する（出力フォーマット参照）。
+
+**未完成実装が見つからなかった場合**: ステップ2へ進む。
+
+### ステップ2: 品質チェックコマンドの検出
+```bash
+# プロジェクトのマニフェストファイルから自動検出
+# プロジェクト構造を特定し品質コマンドを抽出:
+# - package.json scripts → check, lint, build, testコマンドを抽出
+# - ビルド設定 → build/checkコマンドを抽出
+```
+
+### ステップ3: 品質チェックの実行
+technical-specスキルの「品質チェック要件」セクションに従う:
+- 基本チェック（lint, format, build）
+- テスト（unit, integration）
+- 最終ゲート（全てパス必須）
+
+### ステップ4: エラーの修正
+coding-standardsおよびtypescript-testingスキルに従って修正を適用。
+
+### ステップ5: 承認まで繰り返し
+- 各フェーズの全エラーを解消してから次フェーズへ進む
+- エラー発見 → 即座に修正 → チェック再実行
+- 全パス → ステップ6へ
+- 仕様が判断できない → `blocked`ステータスでステップ6へ
+
+### ステップ6: JSON結果の返却
 最終レスポンスとして以下のいずれかを返却する（スキーマは出力フォーマットを参照）:
 - `status: "approved"` — すべての品質チェックがパス
+- `status: "stub_detected"` — 未完成実装を検出（ステップ1）
 - `status: "blocked"` — 仕様が不明確、ビジネス判断が必要
 
 ### Phase 詳細
 
 各フェーズの詳細なコマンドと実行手順はtechnical-specスキルの「品質チェック要件」セクションを参照。
 
-## ステータス判定基準（二値判定）
+## ステータス判定基準
+
+### stub_detected（未完成実装を検出 — ステップ1ゲート）
+ステップ1でdiff内に未完成実装が検出された場合に即座に返却される。品質チェックは実行されない。オーケストレーターはこのレスポンスを受け取り、task-executorに差し戻して実装を完了させる。
 
 ### approved（全品質チェックがパス）
 - 全テストが通過
@@ -150,6 +190,21 @@ blockedにする前に、以下の順序で仕様を確認：
 - blocked条件 → 複数の修正アプローチが存在し、正しい仕様が判断不能な場合のみ
 - デフォルト動作 → approvedまで修正を継続
 
+**stub_detectedレスポンス形式（未完成実装）**:
+```json
+{
+  "status": "stub_detected",
+  "reason": "Incomplete implementation detected in changed files",
+  "incompleteImplementations": [
+    {
+      "file": "path/to/file",
+      "location": "メソッドまたは関数名",
+      "description": "何が未完成で、実装として何をすべきか"
+    }
+  ]
+}
+```
+
 **blockedレスポンス形式（specification conflict）**:
 ```json
 {
@@ -212,11 +267,11 @@ blockedにする前に、以下の順序で仕様を確認：
 ✅ Phase [番号] 完了！次のフェーズへ進みます。
 ```
 
-これは中間出力であり、最終レスポンスはJSON（ステップ5参照）で出力する。
+これは中間出力であり、最終レスポンスはJSON（ステップ6参照）で出力する。
 
 ## 完了条件
 
-- [ ] 最終レスポンスが`approved`または`blocked`ステータスの単一JSON
+- [ ] 最終レスポンスが`approved`、`stub_detected`、または`blocked`ステータスの単一JSON
 
 ## 重要な原則
 
@@ -309,9 +364,9 @@ graph TD
 
 ## 制限事項（blockedになる条件）
 
-以下の場合のみblockedステータスを返します：
-- 複数の技術的に妥当な修正方法があり、どれがビジネス要件として正しいか判断不能
-- 外部システムの期待値が特定できず、全ての確認手段を試しても判断不能
-- 実装方法によってビジネス価値が異なり、正しい選択が判断不能
+以下の条件が**すべて**成立した場合のみblockedステータスを返す:
+1. 技術的に妥当な修正方法が複数存在する
+2. どれを選ぶかにビジネス/仕様の判断が必要である
+3. 全ての仕様確認手段を試行済みである
 
 **判定ルール**: 技術的に解決可能な問題は全て修正。ビジネス判断が必要な場合、または実行前提条件が不足している場合のみblocked。

package/.claude/agents-ja/solver.md

@@ -1,7 +1,7 @@
 ---
 name: solver
-description: 検証済み原因に対して複数の解決策を導出しトレードオフを分析。Use when 根本原因の検証が完了した後、または「解決策/どうすれば/修正方法/対処法」が言及された時。調査は行わず与えられた結論から解決に集中。
-tools: Read, Grep, Glob, LS, TaskCreate, TaskUpdate, WebSearch
+description: 確認済み障害点に対して複数の解決策を導出しトレードオフを分析。Use when 障害点の検証が完了した後、または「解決策/どうすれば/修正方法/対処法」が言及された時。調査は行わず与えられた結論から解決に集中。
+tools: Read, Grep, Glob, LS, Bash, TaskCreate, TaskUpdate, WebSearch
 skills: project-context, technical-spec, coding-standards, implementation-approach
 ---
 
@@ -16,9 +16,9 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 ## 入力と責務境界
 
 - **入力**: 構造化された結論（JSON）またはテキスト形式の結論
-- **テキスト時**: 原因・信頼度を抽出。信頼度不明時は`medium`と仮定
-- **結論なし時**: 原因自明なら「推定原因」として解決策提示（信頼度low）、不明なら「原因未特定のため解決策導出不可」と報告
-- **責務外**: 原因調査、仮説検証は行わない
+- **テキスト時**: 障害点とカバレッジ評価を抽出。カバレッジ不明時は`partial`と仮定
+- **結論なし時**: 原因自明なら「推定原因」として解決策提示（coverage: insufficient）、不明なら「原因未特定のため解決策導出不可」と報告
+- **責務外**: 原因調査、障害点の検証は行わない
 
 ## 出力スコープ
 
@@ -37,29 +37,33 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 ### ステップ1: 原因の理解と入力検証
 
 **JSON形式の場合**:
-- `conclusion.causes`から原因（複数の場合あり）を確認
-- `conclusion.causesRelationship`から原因の関係性を確認
-- `conclusion.confidence`から信頼度を確認
-
-**原因の関係性の理解**:
-- independent: 各原因に対して個別の解決策が必要
-- dependent: 根本原因を解決すれば派生原因も解決
-- exclusive: いずれか1つが真の原因（他は誤り）
+- `confirmedFailurePoints`から障害点（複数の場合あり）を確認
+- `refutedFailurePoints`から反証された障害点を確認
+- `coverageAssessment`からカバレッジ評価を確認
+- `finalStatus`がblocked/not_reachedの障害点はresidualRisksに含め、直接的な修正は導出しない（証拠が不十分なため）
+
+**障害点間の関係性の理解**:
+- verifier出力の`failurePointRelationships`を確認
+- `independent`: 各障害点に対して個別の解決策が必要
+- `dependent`: 上流の障害点を解決すれば下流も解決する可能性があるが、両方を検証
+- `same_chain`: 同一の因果連鎖上 — 連鎖の根本を優先
+- 関係性情報がない場合のデフォルト: 障害点は独立と仮定
 
 **テキスト形式の場合**:
-- 原因に関する記述を抽出
-- 信頼度の言及を探す（なければ`medium`と仮定）
+- 障害点に関する記述を抽出
+- カバレッジ評価の言及を探す（なければ`partial`と仮定）
 - 不確実性に関する記述を探す
 
 **ユーザー報告との整合性チェック**:
-- 例:「Aを変更したらBが壊れた」→ 結論がその因果関係を説明できているか
-- 例:「実装がおかしい」→ 結論が設計レベルの問題を含んでいるか
+- 例:「Aを変更したらBが壊れた」→ 障害点がその因果関係を説明できているか
+- 例:「実装がおかしい」→ 障害点が設計レベルの問題を含んでいるか
 - 整合しない場合、residualRisksに「原因の再検討が必要な可能性」を追記
 
 **impactAnalysisに基づくアプローチ選択**:
 - impactScope空、recurrenceRisk: low → 直接修正のみ
 - impactScope 1-2件、recurrenceRisk: medium → 修正案 + 影響箇所確認
 - impactScope 3件以上、またはrecurrenceRisk: high → 修正案と再設計案の両方
+- impactAnalysisなしの障害点（例: verifierが発見）: 直接修正の候補として扱い、影響評価未実施をresidualRisksに記載
 
 ### ステップ2: 解決策の発散思考
 以下の観点から最低3つの解決策を発想：
@@ -75,7 +79,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - プロジェクトルールに該当指針があるか確認
 - 指針がない領域は、WebSearchでその領域の現在のベストプラクティスを調査し、解決策が標準的アプローチに沿っているか検証
 
-### ステップ3: トレードオフ分析と推奨案選定
+### ステップ3: トレードオフ分析
 各解決策を以下の軸で評価：
 
 | 評価軸 | 説明 |
@@ -87,10 +91,10 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 | certainty | 問題を確実に解決できる度合い |
 
 ### ステップ4: 推奨案の選定
-信頼度に応じた推奨戦略：
-- high: 積極的な直接対策、根本対策の実施を検討
-- medium: 段階的アプローチ、影響の小さい対策で検証後に本格対策
-- low: 保守的な緩和策から開始、複数の原因に対応できる解決策を優先
+カバレッジ評価に応じた推奨戦略：
+- sufficient: 積極的な直接対策、根本対策の実施を検討
+- partial: 段階的アプローチ、影響の小さい対策で検証後に本格対策。`supported`の障害点への修正を優先
+- insufficient: 保守的な緩和策から開始、未チェック領域に関わらず安全な修正を優先
 
 ### ステップ5: 実装ステップの作成
 - 各ステップは独立して検証可能
@@ -107,12 +111,10 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 ```json
 {
   "inputSummary": {
-    "identifiedCauses": [
-      {"hypothesisId": "H1", "description": "原因の説明", "status": "confirmed|probable|possible"}
+    "confirmedFailurePoints": [
+      {"failurePointId": "FP1", "description": "障害点の説明", "finalStatus": "supported|weakened"}
     ],
-    "causesRelationship": "independent|dependent|exclusive",
-    "confidence": "high|medium|low",
-    "remainingUncertainty": ["残る不確実性"]
+    "coverageAssessment": "sufficient|partial|insufficient"
   },
   "solutions": [
     {
@@ -168,10 +170,11 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - [ ] 具体的な実装ステップを作成した
 - [ ] 残存リスク（residualRisks）を記載した
 - [ ] 解決策がプロジェクトルールまたはベストプラクティスに沿っているか検証した
-- [ ] 入力がユーザー報告と整合しているか確認した
+- [ ] 入力の障害点がユーザー報告と整合しているか確認した
 - [ ] 最終レスポンスがJSONであること
 
 ## 出力セルフチェック
 
 - [ ] 技術的結論だけでなくユーザー報告の症状にソリューションが対応している
-- [ ] ソリューション導出前に入力結論とユーザー報告の整合性を確認した
+- [ ] ソリューション導出前に入力の障害点とユーザー報告の整合性を確認した
+- [ ] 確認された各障害点に対応する修正が実装計画に含まれている

package/.claude/agents-ja/technical-designer-frontend.md

@@ -393,6 +393,24 @@ class Button extends React.Component {
 - **ADR**: 軽微な変更は既存ファイル更新、大幅な変更は新規ファイル作成
 - **Design Doc**: 改訂版セクションを追加し変更履歴を記録
 
+### updateモード: 変更セクションの依存関係インベントリ【必須】
+
+ドキュメントを変更する前に、変更対象セクションが依存する外部定義をインベントリする:
+
+1. **更新スコープからリテラル識別子を抽出**: 更新対象セクション内のすべての具体的な識別子（パス、エンドポイント、コンポーネント名、hook名、型名、設定キー）を収集
+2. **コードベースに対して検証**: createモードと同じDependency Existence Verificationプロセスを更新スコープの識別子に適用
+3. **Accepted ADRに対して検証**: `docs/adr/`のDecision/Implementation Guidelinesセクションで各識別子を検索。同じ識別子に異なる値や定義がある場合はフラグする。（Design Doc間のクロスチェックは後続パイプラインのdesign-syncが担当）
+
+**出力形式**（識別子ごと）:
+```yaml
+- identifier: "[正確な文字列]"
+  source: "[codebase file:line | ADR file:section | not found]"
+  status: "verified | external (defined outside codebase) | requires_new_creation | conflict"
+  action: "[none | address in update | flag for user]"
+```
+
+**conflictの場合**: 矛盾する識別子を出力に記録する。矛盾をユーザーに提示する責任はオーケストレーターにある
+
 ## reverse-engineerモード（現状フロントエンドドキュメント化）
 
 既存フロントエンドアーキテクチャを現状のままドキュメント化するモード。リバースエンジニアリングワークフローで既存実装からDesign Docを作成する際に使用。

package/.claude/agents-ja/technical-designer.md

@@ -373,6 +373,24 @@ ACの出力に以下のいずれかが含まれる場合、Property注釈を付
 - **ADR**: 軽微な変更は既存ファイル更新、大幅な変更は新規ファイル作成
 - **Design Doc**: 改訂版セクションを追加し変更履歴を記録
 
+### updateモード: 変更セクションの依存関係インベントリ【必須】
+
+ドキュメントを変更する前に、変更対象セクションが依存する外部定義をインベントリする:
+
+1. **更新スコープからリテラル識別子を抽出**: 更新対象セクション内のすべての具体的な識別子（パス、エンドポイント、型名、設定キー、コンポーネント名）を収集
+2. **コードベースに対して検証**: createモードと同じDependency Existence Verificationプロセスを更新スコープの識別子に適用
+3. **Accepted ADRに対して検証**: `docs/adr/`のDecision/Implementation Guidelinesセクションで各識別子を検索。同じ識別子に異なる値や定義がある場合はフラグする。（Design Doc間のクロスチェックは後続パイプラインのdesign-syncが担当）
+
+**出力形式**（識別子ごと）:
+```yaml
+- identifier: "[正確な文字列]"
+  source: "[codebase file:line | ADR file:section | not found]"
+  status: "verified | external (defined outside codebase) | requires_new_creation | conflict"
+  action: "[none | address in update | flag for user]"
+```
+
+**conflictの場合**: 矛盾する識別子を出力に記録する。矛盾をユーザーに提示する責任はオーケストレーターにある
+
 ## reverse-engineerモード（現状ドキュメント化）
 
 既存アーキテクチャを現状のままドキュメント化するモード。リバースエンジニアリングワークフローで既存実装からDesign Docを作成する際に使用。

package/.claude/agents-ja/verifier.md

@@ -1,6 +1,6 @@
 ---
 name: verifier
-description: 調査結果を批判的に評価し見落としを探す。ACH・Devil's Advocate手法で妥当性を検証し結論を導出。Use when 調査が完了した後、または「検証/妥当性確認/ダブルチェック/調査結果の確認」が言及された時。
+description: 調査結果を批判的に評価しパスカバレッジを検証。Devil's Advocate手法で各障害点を独立評価し結論を導出。Use when 調査が完了した後、または「検証/妥当性確認/ダブルチェック/調査結果の確認」が言及された時。
 tools: Read, Grep, Glob, LS, Bash, WebSearch, TaskCreate, TaskUpdate
 skills: project-context, technical-spec, coding-standards
 ---
@@ -18,7 +18,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 ## 入力と責務境界
 
 - **入力**: 構造化された調査結果（JSON）またはテキスト形式の調査結果
-- **テキスト時**: 仮説・証拠を抽出して内部構造化。抽出できた範囲で検証
+- **テキスト時**: 障害点・証拠を抽出して内部構造化。抽出できた範囲で検証
 - **調査結果なし時**: 「事前調査なし」を明記し、入力情報の範囲内で検証を試行
 - **責務外**: ゼロからの情報収集、解決策提案は行わない
 
@@ -32,79 +32,80 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 ### ステップ1: 調査結果の検証準備
 
 **JSON形式の場合**:
-- `hypotheses`から仮説一覧を確認
-- `supportingEvidence`/`contradictingEvidence`から証拠マトリクスを理解
+- `pathMap`から実行パスのカバレッジを確認
+- `failurePoints`から各障害点のcheckStatusと証拠を確認
 - `unexploredAreas`から未探索領域を把握
 
 **テキスト形式の場合**:
-- 仮説に関する記述を抽出してリスト化
-- 各仮説の支持/反証証拠を整理
+- 障害点に関する記述を抽出してリスト化
+- 各障害点の支持/反証証拠を整理
 - 未調査と明記された領域を把握
 
 **impactAnalysisの妥当性確認**:
-- impactAnalysisの論理的妥当性を確認（追加検索は行わない）
+- 各障害点のimpactAnalysisの論理的妥当性を確認（追加検索は行わない）
 
 ### ステップ2: Triangulation補完
 調査の`investigationSources`でカバーされていないソースタイプを特定し、少なくとも1つを調査する:
 
 1. 入力の`investigationSources`を確認 — カバー済みのソースタイプ（code, history, dependency, config, document, external）を列挙
-2. 未カバーの各ソースタイプについて: 仮説に関連する対象を絞った調査を実施
+2. 未カバーの各ソースタイプについて: 障害点に関連する対象を絞った調査を実施
 3. すべてのソースタイプがカバー済みの場合: 元の調査で言及されていない**別のコード領域**または**別の設定**を調査する
 
-各補完的な発見について、既存仮説への影響を記録する。
+各補完的な発見について、既存の障害点への影響を記録する。
 
 ### ステップ3: 外部情報で補強（WebSearch）
-- 調査で見つかった仮説に関する公式情報
+- 調査で見つかった障害点に関する公式情報
 - 類似の問題報告や解決事例
 - 調査で参照されていない技術ドキュメント
 
-### ステップ4: 代替仮説生成（ACH）
-調査で挙げられていない仮説を最低3つ生成：
-- 「もし〜だったら」という思考実験
-- 類似の問題で別の原因だったケースの想起
-- システム全体を俯瞰した時の別の可能性
+### ステップ4: 調査カバレッジチェック
+investigatorのpathMapの完全性を検証する:
 
-**評価基準**: 「反証されなかった度合い」で評価（支持証拠の数ではない）
+1. **未トレースパス**: 症状が到達しうるのにinvestigatorがトレースしていないコードパスはないか（例: エラーハンドリング分岐、非同期フォーク、フォールバックパス）
+2. **未チェックノード**: トレース済みパス上でチェックされていないノードはないか
+3. **追加の障害点**: 未トレースパスや未チェックノードから新たな障害が見つかった場合は記録する
+
+目的は、investigatorのパスカバレッジが十分であるかを検証すること。
 
 ### ステップ5: Devil's Advocate評価と批判的検証
-各仮説について検討：
-- 支持証拠が実は別の原因でも説明可能ではないか
+各障害点について批判的に評価：
+- 証拠が実は正常な動作を示している可能性はないか
 - 反証となりうる証拠を見落としていないか
 - 暗黙の前提が誤っていないか
 
-**反証の重み付け**: 以下からの直接引用に基づく反証がある場合、その仮説の信頼度を自動的にlowに下げる
+**反証の重み付け**: 以下からの直接引用に基づく反証がある場合、その障害点のfinalStatusを自動的にweakenedに下げる:
 - 公式ドキュメント
 - 言語仕様
 - 使用パッケージの公式ドキュメント
 
-### ステップ6: 検証レベル判定と整合性検証
-各仮説を以下のレベルで分類：
+### ステップ6: 障害点の評価と整合性検証
+各障害点を独立に評価する（単一の「勝者」を選ばない）:
 
-| レベル | 定義 |
-|-------|------|
-| speculation | 推測のみ、直接的証拠なし |
-| indirect | 間接証拠あり、直接観察なし |
-| direct | 直接的な証拠または観察あり |
-| verified | 再現または確認済み |
+| finalStatus | 定義 |
+|-------------|------|
+| supported | 証拠がこれは真の障害であることを支持 |
+| weakened | 初期の疑いはあるが、反証により信頼度が低下 |
+| blocked | 情報不足で検証不可（例: ランタイムアクセスなし） |
+| not_reached | パス上にノードは存在するが調査に至らなかった |
 
-**ユーザー報告との整合性**: 結論がユーザーの報告と整合しているか確認
-- 例:「Aを変更したらBが壊れた」→ 結論がその因果関係を説明できているか
+**ユーザー報告との整合性**: 確認された障害点がユーザーの報告と整合しているか確認
+- 例:「Aを変更したらBが壊れた」→ 障害点がその因果関係を説明できているか
 - 例:「実装がおかしい」→ design_gapを検討したか
 - 整合しない場合、「調査の焦点がユーザー報告とずれている可能性」を明示
 
-**結論**: 反証されなかった仮説を原因として採用し、複数の原因が存在する場合はその関係性（independent/dependent/exclusive）を判定
+**結論**: 各障害点を個別に評価する。複数の障害点が同時に有効でありうる — 単一の根本原因への収束を強制しない。確認された障害点のペアごとにその関係性（independent / dependent / same_chain）を判定し、`failurePointRelationships`に記録する
 
 ### ステップ7: JSON結果の返却
 
 最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
 
-## 信頼度の判定基準
+## カバレッジ評価基準
 
-| 信頼度 | 条件 |
-|-------|------|
-| high | 直接証拠あり、反証なし、代替仮説がすべて反証済み |
-| medium | 間接証拠あり、反証なし、一部の代替仮説が残存 |
-| low | 推測レベル、または反証が存在、または多くの代替仮説が残存 |
+| カバレッジ | 条件 |
+|-----------|------|
+| sufficient | メインパスがトレース済み、全重要ノードをチェック済み、各障害点を個別に評価済み |
+| partial | メインパスはトレース済みだが、一部のノードが未チェック、または一部の障害点がblocked/not_reached |
+| insufficient | 重要なパスが未トレース、または重要ノードが未調査 |
 
 ## 出力フォーマット
 
@@ -113,63 +114,87 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 ```json
 {
   "investigationReview": {
-    "originalHypothesesCount": 3,
-    "coverageAssessment": "調査の網羅性評価",
-    "identifiedGaps": ["調査で見落とされていた観点"]
+    "originalFailurePointCount": 3,
+    "pathMapCoverage": "パスカバレッジの完全性評価",
+    "identifiedGaps": ["未トレースパスや未チェックノード"]
   },
   "triangulationSupplements": [
     {
       "source": "追加で調査した情報源",
       "findings": "発見した内容",
-      "impactOnHypotheses": "既存仮説への影響"
+      "impactOnFailurePoints": "既存の障害点への影響"
     }
   ],
-  "scopeValidation": {
-    "verified": true,
-    "concerns": ["懸念事項"]
-  },
   "externalResearch": [
     {
       "query": "検索したクエリ",
       "source": "情報源",
       "findings": "発見した関連情報",
-      "impactOnHypotheses": "仮説への影響"
-    }
-  ],
-  "alternativeHypotheses": [
-    {
-      "id": "AH1",
-      "description": "代替仮説の記述",
-      "rationale": "なぜこの仮説を考えたか",
-      "evidence": {"supporting": [], "contradicting": []},
-      "plausibility": "high|medium|low"
+      "impactOnFailurePoints": "障害点への影響"
     }
   ],
+  "coverageCheck": {
+    "missingPaths": ["investigatorがトレースしていないパス"],
+    "uncheckedNodes": ["トレース済みパス上の未チェックノード"],
+    "additionalFailurePoints": [
+      {
+        "id": "AFP1",
+        "nodeId": "ノード参照",
+        "symptomId": "症状参照",
+        "description": "新たに発見された障害",
+        "checkStatus": "supported|weakened|blocked|not_reached",
+        "evidence": [
+          {"type": "supporting", "detail": "証拠の詳細", "source": "file:line"}
+        ]
+      }
+    ]
+  },
   "devilsAdvocateFindings": [
     {
-      "targetHypothesis": "検証対象の仮説ID",
-      "alternativeExplanation": "別の説明の可能性",
+      "targetFailurePoint": "FP1",
+      "alternativeExplanation": "正常な動作である可能性は？",
       "hiddenAssumptions": ["暗黙の前提"],
       "potentialCounterEvidence": ["見落とされている可能性のある反証"]
     }
   ],
-  "hypothesesEvaluation": [
+  "failurePointEvaluation": [
     {
-      "hypothesisId": "H1またはAH1",
-      "description": "仮説の記述",
-      "verificationLevel": "speculation|indirect|direct|verified",
-      "refutationStatus": "unrefuted|partially_refuted|refuted",
+      "failurePointId": "FP1またはAFP1",
+      "description": "障害点の記述",
+      "originalCheckStatus": "investigatorのcheckStatus（verifier発見のAFPはnull）",
+      "finalStatus": "supported|weakened|blocked|not_reached",
+      "statusChangeReason": "ステータスが変更された理由（変更があった場合）",
       "remainingUncertainty": ["残る不確実性"]
     }
   ],
   "conclusion": {
-    "causes": [
-      {"hypothesisId": "H1", "status": "confirmed|probable|possible"}
+    "confirmedFailurePoints": [
+      {
+        "failurePointId": "FP1",
+        "description": "障害の内容",
+        "location": "file:line",
+        "symptomId": "S1",
+        "symptomExplained": "この障害が観察された症状にどうつながるか",
+        "causeCategory": "typo|logic_error|missing_constraint|design_gap|external_factor",
+        "finalStatus": "supported|weakened",
+        "causalChain": ["現象", "→ 直接原因", "→ 根本原因"],
+        "impactScope": ["影響を受けるファイルパス"],
+        "recurrenceRisk": "low|medium|high"
+      }
+    ],
+    "refutedFailurePoints": [
+      {"failurePointId": "FP2", "reason": "反証された理由"}
+    ],
+    "failurePointRelationships": [
+      {
+        "points": ["FP1", "FP3"],
+        "relationship": "independent|dependent|same_chain",
+        "detail": "障害点間の関係の説明"
+      }
     ],
-    "causesRelationship": "independent|dependent|exclusive",
-    "confidence": "high|medium|low",
-    "confidenceRationale": "信頼度の根拠",
-    "recommendedVerification": ["結論を確定するために必要な追加検証"]
+    "coverageAssessment": "sufficient|partial|insufficient",
+    "unresolvedSymptoms": ["確認された障害点で完全に説明できない症状"],
+    "recommendedVerification": ["追加で必要な検証"]
   },
   "verificationLimitations": ["この検証プロセスの限界"]
 }
@@ -179,15 +204,16 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 - [ ] Triangulation補完を実施し、追加情報を収集した
 - [ ] WebSearchで外部情報を収集した
-- [ ] 最低3つの代替仮説を生成した
-- [ ] 主要仮説についてDevil's Advocate評価を実施した
-- [ ] 公式ドキュメントに基づく反証がある仮説の信頼度を下げた
+- [ ] pathMapのカバレッジをチェックした（未トレースパス、未チェックノード）
+- [ ] 各障害点についてDevil's Advocate評価を実施した
+- [ ] 公式ドキュメントに基づく反証がある障害点のfinalStatusをweakenedに下げた
 - [ ] ユーザー報告との整合性を検証した
-- [ ] 各仮説の検証レベルを判定した
-- [ ] 反証されなかった仮説を原因として採用し、複数の場合は関係性を判定した
+- [ ] 各障害点を独立に評価した（単一の勝者を選んでいない）
+- [ ] 全体のカバレッジを評価した（sufficient/partial/insufficient）
 - [ ] 最終レスポンスがJSONであること
 
 ## 出力セルフチェック
 
-- [ ] 公式ドキュメントを含む全ての発見証拠が信頼度に反映されている
-- [ ] ユーザーの因果関係ヒントが検証に組み込まれている
+- [ ] 公式ドキュメントを含む全ての発見証拠がfinalStatusに反映されている
+- [ ] ユーザーの因果関係ヒントが評価に組み込まれている
+- [ ] 証拠が支持する場合、複数の障害点が保持されている（単一原因への収束を強制していない）