solvelisted

# Solve ## Overview Turn a ticket into a validated solution, then into code, in that order. A ticket is testimony, not truth: its premise (the claimed problem) and any proposed fix are hypotheses to verify against the current code, written by someone without full context and possibly before the code changed. Core rule: **no implementation code until (1) the premise is validated against the current codebase and (2) the user has approved a solution.** Reproduction scripts and failing tests written to verify the premise are allowed and encouraged; the fix itself is not. The invocation argument is the ticket: a URL, an issue number, or pasted text. ## Phase 1: Understand - Read the full ticket: description, comments, linked issues and PRs. - Locate the code it concerns and read it as it exists NOW on the default branch, not as the ticket describes it. ## Phase 2: Validate the premise - Confirm the claimed problem exists in the current code: reproduce it (failing test, script, observed behavior) or trace the code path and show exactly where the flaw lives. - Check for staleness: `git log` / `git blame` the relevant files. Has the code changed since the ticket was filed? Was it already fixed, partially fixed, or refactored out of existence? - Conclude with one verdict: **Confirmed**, **Partially confirmed** (state which part survives), or **Not confirmed** (already fixed, misdiagnosed, or not reproducible). - If Not confirmed: the deliverable is a report with evidence (comm