feat(v0.55.0): validate by default on shared memory; stop publishing empty releases

[avrabe]

Two things jess reported that I had not acted on, plus her deferred ask.

1. --memory shared validates its own output by default (#390, #391)

Her ask, deferred from #390 because it was a behaviour change rather than the defect. She declined to open it unilaterally, so it went onto #391 with her reasoning attached; this implements it.

The single-address-space paths now run the fused module through wasmparser before writing it. --no-validate opts out; --validate still forces it anywhere; the two conflict rather than resolving silently.

That is where meld rewrites most invasively, and where both recent defects surfaced — #390 emitted invalid wasm at exit 0, #393 emitted a module that validated and returned the wrong number. In her words: she would have caught the first months earlier had this been the default. Cost is one wasmparser pass over an artifact already in memory.

A module that fails validation is not written. Previously the invalid artifact reached disk and failed later, in whatever consumed it.

Potency, established by making it fire

Routing verified across five invocations. Then the control that matters — reintroduce #390 and disable the v0.53.0 wiring backstop, so an invalid module is actually produced and validation is the only guard left:

Validating output (implied by --memory shared; --no-validate to skip)...
Error: Validation failed
Caused by: type mismatch: expected f32, found i32 (at offset 0xea)
→ no file written

Worth recording that the first attempt at that control never reached validation: the wiring backstop caught the defect earlier. Defense in depth behaving correctly — and a reminder that a control passing for the wrong reason proves nothing.

2. Releases are no longer published before their artifacts exist (#395)

She caught v0.53.0 public with one asset — the compliance report — and fetched it in that state.

Cause was the documented process racing its own pipeline. release.yml creates the release itself; AGENTS.md told a human to run gh release create right after the tag push, which publishes immediately. compliance.yml triggers on release: published, so it fired at once and uploaded its report while release.yml was still queued behind a busy fleet. That is precisely the state she saw.

• Process: create as a draft, let the pipeline upload into it, verify checksums and the cosign signature, then gh release edit --draft=false. Nothing public until complete and verified.
• Gate: release-assets-gate.yml fails on publish if the four platform tarballs, SHA256SUMS.txt or the cosign bundle are missing.

The gate reports rather than prevents — GitHub has no pre-publish hook — and that limit is written into the workflow rather than left to be discovered. A documented step nobody verifies is the same inert-gate class this repo has now hit three times; the process fix alone would have been a fourth.

Traceability

SR-73 + SWV-85, advanced by rivet verify with evidence. The decision is extracted into a total function with its implication table enumerated — six cases, not a sample — which is the treatment meld#397 argues these seams deserve.

Note the release-readiness gate from #394 did its job: rivet release status v0.55.0 exited 1 with "no artifacts scoped", which is what forced this requirement to exist for a change small enough to have skipped it.

Gate

fmt clean, clippy -D warnings clean, 879 (--workspace) / 878 (--all-features), both exit 0. rivet validate PASS, v0.55.0 cuttable.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WrmMqf1iuTS1UBEes5TmdC

[github-actions]

LS-N verification gate

✅ 59/59 approved LS entries verified

	count
Passed (≥1 test, all green)	59
Failed (≥1 test failure)	0
Missing (no ls_*_NN_* test found)	0

_{Approved loss-scenarios.yaml entries are expected to have a
regression test named ls_<letter>_<num>_* (e.g. LS-A-11 →
ls_a_11_*). The gate runs each prefix via cargo test --lib --no-fail-fast and aggregates pass/fail/missing.}

Failed LS entries

(none)

Missing regression tests

(none)

_{Updated automatically by tools/post_verification_comment.py.
Source of truth: safety/stpa/loss-scenarios.yaml.}