ExactWidthField

One documented fixed-width field on a wire type, plus the rig that builds a frame carrying that field at an arbitrary width.

The field is identified by its rig, not by an offset: a codec's fields sit at positions only the codec knows, and several of the in-tree ones (a CBOR byte string, a trailing nonce behind a variable-length id) have no fixed offset at all.

What encodeAtWidth owes, and the one way it goes vacuous

encodeAtWidth(w) must return a frame that is well-formed in every respect except that this field is w bytes wide. For a raw, self-describing layout that is byte surgery on the field's range. For a length-delimited encoding (CBOR, protobuf, anything with a length header in front of the field) it is not: truncating the field's bytes without moving its length header leaves the parser with a short read, and the parser rejects it. The property then passes with the width check deleted — which is the whole failure this suite exists to catch, reappearing one level up inside the rig.

So for a length-delimited encoding, re-encode: run the codec's own serializer over a surrogate that is not width-constrained, and let it emit a correct length header for w. See TapAdmitChallengeWireCodecTest for the worked example.

WireCodecConformanceSuite.everyExactWidthFieldsRigVariesTheWidthAndNothingElse checks what it can of this — that the rig's frames grow strictly with w, and that the codec accepts the frame at the declared width — but it cannot see why a wrong-width frame was refused. Only reverting the codec's width check and watching this suite go red establishes that, which is the evidence a new harness owes alongside a new declaration (#1822).