systematic-debugging

Start by reading the full error message and stack trace, then reproduce the failure consistently and check recent changes via git diff. Form one specific hypothesis, test it with the smallest possible change, and verify with a failing test case before implementing the fix.

Add diagnostic logging at each component boundary to capture what data enters and exits every layer, such as workflow, build script, and signing steps. Run once to gather evidence showing which layer breaks, then investigate only that component.

Stop after three failed fix attempts, especially when each fix reveals a new problem in a different place or requires massive refactoring. This pattern indicates an architectural problem, so discuss fundamentals with your team before attempting more fixes.

Quick patches address symptoms rather than root causes, so the underlying issue resurfaces elsewhere. Bundling multiple changes also makes it impossible to isolate what worked, and untested fixes frequently introduce new defects.

No, simple bugs have root causes too, and the process is fast for straightforward issues. Skipping investigation under time pressure leads to guess-and-check thrashing that takes longer than systematic diagnosis.