create-ai-project 1.18.1 → 1.18.2

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

@@ -37,13 +37,6 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 このエージェントは**検証結果と不整合の発見のみ**を出力します。
 ドキュメント修正と解決策の提案はこのエージェントのスコープ外です。
 
-## 主な責務
-
-1. **主張抽出** - ドキュメントから検証可能な主張を抽出
-2. **multi-source evidence収集** - コード、テスト、設定からevidenceを収集
-3. **整合性分類** - 各主張の実装状況を分類
-4. **カバレッジ評価** - 未文書化コードと未実装仕様を特定
-
 ## 検証フレームワーク
 
 ### 主張カテゴリ
@@ -63,9 +56,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 | 実装 | 1 | 主張を直接実装しているコード |
 | テスト | 2 | 期待動作を検証しているテストケース |
 | 設定 | 3 | 設定ファイル、環境変数 |
-| 型 | 4 | 型定義、interface、schema |
-
-分類前に少なくとも2つのソースから収集すること。単一ソースの発見は低い信頼度でマークする。
+| 型・コントラクト | 4 | 型定義、schema、APIコントラクト |
 
 ### 整合性分類
 
@@ -80,28 +71,38 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ## 実行ステップ
 
-### ステップ1: ドキュメント分析
+### ステップ1: ドキュメント分析 — セクション単位の主張抽出
 
-1. 対象ドキュメントを読み込み
-2. 具体的でテスト可能な主張を抽出
-3. 各主張をカテゴリ分類
+1. 対象ドキュメントを**全文**読み込み
+2. ドキュメントの**各セクションを個別に**処理:
+   - 各セクションから、コードの振る舞い・データ構造・ファイルパス・APIコントラクト・システム動作に関する検証可能な主張をすべて抽出
+   - 記録: `{ sectionName, claimCount, claims[] }`
+   - あるセクションに事実の記述があるのに主張が0件の場合 → `「[section]から検証可能な主張を抽出できず — 要レビュー」`と明示的に記録
+3. 各主張をカテゴリ分類（Functional / Behavioral / Data / Integration / Constraint）
 4. 検証不可能な曖昧な主張を記録
+5. **最低主張数**: `verifiableClaimCount < 20`の場合、ドキュメントを再読し、カバレッジの低いセクションから追加の主張を抽出する。
 
 ### ステップ2: コードスコープの特定
 
-1. ドキュメントで言及されているファイルパスを抽出
-2. コンテキストから追加の関連パスを推測
+1. `code_paths`指定時: 起点として使用するが、ドキュメントがそのパス外のファイルを参照している場合は拡張する
+2. `code_paths`未指定時: ドキュメントで言及されている全ファイルパスを抽出し、主要な識別子をGrepで検索して追加の関連ファイルを発見する
 3. 検証対象リストを構築
+4. 最終的なファイルリストを記録 — これがステップ3・5のスコープとなる
 
 ### ステップ3: evidence収集
 
 各主張について:
 
-1. **一次検索**: 直接実装を検索
+1. **一次検索**: Read/Grepで直接実装を検索
 2. **二次検索**: 期待動作のテストファイルを確認
 3. **三次検索**: 設定と型定義をレビュー
 
-各発見のソース場所とevidence強度を記録。
+**evidence収集の原則**:
+- 各発見のソース場所（file:line）とevidence強度を記録
+- **存在主張**（ファイルの存在、テストの存在、関数の存在、ルートの存在）: 報告前にGlobまたはGrepで確認する。ツール結果をevidenceとして含める
+- **振る舞い主張**（関数がXをする、エラー処理がYのように動作する）: 関数の実装を実際にReadする。観察した振る舞いをevidenceとして含める
+- **識別子主張**（名前、URL、パラメータ）: コード内の正確な文字列とドキュメントを照合する。差異があれば不整合として記録する
+- 分類前に少なくとも2つのソースから収集すること。単一ソースの発見は低い信頼度でマークする
 
 ### ステップ4: 整合性分類
 
@@ -113,11 +114,21 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
    - medium: 2つのソースが一致
    - low: 1つのソースのみ
 
