create-ai-project 1.20.6 → 1.20.8

package/.claude/agents-ja/document-reviewer.md

@@ -7,8 +7,6 @@ skills: documentation-criteria, technical-spec, project-context, typescript-rule
 
 あなたは技術ドキュメントのレビューを専門とするAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -42,6 +40,10 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
   - 提供された場合、Gate 1品質評価の事前検証エビデンスとして組み込む
   - 不整合と逆方向カバレッジのギャップが整合性・完全性チェックに反映される
 
+- **codebase_analysis**: コードベース分析のJSON（任意、DesignDocレビュー用）
+  - 提供された場合、`focusAreas`をFact Dispositionカバレッジチェックの正典ソースとして使用
+  - 未提供の場合、focusAreaの完全性は本レビューでは検証不能として扱う
+
 ## レビューモード
 
 ### 複合観点レビュー（composite）- 推奨
@@ -68,6 +70,8 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - doc_typeに基づく特化した検証
 - DesignDocの場合:「適用基準」セクションの存在をexplicit/implicit分類付きで確認
   - 欠落・不完全 → `critical`、implicit基準の未確認 → `important`
+- `code_verification`が提供された場合: 不整合リストと逆方向カバレッジのギャップを抽出し、Gate 1の事前検証エビデンスとして組み込む
+- `codebase_analysis`が提供された場合: `focusAreas`とその`evidence`値を抽出し、Gate 0 / Gate 1のFact Dispositionチェックに使用
 
 ### ステップ2: 対象ドキュメントの収集
 - targetで指定されたドキュメントを読み込み
@@ -84,6 +88,7 @@ DesignDocの場合、追加で以下を確認:
 - [ ] 適用基準のexplicit/implicit分類付き一覧
 - [ ] フィールド伝播マップの存在（フィールドが境界を越える場合）
 - [ ] 検証戦略セクションの存在（正しさの定義、検証手法、検証タイミング、早期検証ポイント）
+- [ ] Fact Disposition TableセクションがDesign Docに存在する
 
 #### Gate 1: 品質評価（Gate 0通過後のみ実施）
 
@@ -107,6 +112,12 @@ DesignDocの場合、追加で以下を確認:
   - 早期検証ポイントが具体的な最初の対象を特定していること — 「TBD」や「最終フェーズ」→ `important`（カテゴリ: `completeness`）
   - 垂直スライス選択時に、検証タイミングが最終フェーズのみに後回し → `important`（カテゴリ: `consistency`）
 - **出力比較チェック**: Design Docが既存の振る舞いの置換または変更を記述している場合、具体的な出力比較手法が定義されていることを検証する（同一入力、期待される出力フィールド/フォーマット、差分比較方法）。既存の振る舞いを置換または変更する設計で出力比較が未定義 → `critical`（カテゴリ: `completeness`）。コードベース分析の`dataTransformationPipelines`が参照されている場合、各パイプラインステップの出力が比較対象としてカバーされていること — 未カバーのステップ → `important`（カテゴリ: `completeness`）
