systematic-debugginglisted

Hard rule: **do not package a guess as a permanent fix before locating the root cause.** If the user explicitly needs emergency containment, you may apply a reversible temporary mitigation first, but you must state its risks and that the root cause is not fixed, then continue investigating. ## 1. Reproduce - Read the error message and full stack trace carefully—the answer is often there. Do not skip them. Note the line number, file, and error code. - Establish a reliable reproduction first: which steps trigger it every time? If you cannot reproduce it reliably, gather data before proceeding. **Do not guess.** - Inspect recent changes: git diff, recent commits, new dependencies, and configuration or environment differences. ## 2. Trace backward to the root cause - Follow the bad value backward: where did it come from → who called something with it → continue to the source. **Fix it at the source, not at the symptom.** - In a multi-component system (CI→build→signing, API→service→library), record what enters and leaves each boundary. Run it once to see **which layer** fails, then investigate that layer. Do not guess based on intuition. - Find a similar working example and list every difference from the broken one. Do not assume that "this difference cannot matter." - Example: an amount on a page has two extra decimal places. Trace it backward: the display layer receives the wrong value → it came from the API → the value read from the database is correct → the API returned cent