create-ai-project 1.20.3 → 1.20.4

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-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/skills-en/documentation-criteria/references/design-template.md

@@ -305,6 +305,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/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)
 

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

@@ -311,6 +311,17 @@ unknowns:
 - **成功基準**: [観察可能な成果 — 例: 「CSVダウンロードが既存と同一の出力を生成」「APIが期待スキーマで200を返す」]
 - **失敗時の対応**: [早期検証が失敗した場合の対処 — 例: 「続行前にアプローチを再評価」「ユーザーにエスカレーション」]
 
+### 出力比較（既存の振る舞いを置換または変更する場合）
+
+既存実装と新実装の振る舞いの同等性をどう検証するか?
+
+- **比較入力**: [両実装に対して使用する同一入力 — 例: 「同一DBスナップショット」「同一APIリクエストペイロード」]
+- **期待される出力フィールド**: [比較対象の具体的なフィールド/カラム — 例: 「全出力カラム」「レスポンスボディのフィールド: id, status, amount」]
+- **差分比較方法**: [比較手法 — 例: 「ファイルレベルのdiff」「JSONフィールド単位の比較」「行数 + スポットチェック」]
+- **変換パイプラインカバレッジ**: [コードベース分析の`dataTransformationPipelines`の各ステップと、比較がカバーする範囲]
+
+既存の同等物がなく完全に新規の振る舞いを導入する場合は、簡潔な理由とともにN/Aと記載。
+
 ## 代替案
 
 ### 代替案1

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レビュー）
 

package/CHANGELOG.md

@@ -5,6 +5,23 @@ 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.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.4",
   "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": [