OpenSpec追加戦略

openspec_strategy.md

スプリント工程とOpenSpec Phaseの対応

スプリント工程	OpenSpec Phase	備考
プランニング	-	OpenSpec以前（やるPBIを決める）
設計	Proposal	proposal.md, design.md, spec.md delta
テスト設計	Proposal	Scenarioがテスト項目の元になる
実装	Apply	tasks.mdに沿って実装
テスト	Apply後〜Archive前	NG→changes/のまま仕様修正
受入	Apply後〜Archive前	同上
完了処理	Archive	spec反映、ドキュメント更新

PR構成

PR1: Proposal（設計 + テスト設計）
PR2~N: Apply（実装、tasks.mdのセクション単位で分割）
  ↓ テスト・受入
PR: Archive（完了処理）

tasks.mdのPR分割戦略

proposalの段階でPR境界を決めておく。

## PR分割戦略
- PR1: Backend層（タスク1-2）→ API+ViewModelが動く状態
- PR2: Frontend層（タスク3-4）→ 画面に表示される状態  
- PR3: 仕上げ（タスク5-7）→ 完成

## PR1: Backend
- [ ] 1.1 API実装
- [ ] 1.2 ViewModel実装

## PR2: Frontend
- [ ] 2.1 UI実装
- [ ] 2.2 フォーマット

## PR3: 仕上げ
- [ ] 3.1 エラーハンドリング
- [ ] 3.2 ドキュメント

モバイルチームの相互レビュー

ファイル	相互レビュー	理由
spec.md	✅ 見る	仕様。iOS/Androidで同じ挙動になるべき部分
proposal.md	✅ 見る	なぜ・何を・影響範囲。意図の共有
tasks.md	❌ 不要	実装タスク。プラットフォーム固有
design.md	△ 場合による	技術判断。API設計など共通部分あれば見る

レビュー観点

• Scenarioが同じ挙動を示しているか
• エッジケースの扱いが揃っているか
• サーバーAPIの解釈がずれてないか

tasks.mdは「Kotlinでこう書く」「Swiftでこう書く」の話なので、相手に見せても意味薄い