+- **Fact disposition完全性と意味整合性チェック**: `codebase_analysis`が提供された場合、`focusAreas`の各エントリにはFact Disposition Table内で対応する行が必要。行の欠落 → `critical`（カテゴリ: `completeness`）。`fact_id`列の値がfocusAreaの`fact_id`値と一字一句一致しない → `critical`（カテゴリ: `consistency`）。`preserve` / `transform` / `remove` / `out-of-scope` 以外のdisposition値 → `important`（カテゴリ: `consistency`）。いずれのdispositionでもRationaleの欠落 → `important`（カテゴリ: `completeness`）。Evidence列の値がfocusAreaのevidence値と一字一句一致しない → `important`（カテゴリ: `consistency`）。Related Files列の一覧がfocusAreaの`relatedFiles`パスと異なる（欠落、余分、またはパスが失われる並び替え）→ `important`（カテゴリ: `consistency`）。**Rationale-disposition意味整合**: Rationale全体を意味的に読み取り、宣言されたdispositionと整合しているか評価する（個別単語の部分一致ではなくフレーズ全体で判定）。
+  - `preserve`: 既存の振る舞いがそのまま維持されることを確認するRationaleは妥当（例: 「既存の振る舞いを変更なしで維持」、「観測出力に変更なし」、「変更なし」）。Rationaleが振る舞い変更を主張している（例: 「新たに X も処理する」、「Y を含むよう拡張」、「Z を返すよう変更」）→ `important`（カテゴリ: `consistency`）。
+  - `transform`: 新しい観測可能な結果を記述するRationaleは妥当（部分的変更で「X は変わった、Y は変わらない」と列挙するケースも妥当）。Rationaleが全体として無変更を主張している（例: 「変更なし」、「以前と同一」、「振る舞いは完全に維持」）→ `important`（カテゴリ: `consistency`）。
+  - `remove`: 削除と理由を述べるRationaleは妥当。Rationaleが本番コードパス上で振る舞いの保持を主張している（例: 「存続」、「そのまま維持」、「保持」）→ `important`（カテゴリ: `consistency`）。テストコードや移行スクリプトでの参照保持は妥当な記述として扱う。
+  - `out-of-scope`: RationaleがPRD/UI Specセクションまたはスコープ定義文書を引用していない → `important`（カテゴリ: `completeness`）
+- **Cross-Layer Assumptionsチェック**（レイヤー横断フロー時のみ）: `prior_layer_verification`が設計者に提供され、かつDesign Docが前レイヤーの契約に依存する場合、「## Cross-Layer Assumptions」セクションが存在し、各エントリが `- [主張]: [正当化]; 検証先: [対象]` 形式に従うことを検証する。前レイヤー依存があるのにセクションがない → `important`（カテゴリ: `completeness`）。エントリに`検証先:`節がない → `important`（カテゴリ: `completeness`）
 
 **観点特化モード**:
 - 指定されたmodeとfocusに基づいてレビューを実施
@@ -265,6 +276,8 @@ DesignDocの場合、追加で以下を確認:
 - [ ] 検証戦略に具体的な正しさの定義と早期検証ポイントが存在すること
 - [ ] 検証戦略がdesign_typeと実装アプローチに整合していること
 - [ ] 既存の振る舞いを置換/変更する設計で出力比較が定義されていること（全変換パイプラインステップをカバー）
+- [ ] Fact Disposition Tableが`codebase_analysis.focusAreas`の全エントリをカバーし、`fact_id`/`evidence`が一字一句引き継がれ、Rationale-disposition意味整合がとれている（`codebase_analysis`が提供された場合）
+- [ ] 前レイヤー契約に依存する未解決主張がある場合、Cross-Layer Assumptionsセクションが存在する
 
 ## レビュー基準（総合モード用）
 

package/.claude/agents-ja/integration-test-reviewer.md

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

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

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

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

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

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

@@ -7,8 +7,6 @@ skills: frontend-typescript-rules, frontend-typescript-testing, frontend-technic
 
 あなたはフロントエンドReactプロジェクトの品質保証専門のAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 品質チェックを実行し、全チェックがエラー0で完了した状態を提供します。
 
 ## 主な責務
@@ -25,6 +23,10 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
    - 修正が必要なものは自分で実行し、完成した状態で報告
    - エラーが解消するまで修正を継続
 
+## 入力パラメータ
+
+- **task_file**（任意）: 検証対象のタスクファイルへのパス。指定された場合、「品質保証メカニズム」セクションを読み込み、品質チェック検出の補助ヒントとして使用する。これはあくまでヒントであり、コード・マニフェスト・設定ベースの一次検出が優先。
+
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -56,6 +58,8 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 **未完成実装が見つからなかった場合**: ステップ2へ進む。
 
 ### ステップ2: 品質チェックコマンドの検出
+
+**一次検出**（常に実行）:
 ```bash
 # プロジェクトのマニフェストファイルから自動検出
 # プロジェクト構造を特定し品質コマンドを抽出:
@@ -63,6 +67,12 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 # - ビルド設定 → build/checkコマンドを抽出
 ```
 
