to-tickets

To Tickets

担当範囲：Ticket Envelope の作成と、実行可能なトレーサーバレット方式でのスライスです。スケジュール設定、実装、監査、または独立した Markdown スキーマの維持は行いません。

Ticket Envelope v1 と、カタログから解決した絶対パスの ticket-autopilot スキルルートを使って "$TICKET_AUTOPILOT_ROOT/scripts/ticket-autopilot.py" ticket-emit を実行します。リポジトリの cwd は使わないでください。front matter を手動でシリアライズしてはいけません。レガシー入力には明示的な migrate コマンドが必要です。

デフォルトのスキルのみのレーン（ランナーなし）では、ランナー CLI ではなく、同じコントラクトの純粋なシリアライザーとパーサー（scripts/ticket-contract.py emit|parse）を使用してください。スキルのみのコントラクトに従ってください。 これは別のスキーマでも、手動シリアライズでもありません。アトミックな書き込みと、読み戻し時の厳密な検証を維持してください。

プロセス

1. 仕様を特定して読みます。所有範囲、規約、テスト、垂直方向の動作境界を理解するために必要な範囲に限り、コードベースを調査します。
2. 作業を、個別に検証できる薄いエンドツーエンドのスライスに分割します。水平方向のスキーマ/API/UI/テストのみのバッチにはしないでください。並列化できるようにします。実際の依存関係がある場合に限ってブロックし、ファイルが重ならないようにし、準備完了のチケットがどちらも編集するファイルがあれば、両方のチケットにそのファイル名を記載します。
3. 各スライスを AFK または HITL に分類します。依存関係を明示し、循環させないでください。AFK を優先しますが、実際の意思決定、認証情報、環境上のゲートを隠してはいけません。仕様の ## Gates を各チケットにコピーし、欠けている場合は to-spec のデフォルトで補います。未解決のゲートがあるチケットは HITL とし、その意思決定をフロンティアにします。
4. チケットのタイトル、モード、ブロッカー、フロンティアの状態、対象となる仕様セクションを提示します。明示的に自律的な依頼の場合は、妥当な前提を記録し、ゲートは設けずに続行します。
5. docs/tickets/<spec-slug>/<NN>-<ticket-slug>.md を依存関係の順序が一定になるように作成します。

すべての本文には、安定した Artifact ID、Role: ticket、および Parent リンクを1つ含む ## Artifact Graph セクションを設けます。チケットを単独で作成してはいけません。同じ変更内で、所有する仕様またはマップに対応する Children リンクを追加します。調査チケットでは、永続的な出力をそれぞれ Produces に記載し、すべての出力からそのチケットへのリンクを設けます。

チケットごとに、envelope JSON を準備します。

{"ticket_schema": 1, "ticket_id": "NN", "execution_mode": "AFK", "blocked_by": []}

Markdown 本文を準備します。

# <Ticket title>

## Artifact Graph
- Artifact ID: `artifact:<stable-id>`
- Role: `ticket`
- Parent: [<spec-filename>](../../specs/<spec-filename>)

## Parent Spec
[<spec-filename>](../../specs/<spec-filename>)

## What to Build
Narrow end-to-end behavior and the source spec sections.

## Acceptance Criteria
- [ ] Observable criterion.

## Frontier
Ready, dependency-blocked, or exact human decision required.

## Gates
The spec's applicable gates plus this ticket's own; an unanswered one is `open`.

## Step-by-Step Implementation Plan
1. Change, reason, affected contract/module, and checkpoint.

## Testing Plan
Automated and manual checks, including unavailable boundaries.

## Out of Scope
- Explicit exclusion.

Autopilot レーンでは、CLI を通じてアトミックに出力します。

python3 -B "$TICKET_AUTOPILOT_ROOT/scripts/ticket-autopilot.py" \
  ticket-emit <envelope.json> <body.md> --output <ticket.md>

正規パーサー（Autopilot レーンでは ticket-parse、スキルのみのレーンでは parse_ticket_markdown）で出力されたチケットを読み戻し、正規化された envelope の完全一致、一意の ID、依存関係のリンク、対応するグラフエッジを検証します。

スキルのみのレーンでは、検証済みバッチの引き渡しで停止します。finalize_batch.py を実行したり、暗黙的に wiki/provider 作業を開始したりしてはいけません。別途依頼され、llm-wiki を通じて許可されない限り、wiki の同期は延期として報告します。成功または変更なしを示す証拠が必要です。チケットの検証方法に変更はありません。

Autopilot レーンでは、バッチ内のすべてのチケットが出力され、検証を通過した後、所有するバッチ後処理の境界を1回だけ呼び出します。チケットごとに呼び出してはいけません。

python3 -B "$TO_TICKETS_ROOT/scripts/finalize_batch.py" \
  <project-root> <ticket-folder> <ticket-path>...

$TO_TICKETS_ROOT はカタログにある絶対パスのスキルルートです。設定済みの wiki は --wiki-root <path> として渡し、それ以外の場合は wiki-sync-v1 の限定的な検出を使用します。ticket-batch-finalize-v1 のレポート全体を保持します。wiki が存在しない場合は、成功として扱う変更なしです。失敗によって出力済みのチケットを隠してはいけません。返された追跡対象の wiki 候補は分離して保持し、ドキュメントのみを対象とします。wiki ファイルをチケットソースの候補に追加してはいけません。wayfinder はこのフックを所有せず、呼び出すこともありません。

レポート

チケットフォルダー、パス、準備完了のフロンティア、ブロック中のチケット、HITL の意思決定、およびバッチ後処理レポートから正規化した wiki_sync の結果を返します。スキルのみの場合は、wiki 同期が延期されていることを明示して返します。