root-cause-tracinglisted

# Root-Cause Tracing A bug surfaces at the symptom. The fix belongs at the cause. The two are rarely in the same file. ## Iron Law **Keep asking "why does this state exist?" until the answer is a decision, not another effect.** Stop one level too early and you'll patch a symptom and ship the bug. ## Red Flags - Wrapping the failure point in `if (x != null)` without knowing why `x` was null. - Adding a `try/catch` that swallows the error to "make it pass." - Coercing types at the boundary to make the function not throw. - "It happened because of bad input" — yes, but *who produced the bad input, and why?* - Stopping at the first plausible explanation that lets you write a fix. If your fix is the same shape as the symptom, you're symptom-patching. ## The "Five Whys" Walk Classic but works. Each "why" should move you one frame up the call stack, one layer deeper into the system, or one step earlier in time. Example: API returns 500. 1. **Why 500?** Handler threw `NullReferenceException`. 2. **Why null?** `user.Profile` was null when we accessed `user.Profile.Email`. 3. **Why was Profile null?** `LoadUser()` didn't include the Profile relation. 4. **Why didn't LoadUser include it?** New endpoint reused old `LoadUser`, but old callers don't need Profile. 5. **Why did the new endpoint use the lean loader?** No overload existed; dev copied the old call without checking what it loaded. Root cause: missing overload + no compile-time signal that Profile is required. Fix: add