proofStrength

What this scheme's CommutativeScheme.verifyEncrypt / CommutativeScheme.verifyStrip pair does with a transition it did not produce — a declaration the subclass makes and verifyAnswersForgedTransitionsAsDeclared then holds it to.

Why a declaration and not simply a property. CommutativeScheme documents that an implementation may return true unconditionally until real proofs land, and both schemes in this repo take that option; a suite that flatly asserted rejection would fail them, and one that asserted nothing — this suite, before #2313 — pins only the accept branch of a predicate that is unconditionally true. Neither is the truth. The declaration puts the scheme's posture in the fixture, in one word, where the next reader of XorKeystreamSchemeConformanceTest cannot mistake "the TCK exercises verification" for "the TCK detects cheating".

Both arms are checkable, which is what makes this different from a skip. A hook that says "I cannot reach that state" is an opt-out, and #2247's finding is that an opt-out moves the vacuity one level up. Here neither arm opts out: ProofStrength.RejectsForgeries fails if a forgery is accepted, and ProofStrength.AcceptsEverything fails if one is rejected. A stub-true scheme that grows a real verifier reds until it updates this line, and a real verifier that regresses to return true reds immediately — which is the direction that matters.

What no declaration can detect. Nothing here inspects how a verifier decides, so a ProofStrength.RejectsForgeries scheme that rejects the six forgeries verifyAnswersForgedTransitionsAsDeclared derives and accepts a seventh nobody thought of is invisible. The suite tests a floor, not soundness; a real proof system needs its own adversary, not a TCK.