create-ai-project 1.20.3 → 1.20.5

package/.claude/agents-en/codebase-analyzer.md

@@ -44,15 +44,19 @@ Design decisions, document creation, and solution proposals are out of scope for
 
 For each file in `affectedFiles`:
 
-1. **Read the file** and extract:
-   - Public interfaces, types, function signatures, class definitions
-   - Record exact names and signatures as they appear in code
-2. **Trace one level of dependencies**: Identify direct dependencies by reading the module's dependency declarations (import statements, use declarations, include directives — adapt to project language). Read each imported module's public interface
-3. **Pattern detection** (adapt search terms to project conventions):
+1. **Read the file in full** and extract every interface, type, function signature, class definition, and method definition at all visibility levels (public, private, internal — adapt terms to project language). Record exact names, visibility, and signatures as they appear in code
+2. **Trace call chains** with these scope rules (adapt visibility terms to project language — e.g., public/private, exported/unexported, pub/pub(crate)):
+   - Same module internal functions/methods: follow every call recursively until the chain terminates (returns, delegates to external, or reaches a leaf). If a chain spans more than 10 unique functions, record the traced portion and note the remainder in `limitations`
+   - External dependencies (imported modules, other packages): read the public interface only (signatures, contracts); record as an integration point but stop tracing into the external module's internals
+3. **Data transformation pipeline detection**: Prioritize entry points relevant to the requirement (as identified in `affectedFiles` and `purpose`). For each such entry point that receives input from outside the module (API handlers, exported service functions called by other modules, CLI entry points), trace how input data is transformed step by step through the call chain. If additional entry points are discovered that share the same output path or transformation logic, include them or record them in `limitations`:
+   - Record each transformation step (what changes, what format/value mapping occurs)
+   - Record external resource lookups that modify values (master table references, configuration lookups, constant substitutions)
+   - Record intermediate data formats (if data passes through a different representation before final output)
+4. **Pattern detection** (adapt search terms to project conventions):
    - Data access: Grep for patterns indicating database operations (query, select, insert, update, delete, find, save, create, repository, model, schema, migration, table, column, entity, record)
    - External integration: Grep for patterns indicating external calls (http, fetch, client, api, endpoint, request, response)
    - Validation: Grep for patterns indicating constraints (validate, check, assert, constraint, rule, require, ensure)
-4. Record each discovered element with file path and line number
+5. Record each discovered element with file path and line number
 
 ### Step 3: Schema and Data Model Discovery
 
@@ -95,9 +99,10 @@ Return the JSON result as the final response. See Output Format for the schema.
   },
   "existingElements": [
     {
-      "category": "interface|type|function|class|constant|configuration",
+      "category": "interface|type|function|method|class|constant|configuration",
       "name": "ElementName",
       "filePath": "path/to/file:lineNumber",
+      "visibility": "public|private|internal",
       "signature": "brief signature or definition",
       "usedBy": ["path/to/consumer1"]
     }
@@ -130,6 +135,23 @@ Return the JSON result as the final response. See Output Format for the schema.
     ],
     "migrationFiles": ["path/to/migration/files"]
   },
