create-ai-project 1.11.2

package/docs/rules/rules-index.yaml

@@ -0,0 +1,137 @@
+# 各ルールファイルのメタデータ
+# 各ルールの概要、タグ、典型的な使用場面、サイズを管理
+
+rules:
+  typescript:
+    file: "typescript.md"
+    tags: [implementation, type-safety, async, refactoring, coding-style, functional-programming, dependency-injection, branded-types]
+    typical-use: "TypeScriptコードの作成・修正・リファクタリング、モダンな型機能活用"
+    size: medium
+    key-references:
+      - "YAGNI原則 - Kent Beck"
+      - "Clean Code - Robert C. Martin"
+      - "DRY原則 - The Pragmatic Programmer"
+      - "Refactoring - Martin Fowler"
+      - "TypeScript 4.9 satisfies演算子 - Microsoft"
+      - "Branded Types - TypeScript Community"
+      - "Effect-TS / fp-ts - 関数型プログラミング"
+      - "Dependency Injection - Martin Fowler"
+      - "Avoiding fallback in distributed systems - AWS Builders' Library"
+    sections:
+      - "基本原則"
+      - "コメント記述ルール"
+      - "型安全性"
+      - "コーディング規約"
+      - "エラーハンドリング"
+      - "リファクタリング手法"
+      - "パフォーマンス最適化"
+
+  typescript-testing:
+    file: "typescript-testing.md"
+    tags: [quality, testing, tdd, coverage, vitest, implementation, debugging, refactoring]
+    typical-use: "テスト作成、品質チェック、コード修正・バグ修正・リファクタリング・新機能実装時の開発ステップ"
+    size: medium
+    key-references:
+      - "Test-Driven Development - Kent Beck"
+      - "Rule of Three - Martin Fowler"
+      - "Red-Green-Refactor - Kent Beck"
+      - "AAAパターン - Arrange-Act-Assert"
+    sections:
+      - "テストフレームワーク"
+      - "テストの基本方針"
+      - "Red-Green-Refactorプロセス（テストファースト開発）"
+      - "テストの設計原則"
+      - "テストヘルパーの活用ルール"
+      - "テストの実装規約"
+      - "テストの粒度"
+      - "モックの型安全性"
+      - "継続性テストの範囲"
+      - "Vitestの基本例"
+
+  ai-development-guide:
+    file: "ai-development-guide.md"
+    tags: [anti-patterns, technical-judgment, debugging, quality-commands, rule-of-three, implementation, type-safety, refactoring, code-reading, best-practices, impact-analysis, unused-code, code-deletion]
+    typical-use: "技術的判断基準、アンチパターン検出、デバッグ手法、品質チェックコマンド、実装時のベストプラクティス、影響範囲調査、未使用コード削除"
+    size: medium
+    key-references:
+      - "Rule of Three - Martin Fowler"
+      - "5 Whys - トヨタ生産方式"
+      - "DRY原則 - The Pragmatic Programmer"
+      - "単一責任原則（SRP） - Clean Code"
+      - "YAGNI原則 - Extreme Programming"
+      - "Avoiding fallback in distributed systems - AWS Builders' Library"
+    sections:
+      - "技術的アンチパターン（赤信号パターン）"
+      - "フォールバック処理に関する設計原則"
+      - "Rule of Three - コード重複の判断基準"
+      - "よくある失敗パターンと回避方法"
+      - "デバッグ手法"
+      - "品質チェックコマンドリファレンス"
+      - "技術的判断が必要な場面"
+      - "継続的改善のマインドセット"
+      - "実装作業の完全性担保"
+
+  technical-spec:
+    file: "technical-spec.md"
+    tags: [architecture, design, documentation, environment, data-flow, implementation]
+    typical-use: "技術設計、環境設定、ドキュメント作成プロセス、実装方針決定"
+    size: medium
+    key-references:
+      - "ADRフォーマット - Michael Nygard"
+      - "単一データソース原則 - Single Source of Truth"
+    sections:
+      - "技術スタックの基本方針"
+      - "環境変数管理とセキュリティ"
+      - "アーキテクチャ設計"
+      - "パターン適用の一貫性"
+      - "データフロー統一原則"
+      - "ビルドとテスト"
+
+  project-context:
+    file: "project-context.md"
+    tags: [context, project-specific, implementation]
+    typical-use: "プロジェクト固有情報、実装原則の理解"
+    size: small
+    key-references:
+      - "プロジェクト固有（経験則）"
+    sections:
+      - "基本設定"
+      - "実装原則"
+      - "カスタマイズガイド"
+
+  documentation-criteria:
+    file: "documentation-criteria.md"
+    tags: [documentation, decision-making, adr, prd, design-doc, planning, process]
+    typical-use: "実装開始時の規模判定、ドキュメント作成判定、ADR/PRD/Design Doc/作業計画書の作成基準"
+    size: medium
+    key-references:
+      - "ADR手法 - Michael Nygard"
+      - "Design Doc文化 - Google Engineering Practices"
+      - "Single Source of Truth"
+    sections:
+      - "作成判定マトリクス"
+      - "ADR作成条件（いずれか該当で必須）"
+      - "各ドキュメントの詳細定義"
+      - "作成プロセス"
+      - "保存場所"
+      - "ADRステータス"
+      - "AI自動化ルール"
+      - "図表作成要件"
+      - "共通ADRとの関係性"
+
+  implementation-approach:
+    file: "architecture/implementation-approach.md"
+    tags: [architecture, implementation, task-decomposition, strategy-patterns, strangler-pattern, facade-pattern, design, planning, confirmation-levels]
+    typical-use: "実装戦略の選択、タスク分解、設計判断、大規模変更の計画"
+    size: medium
+    key-references:
+      - "Strangler Fig Pattern - Martin Fowler"
+      - "Feature Slicing - Martin Fowler"
+      - "Walking Skeleton - Alistair Cockburn"
+      - "Facade Pattern - Gang of Four"
+    sections:
+      - "メタ認知的戦略選択プロセス"
+      - "確認レベル定義"
+      - "統合ポイントの定義"
+      - "アンチパターン"
+      - "メタ認知的実行のための指針"

