yodogawa 1.0.0

package/.windsurf/templates/project/04-design/07-infrastructure.md

@@ -0,0 +1,180 @@
+# インフラ設計
+
+<!--
+何を書くか: インフラ構成図、環境構成、主要な運用方針
+
+目的:
+  - インフラ構成の全体像を可視化
+  - 環境ごとの違いを明確化
+  - 基本的な運用方針の記録
+
+重要性:
+  - 高レベルなインフラ構成の全体像を把握
+  - 詳細な実装（スペック、ネットワーク設定、監視設定）は Infrastructure as Code で管理
+
+記載のポイント:
+  - インフラ構成図で視覚的に表現（Multi-AZ構成など）
+  - 環境ごとの違い（開発、ステージング、本番）
+  - バックアップ・監視の基本方針
+
+更新頻度:
+  - プロジェクト初期にインフラ設計を作成
+  - インフラ構成変更時に更新
+-->
+
+---
+
+## インフラ構成図
+
+<!--
+Mermaid を使用してインフラ全体の構成を可視化
+
+記載のベストプラクティス:
+  1. 物理的な構成を表現（サーバー、ネットワーク、ストレージ）
+  2. 冗長化構成を明記（Multi-AZ、フェイルオーバー）
+  3. ネットワークセグメントを分離（パブリック、プライベート、DMZ）
+  4. セキュリティグループ、ファイアウォールルールを図示
+  5. 外部サービスとの接続も記載
+
+よくあるコンポーネント:
+  - インターネット: 外部ネットワーク
+  - CDN: CloudFront, Cloudflare, Fastly
+  - DNS: Route 53, Cloudflare DNS
+  - Load Balancer: ALB, NLB, ELB
+  - アプリケーションサーバー: EC2, ECS, Lambda
+  - データベース: RDS, Aurora, DynamoDB
+  - キャッシュ: ElastiCache (Redis, Memcached)
+  - ストレージ: S3, EBS, EFS
+  - VPN: VPC Peering, VPN Gateway
+  - 監視: CloudWatch, Datadog, New Relic
+
+Mermaid の記法:
+  - subgraph でネットワークセグメントをグループ化
+  - VPC, Subnet, Availability Zone を表現
+-->
+
+```mermaid
+graph TB
+    Internet[インターネット]
+
+    subgraph "AWS Cloud"
+        Route53[Route 53<br/>DNS]
+        CDN[CloudFront<br/>CDN]
+
+        subgraph "VPC"
+            subgraph "Availability Zone A"
+                subgraph "Public Subnet A"
+                    NAT_A[NAT Gateway A]
+                end
+                subgraph "Private Subnet A"
+                    APP1[App Server 1<br/>EC2]
+                    Cache_A[Redis<br/>ElastiCache]
+                end
+                subgraph "Data Subnet A"
+                    DB_Primary[PostgreSQL<br/>RDS Primary]
+                end
+            end
+
+            subgraph "Availability Zone B"
+                subgraph "Public Subnet B"
+                    NAT_B[NAT Gateway B]
+                end
+                subgraph "Private Subnet B"
+                    APP2[App Server 2<br/>EC2]
+                    Cache_B[Redis<br/>ElastiCache]
+                end
+                subgraph "Data Subnet B"
+                    DB_Replica[PostgreSQL<br/>RDS Replica]
+                end
+            end
+
+            ALB[Application<br/>Load Balancer]
+        end
+
+        S3[S3<br/>Object Storage]
+        CloudWatch[CloudWatch<br/>Monitoring & Logs]
+    end
+
+    Internet --> Route53
+    Route53 --> CDN
+    CDN --> ALB
+    ALB --> APP1
+    ALB --> APP2
+
+    APP1 --> DB_Primary
+    APP2 --> DB_Primary
+    APP1 --> DB_Replica
+    APP2 --> DB_Replica
+
+    APP1 --> Cache_A
+    APP2 --> Cache_B
+
+    APP1 --> S3
+    APP2 --> S3
+
+    APP1 --> NAT_A
+    APP2 --> NAT_B
+    NAT_A --> Internet
+    NAT_B --> Internet
+
+    APP1 -.logs.-> CloudWatch
+    APP2 -.logs.-> CloudWatch
+    DB_Primary -.metrics.-> CloudWatch
+    DB_Replica -.metrics.-> CloudWatch
+```
+
+**補足**:
+<!-- 例:
+- Multi-AZ 構成で可用性を確保（AZ-A と AZ-B で冗長化）
+- Public Subnet: インターネットゲートウェイへの経路あり（NAT Gateway）
+- Private Subnet: アプリケーションサーバー（外部から直接アクセス不可）
+- Data Subnet: データベース（Private Subnet からのみアクセス可能）
+- RDS は Primary と Read Replica で読み取り負荷を分散
+- Redis は各 AZ に配置しレプリケーション構成
+- CloudWatch で全リソースの監視とログ集約
+-->
+
+---
+
+## 環境構成
+
+<!--
+開発、ステージング、本番環境の違いを明記
+
+環境ごとの特徴:
+  - 開発環境: ローカル開発、最小構成
+  - ステージング環境: 本番に近い構成、テスト用
+  - 本番環境: 高可用性、冗長化構成
+
+詳細なスペック（インスタンスタイプ、ストレージ容量など）は
+Infrastructure as Code（Terraform/CloudFormation）で管理します。
+-->
+
+| 環境 | ホスティング | データベース | 特徴 |
+|------|-------------|-------------|------|
+| **開発** | <!-- ローカル（Docker） --> | <!-- PostgreSQL (Docker) --> | <!-- 最小構成、コスト最小化 --> |
+| **ステージング** | <!-- AWS EC2 --> | <!-- RDS PostgreSQL<br/>Single-AZ --> | <!-- 本番に近い構成だが小規模 --> |
+| **本番** | <!-- AWS EC2<br/>Auto Scaling --> | <!-- RDS PostgreSQL<br/>Multi-AZ + Read Replica --> | <!-- Multi-AZ 冗長化、高可用性 --> |
+
+---
+
+## 主要な運用方針
+
+<!--
+バックアップ、監視、セキュリティの基本方針を簡潔に記載
+
+詳細な設定（監視閾値、ログ設定、ネットワーク設定など）は
+Infrastructure as Code とランブックで管理します。
+
+記載すべき内容:
+  - バックアップ方針
+  - 監視方針
+  - セキュリティ基本方針
+-->
+
+| 項目 | 内容 |
+|------|------|
+| **バックアップ** | <!-- 例: RDS 日次自動バックアップ（30日保持）、S3 バージョニング有効化 --> |
+| **監視** | <!-- 例: CloudWatch でインフラ監視、Sentry でエラートラッキング --> |
+| **セキュリティ** | <!-- 例: Private Subnet にアプリケーション配置、RDS/S3 暗号化、IAM 最小権限 --> |
+| **災害復旧** | <!-- 例: RPO: 1時間、RTO: 4時間、Multi-AZ 構成で高可用性確保 --> |

