check_release_plane.py: generalise FIELD to catch `status:` in the fields bag too (6 live cases)

[avrabe]

The defect

tools/check_release_plane.py (landing in #373, for #370) catches release: assignments buried in the fields: extension bag, where rivet's query surface is blind to them. It works, and it is structurally general — but the field it checks is a hardcoded module-level constant:

FIELD = "release"

The same defect exists right now on status:, and nothing catches it.

Measured evidence

While migrating #371 I reconciled 303 raw status: text matches against rivet's 276 reported errors. The 27-item gap is entirely two blind spots:

	count	why rivet misses it
safety/stpa/architecture.yaml	6	status: nested inside fields:, invisible to the query surface
safety/requirements.yaml	21	file is under no path in rivet.yaml's sources: — never loaded at all

The six are ARCH-026, ARCH-027, ARCH-028, ARCH-030, ARCH-031, ARCH-032. Each carries fields.status: planned at 6-space indent, sibling of rationale: and source-files:, and has no artifact-plane status at all. That is precisely #370's shape, one field over.

They are not errors today only because rivet cannot see them. They also did not appear in #371's 276, which is why #371 left them in place and named them rather than silently absorbing them.

Proposed fix

Generalise FIELD to a list — ("release", "status") — and iterate. The parser, the block-scalar handling, the fail-closed behaviour and the fixtures are already field-agnostic; only the constant and the report strings assume a single name.

This was deliberately not done inside #371/#374: that branch is stacked on #368, and touching #373's tool there would have stacked it three-deep and broken the "vocabulary only, no tooling change" scope posted on #371.

Second, separable problem

safety/requirements.yaml holds 21 off-vocabulary statuses and rivet never loads it. A plane-checker will not help — the file is outside the store entirely. Either add it to sources: (and then fix what surfaces), or delete it if it is genuinely dead. It should not keep sitting there looking like tracked traceability while being tracked by nothing.

Ordering

Blocked on both #373 and #374 merging.

[avrabe]

Measured: the second half is "delete", and it is 94 artifacts, not 21

The issue's second problem — safety/requirements.yaml sits outside sources:
and rivet never loads it — is real, larger than recorded, and now decidable.

There are two shadow files, not one

file	artifacts	in rivet.yaml sources:?	last touched
safety/requirements.yaml	23	no	2026-03-10 4974288
safety/analysis.yaml	71	no	2026-03-10 4974288
safety/stpa/requirements.yaml	51	yes	2026-03-29 7c174d4 (#87)
safety/stpa/analysis.yaml	95	yes	2026-04-22 a197bef (#140)

safety/analysis.yaml has the same defect and was not named here. Together it is
94 unloaded artifacts, not 21.

Both are strict subsets, and both are frozen snapshots

Comparing IDs:

safety/analysis.yaml       71 ids   ONLY in the shadow: 0
safety/stpa/analysis.yaml  95 ids   ONLY in the canonical: 24

safety/requirements.yaml       23 ids   ONLY in the shadow: 0
safety/stpa/requirements.yaml  51 ids   ONLY in the canonical: 28

Every ID in each shadow file also exists in the safety/stpa/ file that rivet
does load. Nothing is uniquely held by the unloaded copies.

Comparing content of the shared IDs:

safety/analysis.yaml      vs stpa:  15 byte-identical, 56 differing
safety/requirements.yaml  vs stpa:   2 byte-identical, 21 differing

And every difference runs one way — the canonical copy is ahead:

• H-1, H-2, H-3 … the shadow is missing the links: blocks that chore(stpa): migrate 501 shorthand link fields to canonical blocks — rivet validate PASS #140 added
  on 2026-04-22.
• STPA-REQ-001, -002, -003 … differ only in status, where the shadow
  still holds the pre-chore: update rivet artifacts to v0.4.0 for handoff readiness #87 values.

Which is the same story the dates tell: both shadow files were written by
4974288 on 2026-03-10 and have not been edited since. The canonical files
moved twice after that. They are a 4.5-month-old snapshot.

So the 21 "off-vocabulary statuses" this issue flagged are not a live vocabulary
problem — they are the March values, already migrated in the copy rivet reads.
Nothing needs fixing in them.

The decision

Of the two options this issue offered — add to sources: or delete — delete.

Adding them would inject 94 duplicate IDs carrying stale field values into the
store, which is strictly worse than not loading them. And per the table in
#386 row 14, duplicate IDs are non-fatal in the pinned rivet v0.4.3, so that
breakage would land quietly.

They should not keep sitting there looking like tracked traceability while being
tracked by nothing — which is this issue's own phrasing, and the measurement backs
it exactly.

What this does not change

The first half of this issue stands unaltered: FIELD = "release" in
tools/check_release_plane.py should generalise to ("release", "status"), and
the 6 fields.status cases in safety/stpa/architecture.yaml (ARCH-026,
-027, -028, -030, -031, -032) are in a file rivet does load, so they
are live. Deleting the shadow files does not touch them.

Still ordered behind #387 (which carries #374).