qa-debugging

# QA Debugging (Jan 2026) Use systematic debugging to turn symptoms into evidence, then into a verified fix with a regression test and prevention plan. ## Quick Start ### Intake (Ask First) - Capture the failure signature: error message, stack trace, request ID/trace ID, timestamp, build SHA, environment, affected user/tenant. - Confirm expected vs actual behavior, plus the smallest reliable reproduction steps (or “cannot reproduce” explicitly). - Ask “when did this start?” and “what changed?” (deploy, flag, config, data, dependency, infra). - Identify blast radius and urgency: who/what is impacted, and whether this is an incident. ### Output Shape (Default) - Summary of symptoms + confirmed facts - Top hypotheses (ranked) with evidence and disconfirming tests - Next experiments (smallest, fastest, safest) with expected outcomes - Fix options (root-cause) + verification plan + regression test target - If production-impacting: mitigation/rollback plan + rollout + prevention ## Default Workflow (Reproduce -> Isolate -> Instrument -> Fix -> Verify -> Prevent) Reproduce: - Reduce to a minimal input, minimal config, smallest component boundary. - Quantify reproducibility (e.g., “3/20 runs” vs “20/20 runs”). Isolate: - Narrow scope with binary search (code path, feature flags, config toggles, or `git bisect`). - Separate “data-dependent” vs “time-dependent” vs “environment-dependent” failures. Instrument: - Prefer structured logs + correlation IDs + traces over ad-hoc pri...