yodogawa 1.0.0

package/.windsurf/workflows/a-013-DefineInfrastructure.md

@@ -0,0 +1,120 @@
+---
+description: 技術スタックとアーキテクチャ設計を基に、インフラ構成図、環境構成、運用方針を定義するワークフロー
+---
+
+# DefineInfrastructure (a-013)
+
+## 目的
+
+- 技術スタックとアーキテクチャ設計を基に、インフラ構成を定義する。
+- クラウドリソース、ネットワーク、セキュリティ、監視を含む全体構成を可視化する。
+- 環境ごとの構成（開発、ステージング、本番）を明確化する。
+- 高可用性、冗長化、スケーラビリティ、セキュリティの方針を定義する。
+
+## 前提
+
+- `docs/project/design/01-tech-stack.md` が作成されていること（デプロイ環境、インフラ技術選定済み）。
+- `docs/project/design/06-architecture.md` が作成されていること（推奨）。
+- `docs/project/design/` ディレクトリが存在すること。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+- 必要なドキュメントを読み込む：
+  - `docs/project/design/01-tech-stack.md`
+  - `docs/project/design/06-architecture.md`
+
+- ドキュメントが不足している場合、対応するワークフローの実行を促す。
+
+### 2. テンプレートの準備
+
+- テンプレートをコピーして作業用ファイルを作成する：
+  ```bash
+  cp ".windsurf/templates/project/04-design/07-infrastructure.md" "docs/project/design/07-infrastructure.md"
+  ```
+
+### 3. インフラ構成の提案
+
+- 技術スタックとアーキテクチャ図から、必要なインフラリソース（VPC, ALB, EC2/ECS, RDS等）を抽出する。
+- **インフラ構成案の提示**:
+  - 「以下の構成を提案します：」
+  - 「[Cloud Provider] 上に [Pattern] (例: VPC + Public/Private Subnet) を構築」
+  - 「DBは [Managed Service] (例: RDS) を使用」
+
+### 4. 詳細定義（インタビュー）
+
+ユーザーからのフィードバックを受け、詳細を定義する。
+
+#### 4.1 ネットワークとセキュリティ
+- VPC構成、サブネット分割（Public/Private/Data）
+- セキュリティグループ方針、WAF、HTTPS化
+
+#### 4.2 コンピューティングとスケーリング
+- インスタンスタイプ/サイズ
+- Auto Scalingポリシー（CPU負荷等）
+
+#### 4.3 データベースとストレージ
+- Multi-AZ構成、リードレプリカの有無
+- バックアップ方針（頻度、保持期間）
+
+#### 4.4 環境構成
+- 開発/ステージング/本番環境の差異（リソースサイズ、冗長化）
+
+### 5. ドキュメント作成
+
+- `docs/project/design/07-infrastructure.md` に決定事項を記入する。
+- **必須項目**:
+  - インフラ構成図 (Mermaid)
+  - 環境構成表
+  - 運用方針（バックアップ、監視、セキュリティ）
+
+### 6. 完了条件と構造の確認
+
+- 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
+
+  1. **構造確認**:
+     ```bash
+     # インフラ構成図の確認
+     grep "\`\`\`mermaid" docs/project/design/07-infrastructure.md && echo "OK" || echo "MISSING: Infra Diagram"
+     # 環境構成の確認
+     grep "## 環境構成" docs/project/design/07-infrastructure.md && echo "OK" || echo "MISSING: Environments"
+     # 運用方針の確認
+     grep "## 主要な運用方針" docs/project/design/07-infrastructure.md && echo "OK" || echo "MISSING: Operations"
+     ```
+
+  2. **チェックリスト**:
+     - [ ] `docs/project/design/07-infrastructure.md` が作成されている
+     - [ ] 本番環境の構成（冗長化など）が明確になっている
+     - [ ] バックアップや監視の方針が記録されている
+
+### 7. Git への追加（オプション）
+
+- ユーザーに確認：「作成したインフラ設計ドキュメントを Git に追加しますか？」
+- 「はい」の場合、以下を実行：
+  ```bash
+  git add docs/project/design/07-infrastructure.md
+  git status
+  ```
+- 推奨コミットメッセージ：
+  ```
+  docs: インフラ設計の定義
+
+  - インフラ構成図（Mermaid）の作成
+  - 環境構成と運用方針の記録
+  ```
+
+## 完了条件
+
+- `docs/project/design/07-infrastructure.md` が作成されている。
+- インフラの物理構成とネットワーク構成が可視化されている。
+- 環境ごとの差異が明確になっている。
+- 運用上の重要事項（バックアップ、セキュリティ）が定義されている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- コストが高すぎる場合：
+  - 「冗長化構成によりコストが増加します。ステージング環境はSingle-AZにするなど、コスト最適化を検討しましょう。」と提案する。
+- セキュリティリスクがある場合：
+  - 「DBがパブリックサブネットに配置されています。プライベートサブネットへの移動を強く推奨します。」と警告する。

