pr-verification

Before you open a PR

Your change will be held to a higher bar than "the suite is green." Across ~100 merged and closed PRs, three failures dominate — in this order. They are what most review rounds are spent on, and every one of them is cheaper to catch now than after a reviewer finds it.

This file is a gate, not a checklist to run alongside the PR. Nothing is pushed and no PR is opened until every item below has been done and your local adversarial review has reported and its findings are resolved. Running the review in parallel with git push looks like free wall-clock and is not: a finding that lands after the branch is public costs a force-push or a second PR, it can reach a reviewer or a merge first, and it arrives already framed as follow-up — which is how a should-fix becomes a won't-fix. "Quick PR" is a reason to keep the change small, never a reason to open it before the gate closes.

A review that reports "nothing to fix" still has to report before the push. The point is not that findings are likely; it is that the branch going public is the irreversible step, and the review is what tells you whether it should.

1. Tests must discriminate. Green is not evidence.

The single most common defect. Tests pass; the behavior they claim to pin is absent, unreachable, or staged in a state production can never produce.

The acceptance test: delete the feature and run the suite. If nothing turns red, the tests are theatre regardless of how many there are. One detector shipped with tests staging the scenario in a data region the detector never touches — deleting the entire feature left 85/85 green, and the detector was dead in production.

• Run the full file, not -t isolation — they disagree, and CI runs the file. A test has passed in the full run and failed under -t.
• Stage state through production producers. For chain/head/normalization work, emit the item via response.output_item.done into the expected-assistant history; never plant it directly in the request input. That region is kept verbatim and can never diverge, so a test staged there passes no matter what the code does. This defect has now been seen twice.
• Mutate each independent guard and precedence branch, not just the happy path.
• Include over-scope and under-scope negatives — prove the change does not fire where it shouldn't.
• Never accept the sha256 source-digest pin as the failing test. It is a tripwire, not a behavioural test. A mutation that broke a real bridge leak passed 1329/1330 with the digest pin as the only red. If the pin is the only thing failing, the behaviour is unpinned.