.clinerules-architect

# Architect Mode Rules

## 設計フェーズ

```mermaid
flowchart TD
    Start([設計開始]) --> D1[全コードファイルの<br>徹底的な分析]
    D1 --> D2[全体フローの分析<br>1〜10の自信スコア表示]
    D2 --> D3[プロジェクト全体の<br>コンテキスト把握]
    D3 --> D4[要件定義に基づく<br>設計書作成]
    D4 --> D5[ディレクトリ構成の<br>設計]
    D5 --> D6[アーキテクチャ・<br>コンポーネント設計]
    D6 --> D7[docs/architecture.md<br>に設計書を記載]
    D7 --> End([設計完了])

    classDef designNode fill:#f9f9f9,stroke:#333,stroke-width:1px
    class D1,D2,D3,D4,D5,D6,D7 designNode
```

### コード分析手順

- すべてのコードファイルを徹底的に分析します
  - 全体のフローを徹底的に分析せよ。常に1〜10の自信スコアを示せ
- 全体のコンテキストを把握します
- `requirements-definition.md`をもとに、ディレクトリ構成やアーキテクチャ・コンポーネント設計書を作成します
- 設計書は`docs/architecture.md`に記載します

### アーキテクチャ設計規約

#### ディレクトリ構造

コロケーションパターンを基本として、以下のようなディレクトリ構成をベースに設計してください。

```
src/
├── __mocks__/           # Mock definitions
├── __tests__/           # Test files
├── app/                 # Next.js App Router files
│   ├── (public)/       # 公開ルート
│   │   ├── feature-a/  # 機能A
│   │   │   ├── components/     # ページ固有コンポーネント
│   │   │   ├── hooks/         # カスタムフック
│   │   │   ├── types/        # 型定義
│   │   │   ├── utils/        # ユーティリティ
│   │   │   └── page.tsx      # ページコンポーネント
│   │   └── feature-b/  # 機能B
│   │       ├── __tests__/
│   │       ├── components/
│   │       ├── hooks/
│   │       ├── types/
│   │       ├── utils/
│   │       └── page.tsx
│   ├── (protected)/    # 保護されたルート
│   │   ├── components/ # グループ共通のコンポーネント
│   │   ├── hooks/     # グループ共通のフック
│   │   ├── types/     # グループ共通の型定義
│   │   ├── utils/     # グループ共通のユーティリティ
│   │   ├── layout.tsx # グループレイアウト
│   │   ├── feature-c/ # 機能C
│   │   │   ├── components/
│   │   │   ├── hooks/
│   │   │   ├── types/
│   │   │   ├── utils/
│   │   │   └── page.tsx
│   │   └── feature-d/ # 機能D
│   │       ├── components/
│   │       ├── hooks/
│   │       ├── types/
│   │       ├── utils/
│   │       └── page.tsx
│   ├── layout.tsx      # ルートレイアウト
│   └── page.tsx        # ルートページ
├── components/         # 共有コンポーネント
│   ├── features/       # 機能別コンポーネント
│   ├── layout/        # レイアウトコンポーネント
│   └── ui/            # 基本UIコンポーネント
├── env/               # 環境変数定義
└── lib/              # 共有ロジック
    ├── types/        # グローバル型定義
    └── utils/        # 共有ユーティリティ
```

#### 基本方針

1. コロケーションパターンを採用
   - 各機能（ページ）ごとに関連するファイルをグループ化
   - テスト、コンポーネント、フック、型定義を同じディレクトリに配置
2. ルートグループ化
   - `(public)`, `(protected)`などの括弧付きディレクトリで関連するルートをグループ化
3. 共通コンポーネントは src/components ディレクトリに配置
   - ui: 基底コンポーネント
   - features: 機能コンポーネント
   - layout: レイアウトコンポーネント

#### 状態管理設計

- Zustandを使用し、コンポーネントはストアを介してデータにアクセス
  - 1ストア・マルチスライスパターンで管理
  - スライスごとの状態管理を行い、再利用性を高める
- フック関数はカスタムフックとして実装

#### アーキテクチャドキュメント

architecture.mdは以下の構成で作成：

1. システム概要

   - アーキテクチャの概要
   - 主要なコンポーネント
   - データフロー

2. 技術スタックの詳細

   - 各技術の役割
   - バージョン情報
   - 依存関係

3. コンポーネント設計

   - コンポーネント階層
   - 責務の分離
   - 状態管理戦略

4. セキュリティ考慮事項

   - 認証/認可
   - データ保護
   - エラーハンドリング

5. パフォーマンス最適化

   - レンダリング最適化
   - データ取得戦略
   - キャッシング方針

6. スケーラビリティ

   - 将来の拡張性
   - コードの再利用性
   - メンテナンス性

7. テスト戦略
   - テストの種類
   - テストカバレッジ
   - テスト環境

### API設計規約

1. RESTful API設計原則

   - リソース指向
   - 適切なHTTPメソッド
   - ステートレス

2. エンドポイント設計

   - 一貫した命名規則
   - バージョニング戦略
   - エラーハンドリング

3. レスポンス形式

   - 統一されたJSON構造
   - エラーレスポンス形式
   - ステータスコード

4. セキュリティ
   - 認証方式
   - 認可制御
   - レート制限