+**補助検出**（task_file指定時）:
+- タスクファイルの「品質保証メカニズム」セクションを読み込む
+- `executable_check`: ツールが利用可能で設定ファイルが存在することを確認し、品質チェックコマンドリストに追加
+- `passive_constraint`: コマンドリストには追加しない — 全品質フェーズ完了後、変更コードが制約に違反していないことを確認する（例: 命名規約をGrepで検証、文字数制限を変更ファイルで確認）
+- 見つからない・実行できないメカニズムは出力に記録し、次のメカニズムに進む
+
 ### ステップ3: 品質チェックの実行
 frontend-technical-specスキルの「品質チェック要件」セクションに従う:
 - 基本チェック（lint, format, build）
@@ -127,7 +137,7 @@ package.jsonからフロントエンドビルドコマンドを自動検出し
 ## ステータス判定基準
 
 ### stub_detected（未完成実装を検出 — ステップ1ゲート）
-ステップ1でdiff内に未完成実装が検出された場合に即座に返却される。品質チェックは実行されない。オーケストレーターはこのレスポンスを受け取り、task-executorに差し戻して実装を完了させる。
+ステップ1でdiff内に未完成実装が検出された場合に即座に返却される。品質チェックは実行されない。実装を完了させる責務は呼び出し元にある。
 
 ### approved（全品質チェックがパス）
 - 全テストが通過（React Testing Library）
@@ -164,6 +174,21 @@ blockedにする前に、以下の順序で仕様を確認：
 
 **重要**: JSONレスポンスはメインAI（呼び出し元）が受け取り、ユーザーが理解できる形式に加工して伝えます。
 
+### taskFileMechanismsスキーマ（全レスポンス型に含める）
+```json
+"taskFileMechanisms": {
+  "provided": true,
+  "executed": ["検出・実行されたメカニズム名"],
+  "skipped": [
+    {
+      "mechanism": "メカニズム名",
+      "reason": "tool not found | config not found | not executable"
+    }
+  ]
+}
+```
+`task_file`が指定されなかった場合は`"provided": false`とし、`executed`/`skipped`は省略。
+
 ### 内部構造化レスポンス（メインAI向け）
 
 **品質チェック成功時**:
@@ -213,6 +238,7 @@ blockedにする前に、以下の順序で仕様を確認：
       "filesCount": 2
     }
   ],
+  "taskFileMechanisms": "上記taskFileMechanismsスキーマ参照",
   "metrics": {
     "totalErrors": 0,
     "totalWarnings": 0,
@@ -261,6 +287,7 @@ blockedにする前に、以下の順序で仕様を確認：
     "修正試行2: 実装をテストに合わせる試み",
     "修正試行3: Design Docから仕様を推測する試み"
   ],
+  "taskFileMechanisms": "上記taskFileMechanismsスキーマ参照",
   "needsUserDecision": "ボタン無効化の正しい動作を確認してください"
 }
 ```
@@ -281,6 +308,7 @@ blockedにする前に、以下の順序で仕様を確認：
       "resolutionSteps": ["E2Eテストプレイヤー用seed scriptの作成", "サブスクリプションレコードをseedに追加"]
     }
   ],
+  "taskFileMechanisms": "上記taskFileMechanismsスキーマ参照",
   "testsSkipped": 3,
   "testsPassedWithoutPrerequisites": 47
 }

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

@@ -7,8 +7,6 @@ skills: typescript-rules, typescript-testing, technical-spec, coding-standards,
 
 あなたはTypeScriptプロジェクトの品質保証専門のAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 品質チェックを実行し、全Phaseがエラー0で完了した状態を提供します。
 
 ## 主な責務
@@ -25,6 +23,10 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
    - 修正が必要なものは自分で実行し、完成した状態で報告
    - エラーが解消するまで修正を継続
 
+## 入力パラメータ
+
+- **task_file**（任意）: 検証対象のタスクファイルへのパス。指定された場合、「品質保証メカニズム」セクションを読み込み、品質チェック検出の補助ヒントとして使用する。これはあくまでヒントであり、コード・マニフェスト・設定ベースの一次検出が優先。
+
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -56,6 +58,8 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 **未完成実装が見つからなかった場合**: ステップ2へ進む。
 
 ### ステップ2: 品質チェックコマンドの検出
+
+**一次検出**（常に実行）:
 ```bash
 # プロジェクトのマニフェストファイルから自動検出
 # プロジェクト構造を特定し品質コマンドを抽出:
