fix(aspice): make swe1-has-verification satisfiers reachable (#652)

[avrabe]

Closes #652.

What

The embedded aspice schema warned against itself: rivet validate on a clean aspice-schema project emitted two coverage-rule-consistency warnings because the swe1-has-verification coverage rule lists unit-verification and sw-integration-verification as verifies satisfiers for sw-req, but those types' verifies link-fields only allowed sw-detail-design / sw-arch-component — the satisfiers were unreachable (facets 1 & 2 of #648; facet 3 was fixed in #650). As a follow-on, any implemented sw-req carried a permanent, unfixable lifecycle-coverage-complete gap because the coverage demanded exactly those unreachable satisfiers.

This PR widens the verifies link-field target-types on both types to include sw-req, so the coverage rule is reachable end-to-end.

   - name: unit-verification
     link-fields:
       - name: verifies
         link-type: verifies
-        target-types: [sw-detail-design]
+        target-types: [sw-detail-design, sw-req]

   - name: sw-integration-verification
     link-fields:
       - name: verifies
         link-type: verifies
-        target-types: [sw-arch-component, sw-detail-design]
+        target-types: [sw-arch-component, sw-detail-design, sw-req]

Both new target-types carry an inline comment naming #652 and pointing back at the swe1-has-verification coverage rule they exist to satisfy.

Why this direction, not the other one

The alternative would be dropping unit-verification / sw-integration-verification from the coverage rule's from-types. Rejected because:

1. The issue author's own "likely fix direction" prescribes widening the link-fields ("make the declared satisfiers reachable").
2. The V-model's forward trace is sw-req → sw-arch-component → sw-detail-design, but the reverse verification chain is expected to be evidenceable at any level — a consumer authoring unit-verification --verifies--> sw-req is expressing "this test evidences the requirement directly," which ASPICE 4.0 SUP.10 BP1/BP2 treats as a valid trace.
3. The source-side traceability rule swe4-verifies-swe3 (require unit-verification.verifies to include at least one sw-detail-design) is untouched — widening the allowed target-types does not relax that rule; it just permits an additional target alongside the required one.

Acceptance criteria (from #652)

#	Criterion	How this PR satisfies it
1	rivet validate on an aspice project emits zero coverage-rule-consistency warnings against the embedded schema.	unit-verification and sw-integration-verification can now form verifies → sw-req, so the swe1-has-verification satisfier reachability check in Schema::check_coverage_rule_consistency (rivet-core/src/schema.rs:1235) no longer fires.
2	An implemented sw-req with a real unit/integration verification linked reaches lifecycle-coverage-complete (no permanent unfixable gap).	A consumer can now author unit-verification --verifies--> SW-REQ-x or sw-integration-verification --verifies--> SW-REQ-x as the satisfier the coverage rule demands.
3	A regression test over the embedded aspice schema asserts coverage-rule satisfier reachability.	rivet-core/tests/schema_validation_rules.rs::aspice_embedded_schema_has_no_coverage_rule_consistency_diagnostics — merges the embedded common + aspice and asserts check_coverage_rule_consistency() returns [].

Why draft

This session's egress policy is scoped to pulseengine/rivet only. The workspace transitively depends on pulseengine/rowan (git dependency in Cargo.lock, pinned at 9e7abd1…), which the proxy denies with a 403. I could not run cargo build -p rivet-core --tests or cargo test locally in this session — the fetch of rowan cannot succeed. Please flip to Ready-for-review after CI (which has full scope) confirms:

• cargo test -p rivet-core --test schema_validation_rules aspice_embedded_schema_has_no_coverage_rule_consistency_diagnostics passes on this branch,
• cargo test -p rivet-core --test schema_validation_rules aspice_embedded_schema_has_no_coverage_rule_consistency_diagnostics fails on main (proves the regression test is real),
• rivet validate on the rivet repo remains PASS.

Test plan

• CI Format / Clippy / Test gates green on this branch
• Verify the new test in schema_validation_rules.rs fails on main (revert the two YAML changes, expect one diagnostic per unreachable from-type)
• Optionally, downstream: run rivet validate on an aspice-schema consumer project and confirm the two coverage-rule-consistency warnings are gone

---

Generated by Claude Code

[github-actions]

📐 Rivet artifact delta

No artifact changes in this PR. Code-only changes (renderer, CLI wiring, tests) don't touch the artifact graph.

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Rivet Criterion Benchmarks'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: 897e2bc	Previous: a23af22	Ratio
store_insert/10000	15571643 ns/iter (± 809612)	12404317 ns/iter (± 897535)	1.26

This comment was automatically generated by workflow using github-action-benchmark.

[avrabe]

Completed the failing test updates (pushed to this branch) + merged current main in (picks up the quick-xml 0.41 security fix, so Security Audit (RustSec) goes green).

The 3 failures were tests still encoding the pre-#652 behavior — all now assert the corrected output, verified locally:

• schema::tests::from_type_can_link_respects_link_field_targets — unit-verification can now verifies → sw-req; still respects the target list (rejects sw-arch-component, not among its targets).
• explain_names_directly_linkable_verification_type — validate --explain now lists all three directly-linkable verification types; no longer annotates any as attaching only via the design chain.
• lifecycle_gap_names_the_aspice_verification_chain — the gap hint now names the directly-linkable verification types.

Worth a look: #652 completes REQ-237/#350's own direction ("direct verification → sw-req without the full ASPICE chain"), so REQ-237's chain-naming hint no longer fires for aspice sw-req — the schema now allows the direct link the hint used to route around. The hint code still exists for genuinely-indirect cases; it just doesn't trigger here anymore. If you'd rather keep exercising the chain-naming path, it'd need a scenario where a verification type still can't reach its req directly. Flagging so the REQ-237 scope change is intentional, not accidental.

(Only Kani Proofs should remain red — the known exit-143 runner-shutdown infra flake.)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!