create-ai-project 1.20.7 → 1.20.9

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/documentation-criteria/references/task-template.md

@@ -1,54 +1,57 @@
-# タスク: [タスク名]
+# Task: [タスク名]
 
-メタデータ:
-- 依存関係: task-01 → 成果物: docs/plans/analysis/research-results.md
-- 提供物: docs/plans/analysis/api-spec.md（調査・設計タスクの場合）
-- サイズ: 小規模（1-2ファイル）
+Metadata:
+- Dependencies: task-01 -> Deliverable: docs/plans/analysis/research-results.md
+- Provides: docs/plans/analysis/api-spec.md（調査・設計タスクの場合）
+- Size: 小規模（1-2ファイル）
 
-## 実装内容
+## Implementation Content
 [このタスクで達成すること]
 *依存関係の成果物を参照する場合は明記
 
-## 対象ファイル
+## Target Files
 - [ ] [実装ファイルパス]
 - [ ] [テストファイルパス]
 
-## 調査対象
+## Investigation Targets
 実装開始前に読むべきファイル（ファイルパス、任意でサーチヒント付き）:
-- [例: src/orders/checkout (processOrder関数) — タスクの性質に基づきtask-decomposerが決定]
+- [例: src/orders/checkout (processOrder関数) — タスクの性質に基づきタスク分解時に決定]
 
-## 実装ステップ（TDD: Red-Green-Refactor）
-### 1. Redフェーズ
-- [ ] 全ての調査対象を読み、主要な所見を記録
-- [ ] 依存関係の成果物を確認（ある場合）
+## Investigation Notes
+（実装観察事項を実装開始前にここへ追記する。）
+
+## Implementation Steps (TDD: Red-Green-Refactor)
+### 1. Red Phase
+- [ ] 全ての Investigation Targets を読み、主要な所見を記録
+- [ ] Dependencies の成果物を確認（ある場合）
 - [ ] 契約定義を確認・作成
 - [ ] 失敗するテストを書く
 - [ ] テストを実行し失敗を確認
 
-### 2. Greenフェーズ
+### 2. Green Phase
 - [ ] テストをパスする最小限の実装を追加
 - [ ] 追加したテストのみ実行しパスを確認
 
-### 3. Refactorフェーズ
+### 3. Refactor Phase
 - [ ] コードを改善（テストはパス状態を維持）
 - [ ] 追加したテストが引き続きパスすることを確認
 
-## 品質保証メカニズム
-（作業計画書ヘッダーより — このタスクの対象ファイルに該当するメカニズム）
+## Quality Assurance Mechanisms
+（作業計画書ヘッダーより — このタスクの Target Files に該当するメカニズム）
 - [ツール/チェック名] — 検証内容: [何を担保するか] — 設定/出典: [パス] — 種別: `executable_check` | `passive_constraint`
 
-## 動作検証方法
-（作業計画書の検証戦略から導出）
-- **検証手法**: [何をどう検証するか — 例: 「新実装の出力をsrc/legacy/order_calcの既存実装と比較」「エンドポイントをテストDBに対して実行しレスポンスがコントラクトに一致することを確認」]
+## Operation Verification Methods
+（作業計画書の Verification Strategy から導出）
+- **検証手法**: [何をどう検証するか — 例: 「新実装の出力を src/legacy/order_calc の既存実装と比較」「エンドポイントをテストDBに対して実行しレスポンスがコントラクトに一致することを確認」]
 - **成功基準**: [正しさを証明する観察可能な成果 — 例: 「全入力パターンで既存実装と出力が一致」「APIが期待スキーマで200を返す」]
 - **失敗時の対応**: [検証失敗時の対処 — 例: 「続行前にアプローチを再評価」「ユーザーにエスカレーション」]
 - **検証レベル**: [L1: エンドユーザー機能としての動作確認 / L2: 新規テスト追加・パス / L3: ビルドエラーなし]
 
-## 完了条件
+## Completion Criteria
 - [ ] 追加した全テストがパス
-- [ ] 動作検証方法に基づく動作確認完了
+- [ ] Operation Verification Methods に基づく動作確認完了
 - [ ] 成果物作成完了（調査・設計タスクの場合）
 
-## 備考
+## Notes
 - 影響範囲: [変更が波及する可能性のある領域]
 - スコープ境界: [変更せず維持するファイル — パスと理由]

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

