Found by the v0.53.0 cold review. Traceability/evidence-artifact defects only — no runtime impact, rivet CI stays green — but they corrupt the roadmap as an evidence artifact, which is the thing it exists to be.
1. VCR-RA-004 ID reuse. artifacts/verified-codegen-roadmap.yaml:2067-2083 defines VCR-RA-004 as "Cycle-safe parallel-move resolver for spill/reload insertion", status: proposed. v0.53 lane L1 (#885, PR body and commit titles) tagged the VFP register-file spilling work as VCR-RA-004. Different capability, and the roadmap entry is still proposed — so the roadmap now says a thing is unstarted while the changelog says it shipped.
Either give the VFP spilling work its own ID and leave VCR-RA-004 proposed, or — if the parallel-move resolver genuinely landed as part of L1 — flip the roadmap entry to implemented with its evidence. What is not acceptable is the current state, where the same ID means two things depending on which document you read.
2. VCR-SEL-005 description is stale. The roadmap entry (line ~506ff) still says the parity gate spans "BOTH the ARM (Thumb-2) and RISC-V (RV32IMAC) selectors". As of #883/#889 it spans three backends — aarch64 was added as a universe-complete, no-wildcard third column, which was the entire point of that work.
Both are one-line fixes; filing rather than patching so the change lands with a deliberate decision about (1) rather than a guess.
Found by the v0.53.0 cold review. Traceability/evidence-artifact defects only — no runtime impact, rivet CI stays green — but they corrupt the roadmap as an evidence artifact, which is the thing it exists to be.
1.
VCR-RA-004ID reuse.artifacts/verified-codegen-roadmap.yaml:2067-2083definesVCR-RA-004as "Cycle-safe parallel-move resolver for spill/reload insertion",status: proposed. v0.53 lane L1 (#885, PR body and commit titles) tagged the VFP register-file spilling work asVCR-RA-004. Different capability, and the roadmap entry is stillproposed— so the roadmap now says a thing is unstarted while the changelog says it shipped.Either give the VFP spilling work its own ID and leave
VCR-RA-004proposed, or — if the parallel-move resolver genuinely landed as part of L1 — flip the roadmap entry to implemented with its evidence. What is not acceptable is the current state, where the same ID means two things depending on which document you read.2.
VCR-SEL-005description is stale. The roadmap entry (line ~506ff) still says the parity gate spans "BOTH the ARM (Thumb-2) and RISC-V (RV32IMAC) selectors". As of #883/#889 it spans three backends — aarch64 was added as a universe-complete, no-wildcard third column, which was the entire point of that work.Both are one-line fixes; filing rather than patching so the change lands with a deliberate decision about (1) rather than a guess.