設計指針を固め、全体の設計を進めるために、全体の俯瞰と細かいディテールを往復している。

---

`TODO.md`、`tickets/`はgitで管理されていて、時系列の管理はgitを参照して把握すること。

### TODO.md

- 1チケット = 1行。未完了のみ記載し、完了したら行ごと削除する（履歴はgitで追える）
- ネストは同一領域のグルーピング（表示用）にのみ使う。実装上の依存関係はネストで表現しない
- 完了した子は削除し、親は未完了の子がある限り残す。最後の子が完了したら親ごと削除
- Ticketを追加する際は、合わせてTODOも書くこと

### Ticket の粒度

- 1チケット = 完了時点で、実装が仕様又は機能として説明できる粒度。
- 作成時、背景や要件を前提として書き、実装の方針やコードの詳細は不必要に増やさない。
- チケット内のステップ（Phase 1, 2, ...）は実装順序であり、TODO等、外に出さない
- ビルドが通り、その機能に限り,まだ動作できないと明示出来ている場合を除いて全体を通して動作させられる状態である必要がある。

### Ticket のライフサイクル

gitがタイムラインの単一の情報源。ファイル操作とcommitで状態遷移を表現する。

a. 作成: `tickets/foo.md` を作成してcommit
b. 詳細化や前提の変化: `tickets/foo.md` を更新してcommit
c. レビュー: `tickets/foo.md` にレビュー状態を追記 + `tickets/foo.review.md` を作成してcommit
d. 完了: `tickets/foo.md` と `tickets/foo.review.md` を両方削除してcommit

TODO.mdのリンクは完了後に切れるが、そのリンクを元にgitで消されたファイルを読み、内容を把握できる。
`.review.md` にはレビューの指摘事項と判断結果を記載する。
レビューはdiffの確認だけでなく、チケットはどのような前提・要件であり、それが達成されたかの確認まで含めて行う。