yodogawa 1.0.0

package/.windsurf/workflows/b-005-ReviewTask.md

@@ -0,0 +1,312 @@
+---
+description: 
+auto_execution_mode: 1
+---
+
+# ReviewTask (b-005)
+
+## 目的
+
+- `a-definition.md` / `b-research.md` / `c-implementation.md` の整合性を確認し、実装前にリスクを洗い出す。
+- ユーザーストーリーや受け入れ基準が実装計画に反映されているかを検証する。
+- レビュー結果をレポート化し、修正アクションと実装可否を明確にする。
+
+## 前提
+
+- `docs/tasks/task{ID}-{SLUG}/` が存在し、a/b/c 各ドキュメントが作成済み。
+- レビュー結果を記録するレポート: `docs/tasks/task{ID}-{SLUG}/TASK-REVIEW-REPORT.md`
+
+## 手順
+
+### 1. 対象タスクの確認
+
+```bash
+ls -d docs/tasks/task*
+```
+
+- レビュー対象のタスクIDとスラッグを特定。
+- 不足ドキュメントがあれば該当ワークフロー(b-002/b-003/b-004)に差し戻す。
+
+### 2. 各ドキュメントの読み込み
+
+- `a-definition.md`: 目的/ユーザーストーリー/変更内容/受け入れ基準
+- `b-research.md`: ベストプラクティス/再利用コード/技術選定/リスク
+- `c-implementation.md`: フェーズ/ステップ/成果物/テスト計画
+
+### 3. 一貫性チェック
+
+| # | 観点 | チェック内容 |
+|---|------|--------------|
+|1|定義 ↔ 実装（変更内容）|全ての変更点に対応するステップあるか／スコープ外作業がないか|
+|2|定義 ↔ 実装（ユーザーストーリー）|各ユーザーストーリーを満たすステップが存在するか|
+|3|定義 ↔ 実装（受け入れ基準）|ステップ完了で受け入れ基準を満たせるか／基準が具体的か|
+|4|リサーチ ↔ 実装|選定した技術/リスク対策が計画に反映されているか|
+|5|実装計画の完全性|フェーズ順序・ステップ粒度・テスト計画が適切か|
+|6|タスク全体の実現性|目的/スコープ/依存関係/期間が妥当か|
+
+チェックの際は `OK / Warning / Error` を付与し、根拠をメモする。
+
+### 4. レポート作成
+
+`docs/tasks/task{ID}-{SLUG}/TASK-REVIEW-REPORT.md` に以下を記入：
+
+```markdown
+# タスクレビュー結果: task{ID}-{SLUG}
+**実施日**: YYYY-MM-DD
+
+## 判定
+- 総合評価: [OK / Conditional OK / NG]
+- 実装開始可否: [可 / 要修正]
+
+## 詳細
+- 定義 ↔ 実装（変更内容）: [OK/Warn/Error] – コメント
+- 定義 ↔ 実装（ユーザーストーリー）: ...
+- リサーチ ↔ 実装: ...
+- 実装計画の完全性: ...
+- タスク全体の実現性: ...
+
+## 修正が必要な項目
+1. **カテゴリ**: ...
+   - 詳細 / 推奨対応 / 影響
+
+## 所見
+- 強み:
+- 改善点:
+- 推奨事項:
+```
+
+### 5. Git への追加（任意）
+
+```bash
+git add docs/tasks/task{ID}-{SLUG}/TASK-REVIEW-REPORT.md
+git commit -m "docs(task): レビューレポート作成 task{ID}"
+```
+
+## 完了条件
+
+- 全観点に対して判定とコメントが記載されている。
+- 修正事項がカテゴリ別・優先度付きで整理されている。
+- 実装可否が明記され、関係者に共有済み。
+
+## エスカレーション
+
+- **Error 多発**: 「致命的な不整合が複数あります。タスクドキュメント全体の再検討が必要です。」
+- **目的未達**: 「現在の実装計画では目的を達成できません。定義や計画を更新してください。」
+- **リスク未対策**: 「リサーチで検出されたリスクが計画に反映されていません。対策を追加してください。」
+- **テスト不足**: 「テスト計画が不十分です。ユニット/統合/E2Eを補完してください。」
+- **スコープ過大**: 「フェーズ/ステップ数が多すぎます。タスク分割を検討してください。」
+
+### 4. 一貫性チェック1: タスク定義 ↔ 実装計画（変更内容のカバレッジ）
+
+#### 4.1. 変更内容と実装ステップのマッピング
+
+- タスク定義（a-definition.md）の「変更内容一覧」を抽出：
+  - 画面（追加・変更する画面やコンポーネント）
+  - データモデル（テーブル、カラムの追加・変更）
+  - API（エンドポイントの追加・変更）
+  - その他（環境設定、インフラ、ツール）
+
+- 実装計画（c-implementation.md）の各ステップと成果物を抽出
+
+- 各変更内容に対応する実装ステップが存在するか確認
+
+**チェック項目**:
+- [ ] すべての画面変更に対応する実装ステップが存在する
+- [ ] すべてのデータモデル変更に対応する実装ステップが存在する
+- [ ] すべてのAPI変更に対応する実装ステップが存在する
+- [ ] その他の変更（環境設定など）に対応する実装ステップが存在する
+
+**検出すべき問題**:
+- ❌ **Error**: タスク定義で言及された変更に対応する実装ステップがない
+- ⚠️ **Warning**: 実装計画で定義されているステップがタスク定義の変更内容に含まれていない（スコープ外の作業の可能性）
+
+#### 4.2. 成果物の具体性チェック
+
+- 実装計画の各ステップの成果物を確認
+- 成果物が具体的なファイル名・コンポーネント名で記載されているか確認
+
+**検出すべき問題**:
+- ⚠️ **Warning**: 成果物が抽象的すぎる（例: 「フォームの実装」→ 具体的なファイル名が必要）
+- ⚠️ **Warning**: 成果物が記載されていないステップがある
+
+### 5. 一貫性チェック2: タスク定義 ↔ 実装計画（ユーザーストーリーのカバレッジ）
+
+#### 5.1. ユーザーストーリーと実装ステップの対応
+
+- タスク定義（a-definition.md）のユーザーストーリー一覧を抽出
+- 各ユーザーストーリーについて、実現するための実装ステップが存在するか確認
+
+**チェック項目**:
+- [ ] すべてのユーザーストーリーに対応する実装ステップが存在する
+- [ ] ユーザーストーリーの「何をしたい（目的）」が実装で実現されている
+
+**検出すべき問題**:
+- ❌ **Error**: ユーザーストーリーに対応する実装ステップがない
+```markdown
+# タスクレビュー結果: task{ID}-{SLUG}
+**実施日**: YYYY-MM-DD
+
+## 判定
+- 総合評価: [OK / Conditional OK / NG]
+- 実装開始可否: [可 / 要修正]
+
+## 詳細チェック
+1. **定義 ↔ 実装**:
+   - 画面変更は全てステップに含まれています。
+   - **Error**: APIエンドポイント `POST /api/verify` の実装ステップが漏れています。
+
+2. **リサーチ ↔ 実装**:
+   - **Warning**: リスクとして挙げられた「メール送信遅延」への対策が計画に見当たりません。
+
+3. **計画の完全性**:
+   - ステップの粒度は適切です。
+
+## 推奨アクション
+1. `c-implementation.md` にAPI実装ステップを追加する。
+2. メール送信処理を非同期キューに入れる設計を計画に追加する。
+### 7. 実装計画の完全性
+- フェーズ分割妥当性: [評価]
+- ステップ粒度: [評価]
+- テスト計画包括性: [評価]
+- 検出された問題: X件
+
+### 8. タスク全体の実現可能性
+- 目的との整合性: [評価]
+- スコープの適切性: [評価]
+- 依存関係の明示: [評価]
+- 検出された問題: X件
+
+## 次のアクション
+
+1. [最優先で修正すべき項目]
+2. [次に修正すべき項目]
+3. [余裕があれば修正する項目]
+
+## レビュー所見
+
+### 強み
+[このタスクドキュメントの優れている点]
+
+### 改善点
+[改善すべき点、懸念事項]
+
+### 推奨事項
+[実装開始前に対応すべき事項]
+
+## 備考
+
+[追加のコメント、質問事項など]
+```
+
+### 13. レビュー結果の保存
+
+- レビュー結果を `docs/tasks/task{id}-{スラッグ}/TASK-REVIEW-REPORT.md` として保存
+
+- ユーザーに結果を報告：
+  - 「タスクレビューが完了しました。」
+  - Error件数、Warning件数を表示
+  - 総合評価を表示
+  - 「詳細は `docs/tasks/task{id}-{スラッグ}/TASK-REVIEW-REPORT.md` を参照してください。」
+
+### 14. 修正ガイダンス
+
+- 検出された問題について、修正方法を提案：
+  - Errorが検出された場合：「以下の問題を優先的に修正してください：」
+  - 修正すべきドキュメントとワークフローを案内：
+    - 例：「ユーザーストーリーUS-002に対応する実装ステップがありません → `/b-003-CreateTaskImplementation` で実装計画を更新」
+    - 例：「受け入れ基準が一致していません → `/b-001-CreateTaskDefinition` でタスク定義を見直し」
+
+- ユーザーに確認：「今すぐ修正作業を開始しますか？それとも後で個別に修正しますか？」
+
+### 15. 実装開始可否の判定
+
+**総合評価の基準**:
+- **優（実装開始OK）**: Error 0件、Warning 3件以下
+- **良（軽微な修正後に実装開始）**: Error 0件、Warning 4-10件
+- **可（修正後に実装開始）**: Error 1-3件、または Warning 11件以上
+- **不可（大幅な見直しが必要）**: Error 4件以上
+
+**推奨アクション**:
+- 総合評価が「優」「良」の場合：「実装開始可能です。`/c-001-ImplementTask` を実行してください。」
+- 総合評価が「可」の場合：「Error を修正後、実装を開始してください。」
+- 総合評価が「不可」の場合：「タスクドキュメント全体の見直しが必要です。チームでレビュー会議を実施することを推奨します。」
+
+## 完了条件
+
+- すべてのチェック項目が実行されている
+- タスクレビュー結果レポート（`TASK-REVIEW-REPORT.md`）が作成されている
+- 検出された問題がカテゴリ別・優先度別に整理されている
+- 各問題に具体的な修正提案が含まれている
+- 総合評価と実装開始可否の判定が記載されている
+- ユーザーにレビュー結果が報告されている
+
+## エスカレーション
+
+- 重大な不整合が多数検出された場合（Error 4件以上）：
+  - 「重大な不整合が多数検出されました（Error: X件）。タスクドキュメント全体の見直しが必要です。」
+  - 「チームレビュー会議を開催し、タスクの再定義を検討してください。」
+
+- タスクの目的が実装計画で達成できない場合：
+  - 「実装計画がタスクの目的を達成できません。」
+  - 「タスクの再定義（`/b-001`）または実装計画の再作成（`/b-003`）が必要です。」
+
+- 技術的リスクの軽減策が不足している場合：
+  - 「技術的リスクの軽減策が実装計画に含まれていません（X件）。」
+  - 「リスクの高い項目から順に軽減策を検討し、実装計画に追加してください。」
+
+- テスト計画が不足している場合：
+  - 「テスト計画が不足しています。」
+  - 「ユニットテスト、統合テスト、E2Eテストを含む包括的なテスト計画を作成してください。」
+
+- タスクのスコープが大きすぎる場合：
+  - 「タスクのスコープが大きすぎます（フェーズ数: X、ステップ数: Y）。」
+  - 「タスクを複数の小さなタスクに分割することを推奨します。」
+
+## ベストプラクティス
+
+- **実装開始前に必ず実行**: c-001 実行前に b-004 でレビューし、問題を早期発見
+- **段階的レビュー**: b-001完了後、b-002完了後、b-003完了後の各段階で部分レビューを実施
+- **チームレビュー**: 重要なタスクや大規模なタスクはチーム全体でレビュー会議を実施
+- **継続的更新**: 実装中に新しい発見があれば、ドキュメントを更新し、再レビュー
+- **メトリクス記録**: レビュー結果（Error数、Warning数）を記録し、タスク品質を追跡
+- **フィードバックループ**: レビュー結果を基にテンプレートや次のタスクを改善
+
+## 参考: レビュー対象ドキュメント構造
+
+**a-definition.md（タスク定義）**:
+- 目的（解決する問題、提供する価値）
+- ユーザーストーリー一覧
+- 変更内容一覧（画面、データモデル、API、その他）
+- 受け入れ基準
+
+**b-research.md（リサーチ）**:
+- ベストプラクティス
+- 既存コードの調査
+- 再利用可能なコンポーネント
+- 技術選定
+- 技術的リスクと制約
+
+**c-implementation.md（実装計画）**:
+- フェーズ（目的、完了条件）
+- ステップ（成果物、詳細）
+- 受け入れ基準
+
+## 参考: タスクライフサイクルにおける位置づけ
+
+```
+b-000: タスクディレクトリ作成
+  ↓
+b-001: タスク定義作成
+  ↓
+b-002: リサーチ実施
+  ↓
+b-003: 実装計画作成
+  ↓
+b-004: タスクレビュー ← このワークフロー
+  ↓
+c-001: 実装実行
+  ↓
+c-002: ドキュメント更新
+```
+
+b-004は実装開始前の「最後の砦」として、タスクの品質と実現可能性を保証する重要な役割を果たします。