yodogawa 1.0.0

package/.windsurf/workflows/a-008-DefineRepositoryStructure.md

@@ -0,0 +1,118 @@
+---
+description: 技術スタックに基づいてプロジェクトのディレクトリ構造、アーキテクチャパターン、命名規則を定義するワークフロー
+---
+
+# DefineRepositoryStructure (a-008)
+
+## 目的
+
+- 決定された技術スタックに基づいて、最適なリポジトリ構造を定義する。
+- アーキテクチャパターン（レイヤード、機能ベース、クリーンアーキテクチャなど）を選定する。
+- ディレクトリの責務、命名規則、依存関係ルールを明確化する。
+
+## 前提
+
+- `docs/project/design/01-tech-stack.md` が作成されていること（先に `DefineTechStack` (a-007) を実行）。
+- `docs/project/domain/01-domain-model.md` が作成されていること（推奨）。
+- `docs/project/design/` ディレクトリが存在すること。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+- `docs/project/design/01-tech-stack.md` を読み込み、技術スタックを確認する。
+  ```bash
+  ls -la docs/project/design/01-tech-stack.md 2>/dev/null || echo "ファイルが存在しません"
+  ```
+- 存在しない場合：ユーザーに通知し、`DefineTechStack` (a-007) を実行するよう促す。
+
+### 2. テンプレートの準備
+
+- テンプレートをコピーして作業用ファイルを作成する：
+  ```bash
+  cp ".windsurf/templates/project/04-design/02-repository-structure.md" "docs/project/design/02-repository-structure.md"
+  ```
+
+### 3. アーキテクチャパターンの提案
+
+- 技術スタックと要件に基づき、最適なアーキテクチャパターンを提案する。
+  - **レイヤードアーキテクチャ**: 一般的なバックエンド（NestJS, Django等）
+  - **機能ベース (Feature-based)**: フロントエンド、モジュラーモノリス
+  - **クリーンアーキテクチャ**: 複雑なドメインロジックを持つ場合
+  - **Atomic Design / FSD**: フロントエンド特化
+
+- ユーザーに提示：
+  - 「以下のアーキテクチャパターンを推奨します：[パターン名]」
+  - 「理由：[技術スタックとの適合性、保守性など]」
+
+### 4. ディレクトリ構造の詳細定義
+
+ユーザーからのフィードバックを受け、詳細を決定する。
+
+#### 4.1 ディレクトリ構成
+- ソースコードのルート（`src/` vs `app/`）
+- テストコードの配置（`tests/` vs コロケーション）
+- 機能モジュールの構成（`features/`, `components/`, `lib/` 等）
+
+#### 4.2 命名規則とルール
+- ファイル名（PascalCase, camelCase, kebab-case）
+- 依存関係ルール（上位層から下位層への依存のみ許可など）
+- コロケーション戦略（関連ファイルをまとめるか分離するか）
+
+### 5. ドキュメント作成
+
+- `docs/project/design/02-repository-structure.md` に決定事項を記入する。
+- **必須項目**:
+  - ディレクトリツリー図（`tree`形式）
+  - 各ディレクトリの役割説明
+  - 採用したアーキテクチャパターンと理由
+  - 命名規則と依存ルール
+
+### 6. 完了条件と構造の確認
+
+- 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
+
+  1. **構造確認**:
+     ```bash
+     # ディレクトリ構造図の確認
+     grep "project-root/" docs/project/design/02-repository-structure.md && echo "OK" || echo "MISSING: Directory tree"
+     # アーキテクチャパターンセクションの確認
+     grep "## アーキテクチャパターン" docs/project/design/02-repository-structure.md && echo "OK" || echo "MISSING: Architecture section"
+     # 命名規則セクションの確認
+     grep "## 命名規則" docs/project/design/02-repository-structure.md && echo "OK" || echo "MISSING: Naming convention section"
+     ```
+
+  2. **チェックリスト**:
+     - [ ] `docs/project/design/02-repository-structure.md` が作成されている
+     - [ ] ディレクトリツリーが技術スタックと整合している
+     - [ ] 各ディレクトリの責務が定義されている
+
+### 7. Git への追加（オプション）
+
+- ユーザーに確認：「作成したリポジトリ構造ドキュメントを Git に追加しますか？」
+- 「はい」の場合、以下を実行：
+  ```bash
+  git add docs/project/design/02-repository-structure.md
+  git status
+  ```
+- 推奨コミットメッセージ：
+  ```
+  docs: リポジトリ構造とアーキテクチャ定義の作成
+
+  - ディレクトリ構成、命名規則、依存関係ルールを定義
+  - 採用アーキテクチャパターン: [パターン名]
+  ```
+
+## 完了条件
+
+- `docs/project/design/02-repository-structure.md` が作成されている。
+- プロジェクトのディレクトリ構造が明確に定義されている。
+- チーム開発に必要なルール（命名、配置、依存）が文書化されている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- 技術スタックと構造の不一致がある場合：
+  - 「選択されたフレームワーク（[名前]）の標準構成と異なります。標準に従うか、独自の構造を採用するか確認しましょう。」と提案する。
+- 構造が過度に複雑な場合：
+  - 「初期段階では複雑すぎる可能性があります。まずはフラットな構成から始め、必要に応じて分割することを推奨します。」と提案する。

