create-ai-project 1.11.2 → 1.12.1

package/docs/rules/ai-development-guide.md

@@ -1,260 +0,0 @@
-# AI開発者ガイド - 技術的判断基準とアンチパターン集
-
-## 技術的アンチパターン（赤信号パターン）
-
-以下のパターンを検出したら即座に停止し、設計を見直すこと：
-
-### コード品質のアンチパターン
-1. **同じようなコードを3回以上書いた** - Rule of Threeに違反
-2. **単一ファイルに複数の責務が混在** - 単一責任原則（SRP）違反
-3. **同じ内容を複数ファイルで定義** - DRY原則違反
-4. **依存関係を確認せずに変更** - 予期しない影響の可能性
-5. **コメントアウトでコード無効化** - バージョン管理を活用すべき
-6. **エラーの握りつぶし** - 問題の隠蔽は技術的負債
-7. **型アサーション（as）の多用** - 型安全性の放棄
-
-### 設計のアンチパターン
-- **「一旦動くように」という思考** - 技術的負債の蓄積
-- **継ぎ足し実装** - 既存コードへの無計画な追加
-- **不確実技術の楽観的実装** - 未知要素を「たぶん動く」前提で設計
-- **対処療法的修正** - 根本原因を解決しない表面的な修正
-- **無計画な大規模変更** - 段階的アプローチの欠如
-
-## フォールバック処理に関する設計原則
-
-### 基本原則：Fail-Fast
-分散システムにおいて、フォールバック処理よりもプライマリコードの信頼性向上を優先する設計思想。
-
-### フォールバック実装の判断基準
-- **原則禁止**: エラー時の無条件フォールバックは実装しない
-- **例外的許可**: Design Docで明示的に定義された場合のみ実装
-- **レイヤー責務**:
-  - インフラ層: エラーを必ず上位に投げる（フォールバック判断なし）
-  - アプリケーション層: ビジネス要件に基づく判断を実装
-
-### フォールバック過多の検出
-- 同一機能で3つ目のcatch文を書く時点で設計見直しを必須とする
-- フォールバックを実装する前にDesign Docでの定義を確認
-- エラーは適切にログ出力し、失敗を明確にする
-
-## Rule of Three - コード重複の判断基準
-
-Martin Fowler「Refactoring」に基づく重複コードの扱い方：
-
-| 重複回数 | 対応 | 理由 |
-|---------|------|------|
-| 1回目 | インライン実装 | 将来の変化が予測できない |
-| 2回目 | 将来の統合を意識 | パターンが見え始める |
-| 3回目 | 共通化実施 | パターンが確立された |
-
-### 共通化の判断基準
-
-**共通化すべきケース**
-- ビジネスロジックの重複
-- 複雑な処理アルゴリズム
-- 一括変更が必要になる可能性が高い箇所
-- バリデーションルール
-
-**共通化を避けるべきケース**
-- 偶然の一致（たまたま同じコード）
-- 将来異なる方向に進化する可能性
-- 共通化により可読性が著しく低下
-- テストコード内の簡単なヘルパー
-
-### 実装例
-```typescript
-// ❌ 1回目の重複で即共通化
-function validateUserEmail(email: string) { /* ... */ }
-function validateContactEmail(email: string) { /* ... */ }
-
-// ✅ 3回目で共通化
-function validateEmail(email: string, context: 'user' | 'contact' | 'admin') { /* ... */ }
-```
-
-## よくある失敗パターンと回避方法
-
-### パターン1: エラー修正の連鎖
-**症状**: エラーを修正すると新しいエラーが発生
-**原因**: 根本原因を理解せずに表面的な修正
-**回避方法**: 5 Whysで根本原因を特定してから修正
-
-### パターン2: 型安全性の放棄
-**症状**: any型やasの多用
-**原因**: 型エラーを回避したい衝動
-**回避方法**: unknown型と型ガードで安全に処理
-
-### パターン3: テスト不足での実装
-**症状**: 実装後にバグ多発
-**原因**: Red-Green-Refactorプロセスの無視
-**回避方法**: 必ず失敗するテストから開始
-
-### パターン4: 技術的不確実性の無視
-**症状**: 新技術導入時の想定外エラー多発
-**原因**: 事前調査なしで「公式ドキュメント通りなら動くはず」
-**回避方法**: 
-- タスクファイル冒頭に確実性評価を記載
-  ```
-  確実性: low（理由: MCP接続の実例がない）
-  探索的実装: true
-  フォールバック: 従来APIを使用
-  ```
-- 確実性lowの場合、最初に最小限の動作確認コードを作成
-- 動作確認できたら本実装、できなければフォールバック実行
-
-### パターン5: 既存コード調査不足
-**症状**: 重複実装、アーキテクチャ不整合、結合時の障害
-**原因**: 実装前の既存コード理解不足
-**回避方法**: 
-- 実装前に類似機能の存在を必ず検索（同じドメイン、責務、設定パターンをキーワードに）
-- 類似機能を発見 → その実装を使用する（新規実装は行わない）
-- 類似機能が技術的負債 → ADRで改善提案を作成してから実装
-- 類似機能が存在しない → 既存の設計思想に沿って新規実装
-- すべての判断と根拠をDesign Docの「既存コードベース分析」セクションに記録
-
-## デバッグ手法
-
-### 1. エラー分析手順
-1. エラーメッセージ（最初の行）を正確に読む
-2. スタックトレースの最初と最後に注目
-3. 自分のコードが現れる最初の行を特定
-
-### 2. 5 Whys - 根本原因分析
-```
-症状: TypeScriptのビルドエラー
-Why1: 型定義が一致しない → Why2: インターフェースが更新された
-Why3: 依存関係の変更 → Why4: パッケージ更新の影響
-Why5: 破壊的変更を含むメジャーバージョンアップ
-根本原因: package.jsonでのバージョン指定が不適切
-```
-
-### 3. 最小再現コード
-問題を切り分けるため、最小限のコードで再現を試みる：
-- 関連のない部分を削除
-- モックで外部依存を置き換え
-- 問題が再現する最小構成を作成
-
-### 4. デバッグログ出力
-```typescript
-console.log('DEBUG:', {
-  context: 'user-creation',
-  input: { email, name },
-  state: currentState,
-  timestamp: new Date().toISOString()
-})
-```
-
-## 品質チェックコマンドリファレンス
-
-### Phase 1-3: 基本チェック
-```bash
-# Biome総合チェック（lint + format）
-npm run check
-
-# 未使用エクスポートの検出
-npm run check:unused
-
-# TypeScriptビルド
-npm run build
-```
-
-### Phase 4-6: テストと最終確認
-```bash
-# テスト実行
-npm test
-
-# カバレッジ測定（キャッシュクリア）
-npm run test:coverage:fresh
-
-# 全体統合チェック
-npm run check:all
-```
-
-### 補助コマンド
-```bash
-# カバレッジレポート確認
-open coverage/index.html
-
-# Vitestプロセスのクリーンアップ（テスト後必須）
-npm run cleanup:processes
-
-# 安全なテスト実行（自動クリーンアップ付き）
-npm run test:safe
-
-# 自動修正
-npm run format        # フォーマット修正
-npm run lint:fix      # Lint修正
-```
-
-### トラブルシューティング
-- **ポート使用中エラー**: `npm run cleanup:processes`
-- **キャッシュ問題**: `npm run test:coverage:fresh`
-- **依存関係エラー**: `npm ci`で再インストール
-
-## 技術的判断が必要な場面
-
-### 抽象化のタイミング
-- 具体的な実装を3回書いてからパターンを抽出
-- YAGNIを意識し、現在必要な機能のみ実装
-- 将来の拡張性より現在のシンプルさを優先
-
-### パフォーマンス vs 可読性
-- 明確なボトルネックがない限り可読性を優先
-- 計測してから最適化（推測するな、計測せよ）
-- 最適化する場合はコメントで理由を明記
-
-### 型定義の粒度
-- 過度に細かい型は保守性を低下させる
-- ドメインを適切に表現する型を設計
-- ユーティリティ型を活用して重複を削減
-
-## 継続的改善のマインドセット
-
-- **謙虚**: 完璧なコードは存在しない、フィードバック歓迎
-- **勇気**: 必要なリファクタリングは大胆に実行
-- **透明性**: 技術的な判断理由を明確に記録
-
-## 実装作業の完全性担保
-
-### 影響範囲調査の必須手順
-
-**完了定義**: 以下3段階すべての完了
-
-#### 1. 検索（Discovery）
-```bash
-Grep -n "TargetClass\|TargetMethod" -o content
-Grep -n "DependencyClass" -o content
-Grep -n "targetData\|SetData\|UpdateData" -o content
-```
-
-#### 2. 読解（Understanding）
-**必須**: 発見した全ファイルを読み込み、作業に必要な部分をコンテキストに含める：
-- 呼び出し元の目的と文脈
-- 依存関係の方向
-- データフロー: 生成→変更→参照
-
-#### 3. 特定（Identification）
-影響範囲の構造化報告（必須）：
-```
-## 影響範囲分析
-### 直接影響: ClassA、ClassB（理由明記）
-### 間接影響: SystemX、PrefabY（連携経路明記）
-### 処理フロー: 入力→処理1→処理2→出力
-```
-
-**重要**: 検索のみで完了とせず、3段階すべてを実行すること
-
-### 未使用コード削除ルール
-
-未使用コード検出時 → 使用予定？
-- Yes → 即実装（保留禁止）
-- No → 即削除（Git履歴に残る）
-
-対象: コード・ドキュメント・設定ファイル
-
-### 既存コード削除判断フロー
-
-```
-使用中？ No → 即削除（Git履歴に残る）
-      Yes → 動作？ No → 削除+再実装
-                  Yes → 修正
-```

