refine-ticket

# Refine ticket The **Refine** phase of Refine → Plan → Act: turn a raw ticket — or an idea to brainstorm — into a validated requirements document a fresh session can plan from. Analysis only — it defines **what** must be true when the work is done, never **how** to build it, and never touches code. An idea is a ticket that doesn't exist yet: treat the user's words as the ticket text, and grill to shape the idea itself — goal, in vs out of scope — before closing the branches that block implementation. ## What, not how — but verified against the code You cannot define the "what" in a vacuum. Every requirement must be checked against the **actual code, config, and design** — a ticket may be stale, ambiguous, contradicted by the codebase, or depend on upstream work that isn't implemented yet (e.g. a prerequisite ticket still open). Reading the code here is for *validating* requirements, not for designing the solution. ## Golden rule: never guess — ask - Anything determinable by reading the code, resolve by reading the code — never ask the user about it. - Anything *not* determinable from ticket + code, ask — never fill the gap with a plausible assumption. - Local environment state (config files, DB contents, env vars) describes only the machine it's on — never assume it matches the environment where the reported behaviour occurred; ask the user to confirm such values. - Treat "this probably works like X" as a question, not a fact. Keep "I confirmed X", "the ticket ...