tests-adversarial

Adversarial test authoring

Contract

Field	Bound contract
Trigger	The work is hardening error handling, validating boundary behavior, or hunting silent failures.
Authority	Reversible-local: write test files, local artifacts, and minimal production code changes to fix silent failures discovered by the tests. Rollback by reverting the commit or deleting added files.
Side effect	Writes assumption-violation tests over inputs, ordering, timing, state, resources, and impossible cases; fixes silent failures in production code so every failure path signals; runs sanitized race-detector gates.
Done	Every documented assumption has a violation test, every failure path produces a descriptive error, and the selected sanitizers pass with zero warnings.

Inputs

• Code under test (required): source files, modules, or functions to harden.
• Language runtime and sanitizer toolchain (required): compiler, test runner, and available sanitizers (ASan, TSan, MSan, Miri, -race, or equivalent).
• Existing test suite (optional): prior tests to avoid duplication and to identify gaps.

Refusals

• Will not commit while any sanitizer warning is unresolved.
• Will not commit while silent failures remain; every failure path must produce a descriptive error.
• Will not commit while untested assumptions remain; every documented assumption needs a violation test.
• Will not accept partial results; if any gate fails, the procedure stops at that gate.

Procedure

1. Read the code under test. Understand actual behavior, not documentation claims. Done when: the code's real behavior is understood.

2. Document implicit assumptions, bounded to the error surface. For each function or module, record assumptions across six categories that affect error paths, boundary behavior, or silent failures: inputs (types, nullability, ranges, empty collections, boundary values, encoding); ordering (argument order, sequence dependencies, lifecycle ordering, concurrent call interleaving); timing (timeouts, premature delivery, clock skew, token expiry mid-operation); state (half-initialized state, shared-state corruption during operation, post-error recovery, double-close); resources (file descriptor exhaustion, disk full, permission revocation, allocation failure, connection pool saturation); impossible cases (concurrent modification during iteration, recursive re-entry, self-referential data, deep nesting overflow). Do not enumerate assumptions about correct-path behavior that the existing test suite already covers. Done when: every error-surface assumption is a named, executable check with a unique identifier.