plan-work-tickets

Cut vertical tracer-bullet slices — narrow but complete paths through every layer (schema, action, UI, tests) — each demoable on its own and sized to one context window. Then declare each ticket's blocking edges and order them so a ready ticket always exists.

A tracer-bullet ticket is a narrow but complete vertical slice through all layers of a feature, rather than a horizontal slice of one layer like all the schema. It is demoable or verifiable on its own, such as a screen you can click or a route you can curl.

Run an input-trace audit: for every ticket, trace each input it consumes — data it reads, a component it renders, a route it calls — to the ticket that produces it. An input with no producer reveals a missing edge or a missing ticket.

Yes. The default destination is plain-text files in a local tickets folder, one file per ticket numbered in dependency order with blocked-by lists referencing file numbers. A real tracker's native blocking links are used only when you actually run one.

Do not slice when the problem is not yet framed into a spec, when unresolved unknowns still gate the build order, or when the work is a throwaway prototype spike. Frame the problem, resolve the unknowns, or run the spike first.

Sequence it as expand, migrate, contract: add the new form beside the old, migrate call sites in batches sized by blast radius, then delete the old form in a final ticket blocked by every migrate batch. Do not force it into one tracer bullet.