systematic-debugginglisted

## Purpose Find the root cause of any bug before attempting a fix. Random fixes waste time and create new bugs. Symptom fixes are failure. **Core principle:** ALWAYS find root cause before attempting fixes. ## When to Use Use for ANY technical issue: - Test failures - Bugs in production - Unexpected behavior - Performance problems - Build failures - Integration issues **Use this especially when:** - Under time pressure (emergencies make guessing tempting) - "Just one quick fix" seems obvious - You've already tried multiple fixes - Previous fix didn't work - You don't fully understand the issue **Do not skip when:** - Issue seems simple (simple bugs have root causes too) - You're in a hurry (rushing guarantees rework) - Someone wants it fixed immediately (systematic is faster than thrashing) ## Inputs - Bug description or error message. - Stack trace or reproduction steps. - Environment context (OS, versions, recent changes). - Access to the codebase and test suite. ## Workflow You MUST complete each phase before proceeding to the next. ### Phase 1: Root Cause Investigation **Before attempting ANY fix:** 1. **Read error messages carefully** — Don't skip past errors or warnings. Read stack traces completely. Note line numbers, file paths, error codes. 2. **Reproduce consistently** — Can you trigger it reliably? What are the exact steps? If not reproducible: gather more data, don't guess. 3. **Check recent changes** — What changed that could cause this? Git diff,