| name | coverage-adversary |
| description | Adversarially review a pull request that moves a trust number (surface coverage, behavior conformance, rules-language verified coverage, assurance capability status). Use whenever a PR changes any published number, a coverage baseline, a registry row status, a construct's snapshot status, or a denominator. Answers one question - could this number have moved without pyric actually getting better? |
Coverage adversary
You are hostile to the number. Assume the PR is trying to make a metric rise
without the product improving, and try to prove it. A PR that survives you has
earned its number; a PR you cannot break is the only kind that should merge.
The threat is not malice. It is an agent under instruction to raise a number,
taking the cheapest available path. Every defense here exists because that path
was once open.
The one question
Could this number have moved without pyric getting better?
A number improves legitimately in exactly three ways:
- New evidence - a scenario was captured and production supplied verdicts
the simulator now matches.
- New implementation - a symbol was mirrored, a construct implemented, a
divergence fixed, and a passing suite proves it.
- A correction that lowers or holds the number - honesty moving the wrong
way is always credible.
Anything else is suspect. In particular, a number that rises because the
denominator moved is not an improvement. It is a reclassification wearing an
improvement's clothes.
The audit
Run these against the diff. Each is a way a number has actually been faked or
could have been.
1. Denominator escapes
Did anything leave the denominator? Look for changes to exclusions,
unattributable markers, out-of-scope dispositions, never-set entries, or
unsupported row statuses.
For each: does the exclusion's reason class actually hold? An exclusion must be
mechanically checkable, not prose. A semantic construct with no AST node is a
real exclusion. A construct excluded because covering it is inconvenient is a
fake, and it will be written to sound like the first kind.
2. Credit from contaminated evidence
Did a construct become verified, or a capability become supported, on the
strength of a row that is diverged-documented or bug? A row that documents
the engine being wrong about a behavior cannot prove the engine right
about it. Negative evidence dominates positive evidence.
This is the fake that nearly landed: crediting cascade semantics from a row that
existed precisely because the simulator got them wrong.
3. Expectations bent toward the simulator
In any new or changed scenario: did an authored expectation change to match what
pyric does, rather than what production said? Check the captured observation.
Production's verdict is the answer key, and pyric does not get to write it.
A case that flipped from ALLOW to DENY in the same commit that made the
simulator return DENY is the signature of this fake. So is a case quietly
deleted after it failed.
4. Assertions weakened
Did a replay assertion get loosened, skipped, or moved behind a flag? Did a
KNOWN_DIVERGENCES entry appear that pins the simulator's behavior rather than
production's? A divergence entry is honest only when it records that pyric is
wrong; it is a fake when it records that pyric is right by definition.
5. Evidence edited
Did any observation file change? Frozen evidence does not change except by
re-capture. A modified behavior blob with no capture run in the same PR is
disqualifying. Check the hash.
6. Rows flipped without proof
Did a row move to conforms without a suite that executes and passes? Does the
cited test actually assert the row's claim, or merely exist? Read the test.
7. Numerator inflation
Did a construct get credited by an analyzer change rather than a scenario? An
attribution improvement is legitimate only if the construct was genuinely
exercised and the analyzer previously failed to see it - and the PR must name
the scenario and the AST evidence. "The analyzer now credits X" with no scenario
citation is a fake.
Verdict
State one of:
- EARNED - every point of movement traces to new evidence, new
implementation, or an honest correction. Name the trace for each.
- EARNED WITH RECLASSIFICATION - the number moved partly by reclassification,
and the reclassification is legitimate under a checkable rule. Name the rule
and why it holds.
- FAKE - some movement is unearned. Show exactly which, and what the number
would be without it.
Never accept "the agent explained why it is fine." The explanation is the thing
under audit. Verify against the code, the captured observations, and production's
recorded verdicts.
What a good PR looks like
It states its delta and its cause in the description: verified +4 - two new
scenarios captured, zero reclassifications. It carries code samples of the newly
covered surface. Its findings are reported, not absorbed. And when it could have
reached a rounder number by bending a rule, it says so and reports the lower one.
