verify-before-a-committer-commentlisted

# Verify before a committer-facing comment ## Purpose AI makes a plausible technical claim nearly free to write, which shifts the cost of disproving it onto the maintainer. A confident-but-wrong assertion in a public thread — especially about your own PR's scope — is one of the fastest ways to burn reviewer trust. The fix is a hard gate: before any committer-facing technical claim, trace the real code path and re-run the relevant test on the right clean state, rather than inferring from titles, commit messages, or the JIRA link-graph. Then state confidence explicitly. Verifying often *flips* the answer — turning a wrong, self-promoting claim into an accurate one that scopes your work honestly, which is a far stronger position than being corrected in public. ## When to use - Before posting any "PR/commit X does Y", "the bug is in layer Z", "test T fails/passes", or "A is the root cause of B" claim to a maintainer. - Especially before claiming what your OWN PR fixes. ## When NOT to use You're deciding whether a thread is even waiting on you (whose-turn), not asserting a technical fact — that's track-whose-court; this gate is for claims you're about to state as true. ## The practice (checklist) - [ ] **"PR/commit X does Y"** → `git show <sha>` the actual DIFF; read what it touches, not the message. The diff often contradicts the message. - [ ] **"The bug/gap is in layer Z"** → trace the real call path in code (who delegates to whom). Two similarly-named met