@@ -5,7 +5,7 @@
 [このUI仕様書の目的とスコープを2-3文で説明]
 
 ### 対象PRD
-- PRDパス: [docs/prd/xxx-prd.md | "N/A — requirement-analyzerの出力に基づく"]
+- PRDパス: [docs/prd/xxx-prd.md | "N/A — 要件分析の出力に基づく"]
 - 機能スコープ: [このUI SpecがカバーするPRD要件 | 分析済み要件の概要]
 
 ### 設計ソース

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対応、最新技術情報の調査）
@@ -114,7 +114,7 @@ description: サブエージェントのタスク分担と連携を調整。規
 
 | 規模 | ファイル数 | PRD | ADR | Design Doc | 作業計画書 |
 |------|-----------|-----|-----|------------|-----------|
-| 小規模 | 1-2 | 更新※1 | 不要 | 不要 | 簡易版 |
+| 小規模 | 1-2 | 更新※1 | 不要 | 不要 | task-template 形式の単一タスクファイル（`docs/plans/tasks/` 直下、計画書ファイルは別途作成しない） |
 | 中規模 | 3-5 | 更新※1 | 条件付き※2 | **必須** | **必須** |
 | 大規模 | 6以上 | **必須**※3 | 条件付き※2 | **必須** | **必須** |
 
@@ -131,13 +131,13 @@ description: サブエージェントのタスク分担と連携を調整。規
 | requirement-analyzer | scale, confidence, adrRequired, crossLayerScope, scopeDependencies, questions | scaleでフローを選択。adrRequiredでADRステップ要否を判断 |
 | codebase-analyzer | analysisScope.categoriesDetected, dataModel.detected, qualityAssurance (mechanisms[], domainConstraints[]), focusAreas[], existingElements count, limitations | focusAreasをtechnical-designerにコンテキストとして渡す |
 | code-verifier | status (consistent/mostly_consistent/needs_review/inconsistent), consistencyScore, discrepancies[], reverseCoverage (dataOperationsInCode, testBoundariesSectionPresent). 実装前: Design Docの主張を既存コードに対して検証。実装後: 実装のDesign Doc整合性を検証（`code_paths`で変更ファイルにスコープ） | discrepanciesをdocument-reviewerに連携 |
-| task-executor | status (escalation_needed/completed), escalation_type (design_compliance_violation/similar_function_found/similar_component_found/investigation_target_not_found/out_of_scope_file/dependency_version_uncertain), testsAdded, requiresTestReview | escalation_needed時: escalation_type別に対応 |
-| quality-fixer | 入力: `task_file`（現在のタスクファイルパス — オーケストレーションフローでは常に渡す）。Status: approved/stub_detected/blocked。`stub_detected` → task-executorに`incompleteImplementations[]`の詳細を添えて差し戻し、本実装完了後にquality-fixerを再実行。`blocked` → 下記quality-fixer blockedハンドリング参照 | stub_detected: task-executorを再実行。blocked: 下記参照 |
+| task-executor | 入力: `task_file`（オーケストレーションフローでは必須）; 任意の Fix Mode シグナル `requiredFixes` または `incompleteImplementations` — いずれかが非空の場合、`task_already_completed` チェックをスキップし、各項目の `file_path` / `location`（`location` は `file[:line]` として解釈）で許可リストを拡張する。出力: status (escalation_needed/completed), filesModified[], testsAdded, requiresTestReview, escalation_type ∈ {task_file_not_found, task_already_completed, target_files_missing, design_compliance_violation, similar_function_found, similar_component_found, investigation_target_not_found, out_of_scope_file, dependency_version_uncertain} | escalation_needed時: escalation_type別に対応 |
+| quality-fixer | 入力: `task_file`（現在のタスクファイルパス — オーケストレーションフローでは常に渡す）、`filesModified`（上流の実装ステップのレスポンスから抽出 — 当該タスクの書き込み集合を未完成実装検出の主要スコープとして渡す。省略時は `git diff HEAD` にフォールバック）。Status: approved/stub_detected/blocked。`stub_detected` → 上流の実装ステップに `incompleteImplementations[]` の詳細を添えて差し戻し、本実装完了後にquality-fixerを再実行。`blocked` → 下記quality-fixer blockedハンドリング参照 | stub_detected: 実装ステップを再実行。blocked: 下記参照 |
 | document-reviewer | approvalReady (true/false) | trueで次ステップへ。falseで修正を依頼 |
 | design-sync | sync_status (NO_CONFLICTS/CONFLICTS_FOUND) | CONFLICTS_FOUND時: 矛盾をユーザーに提示してから進む |
