yodogawa 2.1.3 → 2.2.0

package/templates/tasks/task-template/c-implementation.md

@@ -1,200 +1,200 @@
-# 実装タスクリスト
-
-<!--
-このドキュメントについて:
-  - 格納場所: docs/tasks/task000001-{スラッグ}/c-implementation.md
-  - 作成方法: /b-004-create-task-implementation スキルで作成
-  - 実行方法: /c-001-implement-task スキルで各ステップを実行
-  - 前提条件: a-definition.md と b-research.md が作成済みであること
-  - 関連ドキュメント:
-    - a-definition.md (タスク定義ドキュメント)
-    - b-research.md (リサーチドキュメント)
-
-このドキュメントの目的:
-  - 実装作業を段階的に分割して管理
-  - 進捗の可視化とチーム共有
-  - 各ステップの成果物を明確化
-  - 実装漏れの防止
-
-更新タイミング:
-  - 実装開始前にフェーズ分割を計画
-  - 各ステップ完了時にチェック（/c-001-implement-task が自動更新）
-  - 新たな作業が発覚した際に追加
-  - レビュー指摘事項を反映
--->
-
----
-
-## フェーズ 1: [フェーズ名]
-
-<!--
-フェーズの分け方:
-  - 機能単位で分割（例: フロントエンド → バックエンド → 統合）
-  - 依存関係で分割（例: データモデル → API → UI）
-  - リスクで分割（例: 検証 → 本実装 → 最適化）
-
-ベストプラクティス:
-  - 1フェーズは 1-3 日以内で完了できる粒度
-  - フェーズごとに動作確認可能な状態にする
-  - 各フェーズで小さくコミット・PR を作成（レビュー負荷軽減）
--->
-
-**目的:** <!-- 例: データモデルと API エンドポイントの実装 -->
-
-**完了条件:** <!-- 例: API が期待通りのレスポンスを返し、ユニットテストが全て通る -->
-
-### ステップ
-
-<!--
-ステップの粒度:
-  - 1ステップは 1-3 時間程度で完了できる作業
-  - コミット単位で分割すると管理しやすい
-  - 成果物が明確であること（ファイル、機能、テスト）
-
-記載のポイント:
-  - 具体的なファイル名やコンポーネント名を含める
-  - 実装の詳細にはアルゴリズムや技術的な注意点を記載
-  - 依存関係があるステップは順序を意識
--->
-
-- [ ] **ステップ 1:** データベーススキーマの定義
-  - **成果物:** `migrations/001_create_users_table.sql`
-  - **詳細:** User テーブルに `email_verified`, `verification_token`, `token_expires_at` を追加。インデックスは `verification_token` に作成
-
-- [ ] **ステップ 2:** TypeScript 型定義の追加
-  - **成果物:** `src/types/User.ts`
-  - **詳細:** `User` インターフェースに新しいフィールドを追加。Zod スキーマも同時に定義
-
-- [ ] **ステップ 3:** メール送信 API エンドポイントの実装
-  - **成果物:** `src/api/auth/send-verification.ts`
-  - **詳細:** トークン生成（UUID v4）、有効期限 24 時間、SendGrid API 呼び出し。エラーハンドリング実装
-
-- [ ] **ステップ 4:** メール認証 API エンドポイントの実装
-  - **成果物:** `src/api/auth/verify-email.ts`
-  - **詳細:** トークン検証、有効期限チェック、ユーザーステータス更新。無効トークンは 400 エラー
-
----
-
-## フェーズ 2: [フェーズ名]
-
-**目的:** <!-- 例: フロントエンド UI の実装とユーザーフロー統合 -->
-
-**完了条件:** <!-- 例: ユーザー登録から認証完了までの一連の流れが動作し、E2E テストが通る -->
-
-### ステップ
-
-- [ ] **ステップ 1:** メール認証ページの作成
-  - **成果物:** `src/pages/EmailVerificationPage.tsx`
-  - **詳細:** URL パラメータからトークンを取得、API 呼び出し、成功/失敗メッセージ表示
-
-- [ ] **ステップ 2:** ユーザー登録フォームにメール送信処理を追加
-  - **成果物:** `src/features/auth/RegisterForm.tsx` を更新
-  - **詳細:** 登録成功後にメール送信 API を呼び出し、「確認メールを送信しました」メッセージを表示
-
-- [ ] **ステップ 3:** 認証状態のガード実装
-  - **成果物:** `src/middleware/requireEmailVerified.ts`
-  - **詳細:** 未認証ユーザーは特定ページにアクセス不可。リダイレクト処理を実装
-
----
-
-## フェーズ 3: テスト・ドキュメント
-
-<!--
-テストフェーズの重要性:
-  - 実装と同時にテストを書くことでバグを早期発見
-  - テストコードは仕様書の役割も果たす
-  - リグレッション防止（今後の変更で既存機能が壊れない）
-
-記載すべきテスト:
-  - ユニットテスト（関数、コンポーネント単位）
-  - 統合テスト（API、データベース連携）
-  - E2E テスト（ユーザーフロー全体）
-  - エッジケーステスト（異常系、境界値）
--->
-
-**目的:** <!-- 例: テストコード作成とドキュメント整備 -->
-
-**完了条件:** <!-- 例: テストカバレッジ 80% 以上、README にセットアップ手順を記載 -->
-
-### ステップ
-
-- [ ] **ステップ 1:** ユニットテストの作成
-  - **成果物:** `src/api/auth/send-verification.test.ts`, `verify-email.test.ts`
-  - **詳細:** トークン生成、有効期限検証、エラーハンドリングのテスト。モックを使用
-
-- [ ] **ステップ 2:** 統合テストの作成
-  - **成果物:** `tests/integration/email-verification.test.ts`
-  - **詳細:** API エンドポイントの実際の動作をテスト。テストデータベース使用
-
-- [ ] **ステップ 3:** E2E テストの作成
-  - **成果物:** `tests/e2e/user-registration.spec.ts`
-  - **詳細:** Playwright でユーザー登録→メール確認→ログインまでの流れをテスト
-
-- [ ] **ステップ 4:** ドキュメント更新
-  - **成果物:** `README.md`, `docs/tasks/task000001-{スラッグ}/a-definition.md`
-  - **詳細:** セットアップ手順、環境変数設定、API 仕様を記載
-
----
-
-## 受け入れ基準
-
-<!--
-受け入れ基準の記載ポイント:
-  - 機能が正しく動作すること（正常系）
-  - エラーハンドリングが適切に実装されていること（異常系）
-  - エッジケースが処理されること（境界値、特殊な入力）
-  - パフォーマンス要件を満たすこと（必要に応じて）
-  - セキュリティ要件を満たすこと（XSS, CSRF, SQL Injection など）
-  - ブラウザ互換性（必要に応じて）
-  - テストが全て通ること
-  - ドキュメントが更新されていること
-
-各フェーズの完了を判断するための具体的な基準を記載します。
-全ての基準を満たした時点でタスク完了とみなされます。
--->
-
-### フェーズ 1 の受け入れ基準
-
-- [ ] データベースマイグレーションが成功する
-- [ ] 型定義が正しく適用される（TypeScript コンパイルエラーなし）
-- [ ] メール送信 API がトークンを生成し、メールを送信する
-- [ ] 無効なトークンでアクセスした場合、エラーが返る
-- [ ] トークンの有効期限切れが正しく検出される
-
-### フェーズ 2 の受け入れ基準
-
-- [ ] メール認証ページが正しく表示される
-- [ ] 認証成功時に成功メッセージが表示される
-- [ ] 認証失敗時にエラーメッセージが表示される
-- [ ] 未認証ユーザーは保護されたページにアクセスできない
-- [ ] 認証済みユーザーは全ての機能にアクセスできる
-
-### フェーズ 3 の受け入れ基準
-
-- [ ] 全てのユニットテストが通る
-- [ ] 全ての統合テストが通る
-- [ ] E2E テストが通る（CI 環境でも実行）
-- [ ] テストカバレッジが 80% 以上
-- [ ] ドキュメントに記載された手順で環境構築できる
-
----
-
-## メモ
-
-<!--
-実装全体に関する補足情報
-
-記載すべき内容:
-  - 実装中に気づいた技術的な課題
-  - リファクタリングが必要な箇所
-  - パフォーマンス最適化の余地
-  - セキュリティ上の注意点
-  - 今後の拡張予定
-  - チームメンバーへの引き継ぎ事項
-
-例:
-- メール送信は現在同期処理だが、将来的にはジョブキューに移行予定
-- トークンの有効期限は現在 24 時間だが、設定ファイルで変更可能にする
-- SendGrid の API キーは環境変数で管理（.env.example に記載）
-- セキュリティレビュー完了（2025-01-15、レビュアー: @john）
--->
+# 実装タスクリスト
+
+<!--
+このドキュメントについて:
+  - 格納場所: docs/tasks/task000001-{スラッグ}/c-implementation.md
+  - 作成方法: /b-004-create-task-implementation スキルで作成
+  - 実行方法: /c-001-implement-task スキルで各ステップを実行
+  - 前提条件: a-definition.md と b-research.md が作成済みであること
+  - 関連ドキュメント:
+    - a-definition.md (タスク定義ドキュメント)
+    - b-research.md (リサーチドキュメント)
+
+このドキュメントの目的:
+  - 実装作業を段階的に分割して管理
+  - 進捗の可視化とチーム共有
+  - 各ステップの成果物を明確化
+  - 実装漏れの防止
+
+更新タイミング:
+  - 実装開始前にフェーズ分割を計画
+  - 各ステップ完了時にチェック（/c-001-implement-task が自動更新）
+  - 新たな作業が発覚した際に追加
+  - レビュー指摘事項を反映
+-->
+
+---
+
+## フェーズ 1: [フェーズ名]
+
+<!--
+フェーズの分け方:
+  - 機能単位で分割（例: フロントエンド → バックエンド → 統合）
+  - 依存関係で分割（例: データモデル → API → UI）
+  - リスクで分割（例: 検証 → 本実装 → 最適化）
+
+ベストプラクティス:
+  - 1フェーズは 1-3 日以内で完了できる粒度
+  - フェーズごとに動作確認可能な状態にする
+  - 各フェーズで小さくコミット・PR を作成（レビュー負荷軽減）
+-->
+
+**目的:** <!-- 例: データモデルと API エンドポイントの実装 -->
+
+**完了条件:** <!-- 例: API が期待通りのレスポンスを返し、ユニットテストが全て通る -->
+
+### ステップ
+
+<!--
+ステップの粒度:
+  - 1ステップは 1-3 時間程度で完了できる作業
+  - コミット単位で分割すると管理しやすい
+  - 成果物が明確であること（ファイル、機能、テスト）
+
+記載のポイント:
+  - 具体的なファイル名やコンポーネント名を含める
+  - 実装の詳細にはアルゴリズムや技術的な注意点を記載
+  - 依存関係があるステップは順序を意識
+-->
+
+- [ ] **ステップ 1:** データベーススキーマの定義
+  - **成果物:** `migrations/001_create_users_table.sql`
+  - **詳細:** User テーブルに `email_verified`, `verification_token`, `token_expires_at` を追加。インデックスは `verification_token` に作成
+
+- [ ] **ステップ 2:** TypeScript 型定義の追加
+  - **成果物:** `src/types/User.ts`
+  - **詳細:** `User` インターフェースに新しいフィールドを追加。Zod スキーマも同時に定義
+
+- [ ] **ステップ 3:** メール送信 API エンドポイントの実装
+  - **成果物:** `src/api/auth/send-verification.ts`
+  - **詳細:** トークン生成（UUID v4）、有効期限 24 時間、SendGrid API 呼び出し。エラーハンドリング実装
+
+- [ ] **ステップ 4:** メール認証 API エンドポイントの実装
+  - **成果物:** `src/api/auth/verify-email.ts`
+  - **詳細:** トークン検証、有効期限チェック、ユーザーステータス更新。無効トークンは 400 エラー
+
+---
+
+## フェーズ 2: [フェーズ名]
+
+**目的:** <!-- 例: フロントエンド UI の実装とユーザーフロー統合 -->
+
+**完了条件:** <!-- 例: ユーザー登録から認証完了までの一連の流れが動作し、E2E テストが通る -->
+
+### ステップ
+
+- [ ] **ステップ 1:** メール認証ページの作成
+  - **成果物:** `src/pages/EmailVerificationPage.tsx`
+  - **詳細:** URL パラメータからトークンを取得、API 呼び出し、成功/失敗メッセージ表示
+
+- [ ] **ステップ 2:** ユーザー登録フォームにメール送信処理を追加
+  - **成果物:** `src/features/auth/RegisterForm.tsx` を更新
+  - **詳細:** 登録成功後にメール送信 API を呼び出し、「確認メールを送信しました」メッセージを表示
+
+- [ ] **ステップ 3:** 認証状態のガード実装
+  - **成果物:** `src/middleware/requireEmailVerified.ts`
+  - **詳細:** 未認証ユーザーは特定ページにアクセス不可。リダイレクト処理を実装
+
+---
+
+## フェーズ 3: テスト・ドキュメント
+
+<!--
+テストフェーズの重要性:
+  - 実装と同時にテストを書くことでバグを早期発見
+  - テストコードは仕様書の役割も果たす
+  - リグレッション防止（今後の変更で既存機能が壊れない）
+
+記載すべきテスト:
+  - ユニットテスト（関数、コンポーネント単位）
+  - 統合テスト（API、データベース連携）
+  - E2E テスト（ユーザーフロー全体）
+  - エッジケーステスト（異常系、境界値）
+-->
+
+**目的:** <!-- 例: テストコード作成とドキュメント整備 -->
+
+**完了条件:** <!-- 例: テストカバレッジ 80% 以上、README にセットアップ手順を記載 -->
+
+### ステップ
+
+- [ ] **ステップ 1:** ユニットテストの作成
+  - **成果物:** `src/api/auth/send-verification.test.ts`, `verify-email.test.ts`
+  - **詳細:** トークン生成、有効期限検証、エラーハンドリングのテスト。モックを使用
+
+- [ ] **ステップ 2:** 統合テストの作成
+  - **成果物:** `tests/integration/email-verification.test.ts`
+  - **詳細:** API エンドポイントの実際の動作をテスト。テストデータベース使用
+
+- [ ] **ステップ 3:** E2E テストの作成
+  - **成果物:** `tests/e2e/user-registration.spec.ts`
+  - **詳細:** Playwright でユーザー登録→メール確認→ログインまでの流れをテスト
+
+- [ ] **ステップ 4:** ドキュメント更新
+  - **成果物:** `README.md`, `docs/tasks/task000001-{スラッグ}/a-definition.md`
+  - **詳細:** セットアップ手順、環境変数設定、API 仕様を記載
+
+---
+
+## 受け入れ基準
+
+<!--
+受け入れ基準の記載ポイント:
+  - 機能が正しく動作すること（正常系）
+  - エラーハンドリングが適切に実装されていること（異常系）
+  - エッジケースが処理されること（境界値、特殊な入力）
+  - パフォーマンス要件を満たすこと（必要に応じて）
+  - セキュリティ要件を満たすこと（XSS, CSRF, SQL Injection など）
+  - ブラウザ互換性（必要に応じて）
+  - テストが全て通ること
+  - ドキュメントが更新されていること
+
+各フェーズの完了を判断するための具体的な基準を記載します。
+全ての基準を満たした時点でタスク完了とみなされます。
+-->
+
+### フェーズ 1 の受け入れ基準
+
+- [ ] データベースマイグレーションが成功する
+- [ ] 型定義が正しく適用される（TypeScript コンパイルエラーなし）
+- [ ] メール送信 API がトークンを生成し、メールを送信する
+- [ ] 無効なトークンでアクセスした場合、エラーが返る
+- [ ] トークンの有効期限切れが正しく検出される
+
+### フェーズ 2 の受け入れ基準
+
+- [ ] メール認証ページが正しく表示される
+- [ ] 認証成功時に成功メッセージが表示される
+- [ ] 認証失敗時にエラーメッセージが表示される
+- [ ] 未認証ユーザーは保護されたページにアクセスできない
+- [ ] 認証済みユーザーは全ての機能にアクセスできる
+
+### フェーズ 3 の受け入れ基準
+
+- [ ] 全てのユニットテストが通る
+- [ ] 全ての統合テストが通る
+- [ ] E2E テストが通る（CI 環境でも実行）
+- [ ] テストカバレッジが 80% 以上
+- [ ] ドキュメントに記載された手順で環境構築できる
+
+---
+
+## メモ
+
+<!--
+実装全体に関する補足情報
+
+記載すべき内容:
+  - 実装中に気づいた技術的な課題
+  - リファクタリングが必要な箇所
+  - パフォーマンス最適化の余地
+  - セキュリティ上の注意点
+  - 今後の拡張予定
+  - チームメンバーへの引き継ぎ事項
+
+例:
+- メール送信は現在同期処理だが、将来的にはジョブキューに移行予定
+- トークンの有効期限は現在 24 時間だが、設定ファイルで変更可能にする
+- SendGrid の API キーは環境変数で管理（.env.example に記載）
+- セキュリティレビュー完了（2025-01-15、レビュアー: @john）
+-->

