create-ai-project 1.11.2 → 1.12.1

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/typescript.md

@@ -1,166 +0,0 @@
-# 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-ja/architecture/implementation-approach.md

@@ -1,136 +0,0 @@
-# 実装戦略選択フレームワーク（メタ認知的アプローチ）
-
-## メタ認知的戦略選択プロセス
-
-### Phase 1: 現状の包括的分析
-
-**核心質問**: 「既存の実装はどうなっているのか？」
-
-#### 分析フレームワーク
-```yaml
-アーキテクチャ分析: 責務分離、データフロー、依存関係、技術的負債
-実装品質評価: コード品質、テストカバレッジ、パフォーマンス、セキュリティ
-歴史的文脈理解: 現在の形の理由、過去判断の妥当性、制約の変化、要求の進化
-```
-
-#### メタ認知質問リスト
-- この実装の真の責務は何か？
-- どの部分がビジネス本質で、どの部分が技術的制約由来か？
-- コードから明確でない依存関係や暗黙の前提条件は何か？
-- 現在の設計がもたらしている利点と制約は？
-
-### Phase 2: 戦略探索と創造
-
-**核心質問**: 「before → after を判断する時に、参考にすべき実装パターンや戦略は何なのか？」
-
-#### 戦略発見プロセス
-```yaml
-調査・探索: 技術スタック事例（WebSearch活用）、同種プロジェクト、OSS実装、文献・ブログ
-創造的思考: 戦略組み合わせ、制約前提設計、フェーズ分け、拡張ポイント設計
-```
-
-#### 参考戦略パターン（創造的組み合わせを推奨）
-
-**レガシー対応戦略**:
-- ストラングラーパターン: 段階的置換による漸進的移行
-- ファサードパターン: 統一インターフェースによる複雑性の隠蔽
-- アダプターパターン: 既存システムとの橋渡し
-
-**新規開発戦略**:
-- 機能駆動開発: ユーザー価値重視の縦断実装
-- 基盤駆動開発: 安定性重視の基盤優先構築
-- リスク駆動開発: 最大リスク要素から優先的に対処
-
-**統合・移行戦略**:
-- プロキシパターン: 透過的な機能拡張
-- デコレーターパターン: 既存機能の段階的強化
-- ブリッジパターン: 抽象化による柔軟性確保
-
-**重要**: 最適解は各プロジェクトの文脈に応じた創造的思考により発見される。
-
-### Phase 3: リスク評価とコントロール
-
-**核心質問**: 「既存の実装にそれを当てはめた時にどういうリスクが発生し、それをどうコントロールするのが最良なのか？」
-
-#### リスク分析マトリクス
-```yaml
-技術的リスク: 既存システム影響、データ整合性、パフォーマンス劣化、統合複雑性
-運用リスク: サービス可用性、デプロイダウンタイム、運用プロセス変更、切り戻し手順
-プロジェクトリスク: スケジュール遅延、技術習得コスト、品質達成度、チーム連携
-```
-
-#### リスクコントロール戦略
-```yaml
-予防的対策: 段階的移行、並行動作検証、統合・回帰テスト追加、監視設定
-発生時対応: 切り戻し手順、ログ・メトリクス準備、連絡体制定義、サービス継続手順
-```
-
-### Phase 4: 制約適合性検証
-
-**核心質問**: 「このプロジェクトの制約は何か？」
-
-#### 制約チェックリスト
-```yaml
-技術的制約: ライブラリ互換性、リソース容量、義務要件、数値目標
-時間的制約: 期限・優先度、依存関係、マイルストーン、学習期間
-リソース制約: チーム・スキル、作業時間・体制、予算、外部契約
-ビジネス制約: 市場投入時期、顧客影響、法規制・標準
-```
-
-### Phase 5: 実装アプローチ決定
-
-基本的な実装アプローチから最適解を選択（創造的組み合わせも推奨）：
-
-#### 垂直スライス（機能駆動）
-**特徴**: 機能単位で全層を縦断実装
-**適用条件**: 機能間の依存が少ない、ユーザーが利用可能な形で出力、アーキテクチャ全層への変更が必要
-**確認方法**: 各機能完成時のエンドユーザー価値提供
-
-#### 水平スライス（基盤駆動）  
-**特徴**: アーキテクチャ層別の段階的構築
-**適用条件**: 基盤システムの安定性が重要、複数機能が共通基盤に依存、層別の段階的確認が有効
-**確認方法**: 全基盤層完成時の統合動作確認
-
-#### ハイブリッド（創造的組み合わせ）
-**特徴**: プロジェクト特性に応じた柔軟な組み合わせ
-**適用条件**: 要件が明確でない、フェーズごとにアプローチ変更が必要、プロトタイピングから本格実装への移行
-**確認方法**: 各フェーズの目標に応じてL1/L2/L3の適切なレベルで確認
-
-### Phase 6: 判断根拠の文書化
-
-**Design Docでの記載**：実装戦略の選択理由と根拠を明記する。
-
-## 確認レベル定義
-
-各タスクの完了確認における優先順位：
-
-- **L1: 機能動作確認** - エンドユーザー機能として動作（例：検索実行可能）
-- **L2: テスト動作確認** - 新規テストが追加されパス（例：型定義テスト）  
-- **L3: ビルド成功確認** - コンパイルエラーなし（例：インターフェース定義）
-
-**優先順位**: L1 > L2 > L3 の順で確認可能性を重視
-
-## 統合ポイントの定義
-
-選択した戦略に応じて統合ポイントを定義：
-- **ストラングラー系**: 各機能の新旧システム切り替え時
-- **機能駆動**: ユーザーが実際に機能を利用可能になった時
-- **基盤駆動**: 全アーキテクチャ層が揃いE2Eテストが通った時
-- **ハイブリッド**: 各フェーズで定義した個別目標達成時
-
-## アンチパターン
-
-- **パターン固執**: リスト内の戦略のみで選択し、独自の組み合わせを検討しない
-- **分析不足**: Phase 1の分析フレームワークを飛ばして戦略選択  
-- **リスク軽視**: Phase 3のリスク分析マトリクスを省略して実装着手
-- **制約無視**: Phase 4の制約チェックリストを確認せず戦略決定
-- **根拠省略**: Phase 6の文書化テンプレートを使用せず戦略選択
-
-## メタ認知的実行のための指針
-
-1. **既知パターンの活用**: 出発点として参考し、創造的組み合わせを探索
-2. **WebSearch積極活用**: 同種技術スタックの実装事例を調査  
-3. **5 Whys適用**: 根本理由を追求し本質を把握
-4. **複数観点評価**: Phase 1-4の各観点から網羅的に評価
-5. **創造的思考**: 複数戦略の順序適用やプロジェクト固有の制約を活かした設計を検討
-6. **判断根拠明示**: 設計ドキュメントでの戦略選択根拠を明示化

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`フィールドに応じた実行コマンドを使用）で監視し最適化