debugging-systematicallylisted

# Debugging systematically Find the actual cause before changing code. A fix applied without a confirmed cause is a guess that may reappear or mask the real problem. See [enforcing-safety-baseline](../enforcing-safety-baseline/SKILL.md) — an environment-repair step (e.g. resetting local state to isolate a failure) still requires confirmation before anything irreversible, and a fix is never reported working without having just re-verified it. ## Workflow ``` REPRODUCE → ISOLATE → HYPOTHESIZE → VERIFY → FIX → REGRESSION TEST ``` 1. **REPRODUCE.** Get the failure happening under your own control — run the failing test, hit the broken endpoint, execute the reported steps. If it can't be reproduced, say so and gather more information (exact steps, environment, recent changes) rather than guessing at a fix for something unconfirmed. 2. **ISOLATE.** Narrow the failure to the smallest surface that still reproduces it: which layer (frontend/backend/DB), which function, which input. Use logs, breakpoints, `git bisect`, or targeted test runs — not broad speculative edits. 3. **HYPOTHESIZE.** State a specific, falsifiable cause ("the query doesn't filter by tenant_id, so it returns cross-tenant rows") — not a vague one ("something's wrong with auth"). 4. **VERIFY.** Confirm the hypothesis with evidence — read the exact code path, add a temporary log/assertion, or write a minimal failing test that isolates just that cause — before writing the fix. If verification disproves the hypothe