Ticket-authoring conventions: scope declaration block, wave and gate labels, claim and escalation comment formats, model recommendation line

[wow-miley]

Model/effort recommendation: Sonnet, low — documentation and templates; all decisions are already ratified.

Context

The work-source integration recon (ticket #701) identified six pieces of metadata that tickets must carry for automated dispatch to work, and its human verdict (comment on #701, 2026-08-23) approved turning them into conventions. The dispatch ethnography verdict (comment on ticket #700, answer to question 7) added a seventh: ticket-creating agents should embed a recommended model + reasoning effort. This ticket writes those conventions down as templates and a concept cell so every future ticket-creating agent (and human) produces dispatch-ready tickets.

The seven conventions, in full (identifiers "M1"–"M6" come from the #701 findings; they are expanded here so this ticket stands alone):

1. M1 — Machine-readable scope declaration. A fenced code block tagged ampere-scope in the ticket description, containing YAML that lists the repositories and file-path globs the ticket may touch. Purpose: lets the supervisor refuse to dispatch two tickets with overlapping scopes in parallel (Contract 3 from the Four Contracts epic Four Contracts hardening — PromptQL probe adoptions (recon → D-verdicts) #686: dependencies bind at the earliest moment that can know them — scope is knowable at authoring time).
2. M2 — Wave tag. Label wave:<id> (e.g. wave:w0) marking wave membership. Server-side filterable.
3. M3 — Verdict-gate marker. Label gate:awaiting-verdict applied when a ticket reaches a human-verdict STOP gate. A ticket carrying it is never ready for dispatch. Only a human removes it.
4. M4 — Verification-manifest pointer: deliberately NOT a ticket convention. The manifest lives in-repo at .ampere/verify.yml (decision D3 on epic Epic: Ampere CLI v1.0 - Dispatch Loop (Rungs 1-3) #698); tickets don't point at it. Documented as an explicit non-convention so nobody reinvents it.
5. M5 — Claim-owner identity. Claim comments in the format claim:<issue-identifier>:<instance-id>; escalations as comments prefixed esc: plus an escalation label. Formats are owned by the work-source adapter ticket (Work-source adapter: Chassis SPI Plug over MCP implementing the ratified claim protocol, ready-queue, and status lifecycle #719); this ticket documents them for human readers.
6. M6 — Escalation payload. The esc: comment carries the escalation context (what failed, what was tried, what decision is needed) so the ticket itself is the escalation record.
7. Model + effort recommendation. A bolded first line in the description: **Model/effort recommendation:** <model>, <low|medium|high> — <one-line rationale>. Heuristic from the Recon: manual dispatch ethnography - trace the human operator loop end to end #700 verdict: stronger models for recon/planning tickets, smaller models for well-defined implementation tickets.

Objective

Templates + concept cell in the Ampere repo making the seven conventions the documented default for all ticket authoring.

Task Sequence

1. Write docs/concepts/ticket-conventions.md (concept cell per existing conventions in docs/concepts/, with frontmatter) covering all seven, each with a filled example. Validation: scripts/validate-concepts.sh passes.
2. Define the ampere-scope YAML shape (repos + path globs + an optional exclusive: false escape hatch for tickets safe to overlap) with 3 worked examples including one multi-repo ticket. Validation: examples parse with a standard YAML parser.
3. Add a ticket-description template file (markdown) usable by ticket-creating agents, with placeholder sections: model/effort line, Context, Objective, scope block, Task Sequence with validation steps, Technical Constraints, Out of Scope. Validation: template's scope block round-trips through the parser from step 2.
4. Update AGENTS.md with one short section pointing ticket-creating agents at the template and concept cell. Validation: section links resolve.

Technical Constraints

• Documentation and templates only — no supervisor code (the Switchboard consumes these conventions; it is a separate ticket).
• Public-repo language rules apply: no consumer-product names in examples.

Out of Scope

• Retrofitting existing tickets with scope blocks (done lazily as tickets are dispatched).
• Scope-conflict detection logic (Switchboard, Wave 1).
• Any Linear workflow/automation configuration.