to-ticketslisted

# Create Tickets Turn settled intent into the smallest set of independently executable tasks that can remain green as work progresses. ## Respect the Ticket Contract - Draft tickets in the response by default. - Create local files only when the user requests them or provides an established location. - Publish or modify GitHub, Linear, Jira, or another tracker only with explicit authorization and an exact repository or project target. - Never close, relabel, or modify a parent issue unless the user explicitly asks. - Do not decompose unresolved product decisions into implementation guesses. ## Gather the Source of Truth Read the complete approved plan, specification, issue, or conversation and its accepted decisions. Inspect the repository enough to understand: - current architecture and domain vocabulary; - existing seams and test surfaces; - data, API, migration, and compatibility boundaries; - relevant implementation and verification commands; - expected blast radius. Use stable component names and verified paths where they help execution. Avoid brittle line numbers and speculative file lists. ## Identify Required Preparation Look for a small prerequisite change that makes later work safer or independently verifiable. Add it only when evidence shows the current structure blocks the requested implementation. Do not create generic cleanup, modernization, documentation, or infrastructure tickets unrelated to the desired outcome. ## Prefer Vertical Slices Each ticke