root-cause-diagnosislisted

# Root-cause diagnosis discipline Before fixing a bug that involves a dependency - a third-party library, an internal shared module, or any package this code does not own - determine whether the failure is a defect in that dependency or a misuse of it. Name which one it is before writing the fix. ## The check 1. Read the dependency's actual contract for the behavior in question: its documentation, type signatures, or source, not memory or assumption. 2. Compare the observed failure against that contract. Does the call site match the documented usage: correct arguments, correct order, correct version, correct configuration? 3. If the call site deviates from the contract, this is misuse. Fix the call site, not the dependency. 4. If the call site matches the contract and the dependency still misbehaves, this is a candidate defect. Check the dependency's issue tracker or changelog for a known, matching report before concluding it is a fresh bug. 5. If diagnosis is genuinely inconclusive after steps 1-4 (the contract is ambiguous, the behavior is undocumented, or a minimal reproduction is needed and has not been built yet), say so explicitly rather than picking a fix at random. A stated "inconclusive, here is what a reproduction would need to confirm" is a valid outcome of this check. 6. State the diagnosis - misuse or defect, and the evidence for it - before proposing the fix. The fix location follows from the diagnosis: misuse gets fixed at the call site; a genuine defect get