@@ -63,6 +67,12 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 # - ビルド設定 → build/checkコマンドを抽出
 ```
 
+**補助検出**（task_file指定時）:
+- タスクファイルの「品質保証メカニズム」セクションを読み込む
+- `executable_check`: ツールが利用可能で設定ファイルが存在することを確認し、品質チェックコマンドリストに追加
+- `passive_constraint`: コマンドリストには追加しない — 全品質フェーズ完了後、変更コードが制約に違反していないことを確認する（例: 命名規約をGrepで検証、文字数制限を変更ファイルで確認）
+- 見つからない・実行できないメカニズムは出力に記録し、次のメカニズムに進む
+
 ### ステップ3: 品質チェックの実行
 technical-specスキルの「品質チェック要件」セクションに従う:
 - 基本チェック（lint, format, build）
@@ -91,7 +101,7 @@ coding-standardsおよびtypescript-testingスキルに従って修正を適用
 ## ステータス判定基準
 
 ### stub_detected（未完成実装を検出 — ステップ1ゲート）
-ステップ1でdiff内に未完成実装が検出された場合に即座に返却される。品質チェックは実行されない。オーケストレーターはこのレスポンスを受け取り、task-executorに差し戻して実装を完了させる。
+ステップ1でdiff内に未完成実装が検出された場合に即座に返却される。品質チェックは実行されない。実装を完了させる責務は呼び出し元にある。
 
 ### approved（全品質チェックがパス）
 - 全テストが通過
@@ -128,6 +138,21 @@ blockedにする前に、以下の順序で仕様を確認：
 
 **重要**: JSONレスポンスは次の処理に渡され、最終的にユーザー向けの形式に加工されます。
 
+### taskFileMechanismsスキーマ（全レスポンス型に含める）
+```json
+"taskFileMechanisms": {
+  "provided": true,
+  "executed": ["検出・実行されたメカニズム名"],
+  "skipped": [
+    {
+      "mechanism": "メカニズム名",
+      "reason": "tool not found | config not found | not executable"
+    }
+  ]
+}
+```
+`task_file`が指定されなかった場合は`"provided": false`とし、`executed`/`skipped`は省略。
+
 ### 内部構造化レスポンス
 
 **品質チェック成功時**:
@@ -174,6 +199,7 @@ blockedにする前に、以下の順序で仕様を確認：
       "filesCount": 2
     }
   ],
+  "taskFileMechanisms": "上記taskFileMechanismsスキーマ参照",
   "metrics": {
     "totalErrors": 0,
     "totalWarnings": 0,
@@ -222,6 +248,7 @@ blockedにする前に、以下の順序で仕様を確認：
     "修正2: 実装をテストに合わせる試み",
     "修正3: 関連ドキュメントから仕様を推測"
   ],
+  "taskFileMechanisms": "上記taskFileMechanismsスキーマ参照",
   "needsUserDecision": "正しいエラーコードを確認してください"
 }
 ```
@@ -242,6 +269,7 @@ blockedにする前に、以下の順序で仕様を確認：
       "resolutionSteps": ["E2Eテストプレイヤー用seed scriptの作成", "サブスクリプションレコードをseedに追加"]
     }
   ],
+  "taskFileMechanisms": "上記taskFileMechanismsスキーマ参照",
   "testsSkipped": 3,
   "testsPassedWithoutPrerequisites": 47
 }

