debugging

Root-cause debugging involves a four-phase workflow: Investigate the failure by examining logs and stack traces, Analyze the evidence to understand what happened, Hypothesize the underlying defect, then Fix and verify the change. This systematic approach prevents blind fixes and ensures solutions address the actual problem, not just symptoms.

Troubleshooting runtime errors requires capturing error output, reproducing the issue consistently, gathering evidence from logs and git history, and analyzing what changed. The debugging framework guides you through each phase to isolate the defect before implementing a fix, reducing wasted debugging effort.

Reproducing build problems starts by capturing the error output and environment details, then systematically analyzing logs and recent changes. The four-phase framework helps you identify whether the issue stems from dependencies, configuration, code changes, or environment setup before attempting a fix.

Performance issues recur when fixes address symptoms rather than root causes. Root-cause debugging prevents this by requiring you to investigate the underlying defect, gather performance evidence, and hypothesize the true bottleneck before implementing changes, with verification to confirm the fix is effective.

Red flags include fixes that work inconsistently, errors reappearing after deployment, or changes that seem unrelated to the symptoms. The framework recognizes these patterns as signals to revisit the investigation phase and gather more evidence rather than proceeding with incomplete analysis.

Verification involves running tests, reviewing outputs, and confirming the fix addresses the diagnosed root cause before declaring completion. This protocol ensures changes are validated and prevents introducing regressions or shipping incomplete fixes.