---
generated_at: 2026-03-01 15:45:00
metrics:
  claims_total: 30
  claims_with_evidence: 28
  claims_without_evidence: 2
confidence_derived: 0.93
---

# 根拠レポート：jest-resolve-dependencies

## 本レポートについて

### 目的
本レポートは、生成された設計書・ドキュメントの信頼性を検証し、人間レビュアーが効率的にレビューできるようにすることを目的としています。

### チェック方法
以下の観点でドキュメントの内容（Claim：主張）を検証しています：

1. **根拠の有無確認**：各主張に対して、ソースコード・既存設計書・要件定義書などの根拠（Evidence）が存在するか
2. **根拠との整合性**：主張の内容が根拠と矛盾していないか
3. **網羅性**：参照すべき情報源を適切にカバーしているか

### 信頼度スコアの算出
- **confidence_derived** = 根拠あり件数 / 総主張件数
- 状態「○」：根拠あり、「△」：根拠不足または要確認

### 本レポートの使い方
1. まず「サマリー」で全体の信頼度と優先レビュー項目を確認
2. 「Claims と根拠の対応」で △ の項目を重点的にレビュー
3. 「不足情報」で補完が必要な情報源を確認

---

## 1) サマリー（まず見るところ）
- 総合信頼度（derived）：**0.93**
  - 根拠あり：28 / 30、根拠なし：2
- 優先レビュー（高）
  1. **UT-RSD-024**: 大量データ処理のパフォーマンステストは実装なし
  2. **UT-RSD-025**: 循環依存の明示的なテストケースが既存テストに存在しない

## 2) 参照した情報（Evidence一覧）
> ここに「実在するもの」だけ列挙。抽出フェーズで付けたIDをそのまま出す。

- E-01: `packages/jest-resolve-dependencies/src/index.ts` - DependencyResolverクラス実装（180行）
- E-02: `packages/jest-resolve-dependencies/src/__tests__/dependency_resolver.test.ts` - 既存テストスイート（171行）
- E-03: `packages/jest-resolve-dependencies/package.json` - パッケージ依存関係定義
- E-04: `packages/jest-resolve-dependencies/src/__tests__/__fixtures__/` - テストフィクスチャディレクトリ
- E-05: `packages/jest-snapshot/src/SnapshotResolver.ts` - isSnapshotPath関数定義

## 3) Claims と根拠の対応（レビューの主戦場）
| Claim ID | 主張 | Evidence | 状態 |
|---|---|---|---|
| C-01 | constructor: Resolver, HasteFS, SnapshotResolverが正しく設定される | E-01 (L27-35) | ○ |
| C-02 | resolve: 存在するファイルパスで依存関係解決 | E-01 (L37-103), E-02 (L59-67) | ○ |
| C-03 | resolve: モック依存も解決される | E-01 (L75-98), E-02 (L69-79) | ○ |
| C-04 | resolve: スコープ付きパッケージ解決 | E-02 (L81-88) | ○ |
| C-05 | resolve: optionsパラメータの伝播 | E-01 (L37, L52-56) | ○ |
| C-06 | resolve: コアモジュールスキップ | E-01 (L45-47) | ○ |
| C-07 | resolve: 存在しないパスで空配列返却 | E-02 (L54-57) | ○ |
| C-08 | resolve: getDependenciesがnullで空配列 | E-01 (L38-42) | ○ |
| C-09 | resolve: resolveModule失敗時のフォールバック | E-01 (L51-67), E-02 (L143-156) | ○ |
| C-10 | resolve: 両方失敗でスキップ | E-01 (L57-67), E-02 (L143-156) | ○ |
| C-11 | resolve: getMockModule失敗でも実体返却 | E-02 (L158-170) | ○ |
| C-12 | resolve: 依存0件で空配列 | E-01 (L40-42) | ○ |
| C-13 | resolve: 依存1件で1件配列 | E-01 (L44-102) | ○ |
| C-14 | resolve: __mocks__外は除外 | E-01 (L88-98) | ○ |
| C-15 | resolveInverseModuleMap: 逆依存マップ解決 | E-01 (L105-168), E-02 (L102-110) | ○ |
| C-16 | resolveInverseModuleMap: フィルタ機能 | E-01 (L132), E-02 (L20-25) | ○ |
| C-17 | resolveInverseModuleMap: スナップショット変換 | E-01 (L152-154), E-02 (L125-141), E-05 | ○ |
| C-18 | resolveInverseModuleMap: モック逆依存解決 | E-02 (L112-123) | ○ |
| C-19 | resolveInverseModuleMap: options伝播 | E-01 (L164) | ○ |
| C-20 | resolveInverseModuleMap: 空セットで空配列 | E-01 (L110-112), E-02 (L90-94) | ○ |
| C-21 | resolveInverseModuleMap: 存在しないパスで空配列 | E-02 (L96-100) | ○ |
| C-22 | resolveInverseModuleMap: exists=falseでスキップ | E-01 (L151) | ○ |
| C-23 | resolveInverseModuleMap: 1件パス処理 | E-01 (L110-168) | ○ |
| C-24 | resolveInverseModuleMap: 大量パス処理 | **根拠なし** | △ |
| C-25 | resolveInverseModuleMap: 循環依存処理 | E-01 (L119, L125, L136) - visitedModules | △ |
| C-26 | resolveInverseModuleMap: 重複処理防止 | E-01 (L119, L125, L136) | ○ |
| C-27 | resolveInverse: ファイルパス配列返却 | E-01 (L171-179), E-02 (L102-110) | ○ |
| C-28 | resolveInverse: マップからパス抽出 | E-01 (L176-178) | ○ |
| C-29 | resolveInverse: 空セットで空配列 | E-01 (L171-179), E-02 (L90-94) | ○ |
| C-30 | resolveInverse: 存在しないパスで空配列 | E-02 (L96-100) | ○ |

## 4) 不足情報（Unknown / Missing）
- **大量データ処理（C-24）**: パフォーマンステストは明示的に存在しない。`getAbsoluteFileIterator`を使用した処理は実装されているが、100件以上のパスでのテストは未実施
  - 候補：パフォーマンステストの追加 / 統合テストでの検証 / ベンチマーク
- **循環依存（C-25）**: `visitedModules`による重複チェックは実装されているが、循環依存を明示的にテストするケースは既存テストに存在しない
  - 候補：循環依存フィクスチャの追加 / 既存ロジックの動作確認

## 5) リスクフラグ（レビュー観点）
- 0: 低リスク - DependencyResolverクラスは単一ファイルで完結しており、既存テストカバレッジが高い
- 1: 中リスク - 大量データ処理時のメモリ使用量・パフォーマンスは未検証
- 1: 中リスク - 循環依存時の挙動は実装から推測されるが、明示的なテストなし

## 6) レビュアーチェックリスト（最小）
- [ ] DependencyResolver.resolve()のモック解決ロジック（L75-98）が正しく動作するか確認
- [ ] resolveInverseModuleMap()のcollectModules内部関数（L114-146）の再帰処理が正しいか確認
- [ ] visitedModulesによる循環依存防止が十分か確認
- [ ] 大量ファイル処理時のパフォーマンス要件があれば追加テストを検討
- [ ] isSnapshotPath()との連携が正しく動作するか確認