+  "dataTransformationPipelines": [
+    {
+      "entryPoint": "ClassName.methodName (file:line)",
+      "steps": [
+        {
+          "order": 1,
+          "method": "methodName (file:line)",
+          "input": "description of input data/format",
+          "output": "description of output data/format",
+          "externalLookups": ["MasterTable.getData() for code conversion"],
+          "transformation": "what changes (e.g., raw value mapped to display value via lookup table)"
+        }
+      ],
+      "intermediateFormats": ["description of intermediate data representation if any"],
+      "finalOutput": "description of final output data/format"
+    }
+  ],
   "constraints": [
     {
       "type": "validation|business_rule|configuration|assumption",
@@ -157,8 +179,10 @@ Return the JSON result as the final response. See Output Format for the schema.
 ## Completion Criteria
 
 - [ ] Parsed requirement analysis output and identified analysis categories
-- [ ] Read all affected files and extracted public interfaces with file:line references
-- [ ] Traced one level of imports for each affected file
+- [ ] Read all affected files in full and extracted every interface, type, function, method, and class at all visibility levels (public, private, internal) with file:line references — or recorded incomplete files in `limitations`
+- [ ] Traced call chains per scope rules (same-file: recursive; external: public interface only) — or recorded incomplete traces in `limitations`
+- [ ] Identified data transformation pipelines with step-by-step input→output mapping for each public entry point
+- [ ] Recorded every external resource lookup (master tables, config, constants) that modifies output values
 - [ ] Searched for data access, external integration, and validation patterns using Grep
 - [ ] When data access detected: traced to schema definitions and extracted field-level details
 - [ ] Extracted constraints with file:line evidence
@@ -173,4 +197,6 @@ Return the JSON result as the final response. See Output Format for the schema.
 - [ ] Schema field names match actual definitions (not inferred from similar tables)
 - [ ] Each focus area cites specific files and concrete risks
 - [ ] `dataModel.detected` accurately reflects whether data operations were found
+- [ ] `dataTransformationPipelines` populated for every entry point that transforms data (empty array only when no transformations exist)
+- [ ] Each pipeline step's `externalLookups` lists all master table / config / constant references that modify output values
 - [ ] Limitations section documents any files that could not be read or patterns that could not be traced

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

@@ -106,6 +106,7 @@ For DesignDoc, additionally verify:
   - Verification method is sufficient for the change's risk and dependency type — method that cannot detect the primary risk category (e.g., schema correctness, behavioral equivalence, integration compatibility) → `important` issue (category: `consistency`)
   - Early verification point identifies a concrete first target — "TBD" or "final phase" → `important` issue (category: `completeness`)
   - When vertical slice is selected, verification timing deferred entirely to final phase → `important` issue (category: `consistency`)
+- **Output comparison check**: When the Design Doc describes replacing or modifying existing behavior, verify that a concrete output comparison method is defined (identical input, expected output fields/format, diff method). Missing output comparison for changes that replace or modify existing behavior → `critical` issue (category: `completeness`). When codebase analysis `dataTransformationPipelines` are referenced, verify each pipeline step's output is covered by the comparison — uncovered steps → `important` issue (category: `completeness`)
 
 **Perspective-specific Mode**:
 - Implement review based on specified mode and focus
@@ -263,6 +264,7 @@ Include in output when `prior_context_count > 0`:
 - [ ] Code verification results (if provided) reconciled with document content
 - [ ] Verification Strategy present with concrete correctness definition and early verification point
 - [ ] Verification Strategy aligns with design_type and implementation approach
+- [ ] Output comparison defined when design replaces/modifies existing behavior (covers all transformation pipeline steps)
 
 ## Review Criteria (for Comprehensive Mode)
 

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

@@ -62,7 +62,7 @@ Must be performed before Design Doc creation:
    - Record and distinguish between existing implementation locations and planned new locations
 
 2. **Existing Interface Investigation** (Only when changing existing features)
-   - List major public methods of target service (about 5 important ones if over 10)
+   - List every public method of target service with full signatures
    - Identify call sites with `Grep: "ServiceName\." --type ts`
 
 3. **Similar Functionality Search and Decision** (Pattern 5 prevention from coding-standards skill)
@@ -153,7 +153,8 @@ Must be performed when creating Design Doc:
    - For new_feature: specify AC verification method beyond unit tests (e.g., integration test against real dependencies)
    - For extension: specify regression verification method that proves existing behavior is preserved while new behavior is added
    - For refactoring: specify behavioral equivalence verification method (e.g., output comparison with existing implementation)
-   - Define early verification point: what is the first thing to verify, and how, to confirm the approach is correct before scaling
+   - **Output comparison requirement** (all design_types that replace or modify existing behavior): Define concrete output comparison method — specify identical input, expected output fields/format, and how to diff. When codebase analysis provides `dataTransformationPipelines`, each pipeline step's output must be covered by the comparison
+   - Define early verification point: what is the first thing to verify, and how, to confirm the approach is correct before scaling. For replacements/modifications, the default early verification point is an output comparison of at least one representative case. Exception: when the primary risk is not behavioral equivalence (e.g., schema compatibility, integration contract) — in that case, specify the alternative verification target and document why output comparison is deferred
 
 ### Change Impact Map【Required】
 Must be included when creating Design Doc:
@@ -214,6 +215,7 @@ Document state definitions and transitions for stateful components.
   - `dataModel` → populate data-related sections (schema references, data contracts)
   - `focusAreas` → prioritize investigation depth on flagged areas
   - `constraints` → incorporate into design constraints and assumptions
+  - `dataTransformationPipelines` → populate Verification Strategy's Output Comparison section (each pipeline step must be covered by the comparison method)
   - Conduct additional investigation only for areas not covered by the analysis or flagged in `limitations`
 - **PRD**: PRD document (if exists)
 - **Documents to Create**: ADR, Design Doc, or both
@@ -309,6 +311,7 @@ Implementation sample creation checklist:
 - [ ] **Data representation decision documented** (when new structures introduced)
 - [ ] **Field propagation map included** (when fields cross boundaries)
 - [ ] **Verification Strategy defined** (correctness definition, verification method, timing, early verification point)
+- [ ] **Output comparison defined** when replacing/modifying existing behavior (input, expected output fields, diff method; covers all transformation pipeline steps from codebase analysis)
 
 **Reverse-engineer mode only**:
 - [ ] Every architectural claim cites file:line as evidence

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

@@ -45,10 +45,26 @@ Choose Strategy A (TDD) if test skeletons are provided, Strategy B (implementati
 
 **Phase structure**: Select based on implementation approach from Design Doc. See Phase Division Criteria in documentation-criteria skill for detailed definitions. Use plan-template Option A (Vertical) or Option B (Horizontal) accordingly. For hybrid, use Option A as the base and add horizontal foundation phases where needed.
 
-### 5. Define Tasks with Completion Criteria
+### 5. Map DD Technical Requirements to Tasks
+
+Scan the provided Design Doc section by section. Use the category table below as a checklist to extract items:
+
+| Category | What to Look For |
+|---|---|
+| impl-target | Components, functions, or data structures to create or modify |
+| connection-switching | Integration points, dependency wiring, switching methods |
+| contract-change | Interface changes, data contract changes, field propagation across boundaries |
+| verification | Verification methods, test boundaries, integration verification points, Verification Method column in Integration Points List |
+| prerequisite | Migration steps, security measures, environment setup |
+
+Map each extracted item to a covering task. Items may be covered by a dedicated task or included within a broader task — both are valid, but the mapping must be explicit. Record the mapping in the Design-to-Plan Traceability table (see plan template) using the category values from the left column above.
+
+If an item has no covering task, set Gap Status to `gap` with justification in Notes. **When the Traceability table contains any `gap` entry, the plan is in draft status.** Output the plan as draft, but do not finalize it until the user has confirmed each justified gap. Unjustified gaps (no Notes) are errors — add a covering task or provide justification before proceeding.
+
+### 6. Define Tasks with Completion Criteria
 For each task, derive completion criteria from Design Doc acceptance criteria. Apply the 3-element completion definition (Implementation Complete, Quality Complete, Integration Complete).
 
-### 6. Produce Work Plan Document
+### 7. Produce Work Plan Document
 Write the work plan following the plan template from documentation-criteria skill. Include Phase Structure Diagram and Task Dependency Diagram (mermaid).
 
 ## Input Parameters
@@ -73,7 +89,7 @@ Write the work plan following the plan template from documentation-criteria skil
 3. **Deletion**: Delete after all tasks complete with user approval
 
 ## Output Policy
-Execute file output immediately (considered approved at execution).
+Execute file output immediately (considered approved at execution). **Exception**: When the Traceability table contains `gap` entries, output the plan as draft and request user confirmation for each gap before finalizing.
 
 ## Important Task Design Principles
 
@@ -221,6 +237,9 @@ When creating work plans, **Phase Structure Diagrams** and **Task Dependency Dia
 ## Quality Checklist
 
 - [ ] Design Doc(s) consistency verification
+- [ ] Design-to-Plan Traceability table complete (all DD technical requirements categorized and mapped)
+  - [ ] No `gap` entries without justification
+  - [ ] All justified `gap` entries flagged for user confirmation before plan approval
 - [ ] Verification Strategy extracted from Design Doc and included in plan header
 - [ ] Phase structure matches implementation approach (vertical → value unit phases, horizontal → layer phases)
 - [ ] Early verification point placed in Phase 1 (when Verification Strategy specifies one)

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

@@ -44,15 +44,19 @@ skills: coding-standards, project-context, technical-spec
 
 `affectedFiles`の各ファイルに対して:
 
-1. **ファイルを読み込み**、以下を抽出:
-   - publicインターフェース、型、関数シグネチャ、クラス定義
-   - コード上の正確な名前とシグネチャを記録
-2. **1階層の依存関係をトレース**: モジュールの依存宣言（import文、use宣言、includeディレクティブ — プロジェクト言語に適応）から直接依存先を特定。各インポートモジュールのpublicインターフェースを読み込み
-3. **パターン検出**（プロジェクト規約に合わせて検索語を適応）:
+1. **ファイルを全文読み込み**、全可視性レベル（public, private, internal — 用語はプロジェクト言語に適応）のインターフェース、型、関数シグネチャ、クラス定義、メソッド定義をすべて抽出する。コード上の正確な名前、可視性、シグネチャを記録
+2. **コールチェーンのトレース**（可視性の用語はプロジェクト言語に適応 — 例: public/private, exported/unexported, pub/pub(crate)）:
+   - 同一モジュール内の関数/メソッド: チェーンが終端するまで（return、外部への委譲、リーフ到達）すべての呼び出しを再帰的にたどる。チェーンが10個を超えるユニークな関数にまたがる場合、トレース済み部分を記録し残りを`limitations`に記載
+   - 外部依存（インポートされたモジュール、他パッケージ）: publicインターフェースのみ読み込み（シグネチャ、コントラクト）。統合ポイントとして記録するが、外部モジュール内部へのトレースは行わない
+3. **データ変換パイプラインの検出**: 要件に関連するエントリポイント（`affectedFiles`と`purpose`で特定されたもの）を優先する。モジュール外部から入力を受け取る各該当エントリポイント（APIハンドラー、他モジュールから呼び出されるエクスポート済みサービス関数、CLIエントリポイント）について、コールチェーンを通じて入力データがどう変換されるかをステップごとにトレースする。同じ出力パスや変換ロジックを共有する追加エントリポイントが発見された場合は含めるか、`limitations`に記録:
+   - 各変換ステップを記録（何が変わるか、どのようなフォーマット/値のマッピングが行われるか）
+   - 値を変更する外部リソース参照を記録（マスタテーブル参照、設定値の参照、定数の置換）
+   - 中間データフォーマットを記録（最終出力前に別の表現を経由する場合）
+4. **パターン検出**（プロジェクト規約に合わせて検索語を適応）:
    - データアクセス: データベース操作を示すパターンをGrep（query, select, insert, update, delete, find, save, create, repository, model, schema, migration, table, column, entity, record）
    - 外部統合: 外部呼び出しを示すパターンをGrep（http, fetch, client, api, endpoint, request, response）
    - バリデーション: 制約を示すパターンをGrep（validate, check, assert, constraint, rule, require, ensure）
-4. 発見した各要素をファイルパスと行番号付きで記録
+5. 発見した各要素をファイルパスと行番号付きで記録
 
 ### ステップ3: スキーマとデータモデルの発見
 
@@ -95,9 +99,10 @@ skills: coding-standards, project-context, technical-spec
   },
   "existingElements": [
     {
-      "category": "interface|type|function|class|constant|configuration",
+      "category": "interface|type|function|method|class|constant|configuration",
       "name": "要素名",
       "filePath": "path/to/file:行番号",
+      "visibility": "public|private|internal",
       "signature": "シグネチャまたは定義の概要",
       "usedBy": ["path/to/consumer1"]
     }
@@ -130,6 +135,23 @@ skills: coding-standards, project-context, technical-spec
     ],
     "migrationFiles": ["path/to/migration/files"]
   },
+  "dataTransformationPipelines": [
+    {
+      "entryPoint": "ClassName.methodName (file:line)",
+      "steps": [
+        {
+          "order": 1,
+          "method": "methodName (file:line)",
+          "input": "入力データ/フォーマットの説明",
+          "output": "出力データ/フォーマットの説明",
+          "externalLookups": ["MasterTable.getData() でコード変換"],
+          "transformation": "何が変わるか（例: 生値がルックアップテーブル経由で表示値にマッピング）"
+        }
+      ],
+      "intermediateFormats": ["中間データ表現の説明（該当する場合）"],
+      "finalOutput": "最終出力データ/フォーマットの説明"
+    }
+  ],
   "constraints": [
     {
       "type": "validation|business_rule|configuration|assumption",
@@ -157,8 +179,10 @@ skills: coding-standards, project-context, technical-spec
 ## 完了条件
 
 - [ ] 入力された要件分析結果を解析し分析カテゴリを特定した
-- [ ] 全影響ファイルを読み込み、file:line参照付きでpublicインターフェースを抽出した
-- [ ] 各影響ファイルの1階層のインポートをトレースした
+- [ ] 全影響ファイルを全文読み込み、file:line参照付きですべてのインターフェース、型、関数、メソッド、クラスを全可視性レベル（public, private, internal）で抽出した — または不完全なファイルを`limitations`に記録した
+- [ ] スコープルールに従いコールチェーンをトレースした（同一ファイル: 再帰的、外部: publicインターフェースのみ） — または不完全なトレースを`limitations`に記録した
+- [ ] 各publicエントリポイントについてステップごとの入力→出力マッピングでデータ変換パイプラインを特定した
+- [ ] 出力値を変更するすべての外部リソース参照（マスタテーブル、設定値、定数）を記録した
 - [ ] Grepでデータアクセス、外部統合、バリデーションパターンを検索した
 - [ ] データアクセス検出時: スキーマ定義をトレースしフィールドレベルの詳細を抽出した
 - [ ] file:lineエビデンス付きで制約を抽出した
@@ -173,4 +197,6 @@ skills: coding-standards, project-context, technical-spec
 - [ ] スキーマフィールド名が実際の定義と一致（類似テーブルからの推測ではない）
 - [ ] 各注目領域が具体的なファイルと具体的なリスクを引用
 - [ ] `dataModel.detected`がデータ操作の検出有無を正確に反映
+- [ ] `dataTransformationPipelines`がデータを変換するすべてのエントリポイントについて記録されている（変換が存在しない場合のみ空配列）
+- [ ] 各パイプラインステップの`externalLookups`が出力値を変更するすべてのマスタテーブル/設定値/定数参照を列挙
 - [ ] limitationsセクションが読み込めなかったファイルやトレースできなかったパターンを記録

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

@@ -106,6 +106,7 @@ DesignDocの場合、追加で以下を確認:
   - 検証手法が変更のリスクと依存タイプに対して十分であること — 主要なリスクカテゴリ（スキーマの正しさ、振る舞いの同等性、統合互換性等）を検出できない手法 → `important`（カテゴリ: `consistency`）
   - 早期検証ポイントが具体的な最初の対象を特定していること — 「TBD」や「最終フェーズ」→ `important`（カテゴリ: `completeness`）
   - 垂直スライス選択時に、検証タイミングが最終フェーズのみに後回し → `important`（カテゴリ: `consistency`）
+- **出力比較チェック**: Design Docが既存の振る舞いの置換または変更を記述している場合、具体的な出力比較手法が定義されていることを検証する（同一入力、期待される出力フィールド/フォーマット、差分比較方法）。既存の振る舞いを置換または変更する設計で出力比較が未定義 → `critical`（カテゴリ: `completeness`）。コードベース分析の`dataTransformationPipelines`が参照されている場合、各パイプラインステップの出力が比較対象としてカバーされていること — 未カバーのステップ → `important`（カテゴリ: `completeness`）
 
 **観点特化モード**:
 - 指定されたmodeとfocusに基づいてレビューを実施
@@ -263,6 +264,7 @@ DesignDocの場合、追加で以下を確認:
 - [ ] コード検証結果（提供された場合）がドキュメント内容と照合済み
 - [ ] 検証戦略に具体的な正しさの定義と早期検証ポイントが存在すること
 - [ ] 検証戦略がdesign_typeと実装アプローチに整合していること
+- [ ] 既存の振る舞いを置換/変更する設計で出力比較が定義されていること（全変換パイプラインステップをカバー）
 
 ## レビュー基準（総合モード用）
 

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

@@ -62,7 +62,7 @@ Design Doc作成前に必ず実施：
    - 既存実装の場所と新規作成予定の場所を区別して記録
 
 2. **既存インターフェース調査**（既存機能変更時のみ）
-   - 変更対象サービスの主要publicメソッドを列挙（10個超の場合は重要な5個程度）
+   - 変更対象サービスのすべてのpublicメソッドを完全なシグネチャ付きで列挙
    - `Grep: "ServiceName\." --type ts` で呼び出し箇所を特定
 
 3. **類似機能の検索と判断**（coding-standardsスキル パターン5対策）
@@ -153,7 +153,8 @@ Design Doc作成時に必ず実施：
    - new_featureの場合: ユニットテスト以上のAC検証手法を明記（例: 実依存に対する統合テスト）
    - extensionの場合: 既存の振る舞いが維持されつつ新しい振る舞いが追加されることを証明する回帰検証手法を明記
    - refactoringの場合: 振る舞いの同等性を検証する手法を明記（例: 既存実装との出力比較）
-   - 早期検証ポイントを定義: アプローチの妥当性を本格展開前に確認するため、最初に何を、どうやって検証するか
+   - **出力比較要件**（既存の振る舞いを置換または変更するすべてのdesign_type）: 具体的な出力比較手法を定義する — 同一入力、期待される出力フィールド/フォーマット、差分の比較方法を明記。コードベース分析から`dataTransformationPipelines`が提供されている場合、各パイプラインステップの出力が比較の対象としてカバーされていること
+   - 早期検証ポイントを定義: アプローチの妥当性を本格展開前に確認するため、最初に何を、どうやって検証するか。置換/変更の場合、早期検証ポイントのデフォルトは少なくとも1つの代表的なケースでの出力比較とする。例外: 主要リスクが振る舞いの同等性以外にある場合（例: スキーマ互換性、統合コントラクト）は代替の検証対象を明記し、出力比較を後段に回す理由を記録
 
 ### 変更影響マップ【必須】
 Design Doc作成時に必ず含める:
@@ -214,6 +215,7 @@ Design Doc作成前に実施：
   - `dataModel` → データ関連セクション（スキーマ参照、データ契約）に反映
   - `focusAreas` → フラグされた領域の調査深度を優先
   - `constraints` → 設計上の制約と前提条件に組み込む
+  - `dataTransformationPipelines` → 検証戦略の出力比較セクションに反映（各パイプラインステップが比較手法でカバーされていること）
   - 分析でカバーされていない領域、または`limitations`でフラグされた領域についてのみ追加調査を実施
 - **PRD**: PRDドキュメント（存在する場合）
 - **作成するドキュメント**: ADR、Design Doc、または両方
@@ -308,6 +310,7 @@ ADRに含まない：スケジュール、実装手順、具体的コード
 - [ ] **データ構造の採用判断の文書化**（新規構造導入時）
 - [ ] **フィールド伝播マップの記載**（フィールドが境界を越える場合）
 - [ ] **検証戦略の定義**（正しさの定義、検証手法、タイミング、早期検証ポイント）
+- [ ] **出力比較の定義**（既存の振る舞いを置換/変更する場合）（入力、期待される出力フィールド、差分比較方法。コードベース分析の全変換パイプラインステップをカバー）
 
 **reverse-engineerモード限定**:
 - [ ] すべてのアーキテクチャ主張がfile:lineをevidenceとして引用

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

@@ -45,10 +45,26 @@ Design Doc、UI Spec、PRD、ADR（提供されている場合）を読み込み
 
 **フェーズ構成**: Design Docの実装アプローチに基づいて選択。詳細はdocumentation-criteriaスキルのフェーズ分割基準を参照。plan-templateのOption A（垂直）またはOption B（水平）に従う。ハイブリッドの場合はOption Aをベースに、必要に応じて水平基盤フェーズを追加する。
 
-### 5. 完了条件付きタスクの定義
+### 5. DD技術要件のタスクへのマッピング
+
+提供されたDesign Docをセクションごとにスキャンする。以下のカテゴリテーブルをチェックリストとして、該当する項目を抽出する:
+
+| カテゴリ | 抽出対象 |
+|---|---|
+| impl-target | 作成・変更が必要なコンポーネント、関数、データ構造 |
+| connection-switching | 統合ポイント、依存関係の配線、切替方式 |
+| contract-change | インターフェース変更、データコントラクト変更、境界を越えるフィールドの伝搬 |
+| verification | 検証手法、テスト境界、統合検証ポイント、統合ポイント一覧の検証方式列 |
+| prerequisite | マイグレーション手順、セキュリティ対策、環境セットアップ |
+
+抽出した各項目をカバーするタスクにマッピングする。専用タスクでカバーしても、より包括的なタスクに内包してもよいが、マッピングは必ず明示すること。マッピング結果は計画テンプレートの設計-計画トレーサビリティ表に、上記左列のカテゴリ値を使用して記録する。
+
+カバーするタスクがない項目はギャップステータスを`gap`とし、備考に理由を記載する。**トレーサビリティ表に`gap`が1件でも含まれる場合、計画書はドラフト状態とする。** ドラフトとして出力するが、ユーザーが各ギャップを確認するまで確定しない。理由なしのギャップ（備考が空）はエラーとして扱い、カバーするタスクを追加するか理由を記載してから進める。
+
+### 6. 完了条件付きタスクの定義
 各タスクについて、Design Docの受入条件から完了条件を導出。3要素の完了定義（実装完了、品質完了、統合完了）を適用。
 
-### 6. 作業計画書の作成
+### 7. 作業計画書の作成
 documentation-criteriaスキルの計画テンプレートに従って作業計画書を記述。フェーズ構成図とタスク依存関係図（mermaid）を含める。
 
 ## Input Parameters
@@ -72,7 +88,7 @@ documentation-criteriaスキルの計画テンプレートに従って作業計
 2. **更新**: 各フェーズ完了時に進捗更新（チェックボックス）
 3. **削除**: 全タスク完了後、ユーザー承認を得て削除
 ## 出力方針
-ファイル出力は即座に実行（実行時点で承認済み）。
+ファイル出力は即座に実行（実行時点で承認済み）。**例外**: トレーサビリティ表に`gap`が含まれる場合は、計画書をドラフトとして出力し、各ギャップについてユーザー確認を得てから確定する。
 
 ## タスク設計の重要原則
 
@@ -220,6 +236,9 @@ Design Docの技術的依存関係と実装アプローチに基づいてフェ
 ## 品質チェックリスト
 
 - [ ] Design Doc（複数時は各Doc）の整合性確認
+- [ ] 設計-計画トレーサビリティ表の完成（DDの全技術要件がカテゴリ分類・マッピング済み）
+  - [ ] 理由なしの`gap`がないこと
+  - [ ] 理由ありの`gap`は計画承認前にユーザー確認を実施
 - [ ] Design Docから検証戦略を抽出し計画書ヘッダーに記載
 - [ ] フェーズ構成が実装アプローチと整合（垂直 → 価値単位フェーズ、水平 → レイヤーフェーズ）
 - [ ] 早期検証ポイントをPhase 1に配置（検証戦略で指定されている場合）

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

@@ -120,6 +120,12 @@ No Ripple Effect:
   - [Explicitly specify unaffected features]
 ```
 
+### Interface Change Matrix
+
+| Existing | New | Conversion Required | Compatibility Method |
+|----------|-----|--------------------|--------------------|
+| [Function/method/operation name] | [Function/method/operation name] | [Yes/No] | [Approach: adapter, wrapper, deprecation, etc.] |
+
 ### Architecture Overview
 
 [How this feature is positioned within the overall system]
@@ -132,10 +138,10 @@ No Ripple Effect:
 
 ### Integration Points List
 
-| Integration Point | Location | Old Implementation | New Implementation | Switching Method |
-|-------------------|----------|-------------------|-------------------|------------------|
-| Integration Point 1 | [Class/Function] | [Existing Process] | [New Process] | [DI/Factory etc.] |
-| Integration Point 2 | [Another Location] | [Existing] | [New] | [Method] |
+| Integration Point | Location | Old Implementation | New Implementation | Switching Method | Verification Method |
+|-------------------|----------|-------------------|-------------------|------------------|-------------------|
+| Integration Point 1 | [Class/Function] | [Existing Process] | [New Process] | [DI/Factory etc.] | [How to verify this switching works] |
+| Integration Point 2 | [Another Location] | [Existing] | [New] | [Method] | [Verification approach] |
 
 ### Main Components
 
@@ -305,6 +311,17 @@ What is verified first, and how, to confirm the approach is correct before scali
 - **Success criteria**: [Observable outcome — e.g., "CSV download produces identical output to legacy", "API returns 200 with expected schema"]
 - **Failure response**: [What to do if early verification fails — e.g., "reassess approach before proceeding", "escalate to user"]
 
+### Output Comparison (When Replacing or Modifying Existing Behavior)
+
+How will behavioral equivalence be verified between existing and new implementation?
+
+- **Comparison input**: [Identical input used for both implementations — e.g., "same DB snapshot", "same API request payload"]
+- **Expected output fields**: [Specific fields/columns to compare — e.g., "all output columns", "response body fields: id, status, amount"]
+- **Diff method**: [How to compare — e.g., "file-level diff", "JSON field-by-field comparison", "row count + spot check"]
+- **Transformation pipeline coverage**: [Each step from codebase analysis `dataTransformationPipelines` and what the comparison covers]
+
+Mark as N/A with brief rationale when the design introduces entirely new behavior with no existing equivalent.
+
 ## Alternative Solutions
 
 ### Alternative 1

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

@@ -24,6 +24,19 @@ Related Issue/PR: #XXX (if any)
 - **Success criteria**: [extracted from Design Doc]
 - **Failure response**: [extracted from Design Doc]
 
+## Design-to-Plan Traceability
+
+Maps each Design Doc technical requirement to the covering task(s). One row per extracted item. Every row must have at least one covering task, or an explicit gap justification.
+
+| DD Section | DD Item | Category | Covered By Task(s) | Gap Status | Notes |
+|---|---|---|---|---|---|
+| [Section name from DD] | [Specific item] | impl-target / connection-switching / contract-change / verification / prerequisite | [Phase X Task Y] | covered | |
+| Security Considerations | Input validation for API | prerequisite | — | gap | Deferred to Phase 2 per user decision |
+
+**Category values**: `impl-target` (implementation target), `connection-switching` (connection/switching/registration), `contract-change` (contract change and propagation), `verification` (verification requirement), `prerequisite` (prerequisite work)
+
+**Gap Status values**: `covered` (task exists), `gap` (no task — requires justification in Notes, user confirmation required before plan approval)
+
 ## Objective
 [Why this change is necessary, what problem it solves]
 

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

@@ -292,7 +292,7 @@ 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` and `dataModel` to inform the Existing Codebase Analysis section.
+   **Pass to technical-designer**: codebase-analyzer JSON output as additional context in the Design Doc creation prompt. The designer uses `focusAreas`, `dataModel`, and `dataTransformationPipelines` to inform the Existing Codebase Analysis and Verification Strategy sections.
 
    #### code-verifier → document-reviewer (Design Doc review)
 
@@ -301,7 +301,13 @@ Construct the prompt from the agent's Input Parameters section and the deliverab
 
    #### technical-designer → work-planner
 
-   **Pass to work-planner**: Design Doc path. Work-planner extracts Verification Strategy from the Design Doc and includes it in the work plan header.
+   **Pass to work-planner**: Design Doc path. Work-planner scans all DD sections and extracts technical requirements per its Step 5 categories (impl-target, connection-switching, contract-change, verification, prerequisite), then produces a Design-to-Plan Traceability table.
+
+   **Gap handling (orchestrator responsibility)**: If work-planner outputs a draft plan containing `gap` entries, the orchestrator MUST:
+   1. Present the gap entries to the user with justifications
+   2. Keep the plan in draft status until the user confirms each gap
+   3. Do NOT pass the plan to downstream agents (task-decomposer, etc.) until all gaps are resolved or confirmed
+   Unjustified gaps are errors — return to work-planner to add covering tasks or justification.
 
    #### *1 acceptance-test-generator → work-planner
 

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

@@ -120,6 +120,12 @@ unknowns:
   - [明示的に影響を受けない機能]
 ```
 
+### インターフェース変更マトリクス
+
+| 既存 | 新規 | 変換要否 | 互換方式 |
+|------|------|---------|---------|
+| [関数/メソッド/操作名] | [関数/メソッド/操作名] | [Yes/No] | [手法: adapter, wrapper, deprecation等] |
+
 ### アーキテクチャ概要
 
 [この機能がシステム全体の中でどのように位置づけられるか]
@@ -132,10 +138,10 @@ unknowns:
 
 ### 統合ポイント一覧
 
-| 統合ポイント | 箇所 | 旧実装 | 新実装 | 切替方式 |
-|------------|-----|-------|-------|---------|
-| 統合ポイント1 | [クラス/関数] | [既存処理] | [新処理] | [DI/Factoryなど] |
-| 統合ポイント2 | [別の箇所] | [既存] | [新規] | [方式] |
+| 統合ポイント | 箇所 | 旧実装 | 新実装 | 切替方式 | 検証方式 |
+|------------|-----|-------|-------|---------|---------|
+| 統合ポイント1 | [クラス/関数] | [既存処理] | [新処理] | [DI/Factoryなど] | [この切替が動作することの検証方法] |
+| 統合ポイント2 | [別の箇所] | [既存] | [新規] | [方式] | [検証方法] |
 
 ### 主要コンポーネント
 
@@ -311,6 +317,17 @@ unknowns:
 - **成功基準**: [観察可能な成果 — 例: 「CSVダウンロードが既存と同一の出力を生成」「APIが期待スキーマで200を返す」]
 - **失敗時の対応**: [早期検証が失敗した場合の対処 — 例: 「続行前にアプローチを再評価」「ユーザーにエスカレーション」]
 
+### 出力比較（既存の振る舞いを置換または変更する場合）
+
+既存実装と新実装の振る舞いの同等性をどう検証するか?
+
+- **比較入力**: [両実装に対して使用する同一入力 — 例: 「同一DBスナップショット」「同一APIリクエストペイロード」]
+- **期待される出力フィールド**: [比較対象の具体的なフィールド/カラム — 例: 「全出力カラム」「レスポンスボディのフィールド: id, status, amount」]
+- **差分比較方法**: [比較手法 — 例: 「ファイルレベルのdiff」「JSONフィールド単位の比較」「行数 + スポットチェック」]
+- **変換パイプラインカバレッジ**: [コードベース分析の`dataTransformationPipelines`の各ステップと、比較がカバーする範囲]
+
+既存の同等物がなく完全に新規の振る舞いを導入する場合は、簡潔な理由とともにN/Aと記載。
+
 ## 代替案
 
 ### 代替案1

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

@@ -24,6 +24,19 @@
 - **成功基準**: [Design Docから抽出]
 - **失敗時の対応**: [Design Docから抽出]
 
+## 設計-計画トレーサビリティ
+
+Design Docの各技術要件をカバーするタスクへのマッピング。抽出した項目ごとに1行。各行には対応タスクが少なくとも1つ必要。タスクがない場合は明示的なギャップ理由が必要。
+
+| DDセクション | DD項目 | カテゴリ | カバーするタスク | ギャップステータス | 備考 |
+|---|---|---|---|---|---|
+| [DDのセクション名] | [具体的な項目] | impl-target / connection-switching / contract-change / verification / prerequisite | [Phase X タスクY] | covered | |
+| セキュリティ考慮事項 | APIの入力バリデーション | prerequisite | — | gap | ユーザー判断によりPhase 2に延期 |
+
+**カテゴリ値**: `impl-target`（実装対象）、`connection-switching`（接続/切替/登録）、`contract-change`（コントラクト変更と伝搬）、`verification`（検証要件）、`prerequisite`（前提作業）
+
+**ギャップステータス値**: `covered`（タスクあり）、`gap`（タスクなし — 備考に理由必須、計画承認前にユーザー確認が必要）
+
 ## 目的
 [なぜこの変更が必要か、何を解決するか]
 

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

@@ -288,7 +288,7 @@ requirement-analyzerが複数レイヤー（backend + frontend）にまたがる
    #### codebase-analyzer → technical-designer
 
    **codebase-analyzerへの入力**: 要件分析JSON出力、PRDパス（存在する場合）、元のユーザー要件
-   **technical-designerへの入力**: codebase-analyzerのJSON出力をDesign Doc作成プロンプトの追加コンテキストとして渡す。designerは`focusAreas`と`dataModel`を「既存コードベース分析」セクションに反映する。
+   **technical-designerへの入力**: codebase-analyzerのJSON出力をDesign Doc作成プロンプトの追加コンテキストとして渡す。technical-designerは`focusAreas`、`dataModel`、`dataTransformationPipelines`を「既存コードベース分析」セクションおよび「検証戦略」セクションに反映する。
 
    #### code-verifier → document-reviewer（Design Docレビュー）
 
@@ -297,7 +297,13 @@ requirement-analyzerが複数レイヤー（backend + frontend）にまたがる
 
    #### technical-designer → work-planner
 
-   **work-plannerへの入力**: Design Docパス。work-plannerがDesign Docから検証戦略を抽出し、作業計画書ヘッダーに記載する。
+   **work-plannerへの入力**: Design Docパス。work-plannerがDDの全セクションをスキャンし、Step 5のカテゴリ（impl-target, connection-switching, contract-change, verification, prerequisite）に沿って技術要件を抽出した上で、設計-計画トレーサビリティ表を作成する。
+
+   **ギャップ発生時の制御（オーケストレーターの責務）**: work-plannerが`gap`を含むドラフト計画書を出力した場合、オーケストレーターは以下を実行する:
+   1. ギャップ項目と理由をユーザーに提示する
+   2. ユーザーが各ギャップを確認するまで計画書をドラフト状態に保つ
+   3. 全ギャップの解消または確認が完了するまで、後続エージェント（task-decomposer等）に計画書を渡さない
+   理由なしのギャップはエラーとして扱い、work-plannerに差し戻してカバーするタスクの追加または理由の記載を求める。
 
    #### *1 acceptance-test-generator → work-planner
 

package/CHANGELOG.md

@@ -5,6 +5,39 @@ 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.5] - 2026-04-06
+
+### Added
+
+- **work-planner: Design-to-Plan Traceability** (agents) — New Step 5 scans all DD sections and extracts technical requirements into five categories (impl-target, connection-switching, contract-change, verification, prerequisite). Each item is mapped to a covering task in a Traceability table. Items without a covering task are marked as `gap` with mandatory justification; the plan remains in draft status until all gaps are user-confirmed
+- **plan-template: Design-to-Plan Traceability section** (skills) — Traceability table template with sample rows for both `covered` and `gap` entries, category value definitions, and gap status definitions
+- **design-template: Interface Change Matrix** (skills) — New section after Change Impact Map documenting existing-to-new interface mappings with conversion requirements and compatibility methods
+- **design-template: Verification Method column** (skills) — Integration Points List expanded with Verification Method column to explicitly capture how each switching point is verified
+- **orchestration-guide: Gap handling for work-planner handoff** (skills) — Orchestrator must present gap entries to user, keep plan in draft until confirmed, and block downstream agents (task-decomposer, etc.) until all gaps are resolved. Unjustified gaps are errors returned to work-planner
+
+### Changed
+
+- **work-planner: Output Policy gap exception** (agents) — Added explicit exception to the immediate-output policy: plans containing `gap` entries are output as draft and require user confirmation before finalizing
+- **work-planner: Category table simplified** (agents) — Removed Task Requirement column (redundant with Traceability table's Category column). Category values now use short codes (impl-target, etc.) matching the Traceability table directly
+- **orchestration-guide: technical-designer → work-planner handoff deduplicated** (skills) — Replaced inline category descriptions with reference to work-planner Step 5, establishing work-planner as single source of truth for category definitions
+
+## [1.20.4] - 2026-04-05
+
+### Added
+
+- **codebase-analyzer: Deep call chain tracing** (agents) — Replaced shallow public-interface-only extraction with full-depth analysis. All visibility levels (public, private, internal) are now extracted with recursive call chain tracing within modules. External dependencies are traced to public interface only. Chains exceeding 10 unique functions record the remainder in `limitations`
+- **codebase-analyzer: Data transformation pipeline detection** (agents) — New `dataTransformationPipelines` output field traces step-by-step input→output mapping for requirement-relevant entry points, including external resource lookups (master tables, config, constants) that modify output values
+- **codebase-analyzer: `visibility` field in output schema** (agents) — `existingElements` schema now includes `visibility` (public/private/internal) and `method` as a category option, matching the expanded extraction requirements
+- **technical-designer: Output comparison requirement** (agents) — Designs that replace or modify existing behavior must define a concrete output comparison method (identical input, expected output fields, diff method). When codebase analysis provides `dataTransformationPipelines`, each pipeline step must be covered
+- **technical-designer: Early verification exception clause** (agents) — Default early verification point for replacements/modifications is output comparison. Exception: when primary risk is not behavioral equivalence (e.g., schema compatibility, integration contract), specify alternative target and document why output comparison is deferred
+- **document-reviewer: Output comparison check** (agents) — Missing output comparison for changes that replace or modify existing behavior → `critical` issue. Uncovered `dataTransformationPipelines` steps → `important` issue
+- **design-template: Output Comparison section** (skills) — New section under Verification Strategy for behavioral equivalence verification: comparison input, expected output fields, diff method, and transformation pipeline coverage
+- **orchestration-guide: Pipeline bridge** (skills) — codebase-analyzer → technical-designer bridge now passes `dataTransformationPipelines` to inform Verification Strategy in addition to Existing Codebase Analysis
+
+### Changed
+
+- **technical-designer: Full method inventory** (agents) — Removed "about 5 important ones if over 10" limit. Now requires listing every public method with full signatures to prevent investigation shortcuts that lead to incomplete design documents
+
 ## [1.20.3] - 2026-04-04
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-ai-project",
-  "version": "1.20.3",
+  "version": "1.20.5",
   "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": [