yodogawa 1.0.0

package/.windsurf/workflows/b-003-CreateTaskResearch.md

@@ -0,0 +1,412 @@
+---
+description: タスク実装前の技術調査を行い、ベストプラクティス、既存コード、再利用コンポーネント、技術選定、リスクを記録するワークフロー
+---
+
+# CreateTaskResearch (b-003)
+
+## 目的
+
+- 実装に着手する前に、最適なアプローチ・技術・注意点を整理する。
+- 既存コードやコンポーネントを把握し、重複実装や手戻りを防止する。
+- 技術選定・リスク・参考資料を記録し、実装計画 (b-004) の入力とする。
+
+## 前提
+
+- `CreateTaskDefinition (b-002)` が完了し、`a-definition.md` に目的・変更内容が記載されている。
+- タスクディレクトリ: `docs/tasks/task{ID}-{SLUG}/`
+- テンプレート: `.windsurf/templates/tasks/task-template/b-research.md`
+
+## 手順
+
+### 1. ドキュメントとテンプレートの準備
+
+```bash
+# 対象タスクの確認
+ls -d docs/tasks/task*
+
+# テンプレート未設置ならコピー
+cp ".windsurf/templates/tasks/task-template/b-research.md" \
+   "docs/tasks/task{ID}-{SLUG}/b-research.md"
+```
+
+### 2. 調査計画の立案
+
+- `a-definition.md` を読み、変更対象・技術要件・制約を抽出。
+- 調査する観点を整理：例）類似実装、利用ライブラリ、外部API仕様、セキュリティ要件。
+- 調査メモを残しながら進めると、ドキュメント作成がスムーズ。
+
+### 3. 既存実装と再利用候補の調査
+
+- Grep / find / IDE の検索で、類似ロジックやコンポーネントを洗い出す。
+  ```bash
+  rg "keyword" src/
+  ```
+- 再利用できるファイル・モジュール・カスタムフック・APIクライアントをリスト化。
+- 参考にできる実装パターン（バリデーション、エラーハンドリング等）と課題点を併記。
+
+### 4. ベストプラクティス・外部情報の調査
+
+- 公式ドキュメント、信頼できる記事、社内ナレッジを確認し、採用すべきパターン/アンチパターンを整理。
+- 調査内容（タイトル、要点、URL）を記録。例）フォームバリデーション、非同期通信、セキュリティガイドライン。
+
+### 5. 技術選定と比較（必要時）
+
+- 新規導入・置き換え候補のライブラリ/サービスを比較。
+- 比較観点: メンテ状況、TypeScript対応、バンドルサイズ、コスト、既存スタックとの親和性。
+- 選定理由と却下理由を記録。チーム合意が必要な場合はその旨も記載。
+
+### 6. 技術的リスクと対策
+
+- パフォーマンス、セキュリティ、スケーラビリティ、依存サービス等のリスクを洗い出す。
+- 影響度と優先度（高/中/低）を付与し、軽減策やPoCの必要有無を記載。
+
+### 7. ドキュメントへの反映
+
+1. `docs/tasks/task{ID}-{SLUG}/b-research.md` を編集し、以下を記入：
+   - ベストプラクティス / 参考リンク
+   - 既存コード・再利用コンポーネント
+   - 技術選定（比較表含む）
+   - 技術的リスク・制約
+   - メモ / 次に確認すべき事項
+2. HTMLコメントはガイドとして残す。
+
+### 8. 構造チェック
+
+```bash
+grep "## ベストプラクティス" docs/tasks/task{ID}-{SLUG}/b-research.md \
+ && grep "## 既存コード調査" docs/tasks/task{ID}-{SLUG}/b-research.md \
+ && grep "## 技術選定" docs/tasks/task{ID}-{SLUG}/b-research.md \
+ && grep "## 技術的リスク" docs/tasks/task{ID}-{SLUG}/b-research.md \
+ && echo "OK" || echo "MISSING SECTION"
+```
+
+チェックリスト:
+- [ ] 参考リンク・出典が記載されている
+- [ ] 再利用できるコード/コンポーネントが明確
+- [ ] 技術選定理由と代替案が整理されている
+- [ ] リスクに軽減策と優先度が付与されている
+
+### 9. Git への追加（任意）
+
+```bash
+git add docs/tasks/task{ID}-{SLUG}/b-research.md
+git commit -m "docs(task): 技術調査メモの作成 task{ID}"
+```
+
+## 完了条件
+
+- `b-research.md` に以下が網羅されている：
+  - ベストプラクティス／参考資料
+  - 既存コード・再利用コンポーネント
+  - 技術選定と比較（必要に応じて）
+  - 技術的リスクと対策
+  - 追加のメモ／未解決事項
+- 実装計画 (b-004) に渡せるレベルで情報が整理されている。
+- 関係者が内容を確認し、疑問があれば解消済み。
+
+## エスカレーション
+
+- **既存コードが見つからない**: 「grep/rg で検索しても見つからない場合、他メンバーに確認し、再利用可否を判断してください。」
+- **ライブラリ選定で決め手がない**: 「評価軸を追加（保守実績、サポート、コストなど）し、比較表を拡張してください。」
+- **リスクが高い**: 「影響が重大なリスクは PoC や専門チーム相談を提案し、スケジュールに反映してください。」
+- **外部サービス依存がある**: 「 SLA・レート制限・コストを確認し、代替案やフォールバックを検討してください。」
+- **ドキュメントが不足**: 「ベストプラクティスや参考資料の記載が不十分です。公式ドキュメントや社内ナレッジを追加してください。」
+例：
+| トピック | ベストプラクティス | 参考リンク |
+|---------|-------------------|-----------|
+| フォームバリデーション | React Hook Form + Zod を使用。パフォーマンスが良く、型安全性が高い | [React Hook Form 公式](https://react-hook-form.com/) |
+| メール送信 | SendGrid や Resend などのサービスを利用。自前 SMTP は避ける | [Resend Best Practices](https://resend.com/docs) |
+
+**アンチパターンの記録**:
+- 「避けるべきアンチパターンはありますか？」
+
+例：
+- 「フォームの全フィールドを state で管理すると再レンダリングが頻発 → React Hook Form を使用」
+- 「パスワードを平文でログに出力 → 機密情報は絶対にログに出力しない」
+
+### 3. 既存コードの調査
+
+#### 3.1. 類似機能の検索
+
+**質問3: 類似機能の有無**
+- 「このプロジェクト内に類似機能がありますか？」
+
+調査方法：
+- Grep ツールで関連キーワードを検索
+- ファイル名やディレクトリ構造から推測
+- 他の開発者に確認
+
+例：
+- メール送信機能を実装する場合：「email」「send」「mail」で検索
+- 認証機能の場合：「auth」「login」「password」で検索
+
+**質問4: 類似機能のファイルパス**
+- 「類似機能のファイルパスを特定してください。」
+
+Grep を使用してファイルを特定：
+```bash
+Grep pattern="sendEmail" output_mode="files_with_matches"
+```
+
+#### 3.2. 既存実装パターンの分析
+
+類似機能のファイルを読み込み、実装パターンを分析：
+
+**質問5: 実装パターン**
+- 「既存コードではどのような実装パターンを使用していますか？」
+
+分析すべき内容：
+- アーキテクチャパターン（MVC、レイヤードアーキテクチャなど）
+- データフェッチ方法（useSWR、React Query、useState + useEffect など）
+- エラーハンドリング方法
+- ローディング状態の管理
+- フォーム管理（Controlled Component、Uncontrolled Component）
+
+**質問6: 参考にすべき点**
+- 「既存コードのどの部分を参考にすべきですか？」
+
+例：
+| 項目 | 内容 |
+|------|------|
+| 類似機能のファイルパス | src/features/auth/PasswordResetForm.tsx |
+| 実装パターン | React Hook Form でフォーム管理、API 呼び出しは useMutation で非同期処理 |
+| 参考にすべき点 | エラーハンドリングのパターン、ローディング状態の管理、ユーザーへのフィードバック表示 |
+
+**質問7: 改善すべき点**
+- 「既存コードで改善すべき点はありますか？」
+
+例：
+- 「エラーメッセージがハードコードされている → i18n 対応が必要」
+- 「テストコードがない → 今回は必ずテストを書く」
+
+### 4. 再利用可能なコンポーネントの特定
+
+#### 4.1. 共通コンポーネントの調査
+
+**質問8: 共通コンポーネントの確認**
+- 「このプロジェクトの共通コンポーネントを確認しましたか？」
+
+調査対象：
+- UIコンポーネント（Button、Input、Modal、Card、Spinnerなど）
+- カスタムフック（useAuth、useFetch、useToast、useFormなど）
+- ユーティリティ関数（formatDate、validateEmail、debounce、throttleなど）
+- APIクライアント、データフェッチャー
+
+調査方法：
+- `src/components/` ディレクトリを確認
+- `src/hooks/` ディレクトリを確認
+- `src/lib/` または `src/utils/` ディレクトリを確認
+- Storybook があれば参照
+
+#### 4.2. 各コンポーネントの使用方法確認
+
+再利用可能なコンポーネントについて、以下を記録：
+
+**質問9: コンポーネント一覧**
+- 「使用する共通コンポーネントをリストアップしてください。」
+
+各コンポーネントについて：
+- コンポーネント名
+- ファイルパス
+- 使用方法（Props、引数、戻り値）
+- 簡単なコードスニペット
+
+例：
+| コンポーネント名 | ファイルパス | 使用方法 |
+|-----------------|-------------|----------|
+| `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 });` |
+
+**質問10: Propsや型の確認**
+- 「各コンポーネントの Props や型定義を確認しましたか？」
+
+Read ツールでファイルを読み込み、型定義を確認：
+```typescript
+// Button.tsx
+interface ButtonProps {
+  variant: 'primary' | 'secondary' | 'danger';
+  onClick: () => void;
+  children: React.ReactNode;
+}
+```
+
+### 5. 技術選定（必要に応じて）
+
+#### 5.1. 選定が必要な技術の特定
+
+**質問11: 新しいライブラリや技術が必要**
+- 「このタスクで新しいライブラリや技術を導入する必要がありますか？」
+
+例：
+- フォームバリデーションライブラリ（React Hook Form、Formik、Yup、Zodなど）
+- メール送信サービス（SendGrid、Resend、Amazon SESなど）
+- 画像最適化ライブラリ（sharp、imagemin など）
+- 日時処理ライブラリ（date-fns、Day.js、Luxon など）
+
+#### 5.2. 複数の選択肢の比較
+
+新しいライブラリ導入が必要な場合、複数の選択肢を比較：
+
+**質問12: 比較対象**
+- 「どのライブラリを比較しましたか？」
+
+比較すべき観点：
+- **人気度**：npm trends、GitHub スター数
+- **メンテナンス状況**：最終更新日、Issue/PR の対応状況
+- **バンドルサイズ**：フロントエンドの場合は重要
+- **型安全性**：TypeScript サポート
+- **学習コスト**：ドキュメントの充実度、チームの経験
+- **既存プロジェクトとの整合性**：既に使用している技術との相性
+- **ライセンス**：商用利用可能か（MIT、Apache 2.0 など）
+
+**質問13: 選定理由**
+- 「選定した技術の理由を教えてください。」
+
+例：
+| 技術・ライブラリ | 選定理由 | 代替案との比較 |
+|----------------|---------|---------------|
+| Zod | TypeScript の型定義からバリデーションスキーマを自動生成可能。React Hook Form との統合が容易。バンドルサイズも小さい（8KB gzip） | Yup は型推論が弱い。Joi はバンドルサイズが大きい（45KB gzip） |
+
+#### 5.3. チーム内での合意
+
+**質問14: チーム内での合意**
+- 「新しいライブラリ導入についてチーム内で合意を取りましたか？」
+- 「誰かレビューしましたか？」
+
+### 6. 技術的リスクと制約の洗い出し
+
+#### 6.1. リスクの特定
+
+**質問15: 技術的リスク**
+- 「このタスクで想定される技術的リスクは何ですか？」
+
+リスクのカテゴリ：
+- **パフォーマンス**：大量データ、重い処理、ネットワーク遅延
+- **セキュリティ**：XSS、CSRF、SQL Injection、認証・認可の不備
+- **ブラウザ互換性**：古いブラウザでの動作、ポリフィル必要性
+- **外部サービスへの依存**：API の制限、障害時の影響、コスト
+- **スケーラビリティ**：将来的なユーザー数増加への対応
+- **データ整合性**：同時更新、トランザクション
+
+#### 6.2. 各リスクの詳細定義
+
+各リスクについて、以下をヒアリング：
+
+**質問16: リスクの詳細**
+- 「[リスク]の詳細を教えてください。」
+
+記載すべき内容：
+- リスク内容（何が問題か）
+- 影響（どのような影響があるか、影響範囲）
+- 軽減策（どのように対処するか）
+
+例：
+| リスク | 影響 | 軽減策 |
+|--------|------|--------|
+| メール送信の遅延 | ユーザー登録完了までに時間がかかり、UX が悪化 | 非同期ジョブキューで処理。即座に「メール送信中」メッセージを表示 |
+| SendGrid API の障害 | メール送信が完全に停止 | フォールバック先（Amazon SES）を用意。障害時の通知機能を実装 |
+| トークンの総当たり攻撃 | 不正なメール認証の可能性 | UUID v4 でランダム性を確保（2^122の組み合わせ）。有効期限を24時間に制限。レート制限を実装 |
+
+**質問17: 優先度**
+- 「各リスクの優先度は？」
+  - 高：すぐに対処が必要
+  - 中：実装時に考慮
+  - 低：余裕があれば対処
+
+### 7. メモ・補足情報
+
+**質問18: 補足情報**
+- 「その他、調査中に気づいたことや補足情報はありますか？」
+
+記載すべき内容：
+- 調査中に気づいた改善点
+- 今後の調査が必要な項目
+- 参考になった記事や動画
+- チームメンバーへの質問事項
+- 調査の過程で発見した技術的負債
+
+例：
+- 「既存のメール送信機能が古い実装のため、このタスクと一緒にリファクタリング検討」
+- 「パフォーマンステストが必要（1000ユーザー同時登録時の負荷）」
+- 「セキュリティレビューをチームリーダーに依頼予定」
+
+### 8. ドキュメント作成
+
+- 収集した情報を基に、タスクディレクトリ内の `b-research.md` を編集
+- 例: `docs/tasks/task000001-email-verification/b-research.md`
+
+- テンプレートに従い、以下を記載：
+  - **ベストプラクティス**（トピック、ベストプラクティス、参考リンク）
+  - **既存コードの調査**（類似機能のファイルパス、実装パターン、参考にすべき点）
+  - **再利用可能なコンポーネント**（コンポーネント名、ファイルパス、使用方法）
+  - **技術選定**（技術・ライブラリ、選定理由、代替案との比較）（必要に応じて）
+  - **技術的リスクと制約**（リスク、影響、軽減策）
+  - **メモ**（補足情報）
+
+- **HTMLコメントは削除せず残す**
+
+### 9. レビューと確認
+
+- 作成したドキュメントをユーザーに提示：
+  - 「リサーチドキュメントが完成しました。内容を確認してください。」
+  - 「ベストプラクティスは十分に調査されていますか？」
+  - 「既存コードで再利用できるものは特定されていますか？」
+  - 「技術的リスクは網羅されていますか？」
+
+### 10. 完成と次のステップ
+
+- タスクディレクトリ内の `b-research.md` が保存されたことを確認
+- 例: `docs/tasks/task000001-email-verification/b-research.md`
+
+- 次のステップを提案：
+  - 「リサーチが完了しました。次は実装タスクリストを作成しますか？（`/b-003-CreateTaskImplementation`）」
+
+## 完了条件
+
+- タスクディレクトリ内に `b-research.md` が作成されている
+- 例: `docs/tasks/task000001-{スラッグ}/b-research.md`
+- 以下のセクションがすべて記載されている：
+  - ベストプラクティス（最低1個以上、参考リンク付き）
+  - 既存コードの調査（類似機能がある場合）
+  - 再利用可能なコンポーネント（該当するものがすべて含まれている）
+  - 技術的リスクと制約（主要なリスクが網羅されている）
+- ベストプラクティスに参考リンクが含まれている
+- 既存コードのファイルパスが正確である
+- 再利用可能なコンポーネントの使用方法が明確である
+- 技術的リスクに軽減策が記載されている
+- ユーザーが内容を確認し、承認している
+
+## エスカレーション
+
+- ベストプラクティスの調査が不十分な場合：
+  - 「ベストプラクティスの調査が不十分です。公式ドキュメントや信頼できる情報源を参照してください。」
+  - 追加の調査を依頼
+
+- 既存コードの調査が行われていない場合：
+  - 「既存コードの調査が行われていません。車輪の再発明を避けるため、既存の実装パターンを確認してください。」
+  - Grep ツールでの検索方法を提案
+
+- 技術選定の根拠が不明確な場合：
+  - 「技術選定の根拠が不明確です。複数の選択肢を比較し、選定理由を明確にしてください。」
+  - 比較表の作成を提案
+
+- 技術的リスクの軽減策が欠けている場合：
+  - 「技術的リスクは特定されていますが、軽減策が記載されていません。各リスクに対する具体的な対処方法を検討してください。」
+
+- 新しいライブラリ導入がチームで合意されていない場合：
+  - 「新しいライブラリの導入はチーム全体に影響します。チームリーダーやメンバーとレビュー・合意を取ってください。」
+
+- セキュリティリスクが見落とされている場合：
+  - 「セキュリティリスクが考慮されていません。以下の観点で再調査してください：」
+    - 入力バリデーション
+    - XSS、CSRF、SQL Injection
+    - 認証・認可
+    - データの暗号化
+    - API のレート制限
+
+- パフォーマンスリスクが見落とされている場合：
+  - 「パフォーマンスリスクが考慮されていません。大量データや高負荷時の動作を検討してください。」
+
+- 参考リンクが古い、または信頼性が低い場合：
+  - 「参考リンクの情報が古い、または信頼性が低いようです。公式ドキュメントや最新の情報源を参照してください。」

package/.windsurf/workflows/b-004-CreateTaskImplementation.md

@@ -0,0 +1,97 @@
+---
+description: タスクの実装計画を段階的に分割し、ステップごとの成果物と受け入れ基準を定義するワークフロー
+---
+
+# CreateTaskImplementation (b-004)
+
+## 目的
+
+- タスクを実行可能なフェーズとステップに分割し、作業順序と依存関係を明確にする。
+- 各ステップの成果物と受け入れ基準を定義し、作業完了の判断基準を共有する。
+- 実装開始前にテスト計画や懸念点を洗い出し、品質リスクを低減する。
+
+## 前提
+
+- `a-definition.md`（b-002）と `b-research.md`（b-003）が作成済みであること。
+- タスクディレクトリ: `docs/tasks/task{ID}-{SLUG}/`
+- テンプレート: `.windsurf/templates/tasks/task-template/c-implementation.md`
+
+## 手順
+
+### 1. ドキュメント確認とテンプレート準備
+
+```bash
+ls -d docs/tasks/task*
+cp ".windsurf/templates/tasks/task-template/c-implementation.md" \
+   "docs/tasks/task{ID}-{SLUG}/c-implementation.md"
+```
+
+- `a-definition.md` から目的・変更内容・受け入れ基準を読み取る。
+- `b-research.md` から技術方針・ライブラリ選定・リスクを把握する。
+
+### 2. フェーズ設計
+
+- タスクを 2〜4 フェーズに分割し、各フェーズのゴールと依存関係を整理。
+- 目安: 1フェーズ = 1〜3日で完了できる規模。
+- 例: 「データモデル/マイグレーション」「API 実装」「フロントエンド」「統合テスト」
+
+### 3. ステップ分解
+
+- 各フェーズを 1〜3時間で完了できるステップに分割。
+- ステップごとに以下を定義:
+  - **Title**: 作業名
+  - **Details**: 実装内容・注意点（ファイル名・関数名・ライブラリなど）
+  - **Deliverables**: 成果物（PR/コミット/ファイル）
+  - **Verification**: 実装完了の確認方法（テストコマンド、ブラウザチェック等）
+
+### 4. テスト計画
+
+- フェーズ／ステップ単位で必要なテストを記載。
+  - ユニットテスト、API テスト、UI テスト、E2E テスト、負荷テストなど。
+- カバレッジ目標や検証手順（`npm test`, `pnpm vitest`, `playwright test` 等）を明示。
+
+### 5. ドキュメント反映
+
+- `docs/tasks/task{ID}-{SLUG}/c-implementation.md` に以下を記入:
+  1. フェーズ一覧（目的、完了条件、依存関係）
+  2. フェーズ内ステップ（Title/Details/Deliverables/Verification）
+  3. テスト計画
+  4. メモ・補足（懸念点、要確認事項、リファクタ案など）
+- HTMLコメントは削除せずガイドとして残す。
+
+### 6. 構造チェック
+
+```bash
+grep "## 実装フェーズ" docs/tasks/task{ID}-{SLUG}/c-implementation.md \
+ && grep "## ステップ一覧" docs/tasks/task{ID}-{SLUG}/c-implementation.md \
+ && grep "## テスト計画" docs/tasks/task{ID}-{SLUG}/c-implementation.md \
+ && echo "OK" || echo "MISSING SECTION"
+```
+
+チェックリスト:
+- [ ] すべてのフェーズに目的・完了条件・依存関係が記載されている
+- [ ] 各ステップに成果物と検証方法がある
+- [ ] テスト計画が網羅的に記載されている
+- [ ] 懸念点や未決事項がメモ欄に整理されている
+
+### 7. Git への追加（任意）
+
+```bash
+git add docs/tasks/task{ID}-{SLUG}/c-implementation.md
+git commit -m "docs(task): 実装計画の作成 task{ID}"
+```
+
+## 完了条件
+
+- `c-implementation.md` にフェーズ／ステップ／テスト／メモが記載されている。
+- ステップの粒度が適切（1〜3時間）で、成果物が明確。
+- フェーズ順序と依存関係が示されている。
+- 関係者レビューで疑問がない状態になっている。
+
+## エスカレーション
+
+- **フェーズが大きすぎる**: 「1フェーズが 3日以上になりそうです。分割してください。」
+- **ステップが抽象的**: 「成果物が特定できません。ファイル名や検証手順を明記してください。」
+- **テスト計画不足**: 「対象機能のテスト戦略が不足しています。ユニット/統合/E2E を再検討してください。」
+- **リスク対策未反映**: 「b-003 で挙げたリスクへの対策ステップがありません。計画に組み込んでください。」
+- **依存関係不明**: 「並行実行可能なフェーズと、順序が必要なフェーズを明示してください。」