-| integration-test-reviewer | status (approved/needs_revision/blocked), requiredFixes | needs_revision時: requiredFixesをtask-executorに戻す |
-| security-reviewer | status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes | needs_revision時: requiredFixesをtask-executorに戻す |
-| acceptance-test-generator | status, generatedFiles { integration: string, e2e: string | null }, e2eAbsenceReason: string | null | generatedFiles.integrationとgeneratedFiles.e2e（nullable）をwork-plannerに渡す。e2eがnullの場合、e2eAbsenceReasonが妥当であればエラーではない |
+| integration-test-reviewer | status (approved/needs_revision/blocked), requiredFixes | needs_revision時: 同じ task_file と requiredFixes[] を渡してルーティング先の executor を Fix Mode で再実行 |
+| security-reviewer | status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes | needs_revision時: 影響ファイルをTarget Filesに含めた統合修正タスクファイルを作成し、その task_file と requiredFixes[] を渡してexecutor を Fix Mode で起動（build/implementレシピ参照） |
+| acceptance-test-generator | status, generatedFiles (integration: path\|null, e2e: path\|null), budgetUsage, e2eAbsenceReason (E2E 出力時は null。それ以外は no_multi_step_journey \| below_threshold_user_confirmed) | ファイルの存在を確認し、不在理由（e2eAbsenceReason）を添えて work-planner に渡す |
 
 ### quality-fixer blockedハンドリング
 
@@ -181,8 +181,10 @@ quality-fixerが `status: "blocked"` を返した場合、`reason`で判別：
 
 ### 小規模（1-2ファイル） - 2ステップ
 
-1. work-planner → 簡易作業計画書を作成 **[停止: 一括承認]**
-2. 直接実装 → 完了報告
+1. work-planner → 簡易作業計画作成。本スケールでは作業計画書とタスク分解ステップを分けず、`docs/plans/tasks/` 直下に task-template 形式の単一タスクファイルを直接出力する。task-executor にはそのパスを `task_file` として渡す **[停止: 一括承認]**
+2. task-executor → quality-fixer → commit（タスクごと）→ 完了報告
+
+注: 小規模スケールでも実装ステップは task-executor を介して標準の4ステップサイクル（`task-executor → エスカレーション判定 → quality-fixer → commit`）で実行する。オーケストレーターによる直接編集は行わない。
 
 ## レイヤー横断オーケストレーション
 
@@ -195,17 +197,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を自動検出して比較。
 
@@ -236,7 +240,7 @@ requirement-analyzerが複数レイヤー（backend + frontend）にまたがる
 ### Step 2 実行詳細
 - `status: escalation_needed` または `status: blocked` → ユーザーにエスカレーション
 - `requiresTestReview` が `true` → **integration-test-reviewer** を実行
-  - verdict が `needs_revision` → `requiredFixes` と共に task-executor に戻る
+  - verdict が `needs_revision` → ルーティング先の executor（レイヤー別エージェントルーティング 参照、task-executor または task-executor-frontend）を **Fix Mode** で再実行（同じ `task_file` と `requiredFixes[]` を渡す）
   - verdict が `approved` → quality-fixer へ進む
 
 ### 自律実行の停止条件
@@ -265,6 +269,10 @@ requirement-analyzerが複数レイヤー（backend + frontend）にまたがる
 
 エージェントのInput Parametersセクションと、フロー内のその時点で利用可能な成果物からプロンプトを構成する。
 
+追加の2つのルール:
+- サブエージェントは Agent prompt と自身が読み込んだファイルしか参照できない。必須のパス、先行 JSON、パラメータ、スコープ制約をプロンプトに明示的に注入する。
+- 以下の例の `[placeholder]` は Agent ツール呼び出し前にすべて具体値へ置換する。
+
 ### Call Example (codebase-analyzer)
 - subagent_type: "codebase-analyzer"
 - description: "コードベース分析"
@@ -288,12 +296,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
 

package/.claude/skills-ja/task-analyzer/references/skills-index.yaml

@@ -23,6 +23,7 @@ skills:
       - "コメント記述ルール"
       - "エラーハンドリングの基本原則"
       - "Rule of Three - コード重複の判断基準"
