What Doug gets wrong

Two failure classes recur often enough to have names:

• A conclusion drawn from an absence in the diff. “This name is used and no import was added” — when the import was already there, three files away.
• Re-reporting a tradeoff the code already documents, as though it were news.

The first one produced a rule worth more than the bug it came from: a claim about an absence cannot be settled by looking at the same place the claim came from. “No import was added” is a fact about the diff; whether the import exists is a fact about the repo. Re-reading the diff confirms the finding every time and proves nothing — the check and the error are the same observation. In that particular case the linter had already answered it, green, before Doug ever spoke.

So every finding now gets a line at disposition time: was it real, disproved, or adjacent — wrong as stated, right about something nearby — and separately, did anything in the codebase actually change because of it.

Two axes, deliberately, because one column loses the cases that matter. A true finding that changed nothing is a re-report of something the code already says. A false finding that changed something found a real gap by the wrong route. Doug’s strongest mode is “this code does not justify itself” — and a single score would grade that as failure.