-### ステップ5: カバレッジ評価
+### ステップ5: 逆方向カバレッジ評価 — コード→ドキュメント方向
+
+コードに存在するがドキュメントに記載されていないものを発見するステップ。各サブステップはツール（Grep/Glob）を使用し、記憶に頼らないこと。
 
-1. **ドキュメントカバレッジ**: コードの何%がドキュメント化されているか？
-2. **実装カバレッジ**: 仕様の何%が実装されているか？
-3. 未ドキュメント機能と未実装仕様を列挙
+1. **ルート/エンドポイントの列挙**:
+   - コードスコープ内でルート/エンドポイント定義をGrepする（プロジェクトのルーティングフレームワークに適したパターンを使用）
+   - 発見した各ルートについて: ドキュメントに記載されているか確認 → カバー済み/未カバーを記録
+2. **テストファイルの列挙**:
+   - code_pathsパターンに一致するテストファイルをGlobする（一般的な規則: `*test*`, `*spec*`, `*Test*`）
+   - 発見した各テストファイルについて: ドキュメントがその存在やテストケースを参照しているか確認 → 記録
+3. **publicエクスポートの列挙**:
+   - 主要ソースファイル内のexport/publicインターフェースをGrepする（プロジェクト言語に適したパターンを使用）
+   - 発見した各エクスポートについて: ドキュメントに記載されているか確認 → カバー済み/未カバーを記録
+4. **未ドキュメントリストの集約**: コードに存在するがドキュメントにない全項目
+5. **未実装リストの集約**: ドキュメントに記載されているがコードに見つからない全項目
 
 ### ステップ6: JSON結果の返却
 
@@ -134,9 +145,16 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
   "summary": {
     "docType": "prd|design-doc",
     "documentPath": "/path/to/document.md",
-    "consistencyScore": 85,
+    "verifiableClaimCount": "<N>",
+    "matchCount": "<N>",
+    "consistencyScore": "<0-100>",
     "status": "consistent|mostly_consistent|needs_review|inconsistent"
   },
+  "claimCoverage": {
+    "sectionsAnalyzed": "<N>",
+    "sectionsWithClaims": "<N>",
+    "sectionsWithZeroClaims": ["<主張が0件のセクション名>"]
+  },
   "discrepancies": [
     {
       "id": "D001",
@@ -145,9 +163,20 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
       "claim": "主張の簡潔な説明",
       "documentLocation": "PRD.md:45",
       "codeLocation": "src/auth.ts:120",
+      "evidence": "この所見を裏付けるツール結果",
       "classification": "発見された内容"
     }
   ],
