diagnostic-reasoninglisted

# diagnostic-reasoning Use this procedure before scoping a reported bug and before acting on a diagnostic report. It applies both when investigating directly and when briefing a delegated investigation and judging the evidence that comes back. ## Establish the observed behavior Start from the end user's experience rather than an internal error string or an implementation hypothesis. Require an end-to-end reproduction aligned with the real user path whenever it is feasible and safe. If a faithful reproduction is not feasible, record the exact limitation and use the closest representative path without presenting it as equivalent evidence. Capture the expected behavior, observed behavior, setup, inputs, and repeatability before assigning a cause. Separate these three facts explicitly: - The **initiating trigger** is the event, input, or transition that starts the faulty behavior. - The **masking condition** is the independent state, environment, timing, cache, configuration, or path difference that hides or exposes the fault. - The **visible symptom** is what the end user or operator can actually observe. Do not collapse those facts into one label. A masking condition may explain why a fault appears only sometimes without being the initiating cause, and the visible symptom may be several layers downstream from both. ## Test the causal explanation Inspect the failing path and a proven path where the intended behavior is known to work. Compare their inputs, state transitio