bug-huntlisted

# Bug hunt Two habits make agentic debugging expensive. Fixing where the error surfaced rather than where it originates — the stack trace names the crash site, and the crash site is rarely the defect. And declaring a fix with nothing that would have caught the bug, so the next regression is silent. Both come from starting with a theory. Start with an observation instead. ## 1 — Observe Reach the defect in a real browser using `visual-verify`'s tooling, and capture all four signals before forming any explanation. A screenshot alone explains almost nothing: - **Console** — the complete error and stack, not the first line - **Network** — the actual request and response, headers and payload included - **State** — the store, query cache or signal graph at the moment it fails - **DOM** — what rendered, versus what the component claims to render The network signal is the one most often skipped and most often decisive: in a two-repo setup, a large share of "frontend bugs" are backend responses. Check the payload against `api-contract-sync` before suspecting your own code — a field that changed type or nullability produces failures that look exactly like render bugs. Where it will not reproduce, that is the result. Record the conditions you tried and stop; a fix for a defect nobody observed has nothing to verify against. ## 2 — Make it repeatable Turn the observation into **one command you can run unattended**. Everything after this consumes it, and its quality sets the ceili