plan(v0.37): file REQ-327 — rivet cannot state what a release contains - #900

Artifact only. Design grounded in Automotive SPICE PAM v4.1 (VDA QMC),
process SPL.2 Product Release — not in anything invented here.

SPL.2 purpose: to control the release of a product to the intended customer.
BP6: Provide a release note. BP5: Ensure the release approval before the delivery.

Information item 11-03 Release note is the specification

Identifies: functionalities provided · limitations in relation to the
committed scope · known non-conformities · application parameters ·
configurations and variants · unique name and version · added/removed
functionalities · changed/improved functionalities · documentation of resolved
non-conformities

Includes: intended area and environment of usage · impact to other linked
components · upstream/downstream compatibility · copyright and license
information · result of verification and validation measures · approval for
delivery by responsible roles · dependencies to other linked products

Two of the four sections chosen before reading the PAM turn out to be
mandated, not optional: limitations in relation to the committed scope is the
notes-vs-query diff already run by hand (and already responsible for catching
drift twice), and known non-conformities is the residuals section.

The standard treats declared gaps as first-class release-note content. That
explains why a mock-up over real v0.36.0 data had an absence as its
highest-signal line: external references: 0 of 10 declared.

Three elements I'd missed, each already backed by evidence rivet produces:

supply-chain.yaml already models the release — and rivet doesn't use it

release-artifact (artifact-name, version, digest, signing-status, contains →
sbom-component), build-attestation, vulnerability (cve-id, severity,
cvss-score, vuln-status, remediation).

Every field maps to something v0.36.0 produced and discarded: a CycloneDX
SBOM, a cosign bundle + pem + sig, per-asset SHA256 digests I verified by hand,
and 15 cargo audit --ignore entries — which are exactly
declared-unresolved vulnerabilities, each carrying a written rationale, living
in a workflow file where no reader will find them.

Decisions recorded

• rivet emits release-artifact and vulnerability artifacts per release
  rather than only reporting over them — its supply-chain evidence becomes part
  of the trace, and supply-chain.yaml gets dogfooded by its author.
• Linkage reuses cited-source (uri/kind/sha256/last-checked; oslc and
  polarion cover Jira and DOORS) rather than a new directive.
• Links are never inferred. An artifact without one renders as an explicit
  gap — regexing #NNN out of prose would both miss a Jira ticket and invent
  links from stray text.

Blocker to fix first: rivet list --format json exposes only id, links, status, title, type and the release field, so the mock-up had to parse raw YAML
for cited-source and provenance and scrape coverage --tests text.

Not modelled anywhere yet, also produced by SPL.2: 11-04 product release
package, 13-06 delivery evidence, 13-13 product release approval, and 18-06
product release criteria — the last being "conditions to be satisfied prior to
authorization of a product for delivery", which is what the release-readiness
query already computes informally.

rivet is the first consumer.