package/.windsurf/workflows/a-009-DefineScreenDesign.md

@@ -0,0 +1,121 @@
+---
+description: ユーザーストーリーとシナリオから画面一覧を抽出し、画面遷移フローとレスポンシブデザインポリシーを定義するワークフロー
+---
+
+# DefineScreenDesign (a-009)
+
+## 目的
+
+- ユーザーストーリーとシナリオを基に、必要な画面を網羅的に抽出する。
+- 各画面の役割、アクセス権限、考慮すべき状態（Empty State含む）を明確化する。
+- 画面遷移フローをMermaid図で可視化し、ユーザーの導線を明確にする。
+- レスポンシブデザインポリシー（ブレークポイント、デバイス対応方針）を定義する。
+
+## 前提
+
+- `docs/project/requirements/05-user-stories.md` が作成されていること。
+- `docs/project/behavior/01-scenarios.md` が作成されていること。
+- `docs/project/design/` ディレクトリが存在すること。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+- 必要なドキュメントを読み込む：
+  - `docs/project/requirements/05-user-stories.md`
+  - `docs/project/behavior/01-scenarios.md`
+  - `docs/project/design/01-tech-stack.md` (存在する場合)
+
+- ドキュメントが不足している場合、対応するワークフローの実行を促す。
+
+### 2. テンプレートの準備
+
+- テンプレートをコピーして作業用ファイルを作成する：
+  ```bash
+  cp ".windsurf/templates/project/04-design/03-screen-design.md" "docs/project/design/03-screen-design.md"
+  ```
+
+### 3. 画面の抽出と提案
+
+- シナリオのGiven/When/Thenステップから、必要な画面を抽出する。
+- 標準的な画面（ログイン、404エラー、設定など）を追加提案する。
+- **画面リスト案を提示**:
+  - 「以下の画面が必要と考えられます：」
+  - 「[画面名] (役割: [説明])」
+
+### 4. 詳細定義と遷移フロー
+
+ユーザーからのフィードバックを受け、以下を定義する。
+
+#### 4.1 各画面の詳細
+- 画面ID、名称、URLパス
+- アクセス権限（誰が見れるか）
+- **重要な状態**: 初回訪問(Empty State)、ロード中、エラー時など
+
+#### 4.2 画面遷移フロー
+- 主要なユーザーフロー（認証、メイン機能、エラー）をMermaid図で表現する。
+- デッドエンド（戻れない画面）がないか確認する。
+
+### 5. レスポンシブデザインポリシー
+
+- 技術スタック（Tailwind等）に合わせたブレークポイントを定義する。
+- モバイルファーストかデスクトップファーストか、方針を決定する。
+- デバイスごとのレイアウトパターン（ハンバーガーメニュー、ドロワー等）を定義する。
+
+### 6. ドキュメント作成
+
+- `docs/project/design/03-screen-design.md` に決定事項を記入する。
+- **必須項目**:
+  - 画面一覧テーブル
+  - 画面遷移図 (Mermaid)
+  - レスポンシブデザインポリシー
+
+### 7. 完了条件と構造の確認
+
+- 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
+
+  1. **構造確認**:
+     ```bash
+     # 画面一覧セクションの確認
+     grep "## 画面一覧" docs/project/design/03-screen-design.md && echo "OK" || echo "MISSING: Screen list"
+     # 画面遷移図の確認
+     grep "\`\`\`mermaid" docs/project/design/03-screen-design.md && echo "OK" || echo "MISSING: Flowchart"
+     # レスポンシブポリシーの確認
+     grep "## レスポンシブデザインポリシー" docs/project/design/03-screen-design.md && echo "OK" || echo "MISSING: Responsive policy"
+     ```
+
+  2. **チェックリスト**:
+     - [ ] `docs/project/design/03-screen-design.md` が作成されている
+     - [ ] 主要な画面がすべて網羅されている
+     - [ ] Empty Stateについて考慮されている
+
+### 8. Git への追加（オプション）
+
+- ユーザーに確認：「作成した画面設計ドキュメントを Git に追加しますか？」
+- 「はい」の場合、以下を実行：
+  ```bash
+  git add docs/project/design/03-screen-design.md
+  git status
+  ```
+- 推奨コミットメッセージ：
+  ```
+  docs: 画面設計ドキュメントの作成
+
+  - 画面一覧と遷移フロー(Mermaid)を追加
+  - レスポンシブデザインポリシーを定義
+  ```
+
+## 完了条件
+
+- `docs/project/design/03-screen-design.md` が作成されている。
+- 全画面のリストと役割が定義されている。
+- 画面遷移が可視化されている。
+- レスポンシブ対応方針が明確になっている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- シナリオ不足で画面が特定できない場合：
+  - 「シナリオが不足しています。`CreateScenarios` (a-003) に戻ってユーザーフローを明確にしましょう。」と提案する。
+- 画面数が多すぎる場合：
+  - 「初期リリースには多すぎる可能性があります。MVPに必要な画面に絞り込みませんか？」と提案する。

