Nine conformance vectors cannot be reissued by any key in the repository

[lywinged]

What is wrong
Nine of the thirty action-receipt conformance vectors cannot be regenerated by anything in this repository. gen_rule_coverage_vectors.py records why in its own first paragraph: “The 01-09 fixtures pin a key whose private half is not published, so everything here pins its own deterministic test key.” The generator covers 10-30.
Until #171 they also passed the reproduction check, because that check copied the committed fixtures into its work directory before running the generator, so 01-09 were compared against copies of themselves and agreed every time. #171 empties the directory first and names the nine, with the reason, in NOT_GENERATED.
Spec section or file
examples/action-receipts/conformance/01-valid-controller-accepted.json through 09-unsupported-physical-completion.json, and examples/action-receipts/conformance/gen_rule_coverage_vectors.py.
Expected behavior
Every conformance vector reproducible from a key whose private half lives in the repository, which is the pattern gen_rule_coverage_vectors.py already uses for 10-30. Applied to 01-09, NOT_GENERATED empties and the reproduction guard needs no exemptions at all.
Impact
None on conformant implementations today. The nine are read on every run by tests/test_action_receipt_fixtures.py, which globs the whole directory and puts each vector through the verifier, signature included. They are verified; they are only unreproducible.
The cost is deferred rather than absent. A vector nobody can reissue has to be hand-edited every time the spec moves under it, and the first release that revises this corpus instead of adding to it turns all nine into hand edits at once, which is the class of silent divergence #171 exists to catch. #66 and #173 are building that release.
I have deliberately not touched them: reissuing changes pinned key material in vectors other implementations may pin, so the timing belongs to whichever release already touches these files. I am happy to do the mechanical work on request.
Related: #171, #66, #173

[github-actions]

❔ Contributor Check: UNKNOWN

Check	Result
Profile	UNKNOWN
Credential	LOW
Overall	UNKNOWN

Automated check by AgenTrust Contributor Check.

[imran-siddique]

Confirmed, and yes please, with the timing you already identified.

Checked at main dba52b3. gen_rule_coverage_vectors.py says it in its own docstring at line 18: the 01-09 fixtures pin a key whose private half is not published, so everything the generator produces pins its own deterministic test key instead. The header covers 10-16 and 17-30. Nine of thirty vectors have no reissue path in this repository.

The part worth recording is why it survived. The reproduction check copied the committed fixtures into the work directory before running the generator, so 01-09 were compared against copies of themselves and agreed on every run. A guard that passes because it is comparing an artifact to itself is worse than no guard, because it reports coverage it does not have. #171 emptying the directory first is what turned an invisible gap into a named one, and that is the change that made this issue possible.

Your impact assessment is right and it is honest in the direction that costs you the argument: nothing is wrong for a conformant implementation today. tests/test_action_receipt_fixtures.py globs the whole directory and puts all thirty through the verifier with signatures checked, so the nine are verified, just not reproducible. I would rather have that framing than an inflated one.

The deferred cost is the real one. A vector nobody can reissue is hand-edited every time the spec moves under it, and the first release that revises this corpus rather than appending to it converts all nine into hand edits in a single change. Hand-edited conformance vectors are exactly the silent divergence #171 exists to catch, so the repository would be catching the class of error it had just committed.

Land it with whichever of #66 or #173 first touches these files. Your reasoning for not doing it unprompted is the reason: reissuing changes pinned key material, and another implementation may pin those vectors. Moving it once, inside a release that is already revising the corpus, means one migration for downstream rather than two, and it is announceable in that release's notes rather than arriving as a surprise diff. Doing it now as its own PR would mean the key material moves twice.

Scope when it lands, as you set out:

• Reissue 01-09 from a key whose private half is in the repository, following the pattern the generator already uses for 10-30.
• NOT_GENERATED empties, and the reproduction guard loses its exemption mechanism entirely rather than keeping one with nothing in it. An exemption list that exists but is empty grows back.
• Say in the release notes that the pinned key material for 01-09 changed, so anyone pinning those vectors upgrades deliberately.

One thing to preserve: whatever property each of 01-09 exercises has to survive the reissue unchanged. Worth asserting in tests/test_vector_completeness.py::DEFECTS on the way through, so a reissue that quietly weakens a vector fails rather than passes.

The UNKNOWN on the contributor check is the bot, not you.