unity-to-tasks

タスクへの分解

計画、仕様、会話を、タスクのセットに分解します。各タスクはトレーサーバレット型の垂直スライスであり、その実行を妨げるタスクを明示します。

プロセス

1. コンテキストを集める

会話のコンテキストにすでにある情報をもとに作業します。ユーザーが引数として仕様のパスを渡した場合は、その内容とコメントをすべて取得して読みます。

2. コードベースを調べる（任意）

まだコードベースを調べていない場合は、現在の状態を理解するために調査します。タスクのタイトルと説明では、プロジェクトのドメイン用語集の語彙を使い、対象領域の ADR に従います。

実装を容易にするため、コードを事前にリファクタリングできる箇所を探します。「まず変更を容易にし、それから容易な変更を行う」。

3. 垂直スライスの草案を作る

作業をトレーサーバレットタスクに分解します。

• 各スライスは、すべてのレイヤー（スキーマ、API、UI、テスト）を通る、狭くても完全な経路を実現します。レイヤー単位の水平スライスではなく、垂直スライスにします。
• 完了したスライスは、それ単体でデモまたは検証が可能です。
• 各スライスは、新しいコンテキストウィンドウひとつに収まる規模にします。
• 事前のリファクタリングは先に行います。

各タスクに、依存関係を設定します。依存先のタスクが完了するまで開始できないタスクを指定します。ブロッカーがないタスクは、すぐに開始できます。

大規模なリファクタリングは、垂直スライスの例外です。 大規模なリファクタリングとは、列の名前変更や共有シンボルの型変更など、コードベース全体に影響が広がり、一度の変更で何千もの呼び出し箇所が壊れ、垂直スライスでは CI を成功させたまま進められない機械的な変更です。無理にトレーサーバレットに分割せず、拡張–縮小の順序で進めます。まず拡張として、新しい形式を古い形式と並行して追加し、何も壊れない状態にします。次に、影響範囲に応じてパッケージやディレクトリごとのバッチに分け、呼び出し箇所を移行します。各バッチを個別のタスクとし、拡張タスクをブロッカーに指定します。古い形式が残っている間は、各バッチの完了後も CI が成功する状態を保ちます。最後に、すべての呼び出し箇所の移行を終えてから、すべての移行バッチをブロッカーとするタスクで古い形式を削除します。バッチ単独では CI を成功させられない場合も、同じ順序で進めますが、それらを共通の統合ブランチで作業し、すべてのバッチを最後の統合・検証タスクのブロッカーにします。その場合、成功を保証するのは最後の統合タスクだけです。

4. ユーザーに確認する

提案するタスク分解を番号付きリストで示します。各タスクには、次の項目を記載します。

• タイトル：簡潔で説明的な名前
• ブロッカー：先に完了する必要がある他のタスク
• 成果：そのタスクによって実現するエンドツーエンドの動作

ユーザーに次の点を確認します。

• タスクの粒度は適切ですか？（粗すぎる／細かすぎる）
• 依存関係は適切ですか？それぞれのタスクは、本当に必要なタスクだけに依存していますか？
• タスクを統合したり、さらに分割したりする必要はありますか？

ユーザーがタスク分解を承認するまで、調整を繰り返します。

5. タスクを作成する

各タスクについて、docs/<feature-slug>/tasks/<NN>-<slug>.md に1ファイルずつ作成します。依存関係の順序でブロッカーから番号を付け、01 から始めます。各ファイルの「ブロッカー」には、依存するタスクの番号とタイトルを記載します。以下のタスクごとのテンプレートを使い、タスクは必ず1ファイルに1つずつ作成します。複数のタスクを1つのファイルにまとめてはいけません。

タスクの実行可能範囲に取り組みます。つまり、すべてのブロッカーが完了しているタスクを進めます。依存関係が一直線のタスクでは、上から順に進めます。

：<タスクのタイトル>

実装する内容： レイヤーごとの実装項目ではなく、ユーザーの視点から、このタスクによって実現するエンドツーエンドの動作を記載します。

ブロッカー： このタスクの実行を妨げるタスクの番号とタイトル。なければ「なし（すぐに開始可能）」と記載します。

• 受け入れ基準 1
• 受け入れ基準 2

すぐに古くなるため、具体的なファイルパスやコードスニペットは避けます。例外として、プロトタイプで作成したスニペットが、文章よりも正確に設計上の決定（状態遷移、リデューサー、スキーマ、型の形状など）を表す場合は、インラインで含め、その決定がプロトタイプに基づくことを簡潔に記します。動作するデモではなく、決定に関わる重要な部分だけを残します。