package/docs/rules/technical-spec.md

@@ -0,0 +1,47 @@
+# 技術設計ルール
+
+## 技術スタックの基本方針
+TypeScriptをベースとしたアプリケーション実装。アーキテクチャパターンはプロジェクトの要件と規模に応じて選択すること。
+
+## 環境変数管理とセキュリティ
+
+### 環境変数管理
+- 環境変数は一元管理し、型安全性を確保する仕組みを構築すること
+- `process.env` の直接参照は避け、設定管理層を通じて取得すること
+- デフォルト値の設定や必須チェックを適切に実装すること
+
+### セキュリティ
+- `.env`ファイルはGitに含めない
+- APIキーやシークレットは必ず環境変数として管理
+- 機密情報のログ出力は禁止
+- エラーメッセージに機密情報を含めない
+
+## アーキテクチャ設計
+
+### アーキテクチャ設計の原則
+プロジェクトごとに適切なアーキテクチャを選択し、明確に定義すること：
+
+- **明確な定義**: プロジェクトのアーキテクチャは`docs/rules/architecture/`配下に専用ファイルで定義
+- **責務の分離**: 各層やモジュールの責務を明確に定義し、境界を守ること
+
+## パターン適用の一貫性
+
+選択したアーキテクチャパターンに厳密に従う。プロジェクト固有詳細は`docs/rules/architecture/`参照。
+
+## データフロー統一原則
+
+#### 基本原則
+1. **単一データソース**: 同じ情報は1箇所にのみ保存する
+2. **構造化データ優先**: JSON文字列ではなくパース済みオブジェクトを使用
+3. **明確な責務分離**: 各層の責務を明確に定義
+
+#### データフローのベストプラクティス
+- **入力時点での検証**: データは入力層で検証し、型安全な形で内部に渡す
+- **変換の一元化**: データ変換ロジックは専用のユーティリティに集約
+- **ログの構造化**: データフローの各段階で構造化ログを出力
+
+## ビルドとテスト
+
+プロジェクトごとにビルドコマンドとテスト実行方法を定義。
+
+品質チェックは実装完了時に必須。