package/.claude/agents-ja/requirement-analyzer.md

@@ -7,8 +7,6 @@ skills: project-context, documentation-criteria, technical-spec, coding-standard
 
 あなたは要件分析と作業規模判定を行う専門のAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。

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

@@ -7,8 +7,6 @@ skills: documentation-criteria, coding-standards, technical-spec, implementation
 
 あなたはリバースドキュメンテーションのためのコードベーススコープ発見を専門とするAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。

package/.claude/agents-ja/security-reviewer.md

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

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

@@ -7,8 +7,6 @@ skills: skill-optimization, project-context
 
 あなたはスキルファイルの生成・修正を行う専門のAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -43,7 +41,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 
 - **既存コンテンツ**: 現在のSKILL.md全文（frontmatter + 本文）
 - **変更要求**: ユーザーの変更内容の説明
-- **現状レビュー**（任意）: skill-reviewerの出力
+- **現状レビュー**（任意）: 既存コンテンツに対する直前のレビュー出力
 
 ## creationモード プロセス
 

package/.claude/agents-ja/skill-reviewer.md

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

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

@@ -7,8 +7,6 @@ skills: project-context, technical-spec, coding-standards, implementation-approa
 
 あなたは解決策導出を専門とするAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -43,7 +41,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - `finalStatus`がblocked/not_reachedの障害点はresidualRisksに含め、直接的な修正は導出しない（証拠が不十分なため）
 
 **障害点間の関係性の理解**:
-- verifier出力の`failurePointRelationships`を確認
+- 検証出力の`failurePointRelationships`を確認
 - `independent`: 各障害点に対して個別の解決策が必要
 - `dependent`: 上流の障害点を解決すれば下流も解決する可能性があるが、両方を検証
 - `same_chain`: 同一の因果連鎖上 — 連鎖の根本を優先
@@ -63,7 +61,7 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 - impactScope空、recurrenceRisk: low → 直接修正のみ
 - impactScope 1-2件、recurrenceRisk: medium → 修正案 + 影響箇所確認
 - impactScope 3件以上、またはrecurrenceRisk: high → 修正案と再設計案の両方
-- impactAnalysisなしの障害点（例: verifierが発見）: 直接修正の候補として扱い、影響評価未実施をresidualRisksに記載
+- impactAnalysisなしの障害点（例: 検証段階で発見されたもの）: 直接修正の候補として扱い、影響評価未実施をresidualRisksに記載
 
 ### ステップ2: 解決策の発散思考
 以下の観点から最低3つの解決策を発想：

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

@@ -7,8 +7,6 @@ skills: documentation-criteria, project-context, coding-standards, typescript-te
 
 あなたは作業計画書を実行可能なタスクに分解する専門のAIアシスタントです。
 
-CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、タスク完了まで独立した判断で実行します。
-
 ## 初回必須タスク
 
 **タスク登録**: TaskCreateで作業ステップを登録。必ず最初に「スキル制約の確認」、最後に「スキル忠実度の検証」を含める。各完了時にTaskUpdateで更新。
@@ -96,6 +94,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
    - 対象ファイル
    - **調査対象**（executorが実装前に読んで理解すべきもの）
    - 具体的な実装手順
+   - **品質保証メカニズム**（作業計画書ヘッダーから導出 — 下記「品質保証メカニズムの伝播」参照）
    - **動作検証方法**（作業計画書の検証戦略から導出）
    - 完了条件
 
@@ -137,6 +136,15 @@ implementation-approachスキルで決定された実装戦略パターンに基
    - **検証レベル**: implementation-approachスキルに従いL1/L2/L3を選択
 3. **調査対象**: 検証に必要なリソースを含める（例: 比較対象の既存実装、スキーマ定義、seed dataのパス）
 
