プランニング — アプリアーキテクチャと実装計画

スコープ評価

種類	入力	プランニングスコープ
アイデア → アプリ	ストアカード	完全 (画面 + データ + フェーズ)
新機能	機能説明	機能スコープのみ
リファクタリング	対象コード	変更スコープ + マイグレーション

画面設計

画面とルート (Expo Router)

• ファイルベースのルーティング: app/(tabs)/, app/(modals)/
• 1つのルートファイルあたり1つの画面
• ネストされたレイアウトを活用

UIパターン選択 (Apple HIG基準)

各画面のナビゲーション、レイアウト、コアコンポーネントを決定します:

パターン	ユースケース
プッシュナビゲーション	階層的なブラウジング (リスト → 詳細)
モーダル / ボトムシート	一時的なタスク、作成
タブバー	トップレベルのセクション切り替え
スクロール + セクション	長いコンテンツ、ダッシュボード
フラットリスト	同質のアイテムリスト
グリッド	ビジュアル中心のコンテンツ
フォーム	入力収集

データモデル

Supabaseデザイン原則

• テーブル数を最小化。正規化よりも実用性を重視。
• RLS (Row Level Security) は必須: auth.uid() = user_id
• 共通パターン: user_id, created_at, updated_at

フェーズ分離

優先順位基準

1. 依存関係 (他の機能がこれを必要とするか?)
2. コア体験 (P0 — これなしではアプリではない)
3. 体験の向上 (P1 — あるとより良い)
4. 品質ポリッシュ (P2 — 基本品質)

コマンド推奨事項

タスクタイプ	推奨コマンド
すべての実装 (ロジック、UI、インタラクション)	/develop
ステップ完了	/checkpoint

フェーズフォーマット

### フェーズ 1: コア (P0)
- [ ] タスク (ファイル: パス)
- [ ] (TDD) タスク (ファイル: パス)         ← ビジネスロジック

### フェーズ 2: インタラクション (P1)
- [ ] タスク (ファイル: パス)

### フェーズ 3: ポリッシュ (P2)
- [ ] タスク (ファイル: パス)

(TDD) 基準: ビジネスロジック (データ処理、状態管理、ユーティリティ、バリデーション) 付けない: UIレンダリング、インタラクション、アニメーション、ナビゲーション

チェックボックスルール:

• /develop はタスク完了時に - [x] をマーク
• 引数なしで /develop を実行すると、最初の - [ ] タスクが自動選択されます

リスク評価

種類	質問
技術的	初めて使うライブラリ/APIはあるか?
パフォーマンス	アニメーションが多い画面はあるか?
スコープ	時間が短い場合、最初に削減できるものは何か?

成果物フォーマット

/architect が生成するドキュメント。pipeline.md のアーティファクト契約に従う。

PRD.md

# [名前]

## コア体験
## メタファー
## 画面リスト
| 画面 | ルート | 優先順位 |
## アーキテクチャ
## データモデル
## マネタイゼーション
## Fidelity Map
## 完了基準
## Non-Goals
## 依存関係

ドメイン CLAUDE.md (src/features/[domain]/CLAUDE.md)

# [ドメイン名]

## 役割
## コンポーネント
- 既存 (taste-kit): [ワイヤーフレームの data-component から抽出]
- 新規: [ComponentName — 用途]
## 機能仕様
[ユーザー行動 → 結果]
## タスク
- [ ] [行動] — [成果物]
- [ ] (TDD) [行動] — [成果物]
## 注意事項

原則

• 高速出荷、フィードバックで反復
• コア機能を最初に、インタラクションレイヤーを次に
• 1ファイル1コンポーネント、最大200行
• 各フェーズをテスト可能なユニットに分割