fix(rivet): stop double-loading safety/stpa and de-duplicate RENDER-REQ (#360)

[avrabe]

Warning

Two claims below were refuted by cold-context verification and are withdrawn. See the correction comment and #371.

1. "the directory scan alone loses nothing" — measured on rivet list --format json without --full, a view that omits fields entirely. Re-measured: 5 artifacts (VAL-010/011/014/015/021) lose half their test-name. Fixed in cce6fbd; filed upstream as stpa-yaml parser silently truncates comma-containing scalars at the first element (test-name evidence loss) rivet#747.
2. "the repo cannot widen allowed-values locally" and its corollaries "the v0.4.3 pin is load-bearing" / "measured as not viable" — false. Vendoring schemas/common.yaml (v0.3.0, same as embedded) and widening the vocabulary takes rivet validate 276 → 0, exit 0. The remedy is still declined, but on the merits (Verification verdicts are recorded as feature.status — the root cause of all 276 rivet validate errors #371), not on a constraint that doesn't exist.

The duplicate-id result — 190 → 6 → 0 — is unaffected and was independently confirmed exact at all four measurement rows.

---

Closes #360.

rivet validate reported 466 errors on a clean tree. This takes it to 276,
eliminates the duplicate-id class entirely, and — where the issue's own plan was
wrong — says so with the measurement rather than quietly dropping that step.

The 190 phantom duplicates

rivet.yaml listed safety/stpa as a directory scan and listed four files
inside it individually, to force format: generic-yaml on them. Each of those
files was therefore loaded twice, and every id in them was "declared more than
once" — colliding with itself, with the same path on both sides of the
message.

Listing a directory and its own contents isn't additive, it's duplicative, and
the diagnostic couldn't hint at that because both copies had identical
provenance.

Equivalence was measured, not assumed. Dropping the explicit entries changes
those files' parse format, so before/after rivet list --format json was
compared: 883 ids and 1195 links, byte-identical. stpa-yaml is a superset
of what generic-yaml was extracting here.

The 6 real ones

RENDER-REQ-001..006 were defined in both artifacts/requirements.yaml and
safety/stpa/rendering-analysis.yaml. rivet kept one copy and dropped the other
with no diagnostic, and which one won was load order, not a decision.

I deleted the requirements.yaml stubs and kept the STPA copy, because only the
STPA file carries the hazards/satisfies/verified-by links that make these
part of the STPA V. The stubs carried none.

The stubs were stale in both directions, which is why I checked against
source instead of keeping whichever file looked fresher:

id	stub said	actually	evidence
RENDER-REQ-003	implemented	partial	minimap is /// Show minimap (Phase 3b — reserved)
RENDER-REQ-006	partial	implemented	etch/src/html.rs:65-68 emits svg.zoom-low / svg.zoom-overview; :131 asserts a wheel handler

Verified at the pinned etch rev 4c06709, not by grepping this repo — and
that distinction nearly cost me a false finding. A repo-scoped grep shows
zoom-low only in a checked-in playwright fixture and semantic zoom only in a
README bullet, which reads exactly like "asserted against a hand-authored
artifact, never implemented." It reads that way because the implementation lives
in a git dependency. "Not in this repo" and "not implemented" are
indistinguishable to grep.

Where the issue was wrong

#360 predicted that with the overlap and the vocabulary both fixed, "the
residual 0.28.0 error count should be near zero." That is false, and this PR
measures it rather than asserting it:

step	errors	duplicate-id
baseline	466	190
drop source overlap	282	6
delete RENDER-REQ stubs	276	0
normalise pass/pending	276	0

The normalisation cannot reduce the count, because its targets aren't in the
allowed set either:

allowed: draft, proposed, approved, implemented, verified,
         released, accepted, deprecated, rejected

Neither passing nor planned is there. So pass → passing moves 5 errors
between buckets (172 → 177) and pending → planned moves 4 (36 → 40). Net
zero, exactly as measured.

It's still worth doing — it leaves 4 non-conforming values to resolve instead
of 6 — but it is not an error fix, and booking it as one would have overstated
what this change buys.

Why the v0.4.3 pin still can't be lifted

The residual 276 is entirely status-vocabulary skew: 177 passing, 51
not-implemented, 40 planned, 8 partial. These are test/verification
states, not approval-lifecycle states — a VAL record's "passing" is about whether
the test passes right now, which is a genuinely different axis from where an
artifact sits in an approval flow.

rivet names the two options itself: fix the artifacts, or add the values to the
status base-field's allowed-values. The repo can't take the second one —
common@0.3.0 is embedded in the rivet binary, and schemas/ only overrides
sysml2.

So ci.yml's pin to rivet-cli v0.4.3 is load-bearing for the green check,
not incidental. Lifting it turns a required context red with 276 errors that are
real under the current schema. The existing comment there calls a newer rivet's
findings "phantom errors"; for the duplicate-id class that was true and this PR
fixes it, but for the status class it isn't — those are genuine
non-conformances against common@0.3.0 that the pin is holding back.

Resolving them is an upstream rivet conversation (does the lifecycle admit
test-execution states?), not something to force in this PR.

What this does not do

• Does not reduce the 276 status errors. Named above with the reason.
• Does not lift the v0.4.3 pin. Measured as not viable; see above.
• Does not touch safety/stpa/rendering-analysis.yaml. The canonical statuses
  there were independently confirmed correct against etch, so there was nothing
  to change.

🤖 Generated with Claude Code

[github-actions]

Rivet verification gate

✅ 20/20 passed

	count
Passed	20
Failed	0
Skipped (no steps)	0

Filter: (and (= type "feature") (or (has-tag "v093") (has-tag "v0100")))

Failed artifacts

(none)

_{Updated automatically by tools/post_verification_comment.py. Source of truth: artifacts/verification.yaml.}

[avrabe]

Correction — two of this PR's claims were wrong, found by cold-context adversarial verification

I ran a fresh-context agent against this PR's own claims with no inherited framing. It refuted two, and I re-derived both myself before acting. Pushed cce6fbd for the one that was baked into a committed file; the other is corrected here and in #371.

1. "The directory scan alone loses nothing" — FALSE, and it was committed into rivet.yaml

The equivalence check I cited ran rivet list --format json without --full. Per list --help, that emits only the summary view — it omits description, tags, and fields. So the "byte-identical" result was measured on a view structurally incapable of detecting field-level loss, which is exactly the class of change a format: switch produces. The measurement was true and meaningless.

Re-measured with --full, base vs. this branch:

• +86 artifacts gain mitigates and traces-to — stpa-yaml really is broadly a superset, but my original measurement didn't show that either
• −5 artifacts lose half of test-name

The five are VAL-010, VAL-011, VAL-014, VAL-015, VAL-021 — exactly the five whose on-disk test-name is a comma-separated pair (grep -c 'test-name:.*,' safety/stpa/validation.yaml → 5). A/B on identical bytes, only format: differing:

format:	rivet get VAL-010 --format json | jq -r '.fields["test-name"]'
generic-yaml	tests::boolean_matches_aadl_boolean, tests::boolean_mismatches_aadl_string
stpa-yaml	tests::boolean_matches_aadl_boolean

test-name is evidence — the pointer from a verification artifact to the tests discharging it. The trade is still worth taking (5 truncated pointers against 190 phantom duplicate-id errors), but it is a trade, not a free win, and the committed comment now says so. Filed upstream as pulseengine/rivet#747.

2. "The repo cannot widen allowed-values locally" — FALSE

I claimed the residual 276 errors were unfixable here because common@0.3.0 is embedded in the binary. rivet's own output says otherwise, verbatim:

common  0.3.0  embedded  (compiled into rivet — changes on upgrade; vendor under schemas/ to pin)

Measured:

$ cp <rivet>/schemas/common.yaml schemas/common.yaml    # version "0.3.0" — identical to embedded
$ rivet validate | tail -2
Result: FAIL (276 errors, 629 warnings, 0 broken cross-refs)
Schemas: common@0.3.0 (on-disk), ...                     # override live

$ # append passing / not-implemented / planned / partial to status allowed-values
$ rivet validate | tail -2 ; echo exit=$?
Result: PASS (629 warnings)
exit=0

276 → 0. My claim inferred "only sysml2 can be on-disk" from the observation "only sysml2 is on-disk" — an inference reported as a measurement. That's the same one-variable-check failure this repo keeps re-learning.

Consequently these two statements in the PR body are withdrawn: "ci.yml's pin to rivet-cli v0.4.3 is load-bearing for the green check" and "measured as not viable." The pin is load-bearing today, but for a fixable reason.

…and the remedy should still be declined — now on the merits

Now that the option is known to exist, #371 declines it deliberately rather than on a false constraint. Widening the vocabulary on a vendored fork of the org-shared common schema would silence a correct diagnostic: rivet already ships verification-verdict — "Pass/fail verdict for a single verification measure in an execution run" — and spar is recording verdicts in the lifecycle status field of type: feature ("a user-visible capability"). The 276 errors are a real modeling defect, not a vocabulary gap. Softening the ledger to green it is the textbook anti-pattern.

Smaller corrections, for the record

• "rivet kept one copy and dropped the other with no diagnostic" — inaccurate at 0.28.0, which names both files and the winner (— the second definition silently overwrites the first). True only of the pinned v0.4.3.
• "Which one won was load order, not a decision" — load order is a decision: it's the sources: order in rivet.yaml, and Store::upsert is documented last-write-wins. Fully deterministic. Required rivet gate cannot detect duplicate artifact ids — 6 real ones on main, masked by 184 self-inflicted phantoms #360's "looks hash-ordered" is refuted; I softened but inherited it.
• The repo-grep anecdote is overstated. zoom-low also appears in tests/playwright/rendering.spec.ts:145-147 — an executable assertion, not a fixture — and semantic zoom appears in artifacts/verification.yaml:474, the same spec, and a docs plan. The rhetorical point stands; the grep offered as evidence for it does not.
• Adjacent defect this PR canonises without checking: keeping the STPA copies makes RENDER-REQ-006 verified-by: [VAL-R5] authoritative, and VAL-R5's evidence is run: cargo test -p spar-wasm -- semantic_zoom — which matches zero tests repo-wide. playwright appears in no workflow. The status is correct against etch source; its verification pointer is dead. Tracking separately.

The core of the PR is unaffected — the duplicate-id class still goes 190 → 6 → 0, and that measurement was independently confirmed exact at all four rows.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[avrabe]

Superseded by #387, merged as 9903d1a.

This branch was not merged directly — the six guardrail PRs were rebuilt onto one batch branch (batch/ci-guardrails) so they could clear the 18 required contexts together rather than each triggering a full re-run after the previous one advanced main (branch protection has strict = true). So this PR's head commit is not an ancestor of main; its content is.

Verified on origin/main before closing, rather than assumed from the batch's commit list: rivet.yaml has the de-duplicated safety/stpa sources (2 entries, not the doubled set).

Closing as superseded, not as unmerged work. Reopen if anything here is missing from main.