eng-debug-rca

Root cause analysis for a software crash uses a hypothesis-driven workflow to generate 3–7 ranked hypotheses, define evidence needs, and prioritize investigations by probability, confidence, and test cost before reading code. This structured approach reduces time-to-resolution and prevents misdirected fixes.

Git bisect guides bisection for code regressions by iteratively testing midpoint commits to narrow down the offending change. You provide a concise bug description with the repository path, and the workflow gates reproduction to validate the root cause commit accurately.

Evidence tracking during incident response uses an interactive evidence board to mark ranked hypotheses as confirmed or eliminated. This enforces reproduction, iterative testing, and documented verification to ensure reliable remediation of functional bugs.

Yes, you need reproducible steps, access to the code repository, and logs path to start the debugging investigation. These inputs initiate the hypothesis-driven workflow, enabling guided bisection, iterative testing, and local bug documentation.

Documenting a bug fix after root cause identification involves proposing quick versus proper fixes with risks, verifying against original repro steps, testing adjacent functionality, saving a local bug report, and logging a one-line summary to memory for verifiable remediation.