create-ai-project 1.11.2

package/docs/rules-ja/frontend/typescript-testing.md

@@ -0,0 +1,124 @@
+# TypeScript テストルール（フロントエンド）
+
+## テストフレームワーク
+- **Vitest**: このプロジェクトではVitestを使用
+- **React Testing Library**: コンポーネントテスト用
+- **MSW (Mock Service Worker)**: APIモック用
+- テストのインポート: `import { describe, it, expect, beforeEach, vi } from 'vitest'`
+- コンポーネントテストのインポート: `import { render, screen, fireEvent } from '@testing-library/react'`
+- モックの作成: `vi.mock()` を使用
+
+## テストの基本方針
+
+### 品質要件
+- **カバレッジ**: 単体テストのカバレッジは60%以上を必須（フロントエンド標準 2025）
+- **独立性**: 各テストは他のテストに依存せず実行可能
+- **再現性**: テストは環境に依存せず、常に同じ結果を返す
+- **可読性**: テストコードも製品コードと同様の品質を維持
+
+### カバレッジ要件（ADR-0002準拠）
+**必須**: 単体テストのカバレッジは60%以上
+**コンポーネント別目標**:
+- Atoms（Button、Text等）: 70%以上
+- Molecules（FormField等）: 65%以上
+- Organisms（Header、Footer等）: 60%以上
+- Custom Hooks: 65%以上
+- Utils: 70%以上
+
+**指標**: Statements（文）、Branches（分岐）、Functions（関数）、Lines（行）
+
+### テストの種類と範囲
+1. **単体テスト（React Testing Library）**
+   - 個々のコンポーネントや関数の動作を検証
+   - 外部依存はすべてモック化
+   - 最も数が多く、細かい粒度で実施
+   - ユーザーから観測可能な振る舞いに焦点を当てる
+
+2. **統合テスト（React Testing Library + MSW）**
+   - 複数のコンポーネントの連携を検証
+   - MSW（Mock Service Worker）でAPIをモック
+   - 実際のDB接続なし（DBはバックエンドが管理）
+   - 主要な機能フローの検証
+
+3. **E2Eテストでの機能横断検証**
+   - 新機能追加時、既存機能への影響を必ず検証
+   - Design Docの「統合ポイントマップ」で影響度「高」「中」の箇所をカバー
+   - 検証パターン: 既存機能動作 → 新機能有効化 → 既存機能の継続性確認
+   - 判定基準: 表示内容の変化なし、レンダリング時間5秒以内
+   - CI/CDでの自動実行を前提とした設計
+
+## テストの実装規約
+
+### ディレクトリ構造（Co-location原則）
+```
+src/
+└── components/
+    └── Button/
+        ├── Button.tsx
+        ├── Button.test.tsx  # コンポーネントと同じ場所に配置
+        └── index.ts
+```
+
+**理由**:
+- React Testing Libraryのベストプラクティス
+- ADR-0002 Co-location原則
+- 実装と一緒にテストを見つけやすく、保守しやすい
+
+### 命名規則
+- テストファイル: `{ComponentName}.test.tsx`
+- 統合テストファイル: `{FeatureName}.integration.test.tsx`
+- テストスイート: 対象のコンポーネントや機能を説明する名前
+- テストケース: ユーザー視点から期待される動作を説明する名前
+
+### テストコードの品質ルール
+
+✅ **推奨: すべてのテストを常に有効に保つ**
+- メリット: テストスイートの完全性を保証
+- 実践: 問題があるテストは修正して有効化
+
+❌ **避けるべき: test.skip()やコメントアウト**
+- 理由: テストの穴が生まれ、品質チェックが不完全になる
+- 対処: 不要なテストは完全に削除する
+
+## モックの型安全性の徹底
+
+### MSW（Mock Service Worker）セットアップ
+```typescript
+// ✅ 型安全なMSWハンドラー
+import { rest } from 'msw'
+
+const handlers = [
+  rest.get('/api/users/:id', (req, res, ctx) => {
+    return res(ctx.json({ id: '1', name: 'John' } satisfies User))
+  })
+]
+```
+
+### コンポーネントモックの型安全性
+```typescript
+// ✅ 必要な部分のみ
+type TestProps = Pick<ButtonProps, 'label' | 'onClick'>
+const mockProps: TestProps = { label: 'Click', onClick: vi.fn() }
+
+// やむを得ない場合のみ、理由明記
+const mockRouter = {
+  push: vi.fn()
+} as unknown as Router // 複雑なRouter型構造のため
+```
+
+## React Testing Libraryの基本例
+
+```typescript
+import { describe, it, expect, vi } from 'vitest'
+import { render, screen, fireEvent } from '@testing-library/react'
+import { Button } from './Button'
+
+describe('Button', () => {
+  it('should call onClick when clicked', () => {
+    const onClick = vi.fn()
+    render(<Button label="Click me" onClick={onClick} />)
+    fireEvent.click(screen.getByRole('button', { name: 'Click me' }))
+    expect(onClick).toHaveBeenCalledOnce()
+  })
+})
+```