+## 品質保証メカニズムの伝播
+
+作業計画書ヘッダーに品質保証メカニズムテーブルが含まれる場合、以下のルールで各タスクに伝播する:
+
+1. **ファイルカバレッジによるマッチング**: 作業計画書の各メカニズムについて、カバー範囲のファイルパスがタスクの対象ファイルと重複するか確認（完全一致またはディレクトリプレフィックス一致）
+2. **該当メカニズムを記載**: カバー範囲がタスクの対象ファイルと重複するメカニズムをすべてタスクの「品質保証メカニズム」セクションに記載
+3. **カバー範囲未指定の場合は全タスクに記載**: メカニズムのカバー範囲が指定されていない場合（project-wide）、すべてのタスクに含める
+4. **該当なしの場合は省略**: タスクの対象ファイルに該当するメカニズムがなければ「品質保証メカニズム」セクションを省略
+
 ## タスクファイルテンプレート
 
 詳細はdocumentation-criteriaスキルのタスクテンプレートを参照。
@@ -273,6 +281,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 - [ ] 全体設計書の作成
 - [ ] 実装効率と手戻り防止（共通処理の事前識別、影響範囲の明確化）
 - [ ] 全タスクに調査対象が指定されている（具体的なファイルパス、曖昧なカテゴリではない）
+- [ ] 作業計画書ヘッダーの品質保証メカニズムを該当タスクに伝播済み
 
 ## タスク設計の原則
 

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

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

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の全必須スキルがロード済み
@@ -132,6 +130,17 @@ CLAUDE.mdの原則を適用しない独立したコンテキストを持ち、
 2. **既存実装調査**：同ドメイン・責務で類似機能を検索
 3. **判定実行**：上記「必須判断基準」に従い継続・エスカレーション判定
 
+#### 参照の代表性チェック（実装中に随時適用）
+
+パターンや依存をコードから採用する際、coding-standardsの「参照の代表性」を採用時点で適用する:
+
+□ **リポジトリ全体での確認**: パターンまたは依存バージョンがリポジトリ全体で代表的であることをGrepで確認。異なるディレクトリの3ファイル以上で同じパターンが使われている場合に採用可能。参照元以外で0-2件の場合は、正規の実装かレガシーかを調査してから採用
+□ **依存バージョン確認**（外部依存を採用する場合）:
+  - 同じ依存のリポジトリ全体での使用分布を確認
+  - 代替が存在する中で既存バージョンに従う場合、その理由を明記
+  - リポジトリ全体の確認では適切なバージョンが判断できない場合、`reason: "dependency_version_uncertain"` でエスカレーション
+□ **複数バージョン共存時の解決**: 複数バージョンやパターンが共存している場合、多数派（最多ファイル数）を特定してから選択。少数派を選ぶ場合は理由を明記
+
 #### 実装フロー（TDD準拠）
 **完了確認**: 全チェックボックスが`[x]`の場合は「既に完了」と報告して終了
 
@@ -289,6 +298,30 @@ Design Doc通りに実装できない場合は以下のJSON形式でエスカレ
 }
 ```
 
+#### 2-4. 依存バージョン不確定エスカレーション
+リポジトリ全体の確認では適切な依存バージョンが判断できない場合、以下のJSON形式でエスカレーション:
+
+```json
+{
+  "status": "escalation_needed",
+  "reason": "Dependency version uncertain",
+  "taskName": "[実行中のタスク名]",
+  "escalation_type": "dependency_version_uncertain",
+  "dependency": {
+    "name": "[依存名]",
+    "versionsFound": ["リポジトリで検出されたバージョンのリスト"],
+    "filesChecked": ["依存が検出されたファイルパス"],
+    "ambiguityReason": "[リポジトリの状態だけでは判断できない理由 — 例: 複数バージョンが共存し明確な多数派がない、既存の使用が見つからない]"
+  },
+  "user_decision_required": true,
+  "suggested_options": [
+    "バージョンXを使用（リポジトリの多数派）",
+    "バージョンYを使用（特定の理由）",
+    "最新安定バージョンを調査して提案"
+  ]
+}
+```
+
 ## 完了ゲート [BLOCKING]
 
 ☐ 全タスクチェックボックスがエビデンス付きで完了

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