package/.windsurf/workflows/a-014-ReviewDesign.md

@@ -0,0 +1,122 @@
+---
+description: 設計ドキュメント間の一貫性をチェックし、要件・ドメインモデルとの整合性を検証するレビューワークフロー
+auto_execution_mode: 1
+---
+
+# ReviewDesign (a-014)
+
+## 目的
+
+- 設計フェーズで作成されたすべてのドキュメント間の一貫性を体系的にチェックする。
+- 設計ドキュメント間の不整合、漏れ、矛盾を検出し、修正提案を提供する。
+- 技術選定、アーキテクチャ、データモデル、API仕様の整合性を確認する。
+- レビュー結果レポートを作成し、修正すべき項目を優先度付きでリストアップする。
+
+## 前提
+
+- 要件・ドメインレビューが完了していること（`ReviewRequirementsDomain` (a-006) 実施済み）。
+- 以下の設計ドキュメントが作成されていること：
+  - `docs/project/design/01-tech-stack.md`
+  - `docs/project/design/02-repository-structure.md`
+  - `docs/project/design/03-screen-design.md`
+  - `docs/project/design/04-data-model.md`
+  - `docs/project/design/05-api-spec.md`
+  - `docs/project/design/06-architecture.md`
+  - `docs/project/design/07-infrastructure.md`
+
+## 手順
+
+### 1. ドキュメント存在確認
+
+- 必要なすべての設計ドキュメントが存在するか確認する：
+  ```bash
+  ls -l docs/project/design/*.md
+  ```
+- 不足しているドキュメントがある場合、対応するワークフローの実行を促す。
+
+### 2. 一貫性チェックの実行
+
+以下の項目について、自動検索（grep等）と手動確認を組み合わせて検証する。
+
+#### 2.1 テックスタック ↔ アーキテクチャ
+- **整合性**: 選定された技術（01-tech-stack.md）がアーキテクチャ図（06-architecture.md）のコンポーネントと一致しているか。
+- **ADR**: 重要な技術選定理由がADRとして記録されているか。
+
+#### 2.2 データモデル ↔ ドメインモデル
+- **カバレッジ**: ドメインモデルのAggregate（01-domain-model.md）がデータモデル（04-data-model.md）のエンティティとして定義されているか。
+- **用語統一**: テーブル名やカラム名がユビキタス言語と一致しているか。
+
+#### 2.3 API仕様 ↔ データモデル
+- **リソース**: APIリソース（05-api-spec.md）がデータモデルのエンティティに基づいているか。
+- **フィールド**: APIのレスポンスフィールドがデータモデルに存在するか。
+
+#### 2.4 画面設計 ↔ API仕様
+- **カバレッジ**: 画面（03-screen-design.md）で必要なデータ取得・操作がAPIエンドポイントとして定義されているか。
+- **状態**: エラー状態やロード状態に対応するレスポンス仕様があるか。
+
+#### 2.5 インフラ ↔ アーキテクチャ
+- **構成**: インフラ構成（07-infrastructure.md）がアーキテクチャ図のコンポーネントを網羅しているか。
+- **非機能要件**: 可用性やセキュリティ要件がインフラ設計に反映されているか。
+
+### 3. レビュー結果レポートの作成
+
+- 検出された問題（Error/Warning）をまとめ、`docs/project/DESIGN-REVIEW-REPORT.md` を作成する。
+
+**レポートフォーマット例**:
+```markdown
+# 設計ドキュメント一貫性レビュー結果
+**実施日**: YYYY-MM-DD
+
+## サマリー
+- ✅ OK: X項目
+- ⚠️ Warning: X項目
+- ❌ Error: X項目
+
+## 詳細
+
+### 1. テックスタック ↔ アーキテクチャ
+- ✅ OK: 選定技術はアーキテクチャパターンに適合しています。
+
+### 2. データモデル ↔ ドメインモデル
+- ❌ **Error**: Aggregate「Order」に対応するテーブル定義が見つかりません。
+
+### 3. API仕様 ↔ データモデル
+- ⚠️ **Warning**: APIレスポンスのフィールド `user_rank` がデータモデルにありません。
+
+### 4. 画面設計 ↔ API仕様
+- ❌ **Error**: 「注文履歴画面」に必要な `GET /api/orders/history` が定義されていません。
+
+### 5. インフラ ↔ アーキテクチャ
+- ✅ OK: 冗長化構成はアーキテクチャの可用性要件を満たしています。
+
+## 推奨アクション
+1. `DefineDataModel` (a-010) で `orders` テーブルを定義する。
+2. `DefineAPISpec` (a-011) で `GET /api/orders/history` を追加する。
+```
+
+### 4. 結果の報告と修正提案
+
+- ユーザーにレポートの内容を要約して伝える。
+- 重大なエラー（❌）がある場合は、優先的に修正することを提案する。
+- 「修正作業を開始しますか？それともレポートをGitに保存して終了しますか？」
+
+### 5. Git への追加（オプション）
+
+- ユーザーが希望する場合、レポートをコミットする。
+  ```bash
+  git add docs/project/DESIGN-REVIEW-REPORT.md
+  git commit -m "docs: 設計整合性レビューレポートの作成"
+  ```
+
+## 完了条件
+
+- `docs/project/DESIGN-REVIEW-REPORT-YYYYMMDDHHMMSS.md` が作成されている。
+- 全設計ドキュメント間の整合性がチェックされ、結果（OK/Warning/Error）が記録されている。
+- 具体的な修正アクションが提案されている。
+
+## エスカレーション
+
+- 致命的な不整合がある場合：
+  - 「データモデルとAPI仕様の間に大きな乖離があります。実装手戻りを防ぐため、設計の見直しを強く推奨します。」
+- ドメインモデルとの乖離がある場合：
+  - 「設計がドメインモデルの意図を反映していません。ビジネスロジックの破綻につながる恐れがあります。」

