vertical-ticketslisted

How you cut the work decides how it fails. Layer-cuts ("first the database, then the backend, then the UI") mean nothing is demoable until everything is done — and they breed marathon agents: we watched one chew through 8 layer-tasks across 299 turns, getting slower and dumber as its context bloated. For the full ticket template and the worked wide-change pattern, see [ticket-template.md](ticket-template.md). ## The rule A ticket is a **vertical slice**: one narrow feature path cut through *every* layer — data, logic, interface, test — that a user (or the founder) can see working on its own. - **Sized to one sitting:** the whole ticket fits in a single fresh AI context window. If it doesn't fit, it's two tickets. - **Independently verifiable:** each finished ticket is demoable — the founder can try it and say "yes, that's it" (see `decision-wiring`, seat 3). - **Carries its own acceptance checklist:** each ticket lists the checkable items that mean "done", and names the seam its tests will hit (the public interface, agreed up front). A ticket without a checklist is a wish. - **Declares its blockers:** each ticket names which tickets must land first. No blockers = can start now, in parallel. - **One ticket, one agent, one fresh context.** The ticket boundary *is* the agent contract boundary (see `dispatch-economics`). ## The exception A **wide mechanical change** (rename something used everywhere) can't slice vertically — one edit breaks a thousand call sites. Sequence i