audit/mutation-test-scans.json holds one record 35 commits and 5 published tags behind HEAD, with no stated ordering rule

[thedavidmeister]

Audit scope: whole-repo, commit 7aa85a4

Recovered from the docs/process/CI reviewer's report (its finding D6); dimension 0 (process), severity low.

Distinct from the testsAfter finding on the same file: that one is a wrong value plus a missing schema field, this one is that the ledger has not been re-run since, and that nothing in the file says whether its last element is authoritative.

Where

audit/mutation-test-scans.json:1-22

Problem

The file is a JSON array with exactly one record, for sol-v0.1.6 / c72eb89. Everything merged since — including the ten fix PRs the record's own filed list points at, and PRs #49-#54 — is unprobed by any ledgered scan. Because the file is a bare array with no stated ordering rule, a stale single entry is indistinguishable from a current one without reading commit yourself and comparing it to HEAD.

Measured

• The sole record's commit is c72eb89b029c9c7733d4c6deff849cc5da93dd5b, publishedTag: "sol-v0.1.6", commitsAheadOfTag: 0.
• git rev-list --count c72eb89..HEAD = 35 commits.
• Five published tags land after sol-v0.1.6: sol-v0.1.7, sol-v0.1.8, sol-v0.1.9, sol-v0.1.10, sol-v0.1.11. foundry.toml:3 declares the next unpublished version, 0.1.12.
• Test functions: testsBefore: 9 in the record; grep -rhoE '^\s*function (test|invariant)[A-Za-z0-9_]*' test/ | wc -l at HEAD = 134.

(The reviewer reported 30 commits and 6 versions; re-measured at 7aa85a4 the counts are 35 commits and 5 published tags after sol-v0.1.6.)

Proposed fix

Re-run the campaign at HEAD and append a second record. Do not edit the c72eb89 entry — it is a historical fact about that tree.

If the array is meant to be read as "the most recent entry describes current coverage", state that ordering rule in the file itself — a "records" object with the invariant documented, or a sibling audit/README.md line — so a reader knows whether the last element is authoritative rather than having to diff commit against HEAD to find out.

[thedavidmeister]

Closing: the half of this that is a defect belongs to the producer, not to this repo.

audit/mutation-test-scans.json is written by the adversarial-mutation-test
skill, and the missing ordering rule is a property of the format that skill
specifies, not of this repo's copy of it. Every repo running a campaign gets the
same bare array with the same unstated read rule, so fixing it here would state
an org-wide invariant in one consumer and leave every other consumer to
rediscover it.

Filed at the producer with the evidence measured here:
rainlanguage/adversarial-mutation-test#25

That issue covers the ordering and authority rule, the tie-break, a schema
version distinct from skillVersion (the 0.30.0 summary shape and the
0.33.0 template share only filed), and the migration rule for the bare array
this repo already has committed.

The other half of this issue — that the ledger has not been re-run since
c72eb89, 35 commits and 5 published tags back — is not a defect to fix in a
file. It is resolved by running a campaign at HEAD and appending a record, under
whatever format the producer settles on.

Sibling, still open, same file and same shape (the schema does not let a reader
check what it asserts): #86, producer-side half at
rainlanguage/adversarial-mutation-test#23