package/docs/rules/typescript-testing.md

@@ -0,0 +1,188 @@
+# TypeScript テストルール
+
+## テストフレームワーク
+- **Vitest**: このプロジェクトではVitestを使用
+- テストのインポート: `import { describe, it, expect, beforeEach, vi } from 'vitest'`
+- モックの作成: `vi.mock()` を使用
+
+## テストの基本方針
+
+### 品質要件
+- **カバレッジ**: 単体テストのカバレッジは70%以上を必須
+- **独立性**: 各テストは他のテストに依存せず実行可能
+- **再現性**: テストは環境に依存せず、常に同じ結果を返す
+- **可読性**: テストコードも製品コードと同様の品質を維持
+
+### カバレッジ要件
+**必須**: 単体テストのカバレッジは70%以上
+**指標**: Statements（文）、Branches（分岐）、Functions（関数）、Lines（行）
+
+### テストの種類と範囲
+1. **単体テスト（Unit Tests）**
+   - 個々の関数やクラスの動作を検証
+   - 外部依存はすべてモック化
+   - 最も数が多く、細かい粒度で実施
+
+2. **統合テスト（Integration Tests）**
+   - 複数のコンポーネントの連携を検証
+   - 実際の依存関係を使用（DBやAPI等）
+   - 主要な機能フローの検証
+
+3. **E2Eテストでの機能横断検証**
+   - 新機能追加時、既存機能への影響を必ず検証
+   - Design Docの「統合ポイントマップ」で影響度「高」「中」の箇所をカバー
+   - 検証パターン: 既存機能動作 → 新機能有効化 → 既存機能の継続性確認
+   - 判定基準: レスポンス内容の変化なし、処理時間5秒以内
+   - CI/CDでの自動実行を前提とした設計
+
+## Red-Green-Refactorプロセス（テストファースト開発）
+
+**推奨原則**: コード変更は必ずテストから始める
+
+**背景**: 
+- 変更前の動作を保証し、リグレッションを防止
+- 期待する動作を明確化してから実装
+- リファクタリング時の安全性を確保
+
+**開発ステップ**:
+1. **Red**: 期待する動作のテストを書く（失敗する）
+2. **Green**: 最小限の実装でテストを通す
+3. **Refactor**: テストが通る状態を維持しながらコード改善
+
+**NGケース（テストファースト不要）**:
+- 純粋な設定ファイル変更（.env、config等）
+- ドキュメントのみの更新（README、コメント等）
+- 緊急本番障害対応（ただし事後テスト必須）
+
+## テストの設計原則
+
+### テストケースの構造
+- テストは「準備（Arrange）」「実行（Act）」「検証（Assert）」の3段階で構成
+- 各テストの目的が明確に分かる命名
+- 1つのテストケースでは1つの振る舞いのみを検証
+
+### テストデータ管理
+- テストデータは専用ディレクトリで管理
+- 環境変数はテスト用の値を定義
+- 機密情報は必ずモック化
+- テストデータは最小限に保ち、テストケースの検証目的に直接関連するデータのみ使用
+
+### モックとスタブの使用方針
+
+✅ **推奨: 単体テストでの外部依存モック化**
+- メリット: テストの独立性と再現性を確保
+- 実践: DB、API、ファイルシステム等の外部依存をモック化
+
+❌ **避けるべき: 単体テストでの実際の外部接続**
+- 理由: テスト速度が遅くなり、環境依存の問題が発生するため
+
+### テスト失敗時の対応判断基準
+
+**テストを修正**: 間違った期待値、存在しない機能参照、実装詳細への依存、テストのためだけの実装
+**実装を修正**: 妥当な仕様、ビジネスロジック、重要なエッジケース
+**判断に迷ったら**: ユーザーに確認
+
+## テストヘルパーの活用ルール
+
+### 基本原則
+テストヘルパーは、テストコードの重複を減らし、保守性を高めるために活用します。
+
+### 判断基準
+| モックの特性 | 対応方針 |
+|-------------|---------|
+| **単純で安定** | 共通ヘルパーに集約 |
+| **複雑または変更頻度高** | 個別実装 |
+| **3箇所以上で重複** | 共通化を検討 |
+| **テスト固有ロジック** | 個別実装 |
+
+### テストヘルパー活用例
+```typescript
+// ✅ ビルダーパターン
+const testData = new TestDataBuilder().withDefaults().withName('Test User').build()
+
+// ✅ カスタムアサーション
+function assertValidUser(user: unknown): asserts user is User {}
+
+// ❌ 重複する複雑なモックの個別実装
+```
+
+## テストの実装規約
+
+### ディレクトリ構造
+```
+src/
+└── application/
+    └── services/
+        ├── __tests__/
+        │   ├── service.test.ts      # 単体テスト
+        │   └── service.int.test.ts  # 統合テスト
+        └── service.ts
+```
+
+### 命名規則
+- テストファイル: `{対象ファイル名}.test.ts`
+- 統合テストファイル: `{対象ファイル名}.int.test.ts`
+- テストスイート: 対象の機能や状況を説明する名前
+- テストケース: 期待される動作を説明する名前
+
+
+### テストコードの品質ルール
+
+✅ **推奨: すべてのテストを常に有効に保つ**
+- メリット: テストスイートの完全性を保証
+- 実践: 問題があるテストは修正して有効化
+
+❌ **避けるべき: test.skip()やコメントアウト**
+- 理由: テストの穴が生まれ、品質チェックが不完全になる
+- 対処: 不要なテストは完全に削除する
+
+## テストの粒度
+
+### 原則：観測可能な振る舞いのみ
+**テスト対象**：公開API、戻り値、例外、外部呼び出し、永続化された状態
+**テスト対象外**：privateメソッド、内部状態、アルゴリズム詳細
+
+```typescript
+// ✅ 振る舞いをテスト
+expect(calculatePrice(100, 0.1)).toBe(110)
+
+// ❌ 実装詳細をテスト
+expect((calculator as any).taxRate).toBe(0.1)
+```
+
+## モックの型安全性
+
+### 必要最小限の型定義
+```typescript
+// ✅ 必要な部分のみ
+type TestRepo = Pick<Repository, 'find' | 'save'>
+const mock: TestRepo = { find: vi.fn(), save: vi.fn() }
+
+// やむを得ない場合のみ、理由明記
+const sdkMock = {
+  call: vi.fn()
+} as unknown as ExternalSDK // 外部SDKの複雑な型のため
+```
+
+## 継続性テストの範囲
+
+新機能追加時の既存機能への影響確認に限定。長時間運用・負荷テストはインフラ層の責務のため対象外。
+
+## Vitestの基本例
+
+```typescript
+import { describe, it, expect, vi } from 'vitest'
+
+vi.mock('./userService', () => ({
+  getUserById: vi.fn(),
+  updateUser: vi.fn()
+}))
+
+describe('ComponentName', () => {
+  it('should follow AAA pattern', () => {
+    const input = 'test'
+    const result = someFunction(input)
+    expect(result).toBe('expected')
+  })
+})
+```