package/.windsurf/workflows/a-010-DefineDataModel.md

@@ -0,0 +1,125 @@
+---
+description: ドメインモデルと画面設計からデータベース構造（ERD）を定義し、エンティティ、属性、リレーションシップ、制約を明確化するワークフロー
+---
+
+# DefineDataModel (a-010)
+
+## 目的
+
+- ドメインモデル（Aggregates）と画面設計を基に、データベース構造を定義する。
+- エンティティ（テーブル）、属性（カラム）、リレーションシップを明確化する。
+- データ型、制約（NOT NULL、UNIQUE、CHECK）、インデックス戦略を決定する。
+- Mermaid ERD（Entity Relationship Diagram）で視覚化し、開発者間の認識を統一する。
+
+## 前提
+
+- `docs/project/domain/01-domain-model.md` が作成されていること。
+- `docs/project/design/01-tech-stack.md` が作成されていること（DB選定済み）。
+- `docs/project/design/03-screen-design.md` が作成されていること。
+- `docs/project/design/` ディレクトリが存在すること。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+- 必要なドキュメントを読み込む：
+  - `docs/project/domain/01-domain-model.md`
+  - `docs/project/design/01-tech-stack.md`
+  - `docs/project/design/03-screen-design.md`
+
+- ドキュメントが不足している場合、対応するワークフローの実行を促す。
+
+### 2. テンプレートの準備
+
+- テンプレートをコピーして作業用ファイルを作成する：
+  ```bash
+  cp ".windsurf/templates/project/04-design/04-data-model.md" "docs/project/design/04-data-model.md"
+  ```
+
+### 3. エンティティの抽出と提案
+
+- **ドメインモデルから**: Aggregate Rootおよび内部エンティティを抽出。
+- **画面設計から**: 表示・入力項目から必要なデータ構造（履歴、設定、ログ等）を抽出。
+- **エンティティ一覧案を提示**:
+  - 「以下のエンティティを定義します：」
+  - 「[エンティティ名] (対応するAggregate: [名前])」
+
+### 4. 詳細定義（インタビュー）
+
+ユーザーからのフィードバックを受け、各エンティティの詳細を定義する。
+
+#### 4.1 基本定義
+- テーブル名（物理名）、論理名、説明
+- 主キー（ID）の戦略（Auto Increment / UUID / CUID）
+
+#### 4.2 属性（カラム）
+- カラム名、データ型（DB製品に合わせて具体的に）
+- 制約（NOT NULL, UNIQUE, DEFAULT）
+- 監査カラム（created_at, updated_at）の有無
+
+#### 4.3 リレーションシップ
+- 関連するエンティティ（1:1, 1:N, N:M）
+- 外部キー制約（ON DELETE CASCADE / SET NULL / RESTRICT）
+
+### 5. ERDの作成と正規化
+
+- 抽出したエンティティとリレーションシップを Mermaid ERD 形式で記述する。
+- 正規化（1NF-3NF）を確認し、意図的な非正規化があれば理由を記録する。
+- インデックス戦略（検索頻度の高いカラム、ユニーク制約）を定義する。
+
+### 6. ドキュメント作成
+
+- `docs/project/design/04-data-model.md` に決定事項を記入する。
+- **必須項目**:
+  - エンティティ一覧
+  - リレーションシップ定義
+  - ERD (Mermaid)
+
+### 7. 完了条件と構造の確認
+
+- 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
+
+  1. **構造確認**:
+     ```bash
+     # エンティティ一覧の確認
+     grep "## エンティティ一覧" docs/project/design/04-data-model.md && echo "OK" || echo "MISSING: Entities"
+     # ERDの確認
+     grep "\`\`\`mermaid" docs/project/design/04-data-model.md && echo "OK" || echo "MISSING: ERD"
+     # リレーションシップ定義の確認
+     grep "## リレーションシップ" docs/project/design/04-data-model.md && echo "OK" || echo "MISSING: Relationships"
+     ```
+
+  2. **チェックリスト**:
+     - [ ] `docs/project/design/04-data-model.md` が作成されている
+     - [ ] 全エンティティの物理名・論理名が定義されている
+     - [ ] ERDが正しくレンダリングされる
+
+### 8. Git への追加（オプション）
+
+- ユーザーに確認：「作成したデータモデルドキュメントを Git に追加しますか？」
+- 「はい」の場合、以下を実行：
+  ```bash
+  git add docs/project/design/04-data-model.md
+  git status
+  ```
+- 推奨コミットメッセージ：
+  ```
+  docs: データモデル（ERD）の定義
+
+  - エンティティ、属性、リレーションシップを定義
+  - MermaidによるER図を追加
+  ```
+
+## 完了条件
+
+- `docs/project/design/04-data-model.md` が作成されている。
+- データベーススキーマ（テーブル、カラム、型、制約）が定義されている。
+- エンティティ間の関係性が可視化（ERD）されている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- ドメインモデルとの不整合がある場合：
+  - 「ドメインモデルのAggregate構造とデータモデルが乖離しています。ORMのマッピング戦略を確認するか、ドメインモデルを見直してください。」
+- パフォーマンス懸念がある場合：
+  - 「正規化によりJOINが多発する可能性があります。Read Model（参照用テーブル）の導入や、意図的な非正規化を検討しませんか？」