package/.windsurf/templates/tasks/task-template/a-definition.md

@@ -0,0 +1,143 @@
+# タスク定義ドキュメント
+
+<!--
+このドキュメントについて:
+  - 格納場所: docs/tasks/task000001-{スラッグ}/a-definition.md
+  - 作成方法: /b-001-CreateTaskDefinition ワークフローで作成
+  - 関連ドキュメント:
+    - b-research.md (リサーチドキュメント)
+    - c-implementation.md (実装タスクリスト)
+
+このドキュメントの目的:
+  - タスクの目的と範囲を明確化
+  - 実装前に関係者間で認識を統一
+  - 受け入れ基準を事前定義
+  - 影響範囲の可視化
+
+更新タイミング:
+  - タスク着手前に作成
+  - 要件変更時に更新
+  - レビュー時に不明点を追記
+-->
+
+---
+
+## 1. 目的
+
+<!--
+何を書くか: このタスクで解決する問題と提供する価値
+
+記載のポイント:
+  - 「何のために」このタスクをやるのか
+  - ユーザーや開発者が得られる具体的なメリット
+  - 現状の問題点や不便さ
+  - このタスクで変わること
+
+ベストプラクティス:
+  - 具体的な数値があれば含める（例: 「ローディング時間を3秒→1秒に短縮」）
+  - ステークホルダー視点で価値を記載（ユーザー、開発者、運用者など）
+  - Before/After が明確に想像できる表現を使う
+-->
+
+| 項目 | 内容 |
+|------|------|
+| 解決する問題 | <!-- 例: ユーザー登録時のメール認証フローがなく、不正なメールアドレスが登録される --> |
+| 提供する価値 | <!-- 例: メール認証により、有効なメールアドレスのみ登録可能になり、通知配信の精度が向上する --> |
+
+---
+
+## 2. ユーザーストーリー一覧
+
+<!--
+何を書くか: ユーザー視点でのタスクの要件
+
+フォーマット: [役割]として、[目的]がしたい、なぜなら[理由]
+
+記載のポイント:
+  - 誰が（ペルソナ、役割）
+  - 何をしたいか（機能、操作）
+  - なぜそれが必要か（ビジネス価値、動機）
+
+ベストプラクティス:
+  - ストーリーIDは一意に（例: US-001, US-002）
+  - 1つのストーリーは1つの価値に焦点を当てる
+  - 技術的な詳細ではなくユーザー価値を記載
+  - 複数の役割がある場合は分けて記載
+-->
+
+| ストーリーID | ストーリー |
+|--------------|-----------|
+| US-001 | <!-- 例: 新規ユーザーとして、登録時にメール認証を受けたい、なぜなら自分のメールアドレスが正しく登録されたことを確認したいから --> |
+| US-002 | <!-- 例: 管理者として、認証済みユーザーのみに通知を送信したい、なぜなら配信エラーを減らしたいから --> |
+
+---
+
+## 3. 変更内容一覧
+
+<!--
+何を書くか: このタスクで変更する具体的な要素
+
+記載のポイント:
+  - 新規追加なのか、既存の変更なのか
+  - 影響を受けるファイルやコンポーネント
+  - 削除する機能があれば明記
+
+ベストプラクティス:
+  - 具体的なファイル名やコンポーネント名を含める
+  - 「追加」「変更」「削除」を明示
+  - 依存関係がある変更は順序を意識
+-->
+
+| カテゴリ | 変更内容 |
+|----------|----------|
+| 画面 | <!-- 例: RegisterForm.tsx にメールアドレス入力フィールド追加、EmailVerificationPage.tsx 新規作成 --> |
+| データモデル | <!-- 例: User テーブルに email_verified (boolean), verification_token (string) フィールド追加 --> |
+| API | <!-- 例: POST /api/auth/send-verification, POST /api/auth/verify-email エンドポイント追加 --> |
+| その他 | <!-- 例: メール送信サービス (SendGrid) の API キー設定追加 --> |
+
+---
+
+## 4. 受け入れ基準
+
+<!--
+何を書くか: タスク完了の判断基準
+
+記載のポイント:
+  - 機能が正しく動作すること
+  - エッジケースが処理されること
+  - テストが通ること
+  - ドキュメントが更新されていること
+
+ベストプラクティス:
+  - テスト可能な基準を記載（あいまいな表現を避ける）
+  - 正常系だけでなく異常系も含める
+  - パフォーマンス要件があれば明記
+  - セキュリティ要件があれば明記
+-->
+
+- [ ] <!-- 例: ユーザー登録時に認証メールが送信される -->
+- [ ] <!-- 例: メール内のリンクをクリックするとメールアドレスが認証される -->
+- [ ] <!-- 例: 認証されていないユーザーは特定機能にアクセスできない -->
+- [ ] <!-- 例: 無効なトークンでアクセスした場合、適切なエラーメッセージが表示される -->
+- [ ] <!-- 例: ユニットテスト、統合テストが全て通る -->
+
+---
+
+## メモ
+
+<!--
+タスク定義に関する補足情報
+
+記載すべき内容:
+  - 技術的な制約や前提条件
+  - 関連する Issue や PR のリンク
+  - 参考資料（仕様書、デザインモックなど）
+  - 既知の問題や懸念事項
+  - 将来的な拡張予定
+
+例:
+- 関連 Issue: #123
+- 参考デザイン: https://figma.com/file/...
+- 注意: メール送信は非同期処理で実装する
+- 今後の拡張: SMS 認証も追加予定
+-->

