create-ai-project 1.11.2 → 1.12.0

package/docs/rules/rules-index.yaml

@@ -1,137 +0,0 @@
-# 各ルールファイルのメタデータ
-# 各ルールの概要、タグ、典型的な使用場面、サイズを管理
-
-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

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

package/docs/rules/typescript-testing.md

@@ -1,188 +0,0 @@
-# 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-ja/frontend/typescript.md

@@ -1,131 +0,0 @@
-# TypeScript開発ルール
-
-## フロントエンド固有のアンチパターン
-
-coding-standards.mdの普遍的アンチパターンに加え、以下のフロントエンド固有の問題に注意：
-
-- **3階層以上のProp drilling** - Context APIまたは状態管理を使用すべき
-- **巨大なコンポーネント（300行以上）** - 小さなコンポーネントに分割
-
-## Frontend実装における型安全性
-
-**データフローにおける型安全性**
-- **Frontend → Backend**: Props/State（型保証済み） → APIリクエスト（シリアライゼーション）
-- **Backend → Frontend**: APIレスポンス（`unknown`） → 型ガード → State（型保証済み）
-
-**Frontend固有の型シナリオ**:
-- **React Props/State**: TypeScriptが型管理、unknown不要
-- **外部APIレスポンス**: 常に`unknown`として受け取り、型ガードで検証
-- **localStorage/sessionStorage**: `unknown`として扱い、検証
-- **URLパラメータ**: `unknown`として扱い、検証
-- **Form入力（Controlled Components）**: React合成イベントで型安全
-
-**型の複雑性管理（Frontend）**
-- **Props設計**:
-  - Props数: 3-7個が理想（10個超えたらコンポーネント分割検討）
-  - Optional Props: 50%以下（多すぎる場合はデフォルト値やContext使用検討）
-  - ネスト: 2レベルまで（深いネストはFlatten推奨）
-- 型アサーション: 3回以上使用で設計見直し
-- **外部API型**: 制約を緩和し実態に応じて定義（内部で適切に変換）
-
-## コーディング規約
-
-**コンポーネント設計基準**
-- **Function Components（必須）**: React公式推奨、モダンツールで最適化可能
-- **Classes禁止**: Class componentsは完全非推奨（例外: Error Boundary）
-- **Custom Hooks**: ロジック再利用の標準パターン
-
-**関数設計**
-- **0-2パラメータまで**: 3個以上はオブジェクト使用
-  ```typescript
-  // ✅ オブジェクトパラメータ
-  function createUser({ name, email, role }: CreateUserParams) {}
-  ```
-
-**Props設計（Props-drivenアプローチ）**
-- Propsはインターフェース: 必要な情報を全てPropsとして定義
-- 暗黙的依存を避ける: 必要なくグローバルstateやcontextに依存しない
-- 型安全性: Props型を常に明示的に定義
-
-**環境変数**
-- **ビルドツールの環境変数システムを使用**: `process.env`はブラウザで動作しない
-- **クライアントサイドに秘密情報なし**: フロントエンドコードは全て公開、秘密情報はバックエンドで管理
-
-**依存性注入**
-- **カスタムフックで依存性注入**: テスト可能性とモジュール性を確保
-
-**非同期処理**
-- Promise処理: 常に`async/await`使用
-- エラーハンドリング: 常に`try-catch`またはError Boundaryで処理
-- 型定義: 戻り値の型を明示的に定義（例: `Promise<Result>`）
-
-**フォーマットルール**
-- セミコロン省略（Biome設定に従う）
-- 型は`PascalCase`、変数・関数は`camelCase`
-- importは絶対パス使用（`src/`）
-
-**Clean Code原則**
-- ✅ 未使用コードは即座に削除
-- ✅ デバッグ用`console.log()`削除
-- ❌ コメントアウトされたコード（履歴はバージョン管理で）
-- ✅ コメントは「理由」を説明（「何を」ではない）
-
-## エラーハンドリング
-
-**絶対ルール**: エラー抑制禁止。全てのエラーはログ出力と適切な処理が必須。
-
-**Fail-Fast原則**: エラー時は速やかに失敗し、無効な状態での処理継続を防ぐ
-```typescript
-// ❌ 禁止: 無条件フォールバック
-catch (error) {
-  return defaultValue // エラーを隠蔽
-}
-
-// ✅ 必須: 明示的な失敗
-catch (error) {
-  logger.error('処理失敗', error)
-  throw error // Error Boundaryまたは上位層で処理
-}
-```
-
-**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), ApiError(502), NotFoundError(404)
-```
-
-**レイヤー別エラーハンドリング（React）**
-- Error Boundary: Reactコンポーネントエラーをキャッチ、フォールバックUI表示
-- Custom Hook: ビジネスルール違反を検出、AppErrorをそのまま伝播
-- API層: fetchエラーをドメインエラーに変換
-
-**構造化ロギングと機密情報保護**
-ログに機密情報（password、token、apiKey、secret、creditCard）を絶対含めない
-
-**Reactでの非同期エラーハンドリング**
-- Error Boundaryセットアップ必須: レンダリングエラーをキャッチ
-- イベントハンドラ内の全async/awaitでtry-catch使用
-- エラーは常にログ記録し、再スローまたはerror stateで表示
-
-## パフォーマンス最適化
-
-- コンポーネントメモ化: 高コストコンポーネントにReact.memo使用
-- State最適化: 適切なstate構造で再レンダリングを最小化
-- 遅延読み込み: React.lazyとSuspenseでコード分割
-- バンドルサイズ: `build`スクリプト（package.jsonの`packageManager`フィールドに応じた実行コマンドを使用）で監視し最適化