package/.windsurf/workflows/b-001-CreateTaskDirectory.md

@@ -0,0 +1,71 @@
+---
+description: 新規タスク用のディレクトリを作成し、タスクIDを採番するワークフロー
+auto_execution_mode: 1
+---
+
+# CreateTaskDirectory (b-001)
+
+## 目的
+
+- 新しいタスクのための専用ディレクトリを作成する。
+- タスクIDの採番ルール（`taskXXXXXX`）を統一し、管理しやすくする。
+- **注意**: このワークフローはディレクトリ作成のみを行います。タスク定義書などのドキュメント作成は後続のワークフロー（`b-001` 等）で実施します。
+
+## 前提
+
+- `docs/tasks/` ディレクトリが存在すること。
+
+## 手順
+
+### 1. 既存タスクの確認とID採番
+
+- 既存のタスクディレクトリを確認し、次のタスクIDを決定する。
+  ```bash
+  ls -d docs/tasks/task*
+  ```
+- **採番ルール**:
+  - 形式: `task{6桁連番}-{スラッグ}`
+  - 例: `task000001-email-auth`
+  - 既存がない場合は `task000001` から開始。
+  - 既存がある場合は最大番号 + 1。
+
+### 2. タスク名の決定
+
+- ユーザーにタスクのキーワード（スラッグ）を質問する。
+  - 「タスクの内容を3-5語の英数字とハイフンで表現してください（例: `user-profile-edit`）。」
+
+### 3. ディレクトリの作成
+
+- 決定したIDとスラッグを使用してディレクトリを作成する。
+  ```bash
+  mkdir -p docs/tasks/task{ID}-{SLUG}
+  ```
+  例:
+  ```bash
+  mkdir -p docs/tasks/task000001-email-auth
+  ```
+
+### 4. 作成確認
+
+- ディレクトリが正しく作成されたか確認する。
+  ```bash
+  ls -ld docs/tasks/task{ID}-{SLUG} && echo "OK" || echo "FAILED"
+  ```
+
+### 5. 次のステップの案内
+
+- ユーザーに次のアクションを提案する：
+  - 「ディレクトリ `docs/tasks/task{ID}-{SLUG}` を作成しました。」
+  - 「続いてタスク定義書を作成しますか？ (`CreateTaskDefinition` / b-001)」
+
+## 完了条件
+
+- `docs/tasks/task{ID}-{SLUG}/` ディレクトリが作成されている。
+- ユーザーにディレクトリパスが報告されている。
+
+## エスカレーション
+
+- `docs/tasks/` が見つからない場合:
+  - `mkdir -p docs/tasks` を実行するか、`SetupDocStructure` (a-001) の確認を促す。
+- 命名規則違反:
+  - タスク名にスペースや特殊文字が含まれる場合、修正を求める。