+      - "参照の代表性"
       - "よくある失敗パターンと回避方法"
       - "デバッグ手法"
       - "型安全性の基礎"
@@ -32,7 +33,7 @@ skills:
       - "Red-Green-Refactorプロセス（テストファースト開発）"
       - "テスト設計原則"
       - "テストの粒度原則"
-      - "Security Principles (Secure Defaults, Input and Output Boundaries, Access Control, Knowledge Cutoff Supplement)"
+      - "Security Principles"
 
   typescript-rules:
     skill: "typescript-rules"
@@ -110,7 +111,6 @@ skills:
       - "AI自動化ルール"
       - "図表作成要件"
       - "共通ADRとの関係性"
-      - "フェーズ分割基準"
       - "テンプレート"
 
   implementation-approach:
@@ -146,6 +146,7 @@ skills:
       - "テスト種別と上限"
       - "振る舞い優先の原則"
       - "スケルトン仕様"
+      - "マルチステップユーザージャーニーの定義"
       - "実装ルール"
       - "レビュー基準"
 

package/.claude/skills-ja/typescript-testing/SKILL.md

@@ -172,7 +172,7 @@ const sdkMock = {
 - AI生成のデータアクセスコードはスキーマのhallucinationリスクが高い
 - 生成されたクエリは正しい構文でも、存在しないスキーマ要素を参照する場合がある
 - モックベースのテストはスキーマの正確性に関わらずパスする
-- 緩和策: Design Docに明示的なスキーマ参照を含めること。逆方向カバレッジ検証でドキュメント化されたスキーマに対するデータ操作を検証する
+- 緩和策: Design Docに明示的なスキーマ参照を含めることで、レビュー時にドキュメント化されたスキーマとデータアクセスコードを照合可能にする
 
 ## Vitestの基本例
 

package/CHANGELOG.md

@@ -5,6 +5,74 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.20.9] - 2026-05-01
+
+### Added
+
+- **task-executor / -frontend: Fix Mode** (agents) — New optional `requiredFixes` and `incompleteImplementations` input parameters trigger Fix Mode. In Fix Mode the executor drives work from fix items instead of task file checkboxes, skips the `task_already_completed` gate, extends the allowed file list with each item's `file_path` (path) or `location` (parsed as `file[:line]`, file part only), and leaves task checkboxes unchanged. Outcomes recorded in `changeSummary`. Exit Gate validates Fresh Mode checkbox completion AND Fix Mode item coverage
+- **task-executor / -frontend: File Scope Constraint** (agents) — Allowed file list built explicitly from Target Files entries plus the task file, the referenced work plan, `Provides:` deliverable paths, and (in Fix Mode) fix item file paths. Modifications outside this set escalate as `out_of_scope_file` with `details.file_path` / `allowed_list` / `modification_reason`
+- **task-executor / -frontend: Investigation Notes persistence** (agents) — Step 2 appends observations from each Investigation Target to the task file's `## Investigation Notes` section before implementation. Exit Gate references the recorded notes as the consistency check baseline
+- **task-executor / -frontend: Phase Entry Gate / Step Completion Gates separation** (agents) — Phase Entry Gate now covers only true preconditions (skills loaded, task_file resolution input). Mid-flow conditions (task file content readable, uncompleted checkboxes, Target Files extracted, Investigation Targets read) move to Step 1 / Step 2 Completion Gates. New Exit Gate runs immediately before final JSON output
+- **task-executor / -frontend: granular `escalation_type` enum** (agents) — `task_file_not_found`, `task_already_completed`, `target_files_missing`, and `out_of_scope_file` added alongside existing types. Each carries a typed details payload via the common envelope and per-type contract table in Structured Response Specification
+- **security-reviewer: `suspected_risk` category and confidence-aware status routing** (agents) — Findings whose exploitability is uncertain or partially mitigated downgrade from `confirmed_risk` to `suspected_risk` (with `confidence` and rationale) instead of being discarded. High-confidence `suspected_risk` on primary input boundaries (auth, input boundaries, data persistence) routes the response to `blocked` for human investigation. `requiredFixes` remains code-level only
+- **security-reviewer: structured `requiredFixes` items** (agents) — Each entry now carries `{location, issue, fix}` with `location` parseable as `file[:line]` so downstream Fix Mode can extend its allowed file list correctly
+- **quality-fixer / -frontend: `filesModified` primary scope** (agents) — New optional input parameter passes the implementation step's write set as the primary scope for stub-detection. Falls back to `git diff HEAD` when absent. Prevents cross-task false positives when multiple commits accumulate in the working tree
+- **technical-designer / -frontend: Gate 0 / 1 / 2 / 3 ordering** (agents) — Mandatory Process Before Design Doc Creation reorganized into four serial gates (Inputs and Standards / Existing State Analysis / Design Decisions / Impact Documentation). Each subsection annotated with its gate number; subsection order matches gate order
+- **subagents-orchestration-guide: scale-aware Small Scale flow** (skills) — Small Scale (1-2 files) flow now declares that work-planner emits a single task-template-format file directly under `docs/plans/tasks/` and that path is what task-executor receives as `task_file`. Document Requirement table Small row carries the same contract
+- **work-planner: `scale` input parameter and Output Mode by Scale table** (agents) — `scale: small | medium | large` controls output: `small` produces a single task-template-format file under `docs/plans/tasks/` (no separate plan + decomposition); `medium` / `large` produce a plan-template-format work plan under `docs/plans/`. Step 7 branches accordingly
+- **All JSON-returning agents: Output Protocol section** (agents) — Single-sentence directive that the final message is exactly one JSON object matching the schema below (begins with `{`, ends with `}`, no code fence) and that progress text appears only in earlier messages
+- **Self-Validation [BLOCKING — before output] sections** (agents) — Replaces former `## Output Self-Check` blocks across JSON-returning agents. Includes return-to-step recovery rule when any item is unsatisfied. Applied to both EN and JA mirrors
+- **subagents-orchestration-guide: explicit subagent prompt construction rules** (skills) — Two new rules: subagents see only the Agent tool prompt and files they read (so paths, prior JSON, parameters, scope constraints must be injected explicitly); every `[placeholder]` in the call examples must be replaced with concrete values before invoking the Agent tool
+- **task-template: `## Investigation Notes` section** (skills) — New section between Investigation Targets and Implementation Steps. Implementation observations are appended here before implementation begins
+
+### Changed
+
+- **Recipes: Fix Mode wiring across the orchestration cycle** (commands) — `needs_revision` and `stub_detected` re-runs now route through executor Fix Mode with the same `task_file` and `requiredFixes[]` / `incompleteImplementations[]` array. quality-fixer invocations always pass the upstream step's `filesModified` array (with `git diff HEAD` fallback when omitted). Applied to build / front-build / implement / review / front-review / add-integration-tests
+- **Recipes: consolidated fix task file pattern for cross-task verifier outputs** (commands) — Post-implementation Fix cycle and security-reviewer needs_revision route now create a consolidated fix task file (`docs/plans/tasks/post-impl-fixes-YYYYMMDD.md` / `security-fixes-YYYYMMDD.md`) whose Target Files cover every file referenced by all verifier outputs (parsed as `file[:line]`, file part only). Verifier outputs normalized into a unified `requiredFixes[]` before invoking task-executor: `security-reviewer.requiredFixes[]` passes through; `code-verifier.discrepancies[]` converts to `{location, issue, fix}` with planned-target fallback when `codeLocation` is `null`
+- **task-executor / -frontend: progress checkbox update conditional on file existence** (agents) — Task file is always updated; work plan and overall design are updated only when the corresponding files exist. At small scale only the task file exists, so the other two are skipped without escalation
+- **technical-designer / -frontend: Fact Disposition prose to 4-row table** (agents) — Disposition selection criteria (preserve / transform / remove / out-of-scope) reorganized into a table with columns for "when to use", "rationale must state", and "review-time mismatch flag". All four categories preserved
+- **technical-designer / -frontend: Implementation Approach Decision and AC guidelines tables** (agents) — Strategy selection (Vertical / Horizontal / Hybrid) and Verification Strategy by `design_type` rendered as tables. Acceptance Criteria Include / Exclude lists rendered as a 7-row table
+- **quality-fixer / -frontend: Output Format compression** (agents) — Four full per-status JSON examples replaced by a common envelope plus per-status field table plus one minimal example. Mermaid Fix Determination Flow removed (duplicated Fix Execution Policy). Debugging Hints and Correct Fix Patterns consolidated into a single Anti-patterns table
+- **task-executor / -frontend: Escalation Response common trunk** (agents) — Six full JSON examples replaced by a common envelope plus per-type contract table plus one minimal example
+- **All agents: Task Registration wording** (agents) — "first 'Confirm skill constraints', final 'Verify skill fidelity'" replaced with "first task 'Map preloaded skills to applicable concrete rules' and final task 'Verify the mapped rules before final JSON' (or 'before producing the final output' for document-producing agents)"
+- **Recipes: Scope Boundary for Subagents replaces MANDATORY suffix** (commands) — Old "[SYSTEM CONSTRAINT] within X skill scope" suffix replaced with a positive scope-boundary block (operate within task scope and referenced files; use loaded skills; escalate when out of scope). Inline per command, no centralization
+- **subagents-orchestration-guide: Subagent I/O table updates** (skills) — task-executor row carries the full `escalation_type` enum and Fix Mode signal description; quality-fixer row documents `filesModified`; integration-test-reviewer / security-reviewer rows describe Fix Mode routing (security-reviewer routes through a consolidated fix task file)
+- **task-decomposer: English canonical headings in generated tasks** (agents) — Task Structuring step explicitly instructs use of task-template's English headings (`## Target Files`, `## Investigation Targets`, `## Implementation Steps (TDD: Red-Green-Refactor)`, `## Quality Assurance Mechanisms`, `## Operation Verification Methods`, `## Completion Criteria`) with a note that headings are not translated, so executor extraction stays consistent across language environments
+- **task-template: machine-read identifiers preserved as English** (skills) — Section headings and `Metadata:` keys (`Dependencies:`, `Provides:`, `Size:`, `Deliverable:`) kept as English so executor parsing remains language-independent. Body prose remains natural Japanese
+- **JA mirror: routing markers naturalized in frontmatter** (agents) — "Use when / Use PROACTIVELY / MUST BE USED PROACTIVELY" replaced with natural Japanese ("使用するシーン: / 積極的に使用するシーン: / 必ず積極的に使用するシーン:"); keyword pairs that aid routing preserved
+- **JA mirror: terminology unified** (commands, skills) — `step N` → ステップN; `cross-layer` → レイヤー横断; `Layer-Aware Agent Routing` → レイヤー別エージェントルーティング; `INVOKE` → 呼び出す; `consolidated fix task file` → 統合修正タスクファイル; `stub-detection` → 未完成実装検出
+- **Compression of six largest agent files** (agents) — task-executor.md 459 → 315; task-executor-frontend.md 428 → 303; quality-fixer.md 409 → 275; quality-fixer-frontend.md 453 → 316; technical-designer.md 471 → 429; technical-designer-frontend.md 471 → 409. All decision criteria, escalation_types, Fix Mode contract, Gate ordering, and JSON schemas preserved
+
+### Fixed
+
+- **subagents-orchestration-guide: acceptance-test-generator I/O row information loss** (skills) — Restored fields lost in an earlier translation pass: `budgetUsage`, `integration: path|null` (was `string`), `e2eAbsenceReason` enum values (`no_multi_step_journey | below_threshold_user_confirmed`), and the "verify files exist" instruction
+- **task-executor / -frontend: typo** (agents) — テスト嚗空化 → テスト空洞化 in Step 2 Quality Standard Violation Check
+- **JA mirror: stale references and English residue** (agents, commands, skills) — Task Registration old wording, "JSON format is mandatory" boilerplate, "Output Self-Check" sections, and "Final response is the JSON output" checklist items removed in favor of the new Output Protocol / Self-Validation [BLOCKING] structure. Awkward spacing around contract terms (`ルーティング先のexecutor`, `executorをFix Mode`, `task-template を用いて 統合`) corrected
+
+## [1.20.8] - 2026-04-17
+
+### Added
+
+- **codebase-analyzer: Fact Disposition targets in focusAreas** (agents) — Step 4 enumerates existing facts within change scope. Schema expanded with `fact_id` (format: `<primary-file-path>:<symbol>`), `evidence` (single-form reference string), `factsToAddress` (designer checklist), and `relatedFiles` fields. Cross-layer canonical anchor rule: shared types/schemas/APIs referenced from multiple layers anchor `fact_id` to the canonical source file so per-layer analysis runs produce matching identifiers for the same concept. Priority ordering (branching outcomes > external contracts > domain invariants) with cardinality target 5-15 and explicit overflow handling
+- **technical-designer: Fact Disposition Table section** (agents) — Required when Codebase Analysis input is provided. Six-column table (Fact ID / Focus Area / Disposition / Rationale / Evidence / Related Files) with one row per `focusArea`. Dispositions: `preserve` / `transform` / `remove` / `out-of-scope` with specific selection criteria and rationale content guidance per value. Applied to both technical-designer and technical-designer-frontend
+- **document-reviewer: Fact Disposition coverage and semantic alignment checks** (agents) — New `codebase_analysis` input parameter. Gate 0 verifies Fact Disposition Table section presence. Gate 1 verifies row-level coverage of every `focusArea`, verbatim carry-through of `fact_id` / `evidence` / `relatedFiles`, and rationale-disposition semantic alignment using whole-phrase judgment with valid/invalid example patterns per disposition
+- **design-sync: Disposition conflict detection** (agents) — New extraction target for Fact Disposition Table rows as `(fact_id, disposition)` pairs. Critical conflict type detects same `fact_id` across documents carrying different `disposition` values. Detection scope explicitly documented: same-layer cross-DD conflicts and cross-layer conflicts sharing a common anchor file
+- **code-reviewer: Step 4-1 disposition implementation verification** (agents) — Post-implementation verification per disposition row. `remove` rows: cited symbol absent from production code path. `transform` rows: observable behavior matches rationale. `preserve` rows: observable behavior unchanged from pre-change state. `out-of-scope` rows: cited files not modified in the implementation diff. Mismatches produce `dd_violation` findings with specific rationale
+- **Cross-Layer Orchestration: serial backend-first flow with symmetric review gates** (skills) — Sequence updated to Backend design → verify → review → Frontend design → verify → review → design-sync. Both document-reviewer invocations carry `[Stop on critical issues]` to block structural defect propagation to the next layer. Backend verification output passed to the frontend designer as `prior_layer_verification`
+- **technical-designer-frontend: formal cross-layer inputs** (agents) — Required Information section adds Reviewed Prior-Layer Design Doc, Prior-Layer Review Findings, and Prior-Layer Verification as optional cross-layer-only inputs with explicit usage guidance
+- **Cross-Layer Assumptions mechanism** (agents, skills) — Designers record prior-layer claims the design must depend on when those claims remain unverified. Format: `- [claim]: [justification]; verify at [target]`. document-reviewer validates presence (when prior-layer dependencies exist) and verification-target presence per entry. design-template section added
+- **Design Doc template: Fact Disposition Table** (skills) — Six-column template added between Code Inspection Evidence and Design sections. L1/L2/L3 inline definition ("verification granularity tiers") added for self-documenting terminology
+
+### Changed
+
+- **Rationale-disposition alignment: semantic judgment over substring matching** (agents) — document-reviewer evaluates rationale as whole phrases against disposition semantics with valid/invalid example patterns per disposition. Eliminates false-positive risk where valid preserve phrasing (e.g., "no change", "unchanged") would have triggered on substring matches. Writer-side guidance in technical-designer and design-template updated symmetrically across all four dispositions
+- **Agent-to-agent and skill-to-skill decoupling** (agents, skills) — Direct agent name references replaced with artifact names, passive voice, or parameter names across 52 agent files. Dead skill pointers (references to skills not loaded in the reading context) removed or neutralized across skill files. In-context references that aid precision are preserved (e.g., `task-analyzer` routing table)
+- **Scope clarifiers for delegated work** (agents) — Cross-document consistency checks in technical-designer update mode explicitly marked "out of scope for this agent" to remove ambiguity about delegation
+
+### Removed
+
+- **Redundant CLAUDE.md context statement from all subagents** (agents) — Removed "Operates in an independent context without CLAUDE.md principles, executing autonomously until task completion." from 25 EN + 25 JA agent files. Subagents invoked via the Agent tool receive only their own system prompt, environment details, and frontmatter-declared skills — the parent's CLAUDE.md / project memory does not load. The removed statement restated the platform default and added no guidance. `rule-advisor` retains the description-level `(CLAUDE.md required process)` note since it references the caller's obligation, not its own context.
+
 ## [1.20.7] - 2026-04-12
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-ai-project",
-  "version": "1.20.7",
+  "version": "1.20.9",
   "packageManager": "npm@10.8.2",
   "description": "TypeScript boilerplate with skills and sub-agents for Claude Code. Prevents context exhaustion through role-based task splitting.",
   "keywords": [