release status: cuttability is status-only — misses link-based (V-model / ASPICE) verification

[avrabe]

rivet release status cuttability is status-only — misses link-based (V-model) verification

Tool: rivet 0.22.0, release status (#516). Consumer: gale (ASIL-D, 967 artifacts, ASPICE + STPA + safety-case).

What happened

Adopting the new release-handling on gale: scoped a 16-artifact vertical to release: v0.1.0, ran rivet release status v0.1.0. The burn-down view + move + list --release + json output are all great. But cuttability is decided purely by status ∈ {verified, accepted}, and gale has zero artifacts in those statuses — by design.

all gale statuses: {draft:53, approved:869, proposed:30, active:12, resolved:3}
verified/accepted: 0

gale (like any ASPICE/V-model project) expresses verification through links, not a status value: a requirement sits at terminal status approved and is "verified" by a verified-by / verified-on link to a passing verification artifact — exactly what rivet validate's coverage rules already check (e.g. "every sw-req verified by ≥1 verification measure"). So release status reports ✗ NOT cuttable even for a fully-closed-V release, because no artifact will ever carry status: verified.

Net: as shipped, the cuttability gate (the headline CI-gating feature — exits non-zero) can never go green on a link-verification project. The burn-down counts are still useful; the verdict isn't.

Suggestion

Make "release-ready" derive from the schema/lifecycle rather than two hardcoded strings. Options, any of which unblocks the hard-gate use:

1. Schema-aware terminal states — honor per-type lifecycle terminals (you already made status per-type in Per-schema status enum for ai-found-defect (open/triaged/resolved) — slice 3 of #522; blocks downstream upgrade off 0.15.0 #550). For gale, approved is terminal for a requirement.
2. Link/coverage-based readiness — an artifact is release-ready when its validate coverage rules pass (the V is closed), not when a status string matches. This is the most correct for V-model projects and reuses logic validate already has.
3. Configurable — a release.ready-when list in rivet.yaml (statuses and/or "coverage-clean").

Happy to test a build against gale's real artifact set the moment any of these lands — gale is a live ASPICE consumer with the link-based model this would serve.

Workaround (current)

gale wires rivet validate (the real V-gate) as the blocking release gate and runs rivet release status as a non-blocking burn-down view, pending this fix.

[avrabe]

Great catch, and exactly right — the cuttability verdict is status-only (verified/accepted) while V-model/ASPICE projects (gale) express verification through links, so the headline gate can never go green for them. The counts are fine; the verdict isn't.

This is a perfect fit for the in-flight v0.23 "traceability evidence" theme, and your option #2 (link/coverage-based readiness — an artifact is release-ready when its validate coverage rules pass / the V is closed) is the most correct and reuses logic validate already has. I'm filing it as a v0.23 requirement so rivet release status derives cuttability from coverage, not two hardcoded strings — with a release.ready-when escape hatch (your option #3) for projects that want explicit control. Will ping you for a build against gale's real 967-artifact set the moment it lands.