No first-class `release:` field on artifacts — release planning falls back to tag conventions

[avrabe]

Friction

Doing release planning on synth (assign requirements to releases, query readiness as "which artifacts in release: vX.Y are not yet verified"), I expected a first-class release: attribute on artifacts — the status lifecycle (draft → … → verified → accepted) implies a release-planning workflow, but there is nothing to scope an artifact to a release:

• rivet schema show sw-req (rivet 0.15.0): fields are req-type / priority / verification-criteria — no release.
• rivet list filters by --type / --status / --filter s-expression — no release dimension.

Workaround used

Tag convention: release-v0.11.35 etc. in tags:, queried via

rivet list --filter '(has-tag "release-v0.11.35")'

It works, but it's stringly-typed: no validation that the release exists, no burn-down view (rivet release status v0.11.35 → N verified / M total), no "unassigned = backlog" semantics, and scope moves (re-targeting an artifact to a later release) are invisible diff noise rather than a logged scope decision.

What would close the gap

1. A core optional release: field on all artifact types (like status), plus rivet list --release vX.Y.
2. A readiness query: rivet release status vX.Y → per-status counts + the not-yet-verified set (the release is cuttable when zero).
3. (Nice) rivet release move <id> vX.Z that logs the scope change.

Context: synth release planning, rivet 0.15.0 (f66362b). Related friction: #510 (standards presets). Filed via report-tool-friction.

[avrabe]

Triage pass (issue-triage agent run 2026-06-10).

Likely already addressed — flagging as a possible duplicate of #512 before asking for AC. Per the 2026-06-09 comment on #512, rivet already has a schema-declared, queryable version field: baseline, on requirement/decision/feature types (243 artifacts on main use it, with the vX.Y.Z-track → vX.Y.Z convention). It supports exactly the workflow this issue describes:

rivet modify SR-NNN --set-field baseline=v0.11.35-track
rivet list --filter '(= baseline "v0.11.35-track")' --format json

The maintainer's call on #512 was to document that baseline IS the release field rather than add a parallel release field (which would fragment the convention into two competing version tags — and in a safety context baseline carries deliberate config-baseline meaning). That doc fix is pending in the AGENTS.md PR per the #512 thread.

So before AC: would you close this in favour of #512 + the AGENTS.md doc change (recommended — the workflow in your ## What would close the gap is achievable today via baseline), or do you specifically want a parallel release: field on top? If the latter, then this needs its own ## Acceptance Criteria block and a rationale for why baseline doesn't fit synth's release planning.

Sketch if you do want a separate release: field (replace if going the close-as-dup route):

## Acceptance Criteria — only if `baseline` is not sufficient
- [ ] Document why `baseline` doesn't fit (e.g. need to track config-baseline AND release-target independently); link from this issue
- [ ] `schemas/common.yaml` (or appropriate per-type schema) declares an optional `release:` field on the requirement family
- [ ] `rivet validate` no longer emits the INFO `field 'release' is not defined` when a top-level `release:` is set (test fixture)
- [ ] `rivet list --release vX.Y` sugar over `--filter '(= release "vX.Y")'` (test fixture)
- [ ] `rivet release status vX.Y` → per-status counts + the not-yet-verified set (golden-file test)
- [ ] Commit trailers: `Implements: REQ-NNN` + `Refs: #512`
- [ ] **Explicitly out of scope:** the third bullet of your body (`rivet release move` + scope-change log) — file separately

Process side-rail (carried from prior triage threads): https://pulseengine.eu/blog/ is still HTTP 503 (expired TLS). The binding workflow guidance can't be consulted, so no PR will land from this triage run regardless. Comment is the close-vs-AC ask only.

Not implemented this run.

---

Generated by Claude Code — issue-triage agent run 2026-06-10.

---

Generated by Claude Code