to-tickets

チケット化

計画、仕様、会話の内容をチケットに分解します。各チケットはトレーサーバレット型の垂直スライスとし、先行をブロックするチケットを宣言します。利用するリポジトリのトラッカー規約（AGENTS.md）に従って公開します。

再現性の不変条件

イシュー一式を依存関係の順に再生すると、機能追加もバグ修正も含め、誰が、または何が実装するかにかかわらず、ほぼ同じアプリケーションをビルドできなければなりません。

イシューストリーム ＝ ビルド可能な仕様です。以下のルールはすべてこれを実現するためのものです。

自己完結性

成果を左右するすべての判断は、イシュー自体、またはイシューが参照する永続的なドキュメント（ADR（writing-adrs）、用語集の用語（docs/glossary/））に記載します。会話の文脈、暗黙知、実装者の裁量に頼ってはいけません。

判定基準： 独立した2人の実装者が、意味のある違いがあるものを作れてしまう場合、チケットの仕様が不十分です。判断をチケットに追加するか、ADR／用語集の用語として記録して参照します。

新しい語彙

ドメインの概念を導入するチケットでは、## Introduces の下に、その概念を宣言します。1行につき1つのスラッグを記載し、用語ファイルがすでに存在するものとしてリンクします（docs/glossary/<slug>.md、「存在するものとしてリンク」する規約）。実装時にファイルを作成します。それまでは --lint が壊れた相互参照を報告します。これは不具合ではなく、まさにこの仕組みによる強制です。このリストは、チケットが追加する語彙の永続的な記録になります。

バグ修正 ＝ 仕様の訂正

指示の修正（「ファイル Z の Y を X に変更する」）をしてはいけません。仕様の流れに対する訂正を記述します。

• イシュー N は X を示唆していたが、実装は Y になった。正しいのは X。 — または
• イシュー N は Y を指定していたが、Y は誤り。現在は X′ が正しい。

こうして再生すれば、バグとパッチではなく、最初から X がビルドされます。バグ修正によって仕様レベルの判断が明らかになった場合は、ADRを作成し、イシューから参照します。

完了時の整合

チケットは、実際にビルドされたものを反映するまで完了ではありません。クローズする前に、差異、作業中に追加されたスコープ、判断をイシュー（またはそのADR／用語集の参照先）に反映します。そうしないと、再生時に最終状態ではなく初稿がビルドされます。documenting-decisions のタスク後の手順でこれを行います。

精査のゲート

チケットは後続作業の基盤です。コンテキストに精査セッション（docs/glossary/grilling-session.md）がない場合は中断し、ユーザーに「精査セッションが見つかりません。本当にスキップしますか？」と確認します。明示的な確認があった場合にのみ続行し、親イシュー／PRにスキップしたことを記録します。

プロセス

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

会話のコンテキストをもとに作業します。ユーザーから参照先（仕様のパス、イシュー番号／URL）が渡された場合は、取得して本文全体とコメントを読みます。

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

現在のコードの状態を把握します。タイトルや説明には用語集の語彙を使い（uvx disambiguate <term>）、変更対象の領域に関するADRに従います。

事前リファクタリングの機会を探します。「変更を容易にしてから、容易な変更を行う。」

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

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

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

すべての草案に判定基準を適用します。草案作成時の判断（インターフェース、命名、順序のトレードオフ）は、チケット本文、ADR、または用語集の用語に記載します。documenting-decisions に従って明示します。

大規模リファクタリング：垂直スライスの例外です。 1つの機械的な変更（カラム名の変更、共有シンボルの型変更）でも、影響範囲がコードベース全体に及び、単一の編集で何千もの呼び出し箇所が壊れ、どのスライスもグリーンで完了しない場合があります。その場合は、拡張－縮小の順で進めます。拡張：新旧の形式を併存させ、何も壊さないようにします。移行：影響範囲に応じて、パッケージ／ディレクトリ単位のバッチに分けて呼び出し箇所を移行します。各バッチを独立したチケットとし、拡張チケットにブロックさせます。CIをグリーンに保ち、旧形式も残します。縮小：呼び出し箇所がなくなったら旧形式を削除します。すべてのバッチを完了条件とします。バッチ単独ではグリーンを保てない場合は、この順序を維持して統合ブランチを共有し、すべてのバッチを最後の統合・検証チケットにブロックさせます。グリーンを保証するのは、そのチケットだけです。

4. クイズを実施する

番号付きリストです。チケットごとに、次を確認します。

• タイトル：短い名前
• ブロック元：ある場合は、ゲートとなるチケット
• 提供するもの：エンドツーエンドで動作するようにする機能

次の点を確認します。

• 粒度は適切ですか？（大きすぎますか、小さすぎますか？）
• ブロック関係は正しいですか？本当にゲートとなるものだけですか？
• 統合または分割するチケットはありますか？
• リトマス試験に合格しないチケットはありますか？つまり、意思決定がまだ会話の中だけにとどまっていませんか？

承認されるまで繰り返します。

5. 公開する

チケットごとに1件のイシューを作成し、依存関係の順序（ブロッカーを先に）で公開します → エッジは実際のイシュー番号を参照します。トラッカーにネイティブのブロック関係がある場合はそれを使用し、ない場合は「Blocked by」セクションを使います。特に指示がなければ、ready-for-agent ラベルを付けます。チケットは、最初からエージェントが取得できるように構成されています。

フロンティアに取り組みます。すべてのブロッカーが完了しているチケットが対象です。直線的な連鎖の場合は、上から順に進めます。

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

イシューテンプレート：

## Parent

Reference to parent issue (omit if source wasn't an issue).

## What to build

End-to-end behaviour, user's perspective — not layer-by-layer implementation.

## Decisions

Every outcome-shaping decision, stated or referenced (ADR/glossary). Bugfix: spec-correction statement. Omit only if genuinely none.

## Acceptance criteria

- [ ] Criterion 1
- [ ] Criterion 2

## Introduces

- [slug](docs/glossary/slug.md) — one-line meaning. Omit if no new term.

## Blocked by

- Reference per blocking ticket, or "None — can start immediately".

チケットの文章：利用可能な場合は writing-prose スキルで作成・確認し、ticket を表面に出します。正確さと分かりやすさを損なわないでください。

ファイルパスやコードスニペットは記載しません。すぐに古くなるためです。例外：文章よりも正確に意思決定を表すプロトタイプのスニペット（状態機械、リデューサー、スキーマ、型の形状）がある場合は、インラインで記載し、プロトタイプの由来を明記して、意思決定に重要な部分に絞ります。

フロンティアのチケットを1件ずつ進め、チケットごとにコンテキストをクリアします。