Adversarial testing

Adversarial scenarios (crates/adversarial, pack adversarial) actively mutate a valid setup and require the mutation to fail the way the protocol says it must. They exist to catch unexpected acceptance: a mutated proof, witness, public input, or state that the system still accepts.

What is covered (CT-ADV-001..004)

• Proof tampering — take a valid proof reference and corrupt it; a mutated/unknown proof must fail verification (CT-ADV-001).
• Witness/public-input mutation — regenerate and re-verify while the statement changes; a proof whose public inputs no longer match must fail binding, and permuting the same public inputs must not change the verdict (binding is order-independent) (CT-ADV-002).
• Replay / stale proof — a previously consumed proof or state must be refused on reuse (CT-ADV-003).
• Public-input binding — changing a bound public input after proof generation invalidates verification (CT-ADV-004).

Failure classification

Every mutation must produce a predictable failure: tampered-proof, malformed-proof, input-binding-mismatch, state-binding-mismatch, wrong-circuit, unknown-proof. The packs assert the specific classification, so a mutation that fails for the wrong reason is caught.

Never invented semantics

Mutations only touch what the underlying model actually carries (proof references with statement/state fingerprints, public inputs, declared circuit versions). Replay behavior is asserted only to the extent the double defines it — no nonce/nullifier machinery is invented. Where the real crucible-prover replaces the double, these scenarios bind the same contracts against real verification.

Privacy

Mutation inputs are synthesized inside the scenario; adversarial runs never print or log witness material.