タスク: [機能名]
入力: /specs/[###-feature-name]/ からの設計ドキュメント
前提条件: plan.md（必須）、spec.md（ユーザーストーリーに必須）、research.md、data-model.md、contracts/
テスト: 以下の例にはテストタスクが含まれています。テストはオプションです - 機能仕様で明示的に要求された場合のみ含めてください。
構成: タスクはユーザーストーリーごとにグループ化され、各ストーリーの独立した実装とテストを可能にします。
フォーマット: [ID] [P?] [Story] 説明
- [P]: 並列実行可能（異なるファイル、依存関係なし）
- [Story]: このタスクが属するユーザーストーリー（例: US1、US2、US3）
- 説明には正確なファイルパスを含める
パス規約
- 単一プロジェクト: リポジトリルートに
src/、tests/
- Web アプリ:
backend/src/、frontend/src/
- モバイル:
api/src/、ios/src/ または android/src/
- 以下に示すパスは単一プロジェクトを想定 - plan.md の構造に基づいて調整
フェーズ 1: セットアップ（共有インフラストラクチャ）
目的: プロジェクトの初期化と基本構造
フェーズ 2: 基礎（必須の前提条件）
目的: いかなるユーザーストーリーも実装できる前に完了する必要があるコアインフラストラクチャ
⚠️ 重要: このフェーズが完了するまで、ユーザーストーリーの作業は開始できません
基礎タスクの例（プロジェクトに基づいて調整）:
チェックポイント: 基礎準備完了 - ユーザーストーリーの実装を並列で開始できます
フェーズ 3: ユーザーストーリー 1 - [タイトル] (優先度: P1) 🎯 MVP
目標: [このストーリーが提供するものの簡潔な説明]
独立したテスト: [このストーリーを単独で検証する方法]
ユーザーストーリー 1 のテスト（オプション - テストが要求された場合のみ）⚠️
注意: これらのテストを最初に書き、実装前に失敗することを確認してください
ユーザーストーリー 1 の実装
チェックポイント: この時点で、ユーザーストーリー 1 は完全に機能し、独立してテスト可能であるべきです
フェーズ 4: ユーザーストーリー 2 - [タイトル] (優先度: P2)
目標: [このストーリーが提供するものの簡潔な説明]
独立したテスト: [このストーリーを単独で検証する方法]
ユーザーストーリー 2 のテスト（オプション - テストが要求された場合のみ）⚠️
ユーザーストーリー 2 の実装
チェックポイント: この時点で、ユーザーストーリー 1 と 2 の両方が独立して機能するべきです
フェーズ 5: ユーザーストーリー 3 - [タイトル] (優先度: P3)
目標: [このストーリーが提供するものの簡潔な説明]
独立したテスト: [このストーリーを単独で検証する方法]
ユーザーストーリー 3 のテスト（オプション - テストが要求された場合のみ）⚠️
ユーザーストーリー 3 の実装
チェックポイント: すべてのユーザーストーリーが独立して機能するようになりました
[必要に応じて、同じパターンでユーザーストーリーフェーズを追加]
フェーズ N: 仕上げと横断的関心事
目的: 複数のユーザーストーリーに影響する改善
依存関係と実行順序
フェーズの依存関係
- セットアップ（フェーズ 1）: 依存関係なし - すぐに開始できます
- 基礎（フェーズ 2）: セットアップ完了に依存 - すべてのユーザーストーリーをブロックします
- ユーザーストーリー（フェーズ 3+）: すべて基礎フェーズ完了に依存
- その後、ユーザーストーリーは並列で進行可能（人員がいる場合）
- または優先度順に順次進行（P1 → P2 → P3）
- 仕上げ（最終フェーズ）: 希望するすべてのユーザーストーリーが完了していることに依存
ユーザーストーリーの依存関係
- ユーザーストーリー 1（P1）: 基礎（フェーズ 2）後に開始可能 - 他のストーリーへの依存関係なし
- ユーザーストーリー 2（P2）: 基礎（フェーズ 2）後に開始可能 - US1 と統合する可能性があるが、独立してテスト可能であるべき
- ユーザーストーリー 3（P3）: 基礎（フェーズ 2）後に開始可能 - US1/US2 と統合する可能性があるが、独立してテスト可能であるべき
各ユーザーストーリー内
- テスト（含まれる場合）は実装前に書き、失敗することを確認する必要があります
- サービスの前にモデル
- エンドポイントの前にサービス
- 統合の前にコア実装
- 次の優先度に移る前にストーリー完了
並列実行の機会
- [P] でマークされたすべてのセットアップタスクは並列実行可能
- フェーズ 2 内のすべての基礎タスク [P] は並列実行可能
- 基礎フェーズが完了すると、すべてのユーザーストーリーが並列で開始可能（チーム容量が許す場合）
- ユーザーストーリーのすべてのテスト [P] は並列実行可能
- ストーリー内のモデル [P] は並列実行可能
- 異なるユーザーストーリーは異なるチームメンバーによって並列作業可能
並列実行の例: ユーザーストーリー 1
# ユーザーストーリー 1 のすべてのテストを一緒に起動（テストが要求された場合）:
Task: "tests/contract/test_[name].py で [エンドポイント] の契約テスト"
Task: "tests/integration/test_[name].py で [ユーザージャーニー] の統合テスト"
# ユーザーストーリー 1 のすべてのモデルを一緒に起動:
Task: "src/models/[entity1].py に [Entity1] モデルを作成"
Task: "src/models/[entity2].py に [Entity2] モデルを作成"
実装戦略
MVP ファースト（ユーザーストーリー 1 のみ）
- フェーズ 1 完了: セットアップ
- フェーズ 2 完了: 基礎（重要 - すべてのストーリーをブロック）
- フェーズ 3 完了: ユーザーストーリー 1
- 停止して検証: ユーザーストーリー 1 を独立してテスト
- 準備ができたらデプロイ/デモ
段階的デリバリー
- セットアップ + 基礎完了 → 基礎準備完了
- ユーザーストーリー 1 追加 → 独立してテスト → デプロイ/デモ（MVP!）
- ユーザーストーリー 2 追加 → 独立してテスト → デプロイ/デモ
- ユーザーストーリー 3 追加 → 独立してテスト → デプロイ/デモ
- 各ストーリーは以前のストーリーを壊すことなく価値を追加
並列チーム戦略
複数の開発者がいる場合:
- チームで一緒にセットアップ + 基礎を完了
- 基礎が完了したら:
- 開発者 A: ユーザーストーリー 1
- 開発者 B: ユーザーストーリー 2
- 開発者 C: ユーザーストーリー 3
- ストーリーは独立して完了し、統合
注意事項
- [P] タスク = 異なるファイル、依存関係なし
- [Story] ラベルはタスクを特定のユーザーストーリーにマッピングしてトレーサビリティを確保
- 各ユーザーストーリーは独立して完了およびテスト可能であるべき
- 実装前にテストが失敗することを確認
- 各タスクまたは論理グループの後にコミット
- 任意のチェックポイントで停止してストーリーを独立して検証
- 避けるべき: 曖昧なタスク、同じファイルの競合、独立性を壊すストーリー間の依存関係