package/docs/rules/typescript.md

@@ -0,0 +1,166 @@
+# TypeScript 開発ルール
+
+## 基本原則
+
+✅ **積極的なリファクタリング** - 技術的負債を防ぎ、健全性を維持
+❌ **使われない「念のため」のコード** - YAGNI原則（Kent Beck）に反する
+
+## コメント記述ルール
+- **機能説明重視**: コードが「何をするか」を記述
+- **履歴情報禁止**: 開発履歴は記載しない
+- **タイムレス**: いつ読んでも有効な内容のみ記述
+- **簡潔性**: 必要最小限の説明にとどめる
+
+## 型安全性
+
+**絶対ルール**: any型は完全禁止。型チェックが無効化され、実行時エラーの温床となる。
+
+**any型の代替手段（優先順位順）**
+1. **unknown型 + 型ガード**: 外部入力の検証に使用
+2. **ジェネリクス**: 型の柔軟性が必要な場合
+3. **ユニオン型・インターセクション型**: 複数の型の組み合わせ
+4. **型アサーション（最終手段）**: 型が確実な場合のみ
+
+**型ガードの実装パターン**
+```typescript
+function isUser(value: unknown): value is User {
+  return typeof value === 'object' && value !== null && 'id' in value && 'name' in value
+}
+```
+
+**モダンな型機能の活用**
+- **satisfies演算子**: `const config = { port: 3000 } satisfies Config` - 型推論維持
+- **const assertion**: `const ROUTES = { HOME: '/' } as const satisfies Routes` - 不変かつ型安全
+- **ブランド型**: `type UserId = string & { __brand: 'UserId' }` - 意味を区別
+- **テンプレートリテラル型**: `type Endpoint = \`\${HttpMethod} \${Route}\`` - 文字列パターンを型で表現
+
+**実装での型安全性**
+- API通信: レスポンスは必ず`unknown`で受け、型ガードで検証
+- フォーム入力: 外部入力は`unknown`、バリデーション後に型確定
+- レガシー統合: `window as unknown as LegacyWindow`のように段階的アサーション
+- テストコード: モックも必ず型定義、`Partial<T>`や`vi.fn<[Args], Return>()`活用
+
+**データフローでの型安全性**
+入力層（`unknown`） → 型ガード → ビジネス層（型保証） → 出力層（シリアライズ）
+
+**型の複雑性管理**
+- フィールド数: 20個まで（超えたら責務で分割、外部API型は例外）
+- オプショナル率: 30%まで（超えたら必須/任意で分離）
+- ネスト深さ: 3階層まで（超えたらフラット化）
+- 型アサーション: 3回以上使用したら設計見直し
+- **外部API型の扱い**: 制約を緩和し、実態に合わせて定義（内部では適切に変換）
+
+## コーディング規約
+
+**クラス使用の判断基準**
+- **推奨：関数とinterfaceでの実装**
+  - 背景: テスタビリティと関数合成の柔軟性が向上
+- **クラス使用を許可**: 
+  - フレームワーク要求時（NestJSのController/Service、TypeORMのEntity等）
+  - カスタムエラークラス定義時
+  - 状態とビジネスロジックが密結合している場合（例: ShoppingCart、Session、StateMachine）
+- **判断基準**: 「このデータは振る舞いを持つか？」がYesならクラス検討
+  ```typescript
+  // ✅ 関数とinterface
+  interface UserService { create(data: UserData): User }
+  const userService: UserService = { create: (data) => {...} }
+  ```
+
+**関数設計**
+- **引数は0-2個まで**: 3個以上はオブジェクト化
+  ```typescript
+  // ✅ オブジェクト引数
+  function createUser({ name, email, role }: CreateUserParams) {}
+  ```
+
+**依存性注入**
+- **外部依存は引数で注入**: テスト可能性とモジュール性確保
+  ```typescript
+  // ✅ 依存性を引数で受け取る
+  function createService(repository: Repository) { return {...} }
+  ```
+
+**非同期処理**
+- Promise処理: 必ず`async/await`を使用
+- エラーハンドリング: 必ず`try-catch`でハンドリング
+- 型定義: 戻り値の型は明示的に定義（例: `Promise<Result>`）
+
+**フォーマット規則**
+- セミコロン省略（Biomeの設定に従う）
+- 型は`PascalCase`、変数・関数は`camelCase`
+- インポートは絶対パス（`src/`）
+
+**クリーンコード原則**
+- ✅ 使用されていないコードは即座に削除
+- ✅ デバッグ用`console.log()`は削除
+- ❌ コメントアウトされたコード（バージョン管理で履歴管理）
+- ✅ コメントは「なぜ」を説明（「何」ではなく）
+
+## エラーハンドリング
+
+**絶対ルール**: エラーの握りつぶし禁止。すべてのエラーは必ずログ出力と適切な処理を行う。
+
+**Fail-Fast原則**: エラー時は速やかに失敗させ、不正な状態での処理継続を防ぐ
+```typescript
+// ❌ 禁止: 無条件フォールバック
+catch (error) {
+  return defaultValue // エラーを隠蔽
+}
+
+// ✅ 必須: 明示的な失敗
+catch (error) {
+  logger.error('処理失敗', error)
+  throw error // 上位層で適切に処理
+}
+```
+
+**Result型パターン**: エラーを型で表現し、明示的に処理
+```typescript
+type Result<T, E> = { ok: true; value: T } | { ok: false; error: E }
+
+// 使用例：エラーの可能性を型で表現
+function parseUser(data: unknown): Result<User, ValidationError> {
+  if (!isValid(data)) return { ok: false, error: new ValidationError() }
+  return { ok: true, value: data as User }
+}
+```
+
+**カスタムエラークラス**
+```typescript
+export class AppError extends Error {
+  constructor(message: string, public readonly code: string, public readonly statusCode = 500) {
+    super(message)
+    this.name = this.constructor.name
+  }
+}
+// 用途別: ValidationError(400), BusinessRuleError(400), DatabaseError(500), ExternalServiceError(502)
+```
+
+**層別エラー処理**
+- API層: HTTPレスポンスに変換、機密情報を除外してログ出力
+- サービス層: ビジネスルール違反を検出、AppErrorはそのまま伝播
+- リポジトリ層: 技術的エラーをドメインエラーに変換
+
+**構造化ログと機密情報保護**
+機密情報（password, token, apiKey, secret, creditCard）は絶対にログに含めない
+
+**非同期エラーハンドリング**
+- グローバルハンドラー設定必須: `unhandledRejection`, `uncaughtException`
+- すべてのasync/awaitでtry-catch使用
+- エラーは必ずログと再スロー
+
+## リファクタリング手法
+
+**基本方針**
+- 小さなステップ: 段階的改善により、常に動作する状態を維持
+- 安全な変更: 一度に変更する範囲を最小限に抑制
+- 動作保証: 既存の動作を変えないことを確認しながら進める
+
+**実施手順**: 現状把握 → 段階的変更 → 動作確認 → 最終検証
+
+**優先順位**: 重複コード削除 > 長大な関数分割 > 複雑な条件分岐簡素化 > 型安全性向上
+
+## パフォーマンス最適化
+
+- ストリーミング処理: 大きなデータセットはストリームで処理
+- メモリリーク防止: 不要なオブジェクトは明示的に解放

