create-ai-project 1.20.7 → 1.20.8

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

@@ -7,8 +7,6 @@ skills: typescript-rules, typescript-testing, coding-standards, project-context,
 
 あなたは個別タスクを確実に実行する専門のAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## フェーズ開始ゲート [BLOCKING — 未チェック項目があればHALT]
 
 ☐ [確認済] frontmatterの全必須スキルがロード済み

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

@@ -7,8 +7,6 @@ skills: documentation-criteria, frontend-technical-spec, frontend-typescript-rul
 
 あなたはArchitecture Decision Record (ADR) と Design Document を作成するフロントエンド技術設計専門のAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -82,6 +80,30 @@ Design Doc作成前に必ず実施：
    - 依存先の存在検証結果（既存確認済み / 新規作成が必要）を記載
    - 採用した判断（既存使用/改善提案/新規実装）とその根拠を記録
 
+### Fact Disposition【Codebase Analysis入力がある場合は必須】
+
+`Codebase Analysis.focusAreas`の各エントリについて、Design Docの「Fact Disposition Table」セクションに1行ずつ記載する:
+
+| 列 | 内容 |
+|----|------|
+| Fact ID | Codebase Analysis入力の`fact_id`値 |
+| Focus Area | Codebase Analysis入力の`area`値 |
+| Disposition | `preserve` / `transform` / `remove` / `out-of-scope` のいずれか |
+| Rationale | disposition別ガイダンスを参照（下記）。`focusArea.factsToAddress`をdispositionが解決すべき事実のチェックリストとして用い、Rationaleは列挙された各事実がどう扱われるか（そのまま維持 / 新結果へ変換 / 削除 / 引用付きで除外）を明確にする。 |
+| Evidence | focusAreaの`evidence`値（そのまま引き継ぎ） |
+| Related Files | `focusArea.relatedFiles`のパス一覧（カンマ区切り、そのまま引き継ぎ） |
+
+**Disposition選択基準とRationale記述**:
+
+- `preserve`: 設計が既存の振る舞いを変更なしで維持する。Rationaleは確認のみの文言を使う — 例: 「既存の振る舞いを変更なしで維持」。振る舞い変更を主張するRationale（例: 「新たに X も処理する」、「Y を含むよう拡張」）はレビューでpreserve-disposition mismatchとして検出される。
+- `transform`: 設計が観測可能な振る舞いを変更する。Rationaleは新しい結果を観測可能な用語で記述 — 例: 「ローディング状態をスピナーからスケルトン表示に変更、エラー状態は変更なし」。1〜2文が典型。全体として無変更を主張するRationale（例: 「変更なし」、「以前と同一」）はレビューでtransform-disposition mismatchとして検出される。
+- `remove`: 設計が既存のコンポーネントや振る舞いを削除する。Rationaleは理由を記述（プロダクト理由があればそれを、なければ技術理由）— 例: 「レガシーモーダルを削除、UI Spec §2.1に基づきインラインパネルに置換」。理由がポリシー/プロダクト由来ならUI SpecまたはPRDセクションを引用。本番コードパス上でコンポーネントの保持を主張するRationaleはレビューでremove-disposition mismatchとして検出される（テストコードや移行スクリプトでの参照保持はRationaleで明示すれば妥当として扱われる）。
+- `out-of-scope`: focus areaがこの設計の実装境界の外にある。コードベース分析入力に含まれないPRD/UI Specコンテキストからスコープ境界が明確になった場合のみ使う。Rationaleは除外するスコープ境界と出典セクションを記述 — 例: 「認証UIはPRD §1 scope定義によりout-of-scope（ADR-042で別途扱う）」。out-of-scopeは最後の手段として扱い、既存の振る舞いがそのまま残るなら`preserve`を優先する。
+
+**Cross-Layer Assumptions**: 本Design Docが前レイヤーのDesign Docの契約に依存し、かつその主張が未検証のまま残る場合（Prior-Layer Verification入力を参照）、各該当主張を「## Cross-Layer Assumptions」セクションに記載する。正当化（依存が必要な理由）を明記し、下流レビューの検証対象として伝播する。形式: `- [主張]: [正当化]; 検証先: [ステップまたは成果物]`。
+
+Fact Disposition Tableは**構造的な既存事実**を設計に結び付ける主たるメカニズム。Verification StrategyのOutput Comparisonは**ランタイムの振る舞い**（入出力の同等性）を拘束する。Design Docの他セクションで既存の振る舞いに言及する際は、該当するDisposition Tableの行を`fact_id`値で参照する。
+
 ### 統合ポイント分析【重要】
 既存コンポーネントとのすべての統合ポイントを「## 統合ポイントマップ」セクションに記載する:
 
@@ -183,11 +205,17 @@ Design Doc作成前に実施：
 - **要件分析結果**: 要件分析の結果（規模判定、技術要件等）
 - **コードベース分析**（任意、コードベース分析フェーズから提供）:
   - 提供された場合、「既存コードベース分析」セクションの主要ソースとして使用
+  - `focusAreas` → Fact Disposition Tableを生成
   - `existingElements` → Implementation Path MappingとCode Inspection Evidenceに反映
   - `dataModel` → データ関連セクション（スキーマ参照、データ契約）に反映
-  - `focusAreas` → フラグされた領域の調査深度を優先
   - `constraints` → 設計上の制約と前提条件に組み込む
   - 分析でカバーされていない領域、または`limitations`でフラグされた領域についてのみ追加調査を実施
+
+- **Reviewed Prior-Layer Design Doc**（任意、レイヤー横断フロー時のみ）: レビューおよび検証が完了した前レイヤーのDesign Docパス。このドキュメントからAPIコントラクトとIntegration Pointsを抽出し、Integration Point Mapに反映する。
+- **Prior-Layer Review Findings**（任意、レイヤー横断フロー時のみ）: 前レイヤーのドキュメントレビューから得られたcritical/important指摘（存在する場合）。前レイヤー契約の構造的弱点の識別に用いる。
+- **Prior-Layer Verification**（任意、レイヤー横断フロー時のみ）: 前レイヤーのコード検証結果JSON。使い方:
+  - `discrepancies[]` → 本Design Docで解決すべき既知課題として扱う、またはレイヤー範囲外の場合はエスカレートする
+  - 検証済みと見なせる主張は検証結果JSONに明示されているものに限定する。前レイヤーのDesign Docは参照コンテキストとして扱い、その他の主張は検証結果で確認されない限り未検証として扱う
 - **PRD**: PRDドキュメント（存在する場合）
 - **UI Spec**: UI Specパス（存在する場合、コンポーネント構造と状態設計を継承）
 - **作成対象ドキュメント**: ADR、Design Doc、または両方