package/.windsurf/workflows/a-011-DefineAPISpec.md

@@ -0,0 +1,123 @@
+---
+description: データモデルと画面設計からAPI仕様を定義し、認証方式、エンドポイント一覧、共通レスポンス形式を明確化するワークフロー
+---
+
+# DefineAPISpec (a-011)
+
+## 目的
+
+- データモデルと画面設計を基に、API仕様の基本設計を定義する。
+- API設計スタイル（REST、GraphQL、gRPC、tRPC）を決定する。
+- 認証・認可方式を明確化する。
+- エンドポイント一覧（メソッド、パス、説明、認証要否）を定義する。
+- 共通レスポンス形式（成功/エラー）を定義する。
+
+## 前提
+
+- `docs/project/design/01-tech-stack.md` が作成されていること（APIスタイル選定済み）。
+- `docs/project/design/04-data-model.md` が作成されていること。
+- `docs/project/design/03-screen-design.md` が作成されていること。
+- `docs/project/design/` ディレクトリが存在すること。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+- 必要なドキュメントを読み込む：
+  - `docs/project/design/01-tech-stack.md`
+  - `docs/project/design/04-data-model.md`
+  - `docs/project/design/03-screen-design.md`
+
+- ドキュメントが不足している場合、対応するワークフローの実行を促す。
+
+### 2. テンプレートの準備
+
+- テンプレートをコピーして作業用ファイルを作成する：
+  ```bash
+  cp ".windsurf/templates/project/04-design/05-api-spec.md" "docs/project/design/05-api-spec.md"
+  ```
+
+### 3. APIスタイルの確認と提案
+
+- 技術スタック（01-tech-stack.md）で選定されたAPIスタイル（REST, GraphQL等）を確認する。
+- データモデル（04-data-model.md）と画面設計（03-screen-design.md）から、必要なリソースと操作を抽出する。
+- **エンドポイント案の提示**:
+  - 「以下のリソースに対するエンドポイントを定義します：」
+  - 「Users: 一覧, 詳細, 作成, 更新, 削除」
+  - 「Auth: ログイン, 登録, リフレッシュ」
+
+### 4. 詳細定義（インタビュー）
+
+ユーザーからのフィードバックを受け、詳細を定義する。
+
+#### 4.1 認証・認可
+- 認証方式（JWT, OAuth等）、トークンの扱い（Cookie vs Header）
+- 認可スコープやロールの定義
+
+#### 4.2 エンドポイント詳細
+- 各リソースのパス設計（RESTful原則の適用）
+- 認証の要否（Public vs Private）
+- CRUD以外の特殊なアクション（`/cancel`, `/publish` 等）
+
+#### 4.3 共通レスポンス形式
+- 成功時のレスポンス構造（`{ data: ... }` ラップの有無）
+- エラー時のレスポンス構造（`{ error: { code, message } }` 等）
+- ページネーションの仕様
+
+### 5. ドキュメント作成
+
+- `docs/project/design/05-api-spec.md` に決定事項を記入する。
+- **必須項目**:
+  - 認証・認可仕様
+  - エンドポイント一覧（リソース別）
+  - 共通レスポンス形式
+
+### 6. 完了条件と構造の確認
+
+- 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
+
+  1. **構造確認**:
+     ```bash
+     # 認証セクションの確認
+     grep "## 認証・認可" docs/project/design/05-api-spec.md && echo "OK" || echo "MISSING: Auth section"
+     # エンドポイント一覧の確認
+     grep "## エンドポイント一覧" docs/project/design/05-api-spec.md && echo "OK" || echo "MISSING: Endpoints"
+     # レスポンス形式の確認
+     grep "## 共通レスポンス形式" docs/project/design/05-api-spec.md && echo "OK" || echo "MISSING: Response format"
+     ```
+
+  2. **チェックリスト**:
+     - [ ] `docs/project/design/05-api-spec.md` が作成されている
+     - [ ] 認証方式が明確に定義されている
+     - [ ] 主要なリソースのCRUDエンドポイントが網羅されている
+
+### 7. Git への追加（オプション）
+
+- ユーザーに確認：「作成したAPI仕様ドキュメントを Git に追加しますか？」
+- 「はい」の場合、以下を実行：
+  ```bash
+  git add docs/project/design/05-api-spec.md
+  git status
+  ```
+- 推奨コミットメッセージ：
+  ```
+  docs: API仕様（基本設計）の作成
+
+  - 認証・認可方式の定義
+  - エンドポイント一覧と共通レスポンス形式を定義
+  ```
+
+## 完了条件
+
+- `docs/project/design/05-api-spec.md` が作成されている。
+- 認証・認可の仕組みが定義されている。
+- エンドポイント一覧（メソッド、パス、認証要否）が定義されている。
+- 共通レスポンス形式（成功/エラー）が定義されている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- APIスタイル（REST/GraphQL）が未定の場合：
+  - 「APIスタイルが未定です。`DefineTechStack` (a-007) に戻って選定してください。」
+- データモデルとの不整合がある場合：
+  - 「データモデルに存在しないリソースのエンドポイントが要求されています。データモデルを見直すか、APIだけの概念として定義するか確認してください。」

