project-tickets

Project Tickets

project-tickets は、ユーザーが明示的に呼び出す計画段階です。明示的な $project-tickets リクエストの後にのみ実行してください。検証済みの SPEC を、ローカルの Markdown トラッカー上の、番号付きのチケットごとに 1 ファイルの課題に変換します。

トラッカーと作業領域は、docs/agents/light-project.md と、存在する場合はその docs/agents/issue-tracker.md ロケーターから特定してください。設定されたトラッカーがサポート対象のローカル Markdown 契約に準拠していない場合は、.scratch ファイルに黙って書き込むのではなく、不足しているアダプターを示して BLOCKED と報告してください。

基本動作

1. SPEC の引き継ぎを検証します。 指定されたパスの SPEC を読み込みます。SPEC が見つからない、形式が不正、または Approval: pending の場合は、引き継ぎに問題があると報告して停止します。SPEC に Approval: 行がない場合はユーザーに確認し、承認されたら記録します。
2. トレーサービュレット方式で垂直スライスを作成します。 各スライスは、関連レイヤーを通る範囲を絞った、完全でデモ可能なパスとし、Blocked by の依存関係、ready work、parallelizable グループを含めます。
3. ユーザーに確認します。 タイトル、Blocked by、各チケットで実現する内容を提示し、粒度と依存関係が承認されるまで調整します。
4. チケットごとに 1 ファイルを公開します。 承認済みの形式を変更せず、依存関係の順に 01 から番号を付けて、.scratch/<feature>/issues/ に保存します。その後、SPEC の ## Comments に、誰が、いつ、どのような言葉で承認したかを Tickets approved 行として追記します。

変更提案の適用。 ユーザーが .scratch/<feature>/changes/ にある approved 状態の提案を渡した場合は、その Tickets: 行を正確に適用します（追加、削除、分割、並べ替え、Blocked by または受け入れ条件の変更）。SPEC: 行が none であるか、## Comments にすでに SPEC applied 行がある場合は、**Status:** を applied にしてステータス行を記録します。それ以外の場合は、- <date> Tickets applied — project-tickets を追加します。その他のステータスの提案、または提案に記載されていない変更は、変更せずにユーザーに差し戻します。

引き継ぎ

公開後、作業の最前線を説明し、選択したチケットに対する明示的な $light-implement を推奨してから停止します。

オプション機能

• .scratch/<feature>/plan.html が存在する → 公開後、light-html-plan を呼び出して更新します。ページまたは機能がない場合はスキップします。

参考資料

• WORKFLOW.md — スライス作成手順の全容と、大規模リファクタリングの実行順序。
• TICKET-CONTRACT.md — 正規のチケットファイル形式と Wayfinding との互換性。
• EXAMPLES.md — ドッグフーディングと境界事例の例。