package/docs/rules-en/architecture/implementation-approach.md

@@ -0,0 +1,136 @@
+# Implementation Strategy Selection Framework (Meta-cognitive Approach)
+
+## Meta-cognitive Strategy Selection Process
+
+### Phase 1: Comprehensive Current State Analysis
+
+**Core Question**: "What does the existing implementation look like?"
+
+#### Analysis Framework
+```yaml
+Architecture Analysis: Responsibility separation, data flow, dependencies, technical debt
+Implementation Quality Assessment: Code quality, test coverage, performance, security
+Historical Context Understanding: Current form rationale, past decision validity, constraint changes, requirement evolution
+```
+
+#### Meta-cognitive Question List
+- What is the true responsibility of this implementation?
+- Which parts are business essence and which derive from technical constraints?
+- What dependencies or implicit preconditions are unclear from the code?
+- What benefits and constraints does the current design bring?
+
+### Phase 2: Strategy Exploration and Creation
+
+**Core Question**: "When determining before → after, what implementation patterns or strategies should be referenced?"
+
+#### Strategy Discovery Process
+```yaml
+Research and Exploration: Tech stack examples (WebSearch), similar projects, OSS references, literature/blogs
+Creative Thinking: Strategy combinations, constraint-based design, phase division, extension point design
+```
+
+#### Reference Strategy Patterns (Creative Combinations Encouraged)
+
+**Legacy Handling Strategies**:
+- Strangler Pattern: Gradual migration through phased replacement
+- Facade Pattern: Complexity hiding through unified interface
+- Adapter Pattern: Bridge with existing systems
+
+**New Development Strategies**:
+- Feature-driven Development: Vertical implementation prioritizing user value
+- Foundation-driven Development: Foundation-first construction prioritizing stability
+- Risk-driven Development: Prioritize addressing maximum risk elements
+
+**Integration/Migration Strategies**:
+- Proxy Pattern: Transparent feature extension
+- Decorator Pattern: Phased enhancement of existing features
+- Bridge Pattern: Flexibility through abstraction
+
+**Important**: The optimal solution is discovered through creative thinking according to each project's context.
+
+### Phase 3: Risk Assessment and Control
+
+**Core Question**: "What risks arise when applying this to existing implementation, and what's the best way to control them?"
+
+#### Risk Analysis Matrix
+```yaml
+Technical Risks: System impact, data consistency, performance degradation, integration complexity
+Operational Risks: Service availability, deployment downtime, process changes, rollback procedures
+Project Risks: Schedule delays, learning costs, quality achievement, team coordination
+```
+
+#### Risk Control Strategies
+```yaml
+Preventive Measures: Phased migration, parallel operation verification, integration/regression tests, monitoring setup
+Incident Response: Rollback procedures, log/metrics preparation, communication system, service continuation procedures
+```
+
+### Phase 4: Constraint Compatibility Verification
+
+**Core Question**: "What are this project's constraints?"
+
+#### Constraint Checklist
+```yaml
+Technical Constraints: Library compatibility, resource capacity, mandatory requirements, numerical targets
+Temporal Constraints: Deadlines/priorities, dependencies, milestones, learning periods
+Resource Constraints: Team/skills, work hours/systems, budget, external contracts
+Business Constraints: Market launch timing, customer impact, regulatory compliance
+```
+
+### Phase 5: Implementation Approach Decision
+
+Select optimal solution from basic implementation approaches (creative combinations encouraged):
+
+#### Vertical Slice (Feature-driven)
+**Characteristics**: Vertical implementation across all layers by feature unit
+**Application Conditions**: Low inter-feature dependencies, output in user-usable form, changes needed across all architecture layers
+**Verification Method**: End-user value delivery at each feature completion
+
+#### Horizontal Slice (Foundation-driven)
+**Characteristics**: Phased construction by architecture layer
+**Application Conditions**: Foundation system stability important, multiple features depend on common foundation, layer-by-layer verification effective
+**Verification Method**: Integrated operation verification when all foundation layers complete
+
+#### Hybrid (Creative Combination)
+**Characteristics**: Flexible combination according to project characteristics
+**Application Conditions**: Unclear requirements, need to change approach per phase, transition from prototyping to full implementation
+**Verification Method**: Verify at appropriate L1/L2/L3 levels according to each phase's goals
+
+### Phase 6: Decision Rationale Documentation
+
+**Design Doc Documentation**: Clearly specify implementation strategy selection reasons and rationale.
+
+## Verification Level Definitions
+
+Priority for completion verification of each task:
+
+- **L1: Functional Operation Verification** - Operates as end-user feature (e.g., search executable)
+- **L2: Test Operation Verification** - New tests added and passing (e.g., type definition tests)
+- **L3: Build Success Verification** - No compile errors (e.g., interface definitions)
+
+**Priority**: L1 > L2 > L3 in order of verifiability importance
+
+## Integration Point Definitions
+
+Define integration points according to selected strategy:
+- **Strangler-based**: When switching between old and new systems for each feature
+- **Feature-driven**: When users can actually use the feature
+- **Foundation-driven**: When all architecture layers are ready and E2E tests pass
+- **Hybrid**: When individual goals defined for each phase are achieved
+
+## Anti-patterns
+
+- **Pattern Fixation**: Selecting only from listed strategies without considering unique combinations
+- **Insufficient Analysis**: Skipping Phase 1 analysis framework before strategy selection
+- **Risk Neglect**: Starting implementation without Phase 3 risk analysis matrix
+- **Constraint Ignorance**: Deciding strategy without checking Phase 4 constraint checklist
+- **Rationale Omission**: Selecting strategy without using Phase 6 documentation template
+
+## Guidelines for Meta-cognitive Execution
+
+1. **Leverage Known Patterns**: Use as starting point, explore creative combinations
+2. **Active WebSearch Use**: Research implementation examples from similar tech stacks
+3. **Apply 5 Whys**: Pursue root causes to grasp essence
+4. **Multi-perspective Evaluation**: Comprehensively evaluate from each Phase 1-4 perspective
+5. **Creative Thinking**: Consider sequential application of multiple strategies and designs leveraging project-specific constraints
+6. **Clarify Decision Rationale**: Make strategy selection rationale explicit in design documents