plan(v0.61): scope the release — "the capability exists; aim it where it is needed" (6 artifacts)

[avrabe]

Refs #1093, #1091, #1085, #1072, #1062, #1057, #242.

First release on the per-requirement layout (#1059) — six files under artifacts/release-v0.61/, one per requirement, beside the comments-only _release.yaml.

Verified empirically on the CI-pinned rivet 0.23.0 before bumping the floor: 473 → 479 with all six ids visible in rivet list and 0 OURS validation errors. So the directory is genuinely recursed rather than silently skipped — which is the #1064 shape this layout exists to prevent. ARTIFACT_FLOOR 473 → 479 in the same commit (visible-diff rule).

The theme is what v0.60 measured about itself, four times

The mechanism already exists and is pointed somewhere else.

• The strict YAML loader existed — just not on claims.yaml, the file every other claim is checked against (claims.yaml has a duplicate reason: key: a +622-line waiver is recorded with a +10-line justification, and claim_check passes #1087).
• rivet coverage runs in a required job — and prints instead of asserting (The traceability completeness gate has never fired: 60/60 release artifacts across v0.56-v0.60 have no linked sys-verification, and 'rivet coverage' prints instead of asserting #1091).
• The status gate asks whether evidence exists — never which release it came from (An artifact can be 'implemented' in vX.Y on evidence that shipped in vX.Y-1 — every gate passes and the release notes are wrong #1085).
• And now cortex-m PANICS (exit 101) on a multi-value if with block parameters — spec-suite if.wast 'params'; aarch64/rv32 decline cleanly, and --no-optimize does NOT avoid it #1093: the (params, results) arity check exists on aarch64 and on neither of the other two selectors.

That is a different failure mode from "we lacked a check", and it wants a different remedy: audit where existing gates point, rather than adding new ones.

Scope

artifact	issue	what
RQ-61-MVPANIC	#1093	two of three backends panic on a spec-suite multi-value if
RQ-61-VCLOSURE	#1091	60/60 release artifacts have no verifies link; coverage exits 0 at 40.1%
RQ-61-EVIDENCE	#1085	R7 evidence belongs to the release · R8 release: == file version · R9 gate > code path
RQ-61-IMMRANGE	#1072	six debug_assert immediate ranges compiled out in release
RQ-61-WASMOP	#1057	the proof-inventory universe misses the ops the consumer actually meets
RQ-61-CICAP	#1062	six of nine required contexts on ubuntu-latest while seven rust-cpu runners idle

A measured correction inside RQ-61-MVPANIC

The report says rv32 declines cleanly. It does not — it panics at its own site with the identical message, so this is the same defect independently present in two selectors, not one backend missing a guard. 7 of 8 invocation paths panic, --no-optimize helps nowhere (contradicting run_supported.sh's documented workaround), and (param i32 i32) appears 10 times in the if.wast that v0.60.0 vendors.

The fix is a loud decline, not multi-value support — same policy as #1013: match the existing refusal, don't invent one.

Status discipline

All six are proposed with a done-when. None is implemented — nothing has been built, and v0.60's lesson is that a status is a claim about evidence, not about intent.

Gates

status-evidence 0 failures (66 artifacts / 11 release files / 14 done-when predicates)
claim_check 52/52 · tests OK · proof_inventory --check ok
every new file duplicate-key strict-clean · _release.yaml still comments-only

🤖 Generated with Claude Code

https://claude.ai/code/session_01YJK5LZZEkV5smCY1jKn18L

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!