[safer:implement-staff] Phase 2A vectors — two independent encoders, byte-equal

[chughtapan]

Parent: #888
Modality: implement-staff
Depends on: #891 (PR #893, the six-package skeleton) — the corpus and the encoders need somewhere to live.

The specification is already written

docs/spec/wire-profile.md section 12 is normative and exhaustive. It fixes the corpus so, in its own words, "its author chooses nothing." Read it and implement it. Do not redesign it, do not sample it, do not decide anything it already decided.

• 12.1 Fixture material — every seed, identifier, name, and timestamp is a fixed constant. No vector may use a random value, a wall-clock read, or a locally chosen constant.
• 12.2 Positive vectors — 16 enumerated structure families, from AgentCard DER through every result-union arm to every JSON document of section 11 in its exact presented property order.
• 12.3 Negative vectors — exactly one per rejection class, across ten families: CBOR determinism, unions, identifiers, AgentName, X.509, COSE, certificate admission, HTTP envelope, cursors, MCP. Roughly 150 classes, each individually named.
• 12.4 CI obligations — six conditions under which CI MUST fail.

The load-bearing requirement

The positive corpus MUST be generated by two independent encoders and MUST be byte-equal between them. "Independent" means the two encoders do not share a CBOR, DER, COSE, or canonicalization implementation and do not read each other's output.

Two wrappers over one library is not two encoders. If you find yourself reaching for the same cbor package twice, stop — that defeats the entire mechanism. The byte-equality check is what verifies the catalog itself; a shared implementation makes agreement meaningless because both sides inherit the same bug.

Both independent decoders must accept every positive vector and reproduce the fixture values, and must reject every negative vector with exactly the recorded outcome. Section 12.3 is explicit: "'Rejected' alone is not an expected outcome." A decoder that rejects for the wrong reason fails the vector.

CI obligations, verbatim from 12.4

CI must fail when: the positive corpus is empty or any 12.2 structure lacks a vector; the two encoders disagree on any bytes; either decoder rejects a positive, accepts a negative, or produces an unrecorded outcome; any 12.3 rejection class lacks a vector; a wire constant appears in implementation source without appearing in the catalog; or a schema exists only in implementation source.

Prove each of these six can fail. Break one condition at a time, capture the non-zero exit, restore it. Evidence in the PR body. This repo has shipped three gates in one week that passed while inspecting nothing — a docs gate walking an empty tree, five swallowed-error paths printing PASS on unread files, and a manifest warning about vacuous passes in its own text. Obligation 1 exists precisely because an empty corpus would otherwise look identical to a passing one.

Why this matters more than a normal test suite

This corpus is what verifies the catalog. Nothing else does — the catalog merged without a separate review pass, by design, because per the approved plan a byte contract is verified by independent reimplementation rather than by reading. Every downstream lane consumes these bytes, and section 12's own rationale notes that unanimity makes disagreement a liveness failure rather than a decoding warning: an action certificate is valid only if every member agrees byte for byte.

If, while implementing, you find the catalog underspecifies something — two readings produce different bytes — that is a catalog defect, not your choice to make. The catalog says so itself: "A constant absent from the catalog is a catalog defect, never an implementation choice." Stop and escalate on this issue.

Scope

The corpus, the two encoders, the two decoders, and the CI wiring. No product implementation — the plan keeps product, protocol, simulator-port, client, and server implementation blocked until these vectors pass.

Do not edit docs/spec/wire-profile.md or any other frozen document.

Status

planning

[chughtapan]

[chughtapan]

Correction from the orchestrator. I wrote "nine families" for §12.3 in this issue and in the dispatch brief. The chapter lists ten. Caught by impl-896; verified against docs/spec/wire-profile.md on v2. Issue body corrected. Ten is authoritative.

Three catalog defects found from inside the implementation, routed to architect-892 to batch into the fix PR now in progress:

1. §12.3's outcome vocabulary has no arm for a recipient refusing an L1 message, yet the COSE family mandates five UnsignedMessage flipped-bit vectors and §12.3 requires each to name an exact outcome.
2. §9.3 assigns no row to a present Content-Encoding, which §9.1 forbids and §12.3 requires a vector for.
3. §9.3 assigns no distinct row to a Content-Digest algorithm other than sha-256.

These are additive to the five architect-892 found by cold reading — almost no overlap. Its five came from reading the chapter; these three came from trying to emit bytes and finding nothing to emit.