package/.windsurf/workflows/b-002-CreateTaskDefinition.md

@@ -0,0 +1,165 @@
+---
+description: ユーザーストーリーとインタビューからタスク定義ドキュメントを作成し、目的・変更内容・受け入れ基準を明確化するワークフロー
+---
+
+# CreateTaskDefinition (b-002)
+
+## 目的
+
+- 新しいタスクの背景・目的・スコープを明確化する。
+- ユーザーストーリーと変更内容を整理し、後続のリサーチ・実装計画に渡す。
+- 測定可能な受け入れ基準を定義し、完了条件を共有する。
+
+## 前提
+
+- `docs/tasks/task{ID}-{SLUG}/` が `CreateTaskDirectory (b-001)` で作成済みであること。
+- テンプレート: `.windsurf/templates/tasks/task-template/a-definition.md`
+- タスクの概要が関係者と共有済みであること。
+
+## 手順
+
+### 1. タスクディレクトリとテンプレートの確認
+
+1. タスク候補を一覧し、作業対象を特定する。
+   ```bash
+   ls -d docs/tasks/task*
+   ```
+2. テンプレートが未配置の場合はコピーする。
+   ```bash
+   cp ".windsurf/templates/tasks/task-template/a-definition.md" \
+      "docs/tasks/task{ID}-{SLUG}/a-definition.md"
+   ```
+
+### 2. 目的・背景のヒアリング
+
+- 以下をユーザーまたは依頼者に確認し、メモを取る。
+  - 「現状の課題・不具合は何か？」
+  - 「誰が困っているのか？（ユーザー/開発/運用など）」
+  - 「このタスクが完了すると、どのような価値・KPI 改善があるか？」
+- 数値・頻度・Before/After を含め、具体的に記載する。
+
+### 3. ユーザーストーリーの整理
+
+- ペルソナごとにストーリーを作成。
+  - 形式: 「[役割]として、[目的]がしたい。なぜなら[理由]だから」
+  - 参考質問: 「このタスクで誰が何を達成したいですか？」「その理由は？」
+- 優先度や関連するストーリーID（US-001 など）を付与すると後続管理が容易。
+
+### 4. 変更内容の洗い出し
+
+- タスク定義を実現するために必要な変更箇所をカテゴリ別に列挙。
+  - 画面/UI（例: 新規ページ、既存フォームの項目追加）
+  - API/サービス（例: 新規エンドポイント、仕様変更）
+  - データモデル/DB（例: テーブル追加、カラム変更、インデックス）
+  - その他（設定、翻訳、ドキュメント更新など）
+- 可能な限りファイル名・エンドポイント・テーブル名など具体名を記載。
+
+### 5. 受け入れ基準の策定
+
+- 「完了」を判定できる観点を整理。
+  - 正常系（期待する操作が成功する）
+  - 異常系・エラー表示（入力エラー、権限不足など）
+  - 性能・セキュリティ（応答時間、認可/認証、暗号化など）
+  - テスト要件（ユニット/統合/E2E、ログ出力、監視アラート）
+- 例: 「メール認証リンクは1回のみ有効」「API レスポンスは200ms以内」「CSRF トークン必須」
+
+### 6. ドキュメントへの反映
+
+1. `docs/tasks/task{ID}-{SLUG}/a-definition.md` を編集し、以下を順に埋める。
+   - 目的・背景
+   - ユーザーストーリー一覧
+   - 変更内容一覧
+   - 受け入れ基準
+   - メモ/補足情報（関連Issue・制約等）
+2. HTMLコメントは削除せず残す（テンプレートのガイドとして利用）。
+
+### 7. 構造チェック
+
+```bash
+# セクション存在確認
+grep "## 目的" docs/tasks/task{ID}-{SLUG}/a-definition.md \
+  && grep "## ユーザーストーリー" docs/tasks/task{ID}-{SLUG}/a-definition.md \
+  && grep "## 変更内容" docs/tasks/task{ID}-{SLUG}/a-definition.md \
+  && grep "## 受け入れ基準" docs/tasks/task{ID}-{SLUG}/a-definition.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
+
+チェックリスト:
+- [ ] 目的に数値/Before-Afterが含まれている
+- [ ] すべての重要なユーザーストーリーが列挙されている
+- [ ] 変更箇所がファイル名やエンドポイント単位で特定されている
+- [ ] 受け入れ基準がテスト可能な表現になっている
+
+### 8. Git への追加（任意）
+
+```bash
+git add docs/tasks/task{ID}-{SLUG}/a-definition.md
+git commit -m "docs(task): タスク定義書の作成 task{ID}"
+```
+- テンプレートに従い、以下を記載：
+  - **目的**（解決する問題、提供する価値）
+  - **ユーザーストーリー一覧**（ストーリーID、ストーリー）
+  - **変更内容一覧**（カテゴリ、変更内容）
+  - **受け入れ基準**（正常系、異常系、エッジケース、テスト、パフォーマンス、セキュリティ）
+  - **メモ**（補足情報）
+
+- **HTMLコメントは削除せず残す**
+
+### 8. レビューと確認
+
+- 作成したドキュメントをユーザーに提示：
+  - 「タスク定義ドキュメントが完成しました。内容を確認してください。」
+  - 「目的は明確ですか？」
+  - 「変更内容は網羅されていますか？」
+  - 「受け入れ基準は具体的で測定可能ですか？」
+
+### 9. 完成と次のステップ
+
+- タスクディレクトリ内の `a-definition.md` が保存されたことを確認
+- 例: `docs/tasks/task000001-email-verification/a-definition.md`
+
+- 次のステップを提案：
+  - 「タスク定義が完了しました。次はリサーチドキュメントを作成しますか？（`/b-002-CreateTaskResearch`）」
+
+## 完了条件
+
+- タスクディレクトリ内に `a-definition.md` が作成されている
+- 例: `docs/tasks/task000001-{スラッグ}/a-definition.md`
+- 以下のセクションがすべて記載されている：
+  - 目的（解決する問題、提供する価値）
+  - ユーザーストーリー一覧（最低1個以上）
+  - 変更内容一覧（該当するカテゴリがすべて含まれている）
+  - 受け入れ基準（正常系、異常系、テスト要件）
+- 目的が具体的で測定可能である
+- ユーザーストーリーが「[役割]として、[目的]がしたい、なぜなら[理由]」形式で記載されている
+- 変更内容が具体的なファイル名やコンポーネント名を含んでいる
+- 受け入れ基準が具体的で測定可能である
+- ユーザーが内容を確認し、承認している
+
+## エスカレーション
+
+- タスクの目的が曖昧な場合：
+  - 「タスクの目的が曖昧です。具体的な問題と解決後の状態を明確にしてください。」
+  - 追加の質問で深掘り
+
+- 変更内容が不明確な場合：
+  - 「変更内容が抽象的すぎます。具体的なファイル名、コンポーネント名、カラム名を含めてください。」
+
+- 受け入れ基準が曖昧な場合：
+  - 「受け入れ基準が曖昧です。テスト可能な基準を定義してください。」
+  - 例：「使いやすい」→「登録完了まで3クリック以内」
+
+- ユーザーストーリーが技術的すぎる場合：
+  - 「ユーザーストーリーが技術的すぎます。ユーザー視点の価値を記載してください。」
+  - 例：「React Hook Form を使用したい」→「入力エラーを即座に確認したい」
+
+- タスクのスコープが大きすぎる場合：
+  - 「このタスクは範囲が広すぎます。複数のタスクに分割することを推奨します。」
+  - 1タスクは1-5日で完了できる粒度が理想
+
+- 受け入れ基準にセキュリティ要件が欠けている場合：
+  - 「セキュリティに関する受け入れ基準が不足しています。以下を検討してください：」
+    - 入力バリデーション
+    - XSS、CSRF、SQL Injection 対策
+    - 認証・認可
+    - データの暗号化