package/docs/rules-ja/frontend/typescript.md

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

package/docs/rules-ja/integration-e2e-testing.md

@@ -0,0 +1,149 @@
+# 統合テスト・E2Eテスト設計・実装ルール
+
+## テスト種別と上限
+
+| 種別 | 目的 | ファイル形式 | 上限 |
+|------|------|-------------|------|
+| 統合テスト | コンポーネント間連携検証 | `*.int.test.ts` | 機能あたり3件 |
+| E2Eテスト | クリティカルユーザージャーニー検証 | `*.e2e.test.ts` | 機能あたり1-2件 |
+
+**クリティカルユーザージャーニー**: 収益影響・法的要件・大多数のユーザーが日常的に利用する機能
+
+## 振る舞い優先の原則
+
+### 観測可能性チェック（全てYESで対象）
+
+| チェック | 質問 | NOの場合 |
+|---------|------|----------|
+| 観測可能 | ユーザーが結果を観測できるか？ | 除外 |
+| システム文脈 | 複数コンポーネントの統合が必要か？ | 除外 |
+| 自動化可能 | CI環境で安定実行できるか？ | 除外 |
+
+### Include/Exclude基準
+
+**Include**: ビジネスロジック正確性、データ整合性、ユーザー可視機能、エラーハンドリング
+**Exclude**: 外部実接続、パフォーマンス指標、実装詳細、UIレイアウト
+
+## スケルトン仕様
+
+### 必須コメント形式
+
+```typescript
+// AC: "[受入条件原文]"
+// ROI: [0-100] | ビジネス価値: [0-10] | 頻度: [0-10]
+// 振る舞い: [トリガー] → [処理] → [観測可能な結果]
+// @category: core-functionality | integration | edge-case | ux | e2e
+// @dependency: none | [コンポーネント名] | full-system
+// @complexity: low | medium | high
+it.todo('[AC番号]: [テスト名]')
+```
+
+### Property注釈
+
+```typescript
+// Property: `[検証式]`
+// fast-check: fc.property(fc.[arbitrary], (input) => [不変条件])
+it.todo('[AC番号]-property: [不変条件記述]')
+```
+
+### ROI計算
+
+```
+ROI = (ビジネス価値 × 頻度 + 法的要件 × 10 + 欠陥検出) / 総コスト
+```
+
+| 種別 | 総コスト | E2E生成条件 |
+|------|---------|------------|
+| 統合 | 11 | - |
+| E2E | 38 | ROI > 50 |
+
+## 実装ルール
+
+### Property-Based Test実装
+
+Property注釈がある場合、fast-checkライブラリ必須:
+
+```typescript
+import fc from 'fast-check'
+
+it('AC2-property: モデル名は常にgemini-3-pro-image-preview', () => {
+  fc.assert(
+    fc.property(fc.string(), (prompt) => {
+      const result = client.generate(prompt)
+      return result.model === 'gemini-3-pro-image-preview'
+    })
+  )
+})
+```
+
+**必須事項**:
+- `fc.assert(fc.property(...))` 形式で記述
+- スケルトンの`// fast-check:`コメントをそのまま実装に反映
+- 失敗ケース発見時は具体的なユニットテストとして追加（リグレッション防止）
+
+### 振る舞い検証の実装
+
+**振る舞い記述の検証レベル**:
+
+| ステップ種別 | 検証対象 | 例 |
+|-------------|---------|-----|
+| トリガー | Arrangeで再現 | API障害 → mockResolvedValue({ ok: false }) |
+| 処理 | 中間状態または呼び出し | 関数呼び出し、状態変更 |
+| 観測可能な結果 | 最終出力の値 | 戻り値、エラーメッセージ、ログ出力 |
+
+**判定基準**: 「観測可能な結果」がテスト対象の**戻り値またはモックの呼び出し引数**として検証されていれば合格
+
+### 検証項目の決定ルール
+
+| スケルトンの状態 | 検証項目の決定方法 |
+|-----------------|-------------------|
+| `// 検証項目:` が列挙されている | 列挙された全項目をexpectで実装 |
+| `// 検証項目:` がない | 「振る舞い」記述の「観測可能な結果」から導出 |
+| 両方ある | 検証項目を優先、振る舞いは補足として使用 |
+
+**振る舞いからの導出例**:
+```
+// 振る舞い: ユーザーが決済完了 → DBに注文作成 → 注文確認画面表示
+↓ 導出
+- 注文がDBに作成される（または作成関数が呼び出される）
+- 注文確認画面のデータが返される
+```
+
+### 統合テストのモック境界
+
+| 判断基準 | モック | 実物 |
+|---------|--------|------|
+| テスト対象の一部か？ | No → モック可 | Yes → 実物必須 |
+| 呼び出しがテストの検証対象か？ | No → モック可 | Yes → 実物または検証可能なモック |
+| 外部ネットワーク通信か？ | Yes → モック必須 | No → 実物推奨 |
+
+**判定フロー**:
+1. 外部API（HTTP通信）→ モック必須
+2. テスト対象のコンポーネント間連携 → 実物必須
+3. ログ出力の検証が必要 → 検証可能なモック（vi.fn()）を使用
+4. ログ出力の検証が不要 → 実物または無視
+
+### E2Eテストの実行条件
+
+- 全コンポーネント実装完了後に実行
+- モック禁止（`@dependency: full-system`）
+
+## レビュー基準
+
+### スケルトンと実装の整合性
+
+| チェック | 不合格条件 |
+|---------|-----------|
+| Property検証 | Property注釈があるのにfast-check未使用 |
+| 振る舞い検証 | 「観測可能な結果」に対応するexpectがない |
+| 検証項目網羅 | 列挙された検証項目がexpectに含まれていない |
+| モック境界 | 統合テストで内部コンポーネントをモック化 |
+
+### 実装品質
+
+| チェック | 不合格条件 |
+|---------|-----------|
+| AAA構造 | Arrange/Act/Assertの区切りが不明確 |
+| 独立性 | テスト間で状態共有、実行順序依存 |
+| 再現性 | 日時・乱数に依存し結果が変動 |
+| 可読性 | テスト名と検証内容が一致しない |

