create-ai-project 1.18.4 → 1.18.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -92,6 +92,7 @@ For DesignDoc, additionally verify:
92
92
  - Technical information verification: When sources exist, verify with WebSearch for latest information and validate claim validity
93
93
  - Failure scenario review: Identify failure scenarios across normal usage, high load, and external failures; specify which design element becomes the bottleneck
94
94
  - Code inspection evidence review: Verify inspected files are relevant to design scope; flag if key related files are missing
95
+ - Dependency realizability check: For each dependency the Design Doc's Existing Codebase Analysis section describes as "existing", verify its definition exists in the codebase using Grep/Glob. Not found in codebase and no authoritative external source documented → `critical` issue (category: `feasibility`). Found but definition signature (method names, parameter types, return types) diverges from Design Doc description → `important` issue (category: `consistency`)
95
96
  - **As-is implementation document review**: When code verification results are provided and the document describes existing implementation (not future requirements), verify that code-observable behaviors are stated as facts; speculative language about deterministic behavior → `important` issue
96
97
 
97
98
  **Perspective-specific Mode**:
@@ -244,6 +245,7 @@ Include in output when `prior_context_count > 0`:
244
245
  - [ ] Gate 0 structural existence checks pass before quality review
245
246
  - [ ] Design decision rationales verified against identified standards/patterns
246
247
  - [ ] Code inspection evidence covers files relevant to design scope
248
+ - [ ] Dependencies described as "existing" verified against codebase (Grep/Glob)
247
249
  - [ ] Field propagation map present when fields cross component boundaries
248
250
 
249
251
  ## Review Criteria (for Comprehensive Mode)
@@ -59,9 +59,17 @@ Must be performed before Design Doc creation:
59
59
  - Similar component is technical debt → Create ADR improvement proposal before implementation
60
60
  - No similar component → Proceed with new implementation
61
61
 
62
- 4. **Include in Design Doc**
62
+ 4. **Dependency Existence Verification**
63
+ - For each component the design assumes already exists, search for its definition in the codebase using Grep/Glob
64
+ - Typical targets include: components, custom hooks, Context definitions, store/state definitions, API endpoints, type definitions, utility functions
65
+ - If found in codebase: record file path and definition location
66
+ - If found outside codebase (external API, separate repository, generated artifact): record the authoritative source and mark as "external dependency"
67
+ - If not found anywhere: mark as "requires new creation" in the Design Doc and reflect in implementation order dependencies
68
+
69
+ 5. **Include in Design Doc**
63
70
  - Always include investigation results in "## Existing Codebase Analysis" section
64
71
  - Clearly document similar component search results (found components or "none")
72
+ - Include dependency existence verification results (verified existing / requires new creation)
65
73
  - Record adopted decision (use existing/improvement proposal/new implementation) and rationale
66
74
 
67
75
  ### Integration Point Analysis【Important】
@@ -73,12 +73,20 @@ Must be performed before Design Doc creation:
73
73
  - Similar functionality is technical debt → Create ADR improvement proposal before implementation
74
74
  - No similar functionality → Proceed with new implementation
75
75
 
76
- 4. **Include in Design Doc**
76
+ 4. **Dependency Existence Verification**
77
+ - For each component the design assumes already exists, search for its definition in the codebase using Grep/Glob
78
+ - Typical targets include: interfaces, classes, repositories, service methods, API endpoints, DB tables/columns, configuration keys, enum values, type definitions
79
+ - If found in codebase: record file path and definition location
80
+ - If found outside codebase (external API, separate repository, generated artifact): record the authoritative source and mark as "external dependency"
81
+ - If not found anywhere: mark as "requires new creation" in the Design Doc and reflect in implementation order dependencies
82
+
83
+ 5. **Include in Design Doc**
77
84
  - Always include investigation results in "## Existing Codebase Analysis" section
78
85
  - Clearly document similar functionality search results (found implementations or "none")
86
+ - Include dependency existence verification results (verified existing / requires new creation)
79
87
  - Record adopted decision (use existing/improvement proposal/new implementation) and rationale
80
88
 
81
- 5. **Code Inspection Evidence**
89
+ 6. **Code Inspection Evidence**
82
90
  - Record all inspected files and key functions in "Code Inspection Evidence" section of Design Doc
83
91
  - Each entry must state relevance (similar functionality / integration point / pattern reference)
84
92
 
@@ -92,6 +92,7 @@ DesignDocの場合、追加で以下を確認:
92
92
  - 技術情報検証:出典がある場合はWebSearchで最新情報を確認、主張の妥当性を検証
93
93
  - 失敗シナリオ検証:正常系・高負荷・外部障害の失敗シナリオを特定し、どの設計要素がボトルネックになるか指摘
94
94
  - コード調査エビデンス検証:調査ファイルが設計スコープに関連するか確認、主要な関連ファイルの漏れを指摘
95
+ - 依存先の実在性検証:Design Docの「既存コードベース分析」セクションが「既存」と記述する依存先について、Grep/Globでコードベース内の定義を確認。コードベースに見つからず公式の外部出典の記載もない → `critical`(カテゴリ: `feasibility`)。存在するが定義のシグネチャ(メソッド名、パラメータ型、戻り値型)がDesign Docの記述と乖離 → `important`(カテゴリ: `consistency`)
95
96
  - **既存実装ドキュメント検証**: コード検証結果が提供され、ドキュメントが既存実装を記述している場合(将来の要件ではなく)、コードから観察可能な振る舞いが事実として記述されていることを検証する。確定的な振る舞いに対する推測的な表現 → `important`
