systematic-debugging

Start by reading error messages and stack traces completely, then reproduce the failure consistently and check recent changes via git diff. Form a single hypothesis, test it with the smallest possible change, and only implement a fix after confirming the root cause.

Add diagnostic logging at each component boundary to capture what data enters and exits every layer. Run the system once to gather evidence showing exactly where the failure occurs, then investigate only that specific component instead of guessing.

Question the architecture after three or more fix attempts have failed, especially when each fix reveals new problems in different places or requires massive refactoring. This pattern indicates a fundamental design issue rather than an isolated bug.

Quick fixes address symptoms rather than root causes, so the underlying problem resurfaces elsewhere. Untested fixes also cannot be verified, and bundling multiple changes makes it impossible to isolate what actually worked.

Do not guess when a bug cannot be reproduced consistently. Gather more data through logging and monitoring, document what you investigated, and add appropriate handling such as retries or timeouts for genuinely environmental issues.