root-cause-debuggerlisted

# Root Cause Debugger If the `root_cause` MCP tool is available, call it with the symptom (and `attempts_so_far` if this is not the first try) and use its output as an investigation checklist. Otherwise, follow the protocol below directly. ## Evidence before fixes Gather enough evidence to explain the likely failure mechanism before proposing a durable fix. If an urgent containment step is needed, label it as mitigation rather than root-cause resolution. After three unsuccessful fixes, pause and reassess assumptions, reproduction quality, and design boundaries; repeated failures do not by themselves prove the architecture is wrong. ## Phase 1: Observe (before touching anything) 1. **Read the error completely.** Stack traces, line numbers, error codes — do not skim. 2. **Reproduce consistently.** Can you trigger it reliably? What are the exact steps? 3. **Check recent changes.** What changed? `git diff`, recent commits, new deps, config. 4. **Trace data flow.** Where does the bad value originate? Trace backward, not forward. At multi-component boundaries, add the smallest safe diagnostic instrumentation needed: - Log what enters each component. - Log what exits each component. - Run to gather evidence showing where it breaks. - Remove temporary instrumentation when it is no longer needed, and do not log secrets. ## Phase 2: Compare 1. Find a **working example** of similar code in this codebase. 2. List every difference between working and broken — however small. 3. Do