ticket-up

Input: a manifest path. Without one, look for the most recent manifest in ~/.manifest-dev/manifests/ and confirm it's the intended one; if none exists, ask what to ticket up — a manifest is the input, so a session without one runs /define first.

The move: one ticket per Deliverable, plus the dependency edges between them. Each Deliverable is already a vertical slice — finishable on its own, exercisable end-to-end — so it maps to a ticket whole — split below it and the fragments could no longer be judged done. If a Deliverable is too big for one ticket, the cut is wrong in the manifest — fix it there. A one-Deliverable manifest legitimately yields one ticket.

Read references/TICKET_CONVENTION.md before emitting — it defines what a ticket is, its anatomy, lifecycle, and priority; the tickets you write must satisfy it.

Translation: knowledge travels, machinery stays

The manifest is a contract between /define and /do. A ticket is a contract with a stranger who may have neither. So translate, don't excerpt: take each manifest section into the anatomy slot the convention defines for it, rewritten in the ticket's own words.

The self-sufficiency test before emitting each ticket: could a competent stranger holding only this ticket understand why the work exists, know its bounds, avoid its traps, and judge it done? Manifest-dev vocabulary appearing anywhere in a ticket is a failure of this test. The convention's anatomy plus that test settle most of the mapping. Two things they don't: