rule-diagnosislisted

# Diagnose before you fix **A wrong fix costs one cycle. A wrong diagnosis costs every cycle until someone questions the premise.** That asymmetry is the whole reason this is a first-class rule and not a footnote: repeated QA rounds are almost never caused by sloppy edits, they are caused by a confident explanation nobody re-examined. The failure is rarely bad reasoning. It is sound reasoning on an unexamined frame — one machine, one state, one suite, one shape — where the observation was real and the conclusion still wrong. ## 1. Reproduce it, in the state it actually happens An explanation that has not been reproduced is a guess wearing a lab coat. Reproduce in the state the user is in, not the state that is convenient. A refactor was narrowed and half-abandoned because ambient colours "computed identically in every mood, and no CSS rule set them" — measured while signed out, where `body.lockOpen` deliberately pins them. Nothing was broken. The measurement was taken in the wrong state, and the diagnosis inherited that. **Before explaining: can I make it happen on demand?** If not, say so, and say which way you are guessing. ## 2. When two sources disagree, suspect the FRAME before inventing a mechanism The cheap hypothesis is that you measured the wrong thing, in the wrong place, or at the wrong time. The expensive one is that the system has an exotic mechanism you had not heard of. **Reach for the cheap one first.** | the observation | the mechanism invented | the