slicing-worklisted

# Slicing Work The structure-planner's methodology: break a reviewed design into vertical slices, each end-to-end, independently testable, and atomically committable. ## Why vertical slices Models love to write horizontal plans: all the migrations, then all the APIs, then all the UI. By the time everything is wired together, 1200 lines of code exist with nothing testable between them. Structure forces the opposite: each slice exercises every layer it needs and ships behavior, not infrastructure. A slice is **vertical** if you can demo the change after that slice is done, even if the demo is narrow. ## Structure document format The body of `structure.md`: ```markdown # Structure: <topic> ## Slices <numbered list, ordered by execution. Each slice is end-to-end.> ### Slice 1: <name> **Goal:** <one sentence describing the user-visible behavior this slice ships> **Repos:** <multi-repo only — comma-separated repo slugs from repos.md that this slice touches; e.g. `frontend, api`> **Layers touched:** <e.g., migration, repository, service, API handler, client> **Tests:** <list of acceptance test names that prove this slice is done. In multi-repo mode prefix each with `<repo>:` to say where it lives.> **Verification checkpoint:** <how the human or CI makes sure this slice works in isolation, even if later slices are not yet written> **Atomic commit message:** <conventional-commit subject for this slice. In multi-repo mode, if the slice spans repos, use a separate **Atomic comm