package/docs/rules-ja/project-context.md

@@ -0,0 +1,38 @@
+# プロジェクトコンテキスト
+
+## 基本設定
+
+### プロジェクトの性質
+- **プロジェクト形態**: Claude Code専用TypeScriptプロジェクトテンプレート
+- **利用範囲**: プロジェクトの要件に応じて設定可能
+- **実装方針**: LLM主導実装、品質重視、YAGNI原則徹底
+
+### 技術スタック
+- **基盤技術**: TypeScript、Node.js
+- **テストフレームワーク**: Vitest
+- **品質管理**: Biome、TypeScript strict mode
+
+## 実装原則
+
+### 実装方針の特徴
+- **LLM主導実装**: Claude Codeが主要な実装者として機能
+- **品質重視**: 速度より品質を優先する文化
+- **YAGNI原則**: 必要になるまで実装しない
+- **体系的な設計**: ADR/Design Doc/作業計画書による設計プロセス
+
+## カスタマイズガイド
+
+新しいプロジェクトでこのテンプレートを使用する場合：
+
+1. **プロジェクト固有情報の追加**
+   - ターゲットユーザー特性
+   - ビジネス要件と制約
+   - 技術的制約事項
+
+2. **アーキテクチャの選択**
+   - `docs/rules/architecture/` から適切なパターンを選択
+   - `docs/rules/architecture/` にプロジェクト固有の設計を配置
+
+3. **環境設定**
+   - プロジェクトに適した環境変数管理方法の実装
+   - プロジェクト固有の設定ファイル追加

package/docs/rules-ja/rules-index.yaml

