to-ticketslisted

# To Tickets Turn one complete canonical Spec Issue into a dependency graph of independently deliverable implementation Issues. Present the graph once before writing. Publication never claims, schedules, or executes a frontier Issue. ## 1. Bind the source Require one unambiguous `tracker: github` in the root `## verbs` block; invoke `setup-verbs` and stop when configuration is missing or conflicting. Derive the repository from Git and verify authenticated GitHub access. Read the entire source Issue and require substantive `Problem`, `Solution`, `User Stories`, `Implementation Decisions`, `Testing Decisions`, `Out of Scope`, and `Further Notes` sections. Confirm it declares itself the only requirements source of truth. On any gap, report it and stop; do not interview, rewrite, or close the parent. Search existing open and closed Issues for children naming this parent. Reuse an Issue only when its body contract and approved outcome match; otherwise stop on a publication conflict rather than duplicating or adopting stale scope. ## 2. Design vertical slices Each proposed Issue must: - deliver one observable behavior through every required layer; - have independently runnable acceptance evidence; - fit one fresh-context Sprint; - map to one independently reviewable and revertible PR; - name its parent, outcome, scope, acceptance, blockers, and exclusions. Split only when review/revert independence or blast radius differs. For a wide mechanical refactor that cannot form ho