red-team-your-own-difflisted

# Red-team your own diff ## Purpose A green suite says the change works. It says nothing about whether the change will survive the people who have to read it, and those people are not generic: each has rules they have enforced in writing, on other contributors' PRs, repeatedly. Attacking your own diff against *those* rules finds a different class of defect from testing — the guard that hides a failure someone wanted exposed, the title that stopped describing the change, the word the project does not use, the helper twice as long as the invariant requires. Doing it before pushing also converts what would have been review round-trips into a diff that answers them in advance. In a house where an outside PR waits a month for attention, a round-trip saved is worth more than a defect found. ## When to use - A revision answering a review is written and about to be pushed. - The change grew beyond what the reviewer asked for — the widened scope is what breaks titles, invalidates earlier measurements, and creates unrelated-change objections. - You added a guard, a helper, or a default inside something with many callers. - Before replying to a review at all: the reply's claims are part of the diff's surface. ## When NOT to use - A one-line change nobody has reviewed yet, in a house with no recorded reviewer rules. Push and learn what they say. - You want the *automated* reviewer's rulebook rather than a named human's — that is [run-the-bots-review-before-it-does](../run-th