systematic-debugging

Start by reading the error output carefully, then reproduce the failure consistently with a targeted test run. Check recent changes with git diff, trace the bad value back to its source, and only then form a single hypothesis to test with the smallest possible change.

Root cause analysis means tracing a bug back to where the bad value or behavior originates rather than patching where the symptom appears. It involves reproducing the issue, gathering evidence across component boundaries, and fixing at the source.

Add temporary instrumentation like IO.inspect or dbg() at each boundary in the flow, such as LiveView to context to Ecto to database. Run once, find where the data first goes wrong, and investigate that component instead of the symptom site.

After three or more failed fix attempts, stop guessing. If each fix reveals new coupling, requires massive refactoring, or spawns new symptoms elsewhere, the design itself is likely wrong and should be discussed before attempting another fix.

A failing test that reproduces the bug proves you understand the root cause and confirms the fix actually works. It also prevents regression, since the test stays in the suite to catch the bug if it ever returns.