investigate

# Investigate: Root-Cause Debugging Systematic debugging with mandatory root cause investigation before any code changes. **Iron Law: NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST.** Fixing symptoms creates whack-a-mole debugging. Every fix that doesn't address root cause makes the next bug harder to find. ## Instructions ### Phase 1: Collect Symptoms Gather all available context before forming any hypothesis. 1. Read the error messages, stack traces, and reproduction steps in full 2. Ask ONE targeted question if the user hasn't provided enough context: - "What exact error message do you see?" - "Can you reproduce this consistently?" - "When did this start happening?" 3. Identify the affected component and its boundaries **Output**: A precise symptom statement: what fails, when, with what error. --- ### Phase 2: Read the Code Trace the code path from symptom back to potential causes. Do not guess. ```bash # Find all references to the failing component grep -rn "ComponentName\|function_name\|error_string" src/ --include="*.{ts,js,py,rb,go}" | head -30 # Check recent changes to affected files git log --oneline -15 -- <affected-file> # Read the actual diff for each recent commit git show <commit-hash> -- <affected-file> ``` Use Grep to find all references, Read to understand the logic. Never skip reading the code. --- ### Phase 3: Check Recent Changes ```bash # What changed recently across the whole repo git log --oneline -20 # Changes to files rela...