diagnosing-bugslisted

# Diagnosing Bugs ## The Iron Law NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST. Complete the investigation before proposing or implementing any changes. Don't change production code until you've named the root cause out loud. Before phase 1, check `.sixth-sense/learnings.jsonl` per [references/learnings-ledger.md](references/learnings-ledger.md) for entries relevant to the code/files involved — a documented pitfall on this exact class of bug saves re-diagnosing it from scratch. ## The Six-Phase Loop ### 1. Reproduce Create a reliable feedback loop that proves the bug exists. - Isolate: simplify environment and input to the smallest possible test case. - Verify: confirm the reproduction steps consistently trigger the error. - For Java: isolate with a single JUnit test if possible. Run with `./gradlew test --tests "TestClass.testMethod"`. ### 2. Minimise Strip away unnecessary code and context until only the failure remains. - Remove unrelated beans, configurations, dependencies. - For Spring Boot: test with a minimal `@SpringBootTest` context or a plain unit test. ### 3. Hypothesise Formulate a theory about the root cause based on evidence. - State ONE testable hypothesis. - Check recent changes: `git diff` / `git log`. - For Java: read the full stack trace. Check bean wiring, transaction boundaries, lazy loading. ### 4. Instrument Add logging, breakpoints, or probes to verify the hypothesis. - For Spring Boot: temporary `log.debug()` statements, `@Sql` scripts for D