fixlisted

# Fix **For anything beyond a one-line cause, run Claude Code's built-in debugger:** ``` /debug ``` It does root-cause analysis properly — reproduce, isolate, form and test a hypothesis — and it is better at that than a checklist. Reach for it whenever the cause is not immediately obvious from the error text. This skill adds the two things it does not know: how *this* project reproduces a bug, and what counts as fixed here. ## Reproduce | Symptom | Reproduce with | |---------|----------------| | Build error | `npm run build 2>&1` (or the project's package manager) | | Type error | `npm run typecheck 2>&1` | | Runtime error | Start the dev server, then drive the app and read the console — see the `browser` skill for which driver to use | | UI bug | Same, plus a screenshot at desktop and mobile widths | For anything in the browser, read the console **before** reading the code. An error message costs one tool call and usually names the file. ## Fix Change the cause, not the symptom. Specifically, in this codebase: - A `?.` that makes a crash go away is a symptom fix. Ask why the value was absent — a missing loading state is the usual answer, and `rule-design-system` plus the UI-states convention say that state must be handled explicitly. - An `as unknown as Type` on external data is never the fix. Validate with Zod. - If the same class of bug appears in more than one place, grep for the pattern and fix them together, then grep again to prove none remain. ## Veri