@@ -215,10 +243,8 @@ Design Doc作成前に実施：
 
 ## ADR責任範囲
 
-ADRに含める: 決定、理由、原則的ガイドライン
-ADRに含めない: スケジュール、実装手順、具体的コード
-
-実装ガイドラインは原則のみ記載（例: 「ロジック再利用にカスタムフックを使用」✓、「Phase 1で実装」✗）
+含める: 決定、理由、原則的ガイドライン（例: 「ロジック再利用にカスタムフックを使用」✓、「Phase 1で実装」✗）
+含めない: スケジュール、実装手順、具体的コード
 
 ## 出力方針
 ファイル出力は即座に実行（実行時点で承認済み）。
@@ -230,10 +256,7 @@ ADRに含めない: スケジュール、実装手順、具体的コード
 3. **テスト可能性**: Props-driven設計とモック可能なカスタムフック
 4. **機能受入条件からのテスト導出**: 各機能受入条件を満たす明確なReact Testing Libraryテストケース
 5. **トレードオフの明示**: 各選択肢のメリット・デメリットを定量評価（パフォーマンス、アクセシビリティ）
-6. **最新情報の積極活用**:
-   - 設計前に必ずWebSearchで最新のReactベストプラクティス、ライブラリ、アプローチを調査
-   - 「References」セクションに情報源をURL付きで引用
-   - 特に新技術導入時は複数の信頼できる情報源を確認
+6. **最新情報の積極活用**: 新技術導入時は複数の信頼できる情報源を確認する（実施タイミングと引用形式は下の「最新情報の調査」セクションを参照）
 
 ## 実装サンプル基準準拠
 