package/docs/rules/documentation-criteria.md

@@ -1,180 +0,0 @@
-# ドキュメント作成基準
-
-## 作成判定マトリクス
-
-| 条件 | 必要ドキュメント | 作成順序 |
-|-----|--------------|---------|
-| 新機能追加 | PRD → [ADR] → Design Doc → 作業計画書 | PRD承認後 |
-| ADR条件該当（下記参照） | ADR → Design Doc → 作業計画書 | 即座に開始 |
-| 6ファイル以上 | ADR → Design Doc → 作業計画書（必須） | 即座に開始 |
-| 3-5ファイル | Design Doc → 作業計画書（推奨） | 即座に開始 |
-| 1-2ファイル | なし | 直接実装 |
-
-## ADR作成条件（いずれか該当で必須）
-
-### 1. 型システム変更
-- **3階層以上のネスト型追加**: `type A = { b: { c: { d: T } } }`
-  - 判断理由: 深いネストは複雑性が高く、影響範囲が広い
-- **3箇所以上で使用される型の変更・削除**
-  - 判断理由: 複数箇所への影響は慎重な判断が必要
-- **型の責務変更**（例: DTO→Entity）
-  - 判断理由: 概念モデルの変更は設計思想に関わる
-
-### 2. データフロー変更
-- **保存場所変更**（DB→ファイル、メモリ→キャッシュ）
-- **3ステップ以上の処理順序変更**
-  - 例: 「入力→検証→保存」から「入力→保存→非同期検証」
-- **データ受け渡し方法変更**（props→Context、直接参照→イベント）
-
-### 3. アーキテクチャ変更
-- レイヤー追加・責務変更・コンポーネント再配置
-
-### 4. 外部依存変更
-- ライブラリ・フレームワーク・外部API導入・置換
-
-### 5. 複雑な実装ロジック（規模に関わらず）
-- 3つ以上の状態を管理
-- 5つ以上の非同期処理の連携
-
-## 各ドキュメントの詳細定義
-
-### PRD（Product Requirements Document）
-
-**目的**: ビジネス要件とユーザー価値を定義
-
-**含むもの**:
-- ビジネス要件とユーザー価値
-- 成功指標とKPI（測定可能な形式）
-- ユーザーストーリーとユースケース
-- MoSCoW法による優先順位（Must/Should/Could/Won't）
-- MVPとFutureフェーズの分離
-- ユーザージャーニー図（必須）
-- スコープ境界図（必須）
-
-**含まないもの**:
-- 技術実装詳細（→Design Doc）
-- 技術選定理由（→ADR）
-- **実装フェーズ**（→作業計画書）
-- **タスク分解**（→作業計画書）
-
-### ADR（Architecture Decision Record）
-
-**目的**: 技術的決定の理由と背景を記録
-
-**含むもの**:
-- 決定事項（何を選択したか）
-- 根拠（なぜその選択をしたか）
-- 選択肢の比較（最低3案）とトレードオフ
-- アーキテクチャへの影響
-- 実装への原則的な指針（例:「依存性注入を使用」）
-
-**含まないもの**:
-- 実装スケジュール、期間（→作業計画書）
-- 実装手順の詳細（→Design Doc）
-- 具体的なコード例（→Design Doc）
-- 担当者の割り当て（→作業計画書）
-
-### Design Document
-
-**目的**: 技術的実装方法を詳細定義
-
-**含むもの**:
-- **既存コードベース分析**（必須）
-  - 実装パスマッピング（既存と新規の両方を記載）
-  - 統合点の明確化（新規実装でも既存との接続点を記載）
-- 技術的実装アプローチ（垂直/水平/ハイブリッド）
-- **技術的依存関係と実装制約**（実装の必要順序）
-- インターフェース定義と型定義
-- データフローとコンポーネント設計
-- **統合ポイントでのE2E確認手順**
-- **受入条件（測定可能な形式）**
-- 変更影響マップ（直接影響/間接影響/波及なしを明記）
-- 統合点の完全な列挙
-- データ契約の明確化
-- **合意事項チェックリスト**（関係者との合意内容）
-- **前提となるADR**（共通ADR含む）
-
-**必須構造要素**:
-```yaml
-変更影響マップ:
-  変更対象: [コンポーネント/機能]
-  直接影響: [ファイル/関数]
-  間接影響: [データ形式/処理時間]
-  波及なし: [影響を受けない機能]
-
-インターフェース変更マトリクス:
-  既存: [メソッド名]
-  新規: [メソッド名]
-  変換必要性: [あり/なし]
-  互換性確保: [方法]
-```
-
-**含まないもの**:
-- なぜその技術を選んだか（→ADR参照）
-- いつ実装するか、期間（→作業計画書）
-- 誰が実装するか（→作業計画書）
-
-### 作業計画書
-
-**目的**: 実装タスクの管理と進捗追跡
-
-**含むもの**:
-- **フェーズ構成**（Design Docの技術的依存関係を基に作成）
-- タスク分解と依存関係（最大2階層まで）
-- スケジュールと期間見積もり
-- **Design DocのE2E確認手順を各フェーズに配置**
-- **最終フェーズに品質保証を含む**（必須）
-- 進捗記録（チェックボックス形式）
-
-**含まないもの**:
-- 技術的な根拠（→ADR）
-- 設計の詳細（→Design Doc）
-- 技術的依存関係の決定（→Design Doc）
-
-**タスク完了定義の3要素**:
-1. **実装完了**: コードが動作する
-2. **品質完了**: テスト・型チェック・リントがパス
-3. **統合完了**: 他コンポーネントとの連携確認
-
-## 作成プロセス
-
-1. **問題分析**: 変更規模判定、ADR条件確認
-2. **ADR選択肢検討**（ADR時のみ）: 3案以上比較、トレードオフ明記
-3. **作成**: テンプレート使用、測定可能な条件記載
-4. **承認**: レビュー後「Accepted」で実装可
-
-## 保存場所
-
-| ドキュメント | パス | 命名規則 | テンプレート |
-|------------|-----|---------|------------|
-| PRD | `docs/prd/` | `[機能名]-prd.md` | `template-ja.md` |
-| ADR | `docs/adr/` | `ADR-[4桁]-[タイトル].md` | `template-ja.md` |
-| Design Doc | `docs/design/` | `[機能名]-design.md` | `template-ja.md` |
-| 作業計画書 | `docs/plans/` | `YYYYMMDD-{type}-{description}.md` | `template-ja.md` |
-
-※作業計画書は`.gitignore`で除外
-
-## ADRステータス
-`Proposed` → `Accepted` → `Deprecated`/`Superseded`/`Rejected`
-
-## AI自動化ルール
-- 5ファイル以上: ADR作成提案
-- 型・データフロー変更検出: ADR必須化
-- 既存ADR確認してから実装
-
-## 図表作成要件
-
-各ドキュメントで必須の図表（mermaid記法使用）：
-
-| ドキュメント | 必須図表 | 目的 |
-|------------|---------|-----|
-| PRD | ユーザージャーニー図、スコープ境界図 | ユーザー体験と範囲の明確化 |
-| ADR | 選択肢比較図（必要時） | トレードオフの視覚化 |
-| Design Doc | アーキテクチャ図、データフロー図 | 技術構造の理解 |
-| 作業計画書 | フェーズ構成図、タスク依存関係図 | 実装順序の明確化 |
-
-## 共通ADRとの関係性
-1. **作成時**: 共通技術領域（ログ、エラーハンドリング、非同期処理等）を特定し、既存共通ADRを参照
-2. **不足時**: 必要な共通ADRが存在しない場合は作成を検討
-3. **Design Doc**: 「前提となるADR」セクションで共通ADRを明記
-4. **準拠確認**: 設計が共通ADRの決定事項と整合しているかを検証

package/docs/rules/project-context.md

@@ -1,38 +0,0 @@
-# プロジェクトコンテキスト
-
-## 基本設定
-
-### プロジェクトの性質
-- **プロジェクト形態**: 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/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. **明確な責務分離**: 各層の責務を明確に定義
-
-#### データフローのベストプラクティス
-- **入力時点での検証**: データは入力層で検証し、型安全な形で内部に渡す
-- **変換の一元化**: データ変換ロジックは専用のユーティリティに集約
-- **ログの構造化**: データフローの各段階で構造化ログを出力
-
-## ビルドとテスト
-
-プロジェクトごとにビルドコマンドとテスト実行方法を定義。
-
-品質チェックは実装完了時に必須。