tracer-to-tickets

チケットへの分割

計画、仕様、会話を一連のチケットに分割します。各チケットはトレーサーバレット型の垂直スライスで、ブロックするチケットを明示します。

公開先： docs/agents/issue-tracker.md でトラッカーが設定されている場合（/tracer-setup でセットアップ）、そこに公開します。このファイルには、ブロッキングエッジとフロンティアクエリの正確なコマンドが記載されています。そうでない場合は、.tracer/<feature-slug>/issues/ 配下にローカルファイルを作成します。

プロセス

1. コンテキストを収集する

会話のコンテキストにすでにある情報を使います。ユーザーが引数として参照（仕様のパス、イシュー番号、URL）を渡した場合は、それを取得し、本文とコメントをすべて読みます。

その参照が wayfinder:map またはローカルの Wayfinder map.md の場合は、処理を停止し、先に /tracer-to-spec に渡します。マップは分散した意思決定を示す解像度の低いインデックスであり、実装仕様ではありません。これを直接チケット化すると、リンク先の決定事項が失われます。

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

コードベースをまだ調査していない場合は、現在のコードの状態を把握するために調査します。チケットのタイトルと説明には、プロジェクトのドメイン用語集の語彙を使い、対象領域の ADR を尊重してください。

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

3. 垂直スライスを作成する

作業をトレーサーバレット型のチケットに分割します。

• 各スライスは、すべてのレイヤー（スキーマ、API、UI、テスト）を通る、範囲が狭くても完全な経路にします。垂直スライスであり、1 つのレイヤーだけを対象とする水平スライスにはしません
• 完了したスライスは、単独でデモまたは検証が可能です
• 各スライスは、新しいコンテキストウィンドウ 1 つに収まる規模にします
• 必要な事前リファクタリングは、先に実施します

各チケットに、ブロッキングエッジ（着手前に完了していなければならない他のチケット）を設定します。ブロッカーのないチケットは、すぐに着手できます。

大規模なリファクタリングは、垂直スライスの例外です。 大規模なリファクタリングとは、列の名前変更や共有シンボルの型変更など、機械的な変更が 1 つあり、その影響範囲がコードベース全体に及ぶため、1 回の編集で何千もの呼び出し箇所が一度に壊れ、どの垂直スライスも CI を成功させた状態でマージできないケースです。無理にトレーサーバレットに分割せず、拡張–縮小の順序で進めます。まず拡張します。新しい形式を古い形式と並行して追加し、何も壊れないようにします。次に、影響範囲に応じた単位（パッケージごと、ディレクトリごと）で呼び出し箇所をまとめて移行します。各バッチをそれぞれ 1 つのチケットとし、拡張チケットをブロッカーに設定します。古い形式がまだ残っているため、バッチごとに CI が成功する状態を保てます。最後に縮小します。すべての呼び出し箇所の移行が済んだら、古い形式を削除するチケットを作成し、すべての移行バッチをブロッカーに設定します。バッチ単独で CI を成功させた状態にできない場合でも、順序は維持しつつ、すべてのバッチが最終的な統合と検証のチケットをブロックする統合ブランチを共有します。CI が成功する保証は、その最終チケットでのみ行います。

4. ユーザーに確認する

提案する分割を番号付きリストで示します。各チケットについて、次の項目を表示します。

• タイトル：短く、内容がわかる名前
• ブロックされる条件：先に完了が必要な他のチケット（あれば）
• 実現する内容：このチケットによって動作するようになる、エンドツーエンドの振る舞い

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

• 粒度は適切ですか？（粗すぎる／細かすぎる）
• ブロッキングエッジは正しいですか？各チケットは、本当に着手を妨げるチケットだけに依存していますか？
• チケットを統合したり、さらに分割したりする必要がありますか？

ユーザーが分割案を承認するまで、繰り返し調整します。

5. チケットを公開する

承認済みのチケットを公開します。チケット自体はどちらの方法でも同じで、変わるのはブロック関係の表現だけです。

• ローカルファイル → .tracer/<feature-slug>/issues/<NN>-<slug>.md の下にチケットごとに1ファイルを書き込み、依存関係の順序（ブロッカーが先）で 01 から番号を付けます。各ファイルの「ブロック元」には、依存先の番号またはタイトルを記載します。以下のチケットファイルテンプレートを使用します。チケットごとに1ファイルとし、複数のチケットを1つのファイルにまとめてはいけません。
• 実際のイシュートラッカー（GitHub、Linear、…） → ブロッカーが先になる依存関係の順序で、チケットごとに1件のイシューを公開し、各チケットのブロック関係が実際の識別子を参照できるようにします。プラットフォームにネイティブのブロック関係／サブイシュー関係がある場合はそれを使い、ない場合は各チケットの「ブロック元」にブロックするイシューを設定します。特に指示がない限り、トリアージラベル ready-for-agent を適用します。チケットは、エージェントがすぐに取りかかれるように作成されています。

フロンティアに取り組みます。ブロッカーがすべて完了しているチケットが対象です。完全な直線状の依存関係なら、上から順に進めます。各チケットについて /tracer-implement を開始し、その都度コンテキストをクリアしてください。相互に依存関係のないフロンティアのチケットは並行して進められます。それぞれに /tracer-implement セッションを1つ割り当て、各セッションを専用のワークツリー（/tracer-worktrees）で実行してください。すべてのタスクでコミットするため、並行セッション間で未コミットの変更が競合することはありません。

親イシューは閉じたり変更したりしないでください。

—

**作成するもの：**このチケットで実現するエンドツーエンドの動作を、ユーザーの視点から記述します。レイヤーごとの実装一覧にはしません。

**ブロック元：**このチケットの開始を妨げるチケットの番号またはタイトルを記載します。すぐに開始できる場合は「なし — すぐに開始できます」と記載します。

ステータス： ready-for-agent

• 受け入れ条件1
• 受け入れ条件2

親イシュー

トラッカー上の親イシューへの参照を記載します（既存のイシューを元にしている場合。そうでない場合はこのセクションを省略します）。

作成するもの

このチケットで実現するエンドツーエンドの動作を、ユーザーの視点から記述します。レイヤーごとの実装にはしません。

受け入れ条件

• 条件1
• 条件2

ブロック元

• ブロックする各チケットへの参照、または「なし — すぐに開始できます」。

どちらの形式でも、具体的なファイルパスやコードスニペットは避けてください。すぐに古くなるためです。こうした詳細は /tracer-implement の一時的なタスク計画に記載します。例外として、プロトタイプで作成されたスニペットが、文章よりも正確に判断内容を表現している場合（状態機械、リデューサー、スキーマ、型の形状など）は、インラインで記載し、プロトタイプに由来することを簡潔に注記します。重要な判断に関わる部分に絞り、動作するデモではなく要点だけを示してください。