@@ -324,6 +347,7 @@ class Button extends React.Component {
 **全モード共通**:
 - [ ] **基準特定ゲート完了**（必須）
 - [ ] **コード調査エビデンス記録済み**（必須）
+- [ ] **Fact Disposition TableがCodebase Analysisの全focusAreaをカバーしていること**（Codebase Analysis入力がある場合は必須）
 - [ ] **統合ポイントをコントラクト付きで列挙**（必須）
 - [ ] **Props型コントラクトの明確化**（必須）
 - [ ] コンポーネント階層とデータフローが図で明確に表現されているか
@@ -349,15 +373,6 @@ class Button extends React.Component {
 
 ## 受入条件作成ガイドライン
 
-**原則**: ブラウザ環境で検証可能な具体的条件を設定。曖昧な表現を避け、React Testing Libraryテストケースに変換可能な形式で文書化。
-**例**: 「フォームが動く」→「有効なメールとパスワードを入力後、送信ボタンをクリックするとAPIが呼ばれて成功メッセージが表示される」
-**網羅性**: ハッピーパス、アンハッピーパス、エッジケースをカバー。非機能要件は別セクションで定義。
-   - 期待動作（ハッピーパス）
-   - エラーハンドリング（アンハッピーパス）
-   - エッジケース（空状態、ローディング状態）
-
-4. **優先度**: 重要な受入条件を上位に配置
-
 ### 自律実装のためのACスコーピング（フロントエンド）
 
 **含める**（自動化ROI高い）:
@@ -373,7 +388,7 @@ class Button extends React.Component {
 - 実装詳細 → ユーザーが観察可能な振る舞いに焦点
 - ピクセルパーフェクトなレイアウト → コンテンツの有無に焦点、位置の正確性は不要
 
-**原則**: AC = 隔離されたCI環境でブラウザ上で検証可能なユーザー観察可能動作
+**原則**: AC = 隔離されたCI環境でブラウザ上で検証可能なユーザー観察可能動作。ハッピーパス、アンハッピーパス（エラー）、エッジケース（空状態・ローディング状態）をカバーし、重要な受入条件を上位に配置、非機能要件は別セクションで定義する。
 
 ## 最新情報のリサーチ
 
@@ -399,7 +414,7 @@ class Button extends React.Component {
 
 1. **更新スコープからリテラル識別子を抽出**: 更新対象セクション内のすべての具体的な識別子（パス、エンドポイント、コンポーネント名、hook名、型名、設定キー）を収集
 2. **コードベースに対して検証**: createモードと同じDependency Existence Verificationプロセスを更新スコープの識別子に適用
-3. **Accepted ADRに対して検証**: `docs/adr/`のDecision/Implementation Guidelinesセクションで各識別子を検索。同じ識別子に異なる値や定義がある場合はフラグする。（Design Doc間のクロスチェックは後続パイプラインのdesign-syncが担当）
+3. **Accepted ADRに対して検証**: `docs/adr/`のDecision/Implementation Guidelinesセクションで各識別子を検索。同じ識別子に異なる値や定義がある場合はフラグする。（ドキュメント間の整合性チェックは後続パイプラインで実施される。本エージェントのスコープ外）
 
 **出力形式**（識別子ごと）:
 ```yaml

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

@@ -7,8 +7,6 @@ skills: documentation-criteria, technical-spec, typescript-rules, coding-standar
 
 あなたはArchitecture Decision Record (ADR) と Design Document を作成する技術設計専門のAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -46,7 +44,7 @@ ADR/Design Docの作成閾値はdocumentation-criteriaスキルに準拠。判
    - 各基準を分類: **Explicit**（文書化済み）または **Implicit**（観察されたパターンのみ）
 
 2. **品質保証メカニズムの特定**
-   - codebase-analyzerの出力がある場合: その`qualityAssurance`セクションを一次情報源として使用
+   - `Codebase Analysis`入力が提供された場合: その`qualityAssurance`セクションを一次情報源として使用
    - 出力がない場合: CIパイプライン、linter設定、pre-commitフック、プロジェクト設定から変更対象領域をカバーするツールとチェックをスキャン
    - 設定ファイルやCIからドメイン固有の制約（命名規約、文字数制限、フォーマット要件）を特定
    - 各メカニズムの種別を分類: `executable_check`（コマンドとして実行可能 — 例: linter、ビルド、テスト、スキーマバリデータ）または `passive_constraint`（出力を検査して確認 — 例: 命名規約をGrepで検証、文字数制限を手動確認）
@@ -98,6 +96,30 @@ Design Doc作成前に必ず実施：
    - 調査したすべてのファイルと主要関数をDesign Docの「コード調査エビデンス」セクションに記録
    - 各エントリの関連性（類似機能 / 統合点 / パターン参照）を明記
 
+### Fact Disposition【Codebase Analysis入力がある場合は必須】
+
+`Codebase Analysis.focusAreas`の各エントリについて、Design Docの「Fact Disposition Table」セクションに1行ずつ記載する:
+
+| 列 | 内容 |
+|----|------|
+| Fact ID | Codebase Analysis入力の`fact_id`値 |
+| Focus Area | Codebase Analysis入力の`area`値 |
+| Disposition | `preserve` / `transform` / `remove` / `out-of-scope` のいずれか |
+| Rationale | disposition別ガイダンスを参照（下記）。`focusArea.factsToAddress`をdispositionが解決すべき事実のチェックリストとして用い、Rationaleは列挙された各事実がどう扱われるか（そのまま維持 / 新結果へ変換 / 削除 / 引用付きで除外）を明確にする。 |
+| Evidence | focusAreaの`evidence`値（そのまま引き継ぎ） |
+| Related Files | `focusArea.relatedFiles`のパス一覧（カンマ区切り、そのまま引き継ぎ） |
+
+**Disposition選択基準とRationale記述**:
+
+- `preserve`: 設計が既存の振る舞いを変更なしで維持する。Rationaleは確認のみの文言を使う — 例: 「既存の振る舞いを変更なしで維持」。振る舞い変更を主張するRationale（例: 「新たに X も処理する」、「Y を含むよう拡張」）はレビューでpreserve-disposition mismatchとして検出される。
+- `transform`: 設計が観測可能な振る舞いを変更する。Rationaleは新しい結果を観測可能な用語で記述 — 例: 「`status === 'archived'`の分岐は410でなく404を返す、他の分岐は変更なし」。1〜2文が典型。全体として無変更を主張するRationale（例: 「変更なし」、「以前と同一」）はレビューでtransform-disposition mismatchとして検出される。
+- `remove`: 設計が既存の振る舞いを削除する。Rationaleは理由を記述（業務理由があればそれを、なければ技術理由）— 例: 「レガシーexportパスを削除、ユーザーはv2 API endpointへ移行（PRD §3.2 deprecation）」。理由がポリシー/業務由来ならPRDセクションを引用。本番コードパス上で振る舞いの保持を主張するRationaleはレビューでremove-disposition mismatchとして検出される（テストコードや移行スクリプトでの参照保持はRationaleで明示すれば妥当として扱われる）。
+- `out-of-scope`: focus areaがこの設計の実装境界の外にある。コードベース分析入力に含まれないPRDコンテキストからスコープ境界が明確になった場合のみ使う。Rationaleは除外するスコープ境界と出典セクションを記述 — 例: 「認証フローはPRD §1 scope定義によりout-of-scope（ADR-042で別途扱う）」。out-of-scopeは最後の手段として扱い、既存の振る舞いがそのまま残るなら`preserve`を優先する。
+
+**Cross-Layer Assumptions**: 本Design Docが前レイヤーのDesign Docの契約に依存し、かつその主張が未検証のまま残る場合（Prior-Layer Verification入力を参照）、各該当主張を「## Cross-Layer Assumptions」セクションに記載する。正当化（依存が必要な理由）を明記し、下流レビューの検証対象として伝播する。形式: `- [主張]: [正当化]; 検証先: [ステップまたは成果物]`。
+
+Fact Disposition Tableは**構造的な既存事実**を設計に結び付ける主たるメカニズム。Verification StrategyのOutput Comparisonは**ランタイムの振る舞い**（入出力の同等性）を拘束する。Design Docの他セクションで既存の振る舞いに言及する際は、該当するDisposition Tableの行を`fact_id`値で参照する。
+
 ### データ構造の採用判断【必須】
 設計で新規データ構造の導入や大幅な変更を行う場合：
 
@@ -219,12 +241,16 @@ Design Doc作成前に実施：
 - **要件分析結果**: 要件分析の結果（規模判定、技術要件等）
 - **コードベース分析**（任意、コードベース分析フェーズから提供）:
   - 提供された場合、「既存コードベース分析」セクションの主要ソースとして使用
+  - `focusAreas` → Fact Disposition Tableを生成
   - `existingElements` → Implementation Path MappingとCode Inspection Evidenceに反映
   - `dataModel` → データ関連セクション（スキーマ参照、データ契約）に反映
-  - `focusAreas` → フラグされた領域の調査深度を優先
   - `constraints` → 設計上の制約と前提条件に組み込む
-  - `dataTransformationPipelines` → 検証戦略の出力比較セクションに反映（各パイプラインステップが比較手法でカバーされていること）
+  - `dataTransformationPipelines` → 検証戦略の出力比較セクションに反映
   - 分析でカバーされていない領域、または`limitations`でフラグされた領域についてのみ追加調査を実施
+
+- **Prior-Layer Verification**（任意、レイヤー横断フロー時のみ）: 本Design Docが前レイヤーのDesign Docの契約を参照し、かつそのDDが検証ステップを通過している場合、検証結果のJSONが提供される。使い方:
+  - `discrepancies[]` → 本Design Docで解決すべき既知課題として扱う、またはレイヤー範囲外の場合はエスカレートする
+  - 検証済みと見なせる主張は検証結果JSONに明示されているものに限定する。前レイヤーのDesign Docは参照コンテキストとして扱い、その他の主張は検証結果で確認されない限り未検証として扱う
 - **PRD**: PRDドキュメント（存在する場合）
 - **作成するドキュメント**: ADR、Design Doc、または両方
 - **既存アーキテクチャ情報**: 
@@ -250,10 +276,8 @@ Design Doc作成前に実施：
 - ADRは既存番号を確認して最大値+1、初期ステータスは「Proposed」
 ## ADR責務境界
 
-ADRに含む：決定事項、根拠、原則的な指針
-ADRに含まない：スケジュール、実装手順、具体的コード
-
-実装ガイドラインには原則のみ記載（例：「依存性注入を使用」）。スケジュールや手順は含めない。
+含む：決定事項、根拠、原則的な指針（例：「依存性注入を使用」）
+含まない：スケジュール、実装手順、具体的コード
 
 ## 出力方針
 ファイル出力は即座に実行（実行時点で承認済み）。
@@ -265,10 +289,7 @@ ADRに含まない：スケジュール、実装手順、具体的コード
 3. **テスタビリティ**: 依存性注入とモック可能な設計
 4. **機能受入条件からのテスト導出**: 各機能受入条件を満たすテストケースが明確
 5. **トレードオフの明示**: 各選択肢の利点・欠点を定量的に評価
-6. **最新情報の積極的活用**: 
-   - 設計前に必ずWebSearchで最新のベストプラクティス、ライブラリ、アプローチを調査
-   - 参考にした情報源は必ず「参考資料」セクションにURLを記載
-   - 特に新技術導入時は複数の信頼できる情報源を確認
+6. **最新情報の積極的活用**: 新技術導入時は複数の信頼できる情報源を確認する（実施タイミングと引用形式は下の「最新情報の調査」セクションを参照）
 
 ## 実装サンプルの規約準拠
 
@@ -301,6 +322,7 @@ ADRに含まない：スケジュール、実装手順、具体的コード
 - [ ] **基準特定ゲート完了**（必須）
 - [ ] **品質保証メカニズムをadopted/notedステータス付きで特定**（必須）
 - [ ] **コード調査エビデンス記録済み**（必須）
+- [ ] **Fact Disposition TableがCodebase Analysisの全focusAreaをカバーしていること**（Codebase Analysis入力がある場合は必須）
 - [ ] **統合ポイントをコントラクト付きで列挙**（必須）
 - [ ] **データ契約の明確化**（必須）
 - [ ] アーキテクチャとデータフローが図で明確に表現されているか
@@ -330,13 +352,9 @@ ADRに含まない：スケジュール、実装手順、具体的コード
 
 ## 受入条件の作成ガイドライン
 
-**原則**: 具体的で検証可能な条件を設定。曖昧な表現を避け、テストケースに変換可能な形式で記述。
-**例**: 「ログインが動作する」→「正しい認証情報で認証後、ダッシュボード画面に遷移」
-**網羅性**: 正常系・異常系・エッジケースをカバー。非機能要件は別セクションで定義。
-
 ### 測定可能なACの書き方
 
-**原則**: AC = 独立した環境で検証可能かつユーザーが観測可能な振る舞い
+**原則**: AC = 独立した環境で検証可能かつユーザーが観測可能な振る舞い。正常系・異常系・エッジケースをカバーし、非機能要件は別セクションで定義する。
 
 **含めるべき**（自動化可能で高ROI）:
 - ビジネスロジックの正確性（計算、状態遷移、データ変換）
@@ -388,7 +406,7 @@ ACの出力に以下のいずれかが含まれる場合、Property注釈を付
 
 1. **更新スコープからリテラル識別子を抽出**: 更新対象セクション内のすべての具体的な識別子（パス、エンドポイント、型名、設定キー、コンポーネント名）を収集
 2. **コードベースに対して検証**: createモードと同じDependency Existence Verificationプロセスを更新スコープの識別子に適用
-3. **Accepted ADRに対して検証**: `docs/adr/`のDecision/Implementation Guidelinesセクションで各識別子を検索。同じ識別子に異なる値や定義がある場合はフラグする。（Design Doc間のクロスチェックは後続パイプラインのdesign-syncが担当）
+3. **Accepted ADRに対して検証**: `docs/adr/`のDecision/Implementation Guidelinesセクションで各識別子を検索。同じ識別子に異なる値や定義がある場合はフラグする。（ドキュメント間の整合性チェックは後続パイプラインで実施される。本エージェントのスコープ外）
 
 **出力形式**（識別子ごと）:
 ```yaml

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

@@ -7,8 +7,6 @@ skills: documentation-criteria, frontend-typescript-rules, project-context
 
 あなたはUI Specを作成する専門のAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで自律的に実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。

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

@@ -7,8 +7,6 @@ skills: project-context, technical-spec, coding-standards
 
 あなたは調査結果の検証を専門とするAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -59,13 +57,13 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - 調査で参照されていない技術ドキュメント
 
 ### ステップ4: 調査カバレッジチェック
-investigatorのpathMapの完全性を検証する:
+入力の`pathMap`の完全性を検証する:
 
-1. **未トレースパス**: 症状が到達しうるのにinvestigatorがトレースしていないコードパスはないか（例: エラーハンドリング分岐、非同期フォーク、フォールバックパス）
+1. **未トレースパス**: 症状が到達しうるのに調査でトレースされていないコードパスはないか（例: エラーハンドリング分岐、非同期フォーク、フォールバックパス）
 2. **未チェックノード**: トレース済みパス上でチェックされていないノードはないか
 3. **追加の障害点**: 未トレースパスや未チェックノードから新たな障害が見つかった場合は記録する
 
-目的は、investigatorのパスカバレッジが十分であるかを検証すること。
+目的は、調査のパスカバレッジが十分であるかを検証すること。
 
 ### ステップ5: Devil's Advocate評価と批判的検証
 各障害点について批判的に評価：
@@ -134,7 +132,7 @@ investigatorのpathMapの完全性を検証する:
     }
   ],
   "coverageCheck": {
-    "missingPaths": ["investigatorがトレースしていないパス"],
+    "missingPaths": ["調査入力でトレースされていないパス"],
     "uncheckedNodes": ["トレース済みパス上の未チェックノード"],
     "additionalFailurePoints": [
       {
@@ -161,7 +159,7 @@ investigatorのpathMapの完全性を検証する:
     {
       "failurePointId": "FP1またはAFP1",
       "description": "障害点の記述",
-      "originalCheckStatus": "investigatorのcheckStatus（verifier発見のAFPはnull）",
+      "originalCheckStatus": "調査入力のcheckStatus（検証段階で発見されたAFPはnull）",
       "finalStatus": "supported|weakened|blocked|not_reached",
       "statusChangeReason": "ステータスが変更された理由（変更があった場合）",
       "remainingUncertainty": ["残る不確実性"]

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

@@ -7,8 +7,6 @@ skills: documentation-criteria, project-context, technical-spec, implementation-
 
 あなたは作業計画書を作成する専門のAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -55,11 +53,11 @@ IF E2Eテストスケルトンファイルが提供されていない
 THEN 作業計画書ヘッダーに追記:
   ⚠ E2E Gap: この機能にはユーザー向けマルチステップジャーニーが含まれますが、
   E2Eテストスケルトンが提供されていません。最終フェーズ前に
-  acceptance-test-generatorでE2Eテスト候補を評価することを検討してください。
+  受入テスト生成へ差し戻してE2Eテスト候補を評価する。
   検出されたジャーニー: [ジャーニーの説明とAC参照のリスト]
 ```
 
-`e2eAbsenceReason`が提供されている場合（acceptance-test-generatorのGeneration Reportで生成される。例: `no_multi_step_journey`, `below_threshold_user_confirmed`）、E2E不在は意図的 — このギャップチェックをスキップする。
+`e2eAbsenceReason`が提供されている場合（受入テストのGeneration Reportで生成される。例: `no_multi_step_journey`, `below_threshold_user_confirmed`）、E2E不在は意図的 — このギャップチェックをスキップする。
 
 このチェックは戦略AまたはBのどちらが選択されていても適用される。統合テストスケルトンのみの提供はE2Eカバレッジを意味しない。サービス内部ジャーニー（非同期パイプライン、サービス間saga）はここではフラグしない — 通常のROIパスでE2Eが必要な場合はそちらで対応。
 

package/.claude/skills-en/documentation-criteria/references/design-template.md

@@ -110,6 +110,20 @@ Each AC is written in EARS format. Keywords determine test type.
 ### Code Inspection Evidence
 - [path:function] — [relevance: similar functionality / integration point / pattern reference]
 
+### Fact Disposition Table
+
+One row per codebase analysis `focusAreas` entry. This table is the primary binding between structural existing-behavior facts and the design (Verification Strategy's Output Comparison binds runtime behavior separately). Other sections that describe existing behavior reference the row by `fact_id` value.
+
+| Fact ID | Focus Area | Disposition | Rationale | Evidence | Related Files |
+|---------|------------|-------------|-----------|----------|---------------|
+| [fact_id from focusAreas] | [area name from focusAreas] | preserve / transform / remove / out-of-scope | [preserve: confirmation-only language, e.g., "existing behavior retained without modification" — Rationale asserting a behavior change is flagged as preserve mismatch; transform: state new observable outcome, e.g., "branch X now returns 404 instead of 410" — Rationale asserting no change at all is flagged as transform mismatch; remove: state reason with PRD/UI Spec citation when policy-driven — Rationale asserting production-code retention is flagged as remove mismatch (test/migration retention stated explicitly is acceptable); out-of-scope: cite the scope-defining section and prefer preserve when behavior continues unchanged] | [evidence value carried verbatim from focusAreas] | [comma-separated path list carried verbatim from focusAreas.relatedFiles, e.g., `src/auth/createUser.ts, src/api/routes/users.ts`] |
+
+### Cross-Layer Assumptions (cross-layer flow only)
+
+When this Design Doc depends on unverified claims from a prior-layer Design Doc (see Prior-Layer Verification), list each with justification and downstream verification target:
+
+- [claim]: [justification]; verify at [step or artifact]
+
 ## Design
 
 ### Change Impact Map
@@ -299,7 +313,7 @@ Mark as N/A with brief rationale when the feature has no data layer dependencies
 
 ## Verification Strategy
 
-Verification Strategy defines what correctness means and how to prove it at design time. L1/L2/L3 (from implementation-approach skill) define completion verification granularity at task execution time.
+Verification Strategy defines what correctness means and how to prove it at design time. L1/L2/L3 (verification granularity tiers) define completion verification granularity at task execution time.
 
 ### Correctness Proof Method
 

package/.claude/skills-en/documentation-criteria/references/plan-template.md

@@ -69,7 +69,7 @@ Maps each Design Doc technical requirement to the covering task(s). One row per
 
 Select ONE phase structure based on implementation approach from Design Doc.
 See documentation-criteria skill for detailed Phase Division Criteria.
-All quality checks follow Quality Check Workflow from coding-standards skill.
+All quality checks follow the project's standard Quality Check Workflow.
 **Delete the unused Option entirely from the final plan.** For hybrid approach, use Option C.
 
 ### Option A: Vertical Slice Phase Structure

package/.claude/skills-en/frontend-typescript-rules/SKILL.md

@@ -7,7 +7,7 @@ description: Applies React/TypeScript type safety, component design, and state m
 
 ## Frontend-Specific Anti-patterns
 
-In addition to universal anti-patterns in coding-standards skill, watch for these Frontend-specific issues:
+In addition to universal anti-patterns, watch for these Frontend-specific issues:
 
 - **Prop drilling through 3+ levels** - Should use Context API or state management
 - **Massive components (300+ lines)** - Split into smaller components

package/.claude/skills-en/skill-optimization/SKILL.md

@@ -136,7 +136,7 @@ Measurable quality criteria for skill content. Each principle includes a pass/fa
 | # | Principle | Pass Criteria | Fail Example |
 |---|-----------|---------------|--------------|
 | 1 | Context efficiency | Every sentence contributes to LLM decision-making. No filler. | "This is an important skill that helps with..." |
-| 2 | Deduplication | No concept explained twice at the same abstraction level within the skill or across skills. Mentions at different structural roles (e.g., classification framework vs execution detail) are not duplicates, provided the re-mention adds new constraints or criteria | Same error handling rules in both coding-standards and typescript-rules |
+| 2 | Deduplication | No concept explained twice at the same abstraction level within the skill or across skills. Mentions at different structural roles (e.g., classification framework vs execution detail) are not duplicates, provided the re-mention adds new constraints or criteria | Same error handling rules restated at the same abstraction level in multiple related skills |
 | 3 | Grouping | Related criteria in single section (minimize read operations) | Scattered error handling rules across 4 sections |
 | 4 | Measurability | All criteria use if-then format or concrete thresholds | "Write clean code" without definition of clean |
 | 5 | Positive form | Instructions state what to do (BP-001 applied) | "Don't use any" instead of "Use only X" |

package/.claude/skills-en/subagents-orchestration-guide/SKILL.md

@@ -40,7 +40,7 @@ When receiving a new task, pass user requirements directly to requirement-analyz
 2. **task-decomposer**: Appropriate task decomposition of work plans
 3. **task-executor**: Individual task execution and structured response
 4. **integration-test-reviewer**: Review integration/E2E tests for skeleton compliance
-5. **security-reviewer**: Security compliance review against Design Doc and coding-standards after all tasks complete
+5. **security-reviewer**: Security compliance review against Design Doc and project coding standards after all tasks complete
 
 ### Document Creation Agents
 6. **requirement-analyzer**: Requirement analysis and work scale determination (WebSearch enabled, latest technical information research)
@@ -200,17 +200,19 @@ Replace the standard Design Doc creation step with per-layer creation:
 | Step | Agent | Purpose |
 |------|-------|---------|
 | 8 | codebase-analyzer ×2 | Codebase analysis per layer (pass req-analyzer output, filtered to layer) |
-| 9a | technical-designer | Backend Design Doc (with backend codebase-analyzer context) |
-| 9b | technical-designer-frontend | Frontend Design Doc (with frontend codebase-analyzer context + backend Integration Points) |
-| 10 | code-verifier ×2 | Verify each Design Doc against existing code |
-| 11 | document-reviewer ×2 | Review each Design Doc (with code-verifier results as code_verification) |
-| 12 | design-sync | Cross-layer consistency verification **[Stop]** |
+| 9 | technical-designer | Backend Design Doc (with backend codebase-analyzer context) |
+| 10 | code-verifier | Verify Backend Design Doc against existing code (its result JSON becomes `prior_layer_verification` for step 12) |
+| 11 | document-reviewer | Review Backend Design Doc (pass step-10 result as `code_verification` and backend codebase-analyzer JSON as `codebase_analysis`). **[Stop on critical issues]** — structural defects here block step 12. |
+| 12 | technical-designer-frontend | Frontend Design Doc (with frontend codebase-analyzer context + reviewed Backend Design Doc + `prior_layer_verification` from step 10 + UI Spec) |
+| 13 | code-verifier | Verify Frontend Design Doc against existing code |
+| 14 | document-reviewer | Review Frontend Design Doc (pass step-13 result as `code_verification` and frontend codebase-analyzer JSON as `codebase_analysis`). **[Stop on critical issues]** — structural defects here block step 15. |
+| 15 | design-sync | Cross-layer consistency verification **[Stop]** |
 
-Steps marked with ×2 invoke the agent once per layer. These invocations are independent and can run in parallel when the orchestrator supports concurrent Agent tool calls.
+The `codebase-analyzer ×2` invocations can run in parallel. The backend path (steps 9-11) runs sequentially before step 12 so that the frontend designer reads a backend Design Doc whose structural defects (AC gaps, Fact Disposition Table issues, Verification Strategy defects) have already been surfaced by document-reviewer, and whose code/doc discrepancies have already been enumerated by code-verifier. The frontend designer can then identify which backend contracts have known issues via `prior_layer_verification.discrepancies[]` and the step-11 review feedback, and design around those unstable surfaces (route integration points to stable contracts, or record the dependency in `## Cross-Layer Assumptions`).
 
 **Layer Context in Design Doc Creation**:
 - **Backend**: "Create a backend Design Doc from PRD at [path]. Codebase analysis: [JSON from codebase-analyzer for backend layer]. Focus on: API contracts, data layer, business logic, service architecture."
-- **Frontend**: "Create a frontend Design Doc from PRD at [path]. Codebase analysis: [JSON from codebase-analyzer for frontend layer]. Reference backend Design Doc at [path] for API contracts and Integration Points. Focus on: component hierarchy, state management, UI interactions, data fetching."
+- **Frontend**: "Create a frontend Design Doc from PRD at [path]. Codebase analysis: [JSON from codebase-analyzer for frontend layer]. Reviewed Backend Design Doc at [path] — extract API contracts and Integration Points from this document to populate the frontend Integration Point Map. Backend review findings: [critical/important issues from step-11 document-reviewer, if any]. prior_layer_verification: [JSON from code-verifier on backend Design Doc]. Identify unstable backend contracts via `prior_layer_verification.discrepancies[]` and the review findings; limit verified-claim inference to what the verifier output states explicitly. For contracts you must depend on that remain unverified, list them in the `## Cross-Layer Assumptions` section with justification and verification target. Reference UI Spec at [path] for component structure. Focus on: component hierarchy, state management, UI interactions, data fetching."
 
 **design-sync**: Use frontend Design Doc as source. design-sync auto-discovers other Design Docs in `docs/design/` for comparison.
 
@@ -292,12 +294,18 @@ Construct the prompt from the agent's Input Parameters section and the deliverab
    #### codebase-analyzer → technical-designer
 
    **Pass to codebase-analyzer**: requirement-analyzer JSON output, PRD path (if exists), original user requirements
-   **Pass to technical-designer**: codebase-analyzer JSON output as additional context in the Design Doc creation prompt. The designer uses `focusAreas`, `dataModel`, `dataTransformationPipelines`, and `qualityAssurance` to inform the Existing Codebase Analysis, Verification Strategy, and Quality Assurance Mechanisms sections.
+   **Pass to technical-designer**: codebase-analyzer JSON output as additional context in the Design Doc creation prompt. Required downstream uses:
+   - `focusAreas` → canonical disposition-target list for the Fact Disposition Table (one row per focusArea, carrying through `fact_id` and `evidence` verbatim)
+   - `dataModel`, `dataTransformationPipelines`, `qualityAssurance` → Existing Codebase Analysis, Verification Strategy, and Quality Assurance Mechanisms sections
 
    #### code-verifier → document-reviewer (Design Doc review)
 
-   **Pass to code-verifier**: Design Doc path (doc_type: design-doc). `code_paths` is intentionally omitted — the verifier independently discovers code scope from the document.
-   **Pass to document-reviewer**: code-verifier JSON output as `code_verification` parameter.
+   **Pass to code-verifier**: Design Doc path (doc_type: design-doc). Omit `code_paths`; the verifier independently discovers code scope from the document.
+   **Pass to document-reviewer**: code-verifier JSON output as `code_verification` parameter, **and** the same codebase-analyzer JSON previously given to the designer as `codebase_analysis`. The reviewer uses `codebase_analysis.focusAreas` to verify Fact Disposition Table coverage.
+
+   #### code-verifier + document-reviewer → next-layer technical-designer (cross-layer flow only)
+
+   **Pass to next-layer technical-designer**: reviewed prior-layer Design Doc path plus `prior_layer_verification` (the JSON from the prior-layer code-verifier). See Cross-Layer Orchestration section for sequencing. Use `prior_layer_verification.discrepancies[]` plus prior-layer review findings to identify unstable contracts. Limit verified-claim inference to what the verifier output states explicitly; when the design must depend on a claim not confirmed by the verifier, record it in the frontend Design Doc's `## Cross-Layer Assumptions` section with justification and a verification target (escalation uses the same section with `verify at: escalation to user` — choose escalation only when the dependency cannot be bounded by a downstream verification step).
 
    #### technical-designer → work-planner
 

package/.claude/skills-ja/documentation-criteria/references/design-template.md

@@ -110,6 +110,20 @@ unknowns:
 ### コード調査エビデンス
 - [パス:関数] — [関連性: 類似機能 / 統合点 / パターン参照]
 
+### Fact Disposition Table
+
+コードベース分析の`focusAreas`の各エントリに対して1行ずつ記載する。この表は**構造的な既存事実**と設計を結び付ける主たるテーブル（Verification StrategyのOutput Comparisonは**ランタイムの振る舞い**を別途拘束する）。既存の振る舞いに言及する他セクションはこの表の行を`fact_id`値で参照する。
+
+| Fact ID | Focus Area | Disposition | Rationale | Evidence | Related Files |
+|---------|------------|-------------|-----------|----------|---------------|
+| [focusAreasのfact_id] | [focusAreasのarea] | preserve / transform / remove / out-of-scope | [preserve: 確認のみの文言、例「既存の振る舞いを変更なしで維持」 — 振る舞い変更を主張するRationaleはレビューでpreserve mismatchとして検出される、transform: 新しい観測可能な結果を記述、例「分岐Xは410でなく404を返す」 — 全体として無変更を主張するRationaleはtransform mismatchとして検出される、remove: 理由を記述、ポリシー由来ならPRD/UI Specセクションを引用 — 本番コードパスでの保持を主張するRationaleはremove mismatchとして検出される（テスト/移行スクリプトでの保持を明示した場合は妥当）、out-of-scope: スコープ定義セクションを引用、既存の振る舞いがそのまま残るならpreserveを優先] | [focusAreasのevidence値をそのまま引き継ぎ] | [focusAreas.relatedFilesのパス一覧をそのまま引き継ぎ、カンマ区切り、例: `src/auth/createUser.ts, src/api/routes/users.ts`] |
+
+### Cross-Layer Assumptions（レイヤー横断フロー時のみ）
+
+本Design Docが前レイヤーのDesign Docの未検証主張に依存する場合（Prior-Layer Verification参照）、各主張に正当化と下流検証先を記載する:
+
+- [主張]: [正当化]; 検証先: [ステップまたは成果物]
+
 ## 設計
 
 ### 変更影響マップ
@@ -305,7 +319,7 @@ unknowns:
 
 ## 検証戦略
 
-設計時に「正しさとは何か」「どう証明するか」を定義する。L1/L2/L3（implementation-approachスキル）はタスク実行時の完了検証の粒度を定義する。
+設計時に「正しさとは何か」「どう証明するか」を定義する。L1/L2/L3（検証粒度の階層）はタスク実行時の完了検証の粒度を定義する。
 
 ### 正しさの証明方法
 

package/.claude/skills-ja/documentation-criteria/references/plan-template.md

@@ -69,7 +69,7 @@ Design Docの各技術要件をカバーするタスクへのマッピング。
 
 Design Docの実装アプローチに基づいてフェーズ構成をひとつ選択する。
 詳細はdocumentation-criteriaスキルのフェーズ分割基準を参照。
-全品質チェックはcoding-standardsスキルの品質チェックワークフローに従う。
+全品質チェックはプロジェクト標準の品質チェックワークフローに従う。
 **未使用のOptionは最終計画書から削除すること。** ハイブリッドの場合はOption Cを使用する。
 
 ### Option A: 垂直スライスのフェーズ構成

package/.claude/skills-ja/skill-optimization/SKILL.md

@@ -136,7 +136,7 @@ description: スキルファイルの品質を8つのコンテンツパターン
 | # | 原則 | 合格基準 | 不合格例 |
 |---|------|----------|----------|
 | 1 | コンテキスト効率 | 全文がLLMの判断に寄与する。冗長な記述なし | 「これは〜に役立つ重要なスキルで...」 |
-| 2 | 重複排除 | スキル内・スキル間で同じ抽象レベルにおける概念の重複説明なし。異なる構造的役割（例: 分類体系と実行詳細）での言及は、新たな制約や判断基準を伴う場合に限り重複に該当しない | coding-standardsとtypescript-rulesに同じエラーハンドリング規則 |
+| 2 | 重複排除 | スキル内・スキル間で同じ抽象レベルにおける概念の重複説明なし。異なる構造的役割（例: 分類体系と実行詳細）での言及は、新たな制約や判断基準を伴う場合に限り重複に該当しない | 関連する複数スキルで同じエラーハンドリング規則が同じ抽象レベルで繰り返される |
 | 3 | 関連内容の集約 | 関連する基準を1セクションに集約（読み込み回数最小化） | エラーハンドリング規則が4セクションに散在 |
 | 4 | 測定可能性 | 全基準がif-then形式または具体的閾値 | 「きれいなコードを書く」の定義なし |
 | 5 | 肯定形 | 指示は「何をするか」を記述（BP-001適用済み） | 「一切使わないこと」→「Xのみ使用する」 |

package/.claude/skills-ja/subagents-orchestration-guide/SKILL.md

@@ -40,7 +40,7 @@ description: サブエージェントのタスク分担と連携を調整。規
 2. **task-decomposer**: 作業計画書の適切なタスク分解
 3. **task-executor**: 個別タスクの実行と構造化レスポンス
 4. **integration-test-reviewer**: 統合テスト/E2Eテストのスケルトン準拠レビュー
-5. **security-reviewer**: 全タスク完了後のDesign Docおよびcoding-standardsに対するセキュリティ準拠レビュー
+5. **security-reviewer**: 全タスク完了後のDesign Docおよびプロジェクトのコーディング規約に対するセキュリティ準拠レビュー
 
 ### ドキュメント作成エージェント
 6. **requirement-analyzer**: 要件分析と作業規模判定（WebSearch対応、最新技術情報の調査）
@@ -195,17 +195,19 @@ requirement-analyzerが複数レイヤー（backend + frontend）にまたがる
 | ステップ | エージェント | 目的 |
 |---------|-----------|------|
 | 8 | codebase-analyzer ×2 | レイヤー別コードベース分析（要件分析結果をレイヤーでフィルタして入力） |
-| 9a | technical-designer | バックエンドDesign Doc（バックエンドcodebase-analyzerコンテキスト付き） |
-| 9b | technical-designer-frontend | フロントエンドDesign Doc（フロントエンドcodebase-analyzerコンテキスト + バックエンドIntegration Points付き） |
-| 10 | code-verifier ×2 | 各Design Docを既存コードに対して検証 |
-| 11 | document-reviewer ×2 | 各Design Docをレビュー（code-verifier結果をcode_verificationとして入力） |
-| 12 | design-sync | レイヤー間整合性検証 **[停止]** |
+| 9 | technical-designer | バックエンドDesign Doc（バックエンドcodebase-analyzerコンテキスト付き） |
+| 10 | code-verifier | バックエンドDesign Docを既存コードに対して検証（結果JSONはステップ12に`prior_layer_verification`として渡す） |
+| 11 | document-reviewer | バックエンドDesign Docをレビュー（ステップ10の結果を`code_verification`、バックエンドcodebase-analyzer JSONを`codebase_analysis`として入力）**[criticalで停止]** — ここで構造的欠陥が出た場合はステップ12に進めない |
+| 12 | technical-designer-frontend | フロントエンドDesign Doc（フロントエンドcodebase-analyzerコンテキスト + レビュー済みバックエンドDesign Doc + ステップ10の`prior_layer_verification` + UI Spec付き） |
+| 13 | code-verifier | フロントエンドDesign Docを既存コードに対して検証 |
+| 14 | document-reviewer | フロントエンドDesign Docをレビュー（ステップ13の結果を`code_verification`、フロントエンドcodebase-analyzer JSONを`codebase_analysis`として入力）**[criticalで停止]** — ここで構造的欠陥が出た場合はステップ15に進めない |
+| 15 | design-sync | レイヤー間整合性検証 **[停止]** |
 
-×2のステップはレイヤー毎に1回ずつ呼び出す。各呼び出しは独立しており、オーケストレーターが並列Agent呼び出しをサポートする場合は並列実行可能。
+`codebase-analyzer ×2` の呼び出しは並列実行可能。バックエンド経路（ステップ9〜11）はステップ12の前に直列で完了させる。これによりフロントエンドdesignerは、document-reviewerによって構造的欠陥（AC欠落、Fact Disposition Tableの不備、Verification Strategy欠落）が既に検出され、code-verifierによってコード/ドキュメント不整合が既に列挙された状態のバックエンドDesign Docを読む。フロントエンドdesignerは `prior_layer_verification.discrepancies[]` とステップ11のレビュー指摘から、既知の問題を持つバックエンド契約を識別し、不安定な契約面を迂回した設計ができる（統合点を安定した契約へ切り替える、または依存を「## Cross-Layer Assumptions」に記録する）。
 
 **Design Doc作成時のレイヤーコンテキスト指定**:
 - **バックエンド**: 「PRD [パス] からバックエンドDesign Docを作成。コードベース分析: [バックエンドレイヤー用codebase-analyzerのJSON]。対象: APIコントラクト、データ層、ビジネスロジック、サービスアーキテクチャ。」
-- **フロントエンド**: 「PRD [パス] からフロントエンドDesign Docを作成。コードベース分析: [フロントエンドレイヤー用codebase-analyzerのJSON]。バックエンドDesign Doc [パス] のAPIコントラクトとIntegration Pointsを参照。対象: コンポーネント階層、状態管理、UI操作、データ取得。」
+- **フロントエンド**: 「PRD [パス] からフロントエンドDesign Docを作成。コードベース分析: [フロントエンドレイヤー用codebase-analyzerのJSON]。レビュー済みバックエンドDesign Doc [パス] — このドキュメントからAPIコントラクトとIntegration Pointsを抽出し、フロントエンドのIntegration Point Mapに反映する。バックエンドレビュー指摘: [ステップ11 document-reviewerのcritical/important項目があればそれ]。prior_layer_verification: [バックエンドDesign Docに対するcode-verifierのJSON]。`prior_layer_verification.discrepancies[]`とレビュー指摘から不安定なバックエンド契約を識別する。検証済みと見なせる主張は検証結果JSONに明示されているものに限定する。未検証のまま依存せざるを得ない契約は、「## Cross-Layer Assumptions」セクションに正当化と検証先を記載する。UI Spec [パス] のコンポーネント構造を参照。対象: コンポーネント階層、状態管理、UI操作、データ取得。」
 
 **design-sync**: フロントエンドDesign Docをソースとして使用。`docs/design/`内の他のDesign Docを自動検出して比較。
 
@@ -288,12 +290,18 @@ requirement-analyzerが複数レイヤー（backend + frontend）にまたがる
    #### codebase-analyzer → technical-designer
 
    **codebase-analyzerへの入力**: 要件分析JSON出力、PRDパス（存在する場合）、元のユーザー要件
-   **technical-designerへの入力**: codebase-analyzerのJSON出力をDesign Doc作成プロンプトの追加コンテキストとして渡す。technical-designerは`focusAreas`、`dataModel`、`dataTransformationPipelines`、`qualityAssurance`を「既存コードベース分析」「検証戦略」「品質保証メカニズム」の各セクションに反映する。
+   **technical-designerへの入力**: codebase-analyzerのJSON出力をDesign Doc作成プロンプトの追加コンテキストとして渡す。必須の使い道:
+   - `focusAreas` → Fact Disposition Tableの正典となるdisposition targetリスト（各focusAreaを1行に展開し、`fact_id`と`evidence`をそのまま引き継ぐ）
+   - `dataModel`、`dataTransformationPipelines`、`qualityAssurance` → 「既存コードベース分析」「検証戦略」「品質保証メカニズム」の各セクションに反映
 
    #### code-verifier → document-reviewer（Design Docレビュー）
 
-   **code-verifierへの入力**: Design Docパス（doc_type: design-doc）。`code_paths`は意図的に未指定 — verifierがドキュメントからコードスコープを独自に発見する。
-   **document-reviewerへの入力**: code-verifierのJSON出力を`code_verification`パラメータとして渡す。
+   **code-verifierへの入力**: Design Docパス（doc_type: design-doc）。`code_paths`は指定を省略する — verifierがドキュメントからコードスコープを独自に発見する。
+   **document-reviewerへの入力**: code-verifierのJSON出力を`code_verification`パラメータとして渡す。**加えて**、designerに渡したものと同じcodebase-analyzerのJSONを`codebase_analysis`として渡す。reviewerは`codebase_analysis.focusAreas`を使ってFact Disposition Tableのカバレッジを検証する。
+
+   #### code-verifier + document-reviewer → 次レイヤーのtechnical-designer（レイヤー横断フロー時のみ）
+
+   **次レイヤーのtechnical-designerへの入力**: レビュー済みの前レイヤーDesign Docパスに加えて`prior_layer_verification`（前レイヤーcode-verifierのJSON）を渡す。シーケンスは「レイヤー横断オーケストレーション」セクションを参照。`prior_layer_verification.discrepancies[]`と前レイヤーのレビュー指摘を用いて不安定な契約を識別する。検証済みと見なせる主張は検証結果JSONに明示されているものに限定する。verifierで確認されていない主張に設計が依存せざるを得ない場合、フロントエンドDesign Docの「## Cross-Layer Assumptions」セクションに正当化と検証先を記載する（エスカレートする場合は同セクションで `検証先: ユーザーへエスカレーション` と記載する — エスカレーションは下流の検証ステップで依存を閉じられない場合のみ選ぶ）。
 
    #### technical-designer → work-planner