[E13] Acceptance checks do not ask what else is of the same class

[TheAmericanMaker]

Problem

Three independent review rounds have now produced the same pattern:

Round	Reviewer found	Fix closed	Same class still open
E03 round 1	repository digested verbatim	repository shape-checked	executable still coerced
E03 round 2	executable coerced to false	non-booleans refused	— (swept)
B01 review	GIT_CONFIG_COUNT not neutralized	COUNT=0 added	GIT_CONFIG_PARAMETERS still live

In each case the fix was correct and verified, CI was green, and the author believed the work complete. In each case a defect of the same kind remained one identifier away. E03 round 2 found the executable collision only because a second review ran; B01's GIT_CONFIG_PARAMETERS gap reproduced the original failure byte-for-byte on a branch whose author had just declared it fixed.

The contract's acceptance checks are good at asking "did you fix the reported thing, and can you prove it." They do not ask "what else of this kind exists."

What this is not

Not a request for speculative hardening, and not a mandate to widen every fix. A change that grows without bound is its own defect — B01 deliberately left GIT_TEMPLATE_DIR out of scope and recorded it instead. The gap is the absence of a recorded answer, not the absence of a broader fix.

Proposed check

Add to the acceptance-check vocabulary a requirement along these lines:

Class sweep. For each defect a review finds, the implementer records what class it belongs to, what other instances of that class exist in the changed surface, and for each instance either closed it or stated why it is out of scope. An unanswered class is a blocking finding.

Concretely, for the three cases above the answers would have been:

• "repository was digested without validation" → class: inputs that reach the digest without a shape check → sweep entries, excluded, uncovered_relevant_inputs, repository → would have found executable in round 1.
• "GIT_CONFIG_COUNT is not neutralized" → class: environment-reachable git config sources → enumerate all four → would have found GIT_CONFIG_PARAMETERS before review.

Both sweeps are cheap. Neither requires guessing at hypothetical attacks; they require enumerating a surface the implementer already has open.

Scope

Contract/doc change plus, if warranted, a field on the review record so the sweep is recorded rather than asserted in prose. No change to record schemas or trust classification. Should not block E02.

Evidence

• B01 pilot report, section "What this says about the contract"
• PR feat: bind records to stable input and candidate snapshots (E03) #420 commits a63fa75 (round 1) and b9c43b2 (round 2)
• PR fix(tests): isolate git config injected through the environment (B01 pilot) #421 commits 15fee9e (initial fix) and d631c4a (class gap closed)

[TheAmericanMaker]

Shipped in 18eb019 (PR #425). Post-merge CI green.

R11 is in the rubric as a hard gate, and ReviewObjection.class_sweep carries the answer in the record — a gate nothing can record against is decoration.

The schema refuses four ways a sweep could be claimed without being done: an empty instances list, an out-of-scope instance with no note, a note on a closed instance (the field means why this was not done), and a repeated locus (listing one place five times is not enumerating a surface). It routes through the same object gate as every other record field, so non-plain objects and unknown keys are refused too.

The gate caught its own implementation. The first version of the validator was hand-rolled and bypassed checkObject, so a prototype-backed sweep validated ok:true and then serialized to {} — a record that validated and stored with the sweep silently gone. Independent review found it. Applying R11 to itself: the class is "hand-rolled Check that inspects an object without checkObject", the swept surface is validation.ts, and the instances are classSweep (closed) and isPlainObject's own guard (out of scope — it is the primitive).

That is the clearest evidence this issue was worth filing: the defect R11 describes appeared in R11's own code, written by someone who had just spent an hour writing about the pattern.

Two things this deliberately does not do.

class_sweep is optional, and nothing in the code enforces R11. A review that omits it is a valid record with an R11 finding against it, not a malformed one. The contract now says so explicitly, because remaining_blockers sits one row above in the same table and is derived, which invited the opposite reading.

The rubric now defines the swept surface — the file or module the defect was found in, plus every call site of the function that carried it. A gate that makes an unanswered class blocking cannot rest on an undefined phrase: ambiguity would push implementers toward the narrowest defensible class to avoid a merge block, which is the behaviour R11 exists to stop.

Known limitation, recorded rather than hidden: the sweep hangs off an individual objection. A class spanning several objections is recorded once on the objection that named it, with the siblings citing it. A review with no objections has nothing to attach a sweep to; that belongs in the review summary until a record-level class_sweeps[] exists.

Verified: 27/27 contract tests, 1009/1009 full suite, build exit 0, five mutation checks bite.