package/templates/project/01-requirements/01-system-overview.md

@@ -1,49 +0,0 @@
-# システム概要
-
-## 背景
-
-<!--
-何を書くか: このシステムで解決しようとしている問題を記述
-
-文量: 2-4文程度（100-200文字）
-トーン: 客観的で事実ベース。感情的な表現は避ける
-必須情報:
-  - 現在直面している具体的な問題や課題
-  - なぜその問題が重要なのか
-  - 問題の影響を受けるステークホルダー
-
-ベストプラクティス:
-  - 具体的な数値やデータがあれば含める（例: 「3ヶ月かかる」「70%が離脱」）
-  - 「〜できない」「〜が困難」など問題を明確に表現
-  - 誰が・いつ・どこで困っているかを具体的に示す
-  - 現状の workaround や代替手段があればそれも言及
-  - 抽象的な表現（「効率が悪い」）より具体的な表現（「手動で2時間かかる作業」）を使う
--->
-
-**例:**
-新入社員が既存社員とコミュニケーションを取る機会が限られており、チームに溶け込むまでに時間がかかる。また、リモートワークの増加により、雑談や自然な関係構築の場が減少している。
-
----
-
-## 目的
-
-<!--
-何を書くか: このシステムが提供する価値や解決策を記述
-
-文量: 2-4文程度（100-200文字）
-トーン: ポジティブで具体的。実現可能な内容に留める
-必須情報:
-  - システムがどのように問題を解決するか
-  - ユーザーや組織が得られる具体的な価値
-  - 期待される成果や変化
-
-ベストプラクティス:
-  - 「〜を可能にする」「〜を支援する」など能動的な表現を使う
-  - 技術的な詳細（「React使用」）よりもビジネス価値（「開発速度2倍」）に焦点を当てる
-  - 測定可能な成果があれば言及する（例: 「作業時間を50%削減」「離脱率を20%改善」）
-  - どのように問題を解決するか、具体的なメカニズムを簡潔に示す
-  - ユーザーにとっての before/after が想像できる表現を使う
--->
-
-**例:**
-社員がライフラインチャートを通じて自己紹介し、共通点を見つけやすくすることで、組織横断のコミュニケーションを活性化する。コメント機能により双方向の対話を促進し、早期の関係構築を支援する。