package/.windsurf/templates/tasks/task-template/b-research.md

@@ -0,0 +1,185 @@
+# リサーチドキュメント
+
+<!--
+このドキュメントについて:
+  - 格納場所: docs/tasks/task000001-{スラッグ}/b-research.md
+  - 作成方法: /b-002-CreateTaskResearch ワークフローで作成
+  - 前提条件: a-definition.md が作成済みであること
+  - 関連ドキュメント:
+    - a-definition.md (タスク定義ドキュメント)
+    - c-implementation.md (実装タスクリスト)
+
+このドキュメントの目的:
+  - 実装前の技術調査結果を記録
+  - ベストプラクティスの収集と共有
+  - 既存コードの再利用可能性を確認
+  - 技術的なリスクや制約の洗い出し
+
+更新タイミング:
+  - タスク実装前の調査段階で作成
+  - 新しい知見が得られた時に追記
+  - レビュー時の指摘を反映
+-->
+
+---
+
+## 1. ベストプラクティス
+
+<!--
+何を書くか: 実装に関連する技術的なベストプラクティス
+
+記載のポイント:
+  - 公式ドキュメントの推奨事項
+  - 業界標準やコミュニティのコンセンサス
+  - パフォーマンス、セキュリティ、保守性の観点
+  - アンチパターンとその理由
+
+情報源:
+  - 公式ドキュメント（React, Next.js, etc.）
+  - GitHub の人気リポジトリ（類似機能の実装例）
+  - Stack Overflow、Qiita、Zenn などの技術記事
+  - チーム内の過去の実装事例
+
+ベストプラクティス:
+  - 単なる個人の意見ではなく、根拠のある情報を記載
+  - リンクを必ず含める（情報の鮮度確認のため）
+  - 複数の選択肢がある場合は比較表を作成
+  - このプロジェクトに適用できない場合はその理由も記載
+-->
+
+| トピック | ベストプラクティス | 参考リンク |
+|---------|-------------------|-----------|
+| <!-- 例: フォームバリデーション --> | <!-- 例: React Hook Form + Zod を使用。パフォーマンスが良く、型安全性が高い --> | <!-- 例: [React Hook Form 公式](https://react-hook-form.com/) --> |
+| <!-- 例: メール送信 --> | <!-- 例: SendGrid や Resend などのサービスを利用。自前 SMTP は避ける --> | <!-- 例: [Resend Best Practices](https://resend.com/docs) --> |
+
+---
+
+## 2. 既存コードの調査
+
+<!--
+何を書くか: このプロジェクト内の既存実装を調査
+
+調査対象:
+  - 類似機能の実装（同じパターンで実装可能か）
+  - 共通ライブラリやユーティリティ（車輪の再発明を避ける）
+  - アーキテクチャパターン（プロジェクトの慣習に従う）
+  - データモデルや API 設計（既存のパターンを踏襲）
+
+記載のポイント:
+  - ファイルパスを正確に記載（Read や Grep で確認）
+  - コードスニペットを含める（重要な部分のみ）
+  - なぜそのコードを参考にすべきか理由を記載
+  - 改善すべき点があれば指摘
+
+ベストプラクティス:
+  - 単にコードをコピペするのではなく、設計意図を理解する
+  - 依存関係や副作用を確認
+  - テストコードも参考にする（期待される振る舞いを理解）
+  - 最新のコードか確認（古い実装を参考にしない）
+-->
+
+| 項目 | 内容 |
+|------|------|
+| 類似機能のファイルパス | <!-- 例: src/features/auth/PasswordResetForm.tsx (メール送信フロー) --> |
+| 実装パターン | <!-- 例: React Hook Form でフォーム管理、API 呼び出しは useMutation で非同期処理 --> |
+| 参考にすべき点 | <!-- 例: エラーハンドリングのパターン、ローディング状態の管理、ユーザーへのフィードバック表示 --> |
+
+---
+
+## 3. 再利用可能なコンポーネント
+
+<!--
+何を書くか: 既存の共通コンポーネントやライブラリで再利用できるもの
+
+調査対象:
+  - UI コンポーネント（Button, Input, Modal など）
+  - カスタムフック（useAuth, useFetch など）
+  - ユーティリティ関数（formatDate, validateEmail など）
+  - API クライアント、データフェッチャー
+
+記載のポイント:
+  - コンポーネント名とファイルパス
+  - 使用方法（Props、引数、戻り値）
+  - 使用例（簡単なコードスニペット）
+  - 制約事項や注意点
+
+ベストプラクティス:
+  - 実際にコードを読んで Props や型を確認
+  - 他の箇所での使用例を探す（実践的な使い方を学ぶ）
+  - Storybook やドキュメントがあれば参照
+  - 古いコンポーネントの場合、リファクタリング検討
+-->
+
+| コンポーネント名 | ファイルパス | 使用方法 |
+|-----------------|-------------|----------|
+| `Button` | `src/components/Button.tsx` | `<Button variant="primary" onClick={handleClick}>送信</Button>` |
+| `useToast` | `src/hooks/useToast.ts` | `const { showToast } = useToast(); showToast({ message: "成功", type: "success" });` |
+| `apiClient` | `src/lib/apiClient.ts` | `await apiClient.post("/api/auth/verify", { token });` |
+
+---
+
+## 4. 技術選定
+
+<!--
+何を書くか: このタスクで使用する技術やライブラリの選定理由（必要に応じて）
+
+記載のポイント:
+  - 複数の選択肢がある場合の比較
+  - 選定基準（パフォーマンス、型安全性、コミュニティサポート、学習コスト）
+  - 選定した技術のメリット・デメリット
+  - 既存プロジェクトとの整合性
+
+ベストプラクティス:
+  - 感覚ではなくデータに基づいて選定（npm trends、GitHub スター数、メンテナンス状況）
+  - チーム内で合意を取る（新しいライブラリ導入は慎重に）
+  - ライセンスを確認（商用利用可能か）
+  - バンドルサイズを考慮（フロントエンドの場合）
+-->
+
+| 技術・ライブラリ | 選定理由 | 代替案との比較 |
+|----------------|---------|---------------|
+| <!-- 例: Zod --> | <!-- 例: TypeScript の型定義からバリデーションスキーマを自動生成可能。React Hook Form との統合が容易 --> | <!-- 例: Yup は型推論が弱い。Joi はバンドルサイズが大きい --> |
+
+---
+
+## 5. 技術的リスクと制約
+
+<!--
+何を書くか: 実装時に想定される技術的な課題やリスク
+
+記載すべき内容:
+  - パフォーマンス上の懸念（大量データ、重い処理）
+  - セキュリティリスク（XSS, CSRF, SQL Injection など）
+  - ブラウザ互換性の問題
+  - 外部サービスへの依存（API の制限、障害時の影響）
+  - スケーラビリティの課題
+
+ベストプラクティス:
+  - リスクだけでなく軽減策も記載
+  - 優先度をつける（高/中/低）
+  - 実装前にチームで共有して合意を取る
+-->
+
+| リスク | 影響 | 軽減策 |
+|--------|------|--------|
+| <!-- 例: メール送信の遅延 --> | <!-- 例: ユーザー登録完了までに時間がかかる --> | <!-- 例: 非同期ジョブキューで処理。即座に「メール送信中」メッセージを表示 --> |
+
+---
+
+## メモ
+
+<!--
+リサーチ全体に関する補足情報
+
+記載すべき内容:
+  - 調査中に気づいた改善点
+  - 今後の調査が必要な項目
+  - 参考になった記事や動画
+  - チームメンバーへの質問事項
+  - 調査の過程で発見した技術的負債
+
+例:
+- 既存のメール送信機能が古い実装のため、リファクタリング検討
+- パフォーマンステストが必要（大量ユーザー登録時の負荷）
+- セキュリティレビューをチームリーダーに依頼
+-->