Debugging Methodology

Critical rules

• NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST. No evidence → no fix proposal.
• Measure; do not speculate. Instrumentation before hypothesis.
• One change at a time. Never stack unverified fixes.
• 3+ failed fixes → stop, question architecture, discuss before more attempts.
• Red flags: "quick fix now", "try changing X", multi-change batches, "probably X", proposing solutions before data flow is traced.
• Before instrumenting, map the path with code-flow-analysis. Before deep examples, read references/protocol.md.

Workflow

1. Document the exact symptom (error text, expected vs actual, inputs, environment).
2. Add instrumentation at decision points before forming any hypothesis.
3. For complex flows, use OpenTelemetry spans (or existing production traces).
4. Form a testable, evidence-based hypothesis that explains all symptoms.
5. Apply one change; retest; keep structured logging, remove debug-only noise.
6. For Result / workflow failures: log every err(), each step, and mock interactions. See protocol for patterns.

Resources

• references/protocol.md — instrumentation, Result/workflow debugging, decision tree, anti-patterns, rationalizations. Read before instrumenting or when stuck.

Validation

• Exact symptom captured
• Instrumentation evidence explains the failure (not a guess)
• Hypothesis confirmed with a single isolating change
• Root cause identified (not only symptom location)
• Regression test fails without fix, passes with it
• Original failure no longer reproduces; suite/build green
• Debug-level noise removed; structured logs/traces kept

Constraints

• Skip the full protocol only for trivial self-evident issues the compiler already names (typo, missing import).
• Related: code-flow-analysis, investigation-modes, result-types, fn-args-deps, verification-before-completion, confidence-levels, observability.