package/templates/project/01-requirements/03-features-planned.md

@@ -1,75 +0,0 @@
-# 未実装機能一覧
-
-<!--
-何を書くか: 今後実装を検討・予定している機能のリスト
-
-目的:
-  - プロダクトのロードマップや将来ビジョンを可視化
-  - ステークホルダーとの期待値調整
-  - 技術的負債や機能gap の把握
-  - 実装優先度の議論のベース資料
-
-特徴:
-  - 機能IDなし: まだ確定していないため識別子は不要
-  - 優先度なし: 優先度は常に変動し混乱を招くため記載しない
-  - 柔軟性重視: アイデア段階の機能も含めて良い
-
-記載粒度: 実装済み機能一覧と同程度（ユーザーが認識できる機能単位）
-
-更新頻度:
-  - 機能を実装したら「実装済み機能一覧」に移動し、こちらから削除
-  - 新しいアイデアや要望が出たら随時追加
-  - 四半期ごとなど定期的に見直し、不要な機能は削除
--->
-
-<!--
-テーブル構成:
-
-【Category 1】（大分類）
-  - 実装済み機能一覧と同じカテゴリ体系を使用
-  - 既存カテゴリに当てはまらない場合は新カテゴリを追加
-  - 例: ユーザー管理、コンテンツ、決済、通知、分析
-
-【Category 2】（中分類）
-  - 実装済み機能一覧と同じカテゴリ体系を使用
-  - より具体的な機能領域で分類
-  - 例: ユーザー管理 → 認証、プロフィール、権限
-
-【機能名】
-  - 簡潔で分かりやすい名称（2-5単語程度）
-  - ユーザー視点の表現を使う
-  - まだ確定していなくても仮の名称で記載OK
-  - 例: 「二段階認証」「下書き保存」「AIレコメンド」
-
-【説明】
-  - 1-2文で機能の内容を記述（50-100文字程度）
-  - 何を実現したいか（目的）を中心に記述
-  - 「〜したい」「〜できるようにする」など意図が伝わる表現
-  - 実装方法が未定でもユーザー価値を記述
-
-ベストプラクティス:
-  - 実装の難易度や工数は記載しない（別途見積もりで管理）
-  - 「いつか実装したい」程度のアイデアも含めて良い（柔軟に）
-  - 競合製品の機能を参考にする場合は、自社プロダクトでの意義を明確に
-  - カテゴリ分類により、特定領域の機能が不足していないか確認できる
-  - 定期的に見直し、実装しない判断をした機能は削除（理由はGitコミットメッセージに残す）
-  - 技術的な表現（「WebSocket実装」）より価値の表現（「リアルタイム通知」）を優先
--->
-
-| Category 1 | Category 2 | 機能名 | 説明 |
-|-----------|-----------|--------|------|
-| <!-- カテゴリ1 --> | <!-- カテゴリ2 --> | <!-- 機能名 --> | <!-- 簡潔な説明 --> |
-
----
-
-**例:**
-
-| Category 1 | Category 2 | 機能名 | 説明 |
-|-----------|-----------|--------|------|
-| ユーザー管理 | 認証 | 二段階認証 | SMS/アプリでの二段階認証 |
-| ユーザー管理 | 認証 | ソーシャルログイン | Google/GitHubアカウントでログイン |
-| ユーザー管理 | プロフィール | バッジシステム | 実績に応じたバッジ表示 |
-| コンテンツ | 投稿 | 下書き保存 | 記事の下書き保存機能 |
-| コンテンツ | 投稿 | 予約投稿 | 指定日時での自動投稿 |
-| コンテンツ | コメント | 返信機能 | コメントへの返信スレッド |
-| コンテンツ | コメント | いいね機能 | コメントへのいいね |