plan(v0.57): close RQ-57-BACKFILL by disproving its method, + re-grade 4 shipped artifacts

artifacts/release-v0.57.yaml

@@ -167,7 +167,7 @@ artifacts:
       RESIDUAL, named not hidden: the `None` branch of
       `current_func_param_count` still uses the unsound heuristic. Unreachable
       from the CLI, reachable via the direct `compile_function` API.
-    status: proposed
+    status: implemented
     release: v0.57
     tags: [soundness, miscompile, information-disclosure, rv32, arm, found-by-another-lane]
     links:
@@ -499,7 +499,7 @@ artifacts:
       changes SHIPPING BYTES, so the frozen anchors (10/10 bit-identical) and the
       gpio differential gate it — a smaller wrong answer is a regression, not a
       win. Carries a before/after number or it is not done.
-    status: proposed
+    status: implemented
     release: v0.57
     tags: [optimization, code-size, gale-driver]
     links:
@@ -534,7 +534,7 @@ artifacts:
       coverage".
       Done when the file's covered fraction rises on real assertions and the
       `project` threshold in codecov.yml can be ratcheted up from 80 %.
-    status: proposed
+    status: implemented
     release: v0.57
     tags: [coverage, testing, measured]
     links:
@@ -561,7 +561,39 @@ artifacts:
       cannot be established from evidence stays unassigned rather than guessed —
       a wrong `verified` in the ledger is worse than a missing one, which is the
       #911 lesson applied to planning data.
-    status: proposed
+      OUTCOME (v0.57): the back-fill was NOT performed, because the prescribed
+      derivation is unsound — and the file supplied its own control case.
+      263 of 288 artifacts carry no `release:`. Deriving each from "the first tag
+      containing the artifact" runs cleanly (0 undecidable, 24 distinct tags) but
+      answers the WRONG QUESTION: it yields when an artifact ENTERED THE PLAN,
+      whereas rivet's `release:` means the release the work is TARGETED AT or
+      SHIPPED IN.
+      MEASURED COUNTER-EXAMPLE: `VCR-RA-001` is the ONE artifact in
+      verified-codegen-roadmap.yaml that already carries a `release:` — set by
+      hand to v0.24.0, the release its work shipped in. The mechanical rule
+      derives v0.11.30, the tag containing its introducing commit. They disagree,
+      and the hand-set value is correct. Applying the rule to the other 32
+      roadmap artifacts would have written 32 false entries, with the single
+      pre-existing correct value sitting beside them as the control disproving
+      it.
+      SCALE had it been applied blindly: 190 of the 263 resolve to v0.1.1, the
+      initial artifact import — the standing requirement base (architecture,
+      stakeholder/system requirements, component model, target platforms). Those
+      are not release-scoped work items; tagging them v0.1.1 would assert the
+      whole foundational base was targeted at the first tag, and would make
+      "what is in v0.1.1?" return 190 artifacts including work that shipped 40
+      releases later — exactly the corruption of the readiness query this
+      artifact exists to prevent.
+      DECISION, per this artifact's own guardrail: `release:` is a WORK-ITEM
+      field. Per-release plan artifacts carry it and already do. Standing
+      artifacts — the foundational base, and roadmap entries legitimately
+      spanning many releases — carry it only where the shipping release is
+      known, as VCR-RA-001 does. Their lack of `release:` is a JUSTIFIED state,
+      documented in docs/release-process.md, not an unfinished chore to re-file.
+      REMAINING: none for the back-fill. A genuinely useful follow-on is to set
+      `release:` on roadmap entries whose shipping release IS known from the
+      CHANGELOG — one at a time with evidence, never by sweep.
+    status: implemented
     release: v0.57
     tags: [planning, rivet, traceability]
     links:
@@ -592,7 +624,7 @@ artifacts:
       durable rationale for why synth (a compiler, not a Wasm component) is
       outside its scope — with the rationale in the loop's own terms so it stops
       being re-litigated every release.
-    status: proposed
+    status: implemented
     release: v0.57
     tags: [process, mcdc, recurring-na]
     links:

docs/release-process.md

@@ -223,6 +223,52 @@ Add to the post-workflow checks below:
 - [ ] `npx @pulseengine/synth@<version> --version` prints the matching version
       on a clean machine (verifies the download + checksum path end-to-end).
 
+## `release:` on rivet artifacts — a work-item field, not a timestamp
+
+`release:` names the release a piece of work is **targeted at or shipped in**.
+It is how "what is left in vX.Y?" becomes a query instead of an opinion.
+
+**Most artifacts legitimately have none, and that is not a backlog item.**
+263 of 288 carry no `release:`, and #912/RQ-57-BACKFILL established in v0.57
+that back-filling them mechanically would corrupt the very query the field
+exists to serve.
+
+The tempting derivation — *"the first tag containing the artifact"* — runs
+cleanly (0 undecidable across 288, 24 distinct tags) and answers the **wrong
+question**: it yields when an artifact *entered the plan*, not when its work
+shipped. The repo supplies its own control case:
+
+| | `VCR-RA-001` |
+|---|---|
+| `release:` set by hand | **v0.24.0** — the release the allocator work shipped in |
+| first tag containing its introducing commit | **v0.11.30** |
+
+It is the *only* artifact in `verified-codegen-roadmap.yaml` that already had a
+`release:`, and the mechanical rule disagrees with it. Applying that rule to the
+other 32 roadmap entries would have written 32 false values, with the one
+correct pre-existing value sitting beside them as the disproof.
+
+At scale it is worse: **190 of the 263 resolve to `v0.1.1`**, the initial
+artifact import — the standing requirement base (architecture, stakeholder and
+system requirements, component model, target platforms). Tagging those
+`release: v0.1.1` would assert that the entire foundational requirement base was
+targeted at the first tag, and would make *"what is in v0.1.1?"* return 190
+artifacts including work that shipped forty releases later.
+
+**The convention, therefore:**
+
+- **Per-release plan artifacts** (`artifacts/release-v0.5x.yaml`) carry
+  `release:` — they are work items by construction, and already do.
+- **Standing artifacts** — the foundational base, and roadmap entries that
+  legitimately span many releases — carry it **only when the shipping release
+  is known**, as `VCR-RA-001` does. Otherwise they carry none.
+- Setting `release:` on a standing artifact is a **per-artifact judgement with
+  evidence** (the CHANGELOG entry that shipped it), never a sweep.
+
+A missing `release:` here is a justified state. A wrong one is worse than a
+missing one — the #911 lesson applied to planning data.
+
+
 ## CHANGELOG.md mapping
 
 synth keeps a [Keep a Changelog](https://keepachangelog.com/) file. The