package/.windsurf/workflows/a-012-DefineArchitecture.md

@@ -0,0 +1,119 @@
+---
+description: 技術スタック、リポジトリ構造、データモデル、API仕様を統合し、システム全体のアーキテクチャ設計とADRを定義するワークフロー
+---
+
+# DefineArchitecture (a-012)
+
+## 目的
+
+- これまでに定義された設計（技術スタック、リポジトリ構造、データモデル、API仕様）を統合する。
+- システム全体の構造をMermaid図で視覚化する。
+- 採用したアーキテクチャパターン（レイヤード、クリーンアーキテクチャなど）を明確化する。
+- 重要なアーキテクチャ決定（ADR: Architecture Decision Record）を記録する。
+
+## 前提
+
+- `docs/project/design/01-tech-stack.md` が作成されていること。
+- `docs/project/design/02-repository-structure.md` が作成されていること。
+- `docs/project/design/04-data-model.md` が作成されていること。
+- `docs/project/design/05-api-spec.md` が作成されていること。
+- `docs/project/design/` ディレクトリが存在すること。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+- 必要なドキュメントを読み込む：
+  - `docs/project/design/01-tech-stack.md`
+  - `docs/project/design/02-repository-structure.md`
+  - `docs/project/design/04-data-model.md`
+  - `docs/project/design/05-api-spec.md`
+
+- ドキュメントが不足している場合、対応するワークフローの実行を促す。
+
+### 2. テンプレートの準備
+
+- テンプレートをコピーして作業用ファイルを作成する：
+  ```bash
+  cp ".windsurf/templates/project/04-design/06-architecture.md" "docs/project/design/06-architecture.md"
+  ```
+
+### 3. アーキテクチャの提案
+
+- 技術スタックとリポジトリ構造から、システムの主要コンポーネント（クライアント、API、DB、外部サービス）を抽出する。
+- **システム全体図の構成案を提示**:
+  - 「以下のコンポーネントとデータフローを図示します：」
+  - 「[Web] -> [API Server] -> [DB]」
+  - 「[API Server] -> [External Service]」
+
+### 4. 詳細定義（インタビュー）
+
+ユーザーからのフィードバックを受け、詳細を定義する。
+
+#### 4.1 システムアーキテクチャ図
+- コンポーネント間の接続、プロトコル（HTTP/gRPC）、データフローをMermaid図で表現する。
+- スケーラビリティや冗長化構成（ロードバランサー、レプリカDB）を反映する。
+
+#### 4.2 アーキテクチャパターン
+- 採用したパターン（レイヤード、クリーン、マイクロサービス等）とその選定理由を明確にする。
+
+#### 4.3 ADR (Architecture Decision Records)
+- 重要な技術的決定（DB選定、認証方式、フレームワーク選定など）を抽出する。
+- 各決定について、背景・代替案・決定理由・影響を記録する。
+
+### 5. ドキュメント作成
+
+- `docs/project/design/06-architecture.md` に決定事項を記入する。
+- **必須項目**:
+  - システムアーキテクチャ図 (Mermaid)
+  - 採用アーキテクチャパターンの説明
+  - ADR一覧
+
+### 6. 完了条件と構造の確認
+
+- 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
+
+  1. **構造確認**:
+     ```bash
+     # アーキテクチャ図の確認
+     grep "\`\`\`mermaid" docs/project/design/06-architecture.md && echo "OK" || echo "MISSING: Architecture Diagram"
+     # パターン定義の確認
+     grep "## 採用アーキテクチャパターン" docs/project/design/06-architecture.md && echo "OK" || echo "MISSING: Pattern definition"
+     # ADRセクションの確認
+     grep "## ADR" docs/project/design/06-architecture.md && echo "OK" || echo "MISSING: ADR section"
+     ```
+
+  2. **チェックリスト**:
+     - [ ] `docs/project/design/06-architecture.md` が作成されている
+     - [ ] システム全体像が視覚化されている
+     - [ ] 重要な技術選定の理由（ADR）が記録されている
+
+### 7. Git への追加（オプション）
+
+- ユーザーに確認：「作成したアーキテクチャ設計ドキュメントを Git に追加しますか？」
+- 「はい」の場合、以下を実行：
+  ```bash
+  git add docs/project/design/06-architecture.md
+  git status
+  ```
+- 推奨コミットメッセージ：
+  ```
+  docs: アーキテクチャ設計の定義
+
+  - システム全体図（Mermaid）の作成
+  - アーキテクチャパターンとADRの記録
+  ```
+
+## 完了条件
+
+- `docs/project/design/06-architecture.md` が作成されている。
+- システム全体の構成要素と関係性が可視化されている。
+- 技術選定の背景（ADR）が文書化され、将来の参照用に残されている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- アーキテクチャが複雑すぎる場合：
+  - 「コンポーネント数が多すぎます。概要図と詳細図に分割するか、主要なフローに絞って図示することを検討しましょう。」と提案する。
+- 決定理由が不明確な場合：
+  - 「[技術名]の選定理由が曖昧です。後で振り返れるよう、比較検討した代替案も含めてADRに記録しましょう。」と促す。