to-ticketslisted

# To Tickets Break a plan, spec, or conversation into **tickets** — tracer-bullet vertical slices, each declaring the tickets that **block** it — written as local files, so the team's tracker stays clean and each file is runnable on its own. ## Process ### 1. Gather context Work from what is already in the conversation. A reference passed as an argument (a spec path, a Linear URL) is fetched and read in full, comments included. ### 2. Explore the codebase Understand the current state of the code the work touches. Titles and descriptions use the glossary vocabulary in `CONTEXT.md` and respect ADRs in the area. Look for **prefactoring** that would make the change easy — "make the change easy, then make the easy change" — and put it first. ### 3. Draft vertical slices <vertical-slice-rules> - Each slice cuts a narrow but COMPLETE path through every layer (schema, API, UI, tests) — vertical, not one layer. - A completed slice is demoable or verifiable on its own. - Each slice is sized for one fabrika run: a single fresh context window. - Prefactoring comes first. </vertical-slice-rules> Give each ticket its **blocking edges** — the tickets that must complete first. A ticket with no blockers can start immediately. **Wide refactors are the exception.** A mechanical change with a **blast radius** across the whole codebase (rename a column, retype a shared symbol) cannot land green as one slice. Sequence it as **expand–contract**: expand (add the new form beside the old),