From 03465e7fddb6f0deaa0209c8238d3d6687d11589 Mon Sep 17 00:00:00 2001 From: Ralf Anton Beier Date: Fri, 14 Aug 2026 20:33:43 +0200 Subject: [PATCH] plan(v0.57): close RQ-57-BACKFILL by DISPROVING its method, + re-grade 4 shipped MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two things. The re-grades are bookkeeping; the back-fill is a finding. RE-GRADED to `implemented` (work merged on main): RQ-57-COUNTPARAMS #970 (#974) ARM+RV32 conditional-param miscompile RQ-57-GPIO #846 (#976) gpio-thin 502 -> 494 B RQ-57-ARMSEM #923 (#975) ArmSemantics no-oped 87 of 222 ops RQ-57-MCDC #912 (#978) MC/DC over synth's own decision logic RQ-57-BACKFILL: the back-fill was NOT performed, on evidence. 263 of 288 artifacts carry no `release:`. The prescribed derivation — "the first tag containing the artifact" — RUNS FINE (0 undecidable, 24 distinct tags) and answers the WRONG QUESTION. It yields when an artifact ENTERED THE PLAN; `release:` means the release the work is TARGETED AT or SHIPPED IN. The file supplied its own control case, which is what settles it: VCR-RA-001, hand-set release: v0.24.0 <- when the work shipped VCR-RA-001, mechanical rule v0.11.30 <- introducing commit's tag It is the ONLY artifact in verified-codegen-roadmap.yaml that already carried a `release:`, and the rule contradicts it. Sweeping the other 32 would have written 32 false values with the one correct value sitting beside them as the disproof. Scale, had it been applied blindly: 190 of the 263 resolve to v0.1.1 — the initial import, i.e. the standing requirement base (architecture, stakeholder and system requirements, component model, target platforms). Tagging those v0.1.1 asserts the whole foundational base was targeted at the first tag, and makes "what is in v0.1.1?" return 190 artifacts including work that shipped forty releases later. That is the corruption of the readiness query this artifact exists to prevent — so the artifact's own guardrail ("stays unassigned rather than guessed", the #911 lesson applied to planning data) decides it. CONVENTION, now documented in docs/release-process.md so the absence stops being re-filed as an unfinished chore: * per-release plan artifacts carry `release:` (they are work items; they do) * standing artifacts carry it ONLY where the shipping release is known, as VCR-RA-001 does * setting it on a standing artifact is a per-artifact judgement with CHANGELOG evidence, never a sweep A missing `release:` is a justified state. A wrong one is worse than a missing one. rivet: 50 errors / 166 warnings before AND after — unchanged. claim_check 43/43. Refs #912 Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01YJK5LZZEkV5smCY1jKn18L --- artifacts/release-v0.57.yaml | 42 ++++++++++++++++++++++++++++---- docs/release-process.md | 46 ++++++++++++++++++++++++++++++++++++ 2 files changed, 83 insertions(+), 5 deletions(-) diff --git a/artifacts/release-v0.57.yaml b/artifacts/release-v0.57.yaml index ebb31b49..2e1f9677 100644 --- a/artifacts/release-v0.57.yaml +++ b/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: diff --git a/docs/release-process.md b/docs/release-process.md index a337dc2f..56fb8ce5 100644 --- a/docs/release-process.md +++ b/docs/release-process.md @@ -223,6 +223,52 @@ Add to the post-workflow checks below: - [ ] `npx @pulseengine/synth@ --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