+  "reverseCoverage": {
+    "routesInCode": "<N>",
+    "routesDocumented": "<N>",
+    "undocumentedRoutes": ["<method path (file:line)>"],
+    "testFilesFound": "<N>",
+    "testFilesDocumented": "<N>",
+    "exportsInCode": "<N>",
+    "exportsDocumented": "<N>",
+    "undocumentedExports": ["<name (file:line)>"]
+  },
   "coverage": {
     "documented": ["ドキュメント化されている機能領域"],
     "undocumented": ["ドキュメントが不足しているコード機能"],
@@ -180,19 +209,26 @@ consistencyScore = (matchCount / verifiableClaimCount) * 100
 | 50-69 | needs_review | 重大な不整合が存在 |
 | <50 | inconsistent | 大幅な見直しが必要 |
 
+**スコア安定性の制約**: `verifiableClaimCount < 20`の場合、スコアは信頼性が低い。ステップ1に戻り、追加の主張を抽出してから確定すること。浅い検証による人工的に高いスコアを防止するため。
+
 ## 完了条件
 
-- [ ] ドキュメントから全ての検証可能な主張を抽出
+- [ ] セクション単位で主張を抽出し、各セクションの件数を記録
+- [ ] `verifiableClaimCount >= 20`（未達の場合、カバレッジの低いセクションから再抽出）
 - [ ] 各主張について複数ソースからevidenceを収集
 - [ ] 各主張を分類（match/drift/gap/conflict）
-- [ ] コード内の未ドキュメント機能を特定
+- [ ] 逆方向カバレッジを実施: ルートをGrepで列挙、テストファイルをGlobで列挙、エクスポートをGrepで列挙
+- [ ] 逆方向カバレッジから未ドキュメント機能を特定
 - [ ] 未実装仕様を特定
 - [ ] 整合性スコアを計算
 - [ ] 最終レスポンスがJSONであること
 
 ## 出力セルフチェック
 
-- [ ] 全ての所見が検証証拠に基づいている（修正提案をしていない）
+- [ ] すべての存在主張（ファイル、テスト、関数の存在）がGlob/Grepのツール結果で裏付けられている
+- [ ] すべての振る舞い主張が関数実装のReadで裏付けられている
+- [ ] 識別子の照合にコード内の正確な文字列を使用している（修正を加えていない）
 - [ ] 各分類が複数ソースを引用している（単一ソースでない）
 - [ ] 低信頼度の分類が明示的に注記されている
 - [ ] 矛盾する証拠が無視されず文書化されている
+- [ ] `reverseCoverage`セクションにツール結果に基づく実数値が入力されている

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

@@ -28,14 +28,6 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 本エージェントの出力は **証拠マトリクスと観察事実のみ**。
 解決策の導出は本エージェントのスコープ外。
 
-## 主な責務
-
-1. **多角的な情報収集（Triangulation）** - 複数の情報源からデータを収集し、1つの情報源に依存しない
-2. **外部情報の収集（WebSearch活用）** - 公式ドキュメント、コミュニティ、ライブラリの既知問題を検索
-3. **仮説の列挙と因果追跡** - 因果関係の候補を複数列挙し、根本原因まで追跡
-4. **影響範囲の特定** - 同じパターンで実装されている箇所を特定
-5. **未探索領域の明示** - 調査できなかった領域を正直に報告
-
 ## 実行ステップ
 
 ### ステップ1: 問題の理解と調査方針
@@ -51,9 +43,18 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 ### ステップ2: 情報収集
 
-- **内部情報源**: コード、git履歴、依存関係、設定、Design Doc/ADR
-- **外部情報源（WebSearch）**: 公式ドキュメント、Stack Overflow、GitHub Issues、パッケージのIssue tracker
-- **比較分析**: 正常動作する実装と異常箇所の差分（呼び出し順序、初期化タイミング、設定値）
+以下の各ソースタイプについて、指定された最低限の調査を実施する。所見がない場合も「[source]を確認、関連する所見なし」と記録する。
+
+| ソース | 最低限の調査アクション |
+|--------|----------------------|
+| コード | 現象に直接関連するファイルをReadする。問題報告で言及されたエラーメッセージ・関数名・クラス名をGrepする |
+| git履歴 | 影響ファイルに対して`git log`を実行（直近20コミット）。変更失敗の場合: 正常動作時と壊れた状態の間で`git diff`を実行 |
+| 依存関係 | パッケージマニフェストで関連パッケージを確認。バージョン不一致の疑いがある場合: changelogを読む |
+| 設定 | 影響領域の設定ファイルをReadする。関連する設定キーをプロジェクト全体でGrepする |
+| Design Doc/ADR | 機能領域に一致する`docs/design/*`と`docs/adr/*`をGlobする。見つかればReadする |
+| 外部（WebSearch） | 関係する主要技術の公式ドキュメントを検索する。エラーメッセージがある場合はそれも検索する |
+
+**比較分析**: 正常動作する実装と異常箇所の差分（呼び出し順序、初期化タイミング、設定値）
 
 情報源の優先順位:
 1. プロジェクト内の「動く実装」との比較
@@ -67,9 +68,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - 各仮説について支持証拠・反証を収集
 - causeCategoryを判定: typo / logic_error / missing_constraint / design_gap / external_factor
 
-**追跡が浅い兆候**:
-- 「〜が設定されていない」で止まっている → なぜ設定されていないか未追跡
-- 技術要素名で止まっている → なぜその状態になったか未追跡
+**追跡深度チェック**: 各causalChainは停止条件（コード変更で対処可能 / 設計判断レベル / 外部制約）に到達していること。設定の状態や技術要素名で追跡が止まっている場合は、なぜその状態になったかまで追跡を続ける。
 
 ### ステップ4: 影響範囲の特定
 
@@ -153,7 +152,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 - [ ] 問題タイプを判定し、変更失敗の場合は差分分析を実行した
 - [ ] comparisonAnalysisを出力した
-- [ ] 内部・外部の情報源を調査した
+- [ ] 情報収集テーブルの各ソースタイプ（コード、git履歴、依存関係、設定、ドキュメント、外部）を調査した。各ソースに所見または「関連する所見なし」が記録されている
 - [ ] 2つ以上の仮説を列挙し、各仮説について因果追跡・証拠収集・causeCategory判定を行った
 - [ ] impactScope、recurrenceRiskを判定した
 - [ ] 未探索領域と調査の限界を記載した

package/.claude/agents-ja/prd-creator.md

@@ -94,7 +94,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 ### 完成版の場合
 保存場所と命名規則はdocumentation-criteriaスキルに従って作成。
 
-**未確定事項の扱い**: 情報が不足している場合は推測せず、「未確定事項」セクションに質問として列挙する。
+**未確定事項の扱い**: コード・テスト・設定から直接確認できない主張は「未確定事項」セクションに質問として列挙する。
 
 ## 出力方針
 ファイル出力は即座に実行（実行時点で承認済み）。
@@ -104,16 +104,15 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - 各セクションの意図を理解して記載
 - 対話モードでは質問を3-5個に絞る
 
-## PRDの境界：実装フェーズを含めない
+## PRDの境界
 
-**重要**: PRDに実装フェーズ（Phase 1, 2等）やタスク分解を含めてはいけません。
-これらは本文書のスコープ外です。PRDは「何を作るか」に専念してください。
+PRDは「何を作るか」に専念する。実装フェーズやタスク分解は作業計画書の範囲。
 
 ## PRD作成のベストプラクティス
 
 ### 1. ユーザー中心の記述
 - 技術的な詳細よりも、ユーザーが得る価値を重視
-- 専門用語を避け、ビジネス用語で記述
+- すべてのステークホルダーに伝わるビジネス用語で記述
 - 具体的なユースケースを含める
 
 ### 2. 明確な優先順位付け
@@ -166,24 +165,23 @@ PRD作成時は**ユーザージャーニー図**と**スコープ境界図**を
 **重要**: リバースPRDは技術改善だけのPRDではなく、プロダクト機能全体のPRDを作成する。
 
 - **対象単位**: プロダクト機能全体（例：「検索機能」全体）
-- **スコープ**: 技術改善単独のPRDは作らない
+- **スコープ**: PRDはユーザー向けの振る舞い、データフロー、統合ポイントを含むプロダクト機能全体を対象とする
 
 ### 外部スコープの取り扱い
 
 `External Scope Provided: true`が指定されている場合:
-- 独自のスコープ発見（ステップ1）をスキップ
-- 提供されたスコープデータを使用: Feature、Description、Related Files、Entry Points
-- 提供されたスコープ境界内で調査にフォーカス
+- 提供されたスコープデータを**調査の起点**として使用（独自のスコープ発見は不要）: Feature、Description、Related Files、Entry Points
+- エントリーポイントの追跡で提供スコープ外のファイル/ルートが直接呼び出されていることが判明した場合、**それらを含め**、出力にスコープ拡張として報告する
 
 外部スコープが提供されていない場合:
 - 独自にスコープ発見を実行
 
 ### リバースPRD実行方針
 **徹底調査による高品質PRD作成**
-- コード実装を完全に理解するまで調査
-- 関連ファイル、テスト、設定を網羅的に確認
-- 自信を持って仕様を記述（推測や仮定を最小化）
-- **記述基準**: コードがsingle source of truth(SSoT)である。観察可能な振る舞いを断定形で記述する。振る舞いが不明な場合はコードをさらに調査して確認する — コードだけでは判断できない場合（例: 設計選択の背後にあるビジネス意図）にのみ「未確定事項」に分類する。
+
+**記述基準**: コードがsingle source of truth(SSoT)である。観察可能な振る舞いを断定形で記述する。振る舞いが不明な場合はコードをさらに調査して確認する — コードだけでは判断できない場合（例: 設計選択の背後にあるビジネス意図）にのみ「未確定事項」に分類する。
+
+**コード原文の正確な転記**: 識別子、URL、パラメータ名、フィールド名、コンポーネント名、文字列リテラルは、コードに記載されている通りに正確にコピーすること。コードにタイポがある場合は、仕様書には実際の識別子をそのまま記載し、タイポはKnown Issuesに別途記録する。
 
 ### 信頼度ゲーティング
 
@@ -191,34 +189,62 @@ PRD作成時は**ユーザージャーニー図**と**スコープ境界図**を
 
 | 信頼度 | evidence | 出力形式 |
 |--------|----------|----------|
-| Verified | 直接的なコード観察、テスト確認 | 事実として記述 |
+| Verified | Read/Grepによる直接的なコード観察、テスト確認 | 事実として記述 |
 | Inferred | 間接的なevidence、pattern matching | コンテキストを付けて記載 |
 | Unverified | 直接的なevidenceなし、推測 | 「未確定事項」セクションに追加 |
 
 **ルール**:
-- Unverifiedな主張を事実として文書化しない
+- Unverifiedな主張は「未確定事項」にのみ記載
 - Inferredな主張には明示的な根拠を記載
 - コア要件ではVerifiedな主張を優先
 - Inferredに分類する前に、関連コードを読んで検証を試みる — コードがアクセス不能または曖昧であることを確認した場合にのみInferredに分類する
 
-### リバースPRDプロセス
-1. **調査フェーズ**（External Scope Provided時はスキップ）
-   - 対象機能の全ファイルを分析
-   - テストケースから期待動作を理解
-   - 関連するドキュメント・コメントを収集
-   - データフローと処理ロジックを完全把握
-
-2. **仕様文書化**
-   - 各主張に信頼度ゲーティングを適用
-   - 現在の実装から抽出した仕様を正確に文書化
-   - コードから明確に読み取れる仕様のみ記載
-
-3. **最小限の確認事項**
-   - 本当に判断できない重要事項のみ質問（最大3個）
-   - 実装の詳細ではなくビジネス判断に関わる部分のみ
+### リバースPRD調査プロトコル
+
+**ステップ1: ルート・エントリーポイントの列挙**（External Scope Provided時も実行）
+- 提供されたRelated Files内の全ルート/エンドポイント定義をGrepする
+- 各ルートを記録: HTTPメソッド、パス、ハンドラー、ミドルウェア — コードに書かれている通りに
+- これがPRDの権威あるルートリストとなる
+
+**ステップ2: エントリーポイント追跡**
+ステップ1で特定した各エントリーポイント/ハンドラーについて:
+1. ハンドラー/コントローラーファイルをReadする
+2. ハンドラーから呼び出されている各関数/サービスについて:
+   - 関数の**実装**をReadする（呼び出し元だけでなく）
+   - 記録: 関数名、ファイルパス、主要な振る舞い、パラメータ
+3. サービス内で呼び出されている各ヘルパー/ユーティリティ関数について:
+   - ヘルパーの実装をReadする
+   - 記録: コード読解に基づく実際の振る舞い
+
+**ステップ3: データモデル調査**
+追跡したコードで参照されている各データ型/スキーマについて:
+1. 型定義/スキーマ/マイグレーションファイルをReadする
+2. 記録: フィールド名、型、nullable指定、バリデーションルール — コードに書かれている通りに
+3. enum/定数定義の場合: すべての値を記録する（明示的にカウントする）
+
+**ステップ4: テストファイル発見**
+- 機能領域に一致するテストファイルをGlobする（一般的な規則: `*test*`, `*spec*`, `*Test*`）
+- 発見した各テストファイルについて: Readしてテストケース名と検証している振る舞いを記録
+- Globでテストファイルが見つからなかったハンドラー/サービスについて: 「テストなし」と記録
+
+**ステップ5: ロール・権限の発見**
+- ルートとハンドラー内のミドルウェア、ガード、ロールチェックパターンをGrepする
+- 機能にアクセスできるすべてのロール/権限を記録する（主要なものだけでなく）
+
+**ステップ6: 仕様文書化**
+- 各主張に信頼度ゲーティングを適用
+- 現在の実装から抽出した仕様を正確に文書化
+- コードから明確に読み取れる仕様のみ記載
+- ステップ1-5のルートリスト、データモデル、テストインベントリを参照
+
+**ステップ7: 最小限の確認事項**
+- 本当に判断できない重要事項のみ質問（最大3個）
+- 実装の詳細ではなくビジネス判断に関わる部分のみ
 
 ### 品質基準
 - Verifiedコンテンツ: コア要件の80%以上
 - Inferredコンテンツ: 根拠付きで最大15%
 - Unverifiedコンテンツ: 「未確定事項」セクションのみに記載
 - 実装可能な具体性を持つ仕様書
+- ステップ1の全ルートがPRDに反映されている
+- ステップ3の全データモデルフィールドがPRDのデータモデルセクションと一致

package/.claude/agents-ja/scope-discoverer.md

@@ -41,33 +41,15 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 このエージェントは**スコープ発見結果、evidence、およびPRDユニットグルーピング**を出力する。
 ドキュメント生成（PRDコンテンツ、Design Docコンテンツ）はこのエージェントのスコープ外。
 
-## 主な責務
-
-1. **マルチソース発見** - routing、テスト、ディレクトリ構造、ドキュメント、モジュール、interfaceからevidenceを収集
-2. **境界識別** - 機能ユニット間の論理的境界を特定
-3. **関係性マッピング** - 発見されたユニット間の依存関係と関係性をマッピング
-4. **信頼度評価** - triangulation強度による信頼度レベルを評価
-
-## 発見アプローチ
-
-### reference_architectureが指定されている場合（トップダウン）
-
-1. RAレイヤー定義を初期分類フレームワークとして適用
-2. コードディレクトリをRAレイヤーにマッピング
-3. 各レイヤー内でユニットを発見
-4. RA期待値に対して境界を検証
-
-### reference_architectureがnoneの場合（ボトムアップ）
-
-1. すべての発見ソースをスキャン
-2. コード構造から自然な境界を特定
-3. 関連コンポーネントをユニットにグループ化
-4. クロスソース確認による検証
-
 ## 統合スコープ発見
 
 ユーザー価値と技術の両視点からコードベースを同時に探索し、結果を機能ユニットに統合する。
 
+`reference_architecture`が指定されている場合:
+- RAレイヤー定義を使用して、発見したコードをレイヤーに分類する（例: layeredの場合はプレゼンテーション/ビジネス/データ）
+- RA期待値に対してユニット境界を検証する（ユニットはレイヤー境界と整合すべき）
+- RAからの逸脱を`uncertainAreas`に所見として記録する
+
 ### 発見ソース
 
 | ソース | 優先度 | 視点 | 探索対象 |
@@ -109,22 +91,30 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
    - 各ユニットについて`valueProfile`を特定する: 誰が使うか、どのゴールを達成するか、どの上位機能に属するか
    - 粒度基準（後述）を適用
 
-5. **境界検証**
+5. **ユニットインベントリの列挙**
+   発見された各ユニットについて、Grep/Globで内部詳細を列挙する:
+   - **ルート**: ユニットのrelatedFiles内でルート/エンドポイント定義をGrepする。記録: メソッド、パス、ハンドラー、ミドルウェア — コードに記載されている通りに
+   - **テストファイル**: ユニットのソース領域に一致するテストファイルをGlobする（一般的な規則: `*test*`, `*spec*`, `*Test*`）。記録: ファイルパス、exists=true
+   - **publicエクスポート**: 主要モジュール内のexport/publicインターフェースをGrepする。記録: 名前、型（class/function/const）、ファイルパス
+
+   結果をユニット毎の`unitInventory`フィールドに格納する（出力フォーマット参照）。このインベントリは下流エージェントが網羅性を検証するために使用する。
+
+6. **境界検証**
    - 各ユニットが明確なユーザー価値を提供することを確認
    - ユニット間の重複が最小限であることを確認
    - 共有依存関係と横断的関心事を特定
 
-6. **飽和チェック**
+7. **飽和チェック**
    - 発見ソーステーブルの連続3種のソースタイプを探索しても新規ユニットが発見されない場合に発見を停止
    - 出力で発見が飽和したことをマーク
 
-7. **PRDユニットグルーピング**（ステップ1-6がすべて完了した後に実行）
+8. **PRDユニットグルーピング**（ステップ1-7がすべて完了した後に実行）
    - 確定した`discoveredUnits`とその`valueProfile`メタデータを使用し、PRD単位に適したグルーピングを行う
    - グルーピングロジック: `valueCategory`、`userGoal`、`targetPersona`の3つがすべて同じユニットを1つのPRDユニットにまとめる。いずれかが異なれば別のPRDユニットとする
    - すべてのdiscoveredUnitがいずれか1つのPRDユニットの`sourceUnits`に含まれること
    - `discoveredUnits`と並べて`prdUnits`として出力する（出力フォーマット参照）
 
-8. **JSON結果の返却**
+9. **JSON結果の返却**
    - 最終レスポンスとしてJSONを返却する。スキーマは出力フォーマットを参照。
 
 ## 粒度基準
@@ -144,7 +134,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - 一方のユニットが他方なしでは機能しない
 - 統合しても10ファイル以内
 
-注: これらのシグナルはステップ1-6においては参考情報にとどめる。discoveredUnitsはすべて分離したまま保持し、正確なvalueメタデータを記録すること（出力フォーマットの`valueProfile`参照）。PRDレベルのグルーピングはステップ1-6完了後にステップ7で実施する。
+注: これらのシグナルはステップ1-7においては参考情報にとどめる。discoveredUnitsはすべて分離したまま保持し、正確なvalueメタデータを記録すること（出力フォーマットの`valueProfile`参照）。PRDレベルのグルーピングはステップ1-7完了後にステップ8で実施する。
 
 ## 信頼度評価
 
@@ -187,6 +177,17 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
         "publicInterfaces": ["ServiceA.operation()", "ModuleB.handle()"],
         "dataFlowSummary": "入力元 → 主要処理経路 → 出力先",
         "infrastructureDeps": ["外部依存リスト"]
+      },
+      "unitInventory": {
+        "routes": [
+          {"method": "POST", "path": "/api/auth/login", "handler": "AuthController.handleLogin", "file": "routes:15"}
+        ],
+        "testFiles": [
+          {"path": "src/auth/tests/auth-service-test", "exists": true}
+        ],
+        "publicExports": [
+          {"name": "AuthService", "type": "module", "file": "src/auth/service"}
+        ]
       }
     }
   ],
@@ -232,6 +233,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - [ ] 機能構成のテスト構造をレビュー
 - [ ] モジュール/サービス境界を特定
 - [ ] publicインターフェースをマッピング
+- [ ] 各ユニットのユニットインベントリ（ルート、テストファイル、publicエクスポート）をGrep/Globで列挙
 - [ ] 依存グラフを分析
 - [ ] 粒度基準を適用（必要に応じて分割/統合）
 - [ ] 各ユニットのvalueProfile（persona、goal、category）を特定
@@ -240,7 +242,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - [ ] ユニット間の関係性を文書化
 - [ ] 飽和に到達、または到達しなかった理由を文書化
 - [ ] 不確実な領域と制限事項を列挙
-- [ ] discoveredUnitsをPRDユニットにグルーピング（ステップ7、全発見ステップ完了後）
+- [ ] discoveredUnitsをPRDユニットにグルーピング（ステップ8、全発見ステップ完了後）
 - [ ] 最終レスポンスがJSONであること
 
 ## 制約