96
97
 
97
98
  **観点特化モード**:
@@ -244,6 +245,7 @@ DesignDocの場合、追加で以下を確認:
244
245
  - [ ] Gate 0の存在チェックが品質レビュー前に通過していること
245
246
  - [ ] 設計判断の根拠が特定された基準/パターンに照合されていること
246
247
  - [ ] コード調査エビデンスが設計スコープに関連するファイルを網羅していること
248
+ - [ ] 「既存」と記述された依存先がコードベースに対して検証されていること(Grep/Glob)
247
249
  - [ ] フィールドが境界を越える場合にフィールド伝播マップが存在すること
248
250
 
249
251
  ## レビュー基準(総合モード用)
@@ -69,9 +69,17 @@ Design Doc作成前に必ず実施:
69
69
  - 類似コンポーネントが技術的負債 → ADRで改善提案を作成してから実装
70
70
  - 類似コンポーネントなし → 新規実装を進める
71
71
 
72
- 4. **Design Docへの記載**
72
+ 4. **依存先の存在検証**
73
+ - 設計が「既存」と想定するコンポーネントについて、Grep/Globでコードベース内の定義を検索
74
+ - 典型的な対象: コンポーネント、カスタムフック、Context定義、ストア/状態定義、APIエンドポイント、型定義、ユーティリティ関数
75
+ - コードベースに存在 → ファイルパスと定義箇所を記録
76
+ - コードベース外に存在(外部API、別リポジトリ、生成物など) → 公式の出典を記録し「外部依存」としてマーク
77
+ - どこにも見つからない → Design Docで「新規作成が必要」とマークし、実装順序の依存関係に反映
78
+
79
+ 5. **Design Docへの記載**
73
80
  - 「## 既存コードベース分析」セクションに調査結果を必ず記載
74
81
  - 類似コンポーネントの検索結果(発見したコンポーネント、または「なし」)を明記
82
+ - 依存先の存在検証結果(既存確認済み / 新規作成が必要)を記載
75
83
  - 採用した判断(既存使用/改善提案/新規実装)とその根拠を記録
76
84
 
77
85
  ### 統合ポイント分析【重要】
@@ -73,12 +73,20 @@ Design Doc作成前に必ず実施:
73
73
  - 類似機能が技術的負債 → ADRで改善提案を作成してから実装
74
74
  - 類似機能なし → 新規実装を進める
75
75
 
76
- 4. **Design Docへの記載**
76
+ 4. **依存先の存在検証**
77
+ - 設計が「既存」と想定するコンポーネントについて、Grep/Globでコードベース内の定義を検索
78
+ - 典型的な対象: インターフェース、クラス、リポジトリ、サービスメソッド、APIエンドポイント、DBテーブル/カラム、設定キー、enum値、型定義
79
+ - コードベースに存在 → ファイルパスと定義箇所を記録
80
+ - コードベース外に存在(外部API、別リポジトリ、生成物など) → 公式の出典を記録し「外部依存」としてマーク
81
+ - どこにも見つからない → Design Docで「新規作成が必要」とマークし、実装順序の依存関係に反映
82
+
83
+ 5. **Design Docへの記載**
77
84
  - 「## 既存コードベース分析」セクションに調査結果を必ず記載
78
85
  - 類似機能の検索結果(発見した実装、または「なし」)を明記
86
+ - 依存先の存在検証結果(既存確認済み / 新規作成が必要)を記載
79
87
  - 採用した判断(既存使用/改善提案/新規実装)とその根拠を記録
80
88
 
81
- 5. **コード調査エビデンス**
89
+ 6. **コード調査エビデンス**
82
90
  - 調査したすべてのファイルと主要関数をDesign Docの「コード調査エビデンス」セクションに記録
83
91
  - 各エントリの関連性(類似機能 / 統合点 / パターン参照)を明記
84
92
 
package/CHANGELOG.md CHANGED
@@ -5,6 +5,16 @@ All notable changes to this project will be documented in this file.
5
5
  The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
6
6
  and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
7
7
 
8
+ ## [1.18.5] - 2026-03-29
9
+
10
+ ### Fixed
11
+
12
+ #### Dependency Existence Verification in Design Workflow
13
+ Design documents could describe components as "existing" without verification, causing implementation failures when those dependencies turned out to be missing or mismatched.
14
+
15
+ - `technical-designer` / `technical-designer-frontend`: Add **Dependency Existence Verification** step to Existing Code Investigation — each assumed dependency is now verified via Grep/Glob before design proceeds, with three-way classification (found in codebase / external dependency / requires new creation)
16
+ - `document-reviewer`: Add **dependency realizability check** to Gate 1 — cross-checks claimed "existing" dependencies against the codebase during review. Missing dependency with no external source → `critical` (feasibility). Signature mismatch (method names, parameter types, return types) → `important` (consistency)
17
+
8
18
  ## [1.18.4] - 2026-03-28
9
19
 
10
20
  ### Fixed
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "create-ai-project",
3
- "version": "1.18.4",
3
+ "version": "1.18.5",
4
4
  "packageManager": "npm@10.8.2",
5
5
  "description": "TypeScript boilerplate with skills and sub-agents for Claude Code. Prevents context exhaustion through role-based task splitting.",
6
6
  "keywords": [