@@ -0,0 +1,196 @@
+# 各ルールファイルのメタデータ
+# 各ルールの概要、タグ、典型的な使用場面、サイズを管理
+
+rules:
+  coding-standards:
+    file: "coding-standards.md"
+    tags: [anti-patterns, technical-judgment, debugging, rule-of-three, implementation, type-safety, refactoring, code-reading, best-practices, impact-analysis, unused-code, code-deletion, testing, tdd]
+    typical-use: "全ドメイン共通の技術的判断基準、アンチパターン検出、デバッグ手法、実装時のベストプラクティス、影響範囲調査、未使用コード削除、テスト設計原則"
+    size: large
+    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"
+      - "Test-Driven Development - Kent Beck"
+      - "Red-Green-Refactor - Kent Beck"
+      - "AAAパターン - Arrange-Act-Assert"
+    sections:
+      - "技術的アンチパターン（赤信号パターン）"
+      - "基本原則"
+      - "コメント記述ルール"
+      - "エラーハンドリングの基本原則"
+      - "Rule of Three - コード重複の判断基準"
+      - "よくある失敗パターンと回避方法"
+      - "デバッグ手法"
+      - "型安全性の基礎"
+      - "リファクタリング手法"
+      - "技術的判断が必要な場面"
+      - "継続的改善のマインドセット"
+      - "実装作業の完全性担保"
+      - "Red-Green-Refactorプロセス（テストファースト開発）"
+      - "テスト設計原則"
+      - "テストヘルパーの活用ルール"
+      - "テストの粒度原則"
+      - "継続性テストの範囲"
+
+  typescript:
+    file: "typescript.md"
+    tags: [implementation, type-safety, async, coding-style, functional-programming, dependency-injection, backend]
+    typical-use: "バックエンドTypeScriptコードの作成・修正、クラス使用判断、DI実装"
+    size: small
+    key-references:
+      - "Dependency Injection - Martin Fowler"
+    sections:
+      - "Backend実装における型安全性"
+      - "コーディング規約"
+      - "エラーハンドリング"
+      - "パフォーマンス最適化"
+
+  typescript-testing:
+    file: "typescript-testing.md"
+    tags: [quality, testing, coverage, vitest, backend, implementation]
+    typical-use: "バックエンドテスト作成、Vitest設定、70%カバレッジ要件、テスト品質基準"
+    size: small
+    key-references:
+      - "Vitest公式ドキュメント"
+    sections:
+      - "テストフレームワーク"
+      - "テストの基本方針"
+      - "テストの実装規約"
+      - "テスト品質基準"
+      - "モックの型安全性"
+      - "Vitestの基本例"
+
+  technical-spec:
+    file: "technical-spec.md"
+    tags: [architecture, design, documentation, environment, data-flow, implementation, quality-commands, testing, build]
+    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:
+      - "メタ認知的戦略選択プロセス"
+      - "確認レベル定義"
+      - "統合ポイントの定義"
+      - "アンチパターン"
+      - "メタ認知的実行のための指針"
+
+  integration-e2e-testing:
+    file: "integration-e2e-testing.md"
+    tags: [testing, integration-test, e2e-test, property-based-testing, fast-check, test-skeleton, test-review, quality]
+    typical-use: "統合テスト・E2Eテストのスケルトン生成、テスト実装、テストレビュー、Property-Based Test実装"
+    size: small
+    key-references:
+      - "fast-check - Property-based testing for TypeScript"
+      - "Node.js Testing Best Practices - Yoni Goldberg"
+      - "Property-Based Testing - 2025 Practices"
+    sections:
+      - "テスト種別と上限"
+      - "振る舞い優先の原則"
+      - "スケルトン仕様"
+      - "実装ルール"
+      - "レビュー基準"
+
+  frontend-typescript:
+    file: "frontend/typescript.md"
+    tags: [frontend, react, implementation, type-safety, props-driven, hooks, component-design, vite, error-boundary]
+    typical-use: "React/Viteでのフロントエンド開発、コンポーネント設計、Props設計、環境変数管理"
+    size: small
+    key-references:
+      - "React公式ドキュメント - Function Components"
+      - "Props-driven開発 - React Patterns"
+    sections:
+      - "フロントエンド固有のアンチパターン"
+      - "Frontend実装における型安全性"
+      - "コーディング規約"
+      - "エラーハンドリング"
+      - "パフォーマンス最適化"
+
+  frontend-typescript-testing:
+    file: "frontend/typescript-testing.md"
+    tags: [frontend, react, quality, testing, coverage, vitest, react-testing-library, msw, component-testing, implementation]
+    typical-use: "Reactコンポーネントのテスト作成、React Testing Library、MSW、60%カバレッジ要件、Co-location"
+    size: small
+    key-references:
+      - "React Testing Library - Kent C. Dodds"
+      - "MSW (Mock Service Worker) - API Mocking"
+      - "ADR-0002 Co-location原則"
+    sections:
+      - "テストフレームワーク"
+      - "テストの基本方針"
+      - "テストの実装規約"
+      - "モックの型安全性の徹底"
+      - "React Testing Libraryの基本例"
+
+  frontend-technical-spec:
+    file: "frontend/technical-spec.md"
+    tags: [frontend, react, architecture, design, documentation, environment, data-flow, implementation, vite, security, client-side, state-management, context-api, hooks, lighthouse, bundle-size, non-functional-requirements]
+    typical-use: "フロントエンド技術設計、環境変数管理（Vite）、セキュリティ制約、アーキテクチャ設計、状態管理パターン、実装方針決定、非機能要件の確認"
+    size: medium
+    key-references:
+      - "Vite公式ドキュメント - Environment Variables"
+      - "React公式ドキュメント - State Management"
+      - "Single Source of Truth - データフロー原則"
+      - "Immutable Update Patterns - React"
+      - "Lighthouse - Google Web Performance"
+      - "Web.dev - Performance Best Practices"
+    sections:
+      - "技術スタックの基本方針"
+      - "環境変数管理とセキュリティ"
+      - "アーキテクチャ設計"
+      - "データフロー統一原則"
+      - "ビルドとテスト"