Split from #648, which is being closed by #650 — but #650 only fixes facet 3 (the rivet check bidirectional vs. non-authorable-inverse contradiction). Facets 1 & 2 remain and are a distinct defect in the embedded aspice schema itself, not in any consumer project:
Facet 1 — rivet warns against its own embedded schema
A clean rivet validate on an aspice-schema project emits two coverage-rule-consistency warnings: coverage rule swe1-has-verification lists unit-verification and sw-integration-verification as verifies satisfiers for sw-req, but those types' verifies link-fields only target sw-detail-design / sw-arch-component — the satisfiers are unreachable. The consumer cannot fix this; the rule and the link-fields ship together inside the binary.
Facet 2 — lifecycle coverage then demands exactly those unreachable satisfiers
Setting a sw-req to status: implemented yields ... missing: unit-verification, sw-integration-verification. Per facet 1, no authorable link can ever satisfy this, so any implemented sw-req carries a permanent, unfixable coverage gap.
Why this is real
Both facets originate in the embedded aspice schema (common@… + aspice@…), so no downstream project can remediate them. Together they mean the aspice schema can never reach a clean traceability state — a coverage gate on it is permanently yellow.
Likely fix direction
Reconcile the embedded aspice schema so the swe1-has-verification coverage rule's satisfier types (unit-verification, sw-integration-verification) actually declare a verifies link-field that targets sw-req — i.e. make the declared satisfiers reachable. Then facet 2 resolves for free (the demanded types become authorable satisfiers).
Acceptance
rivet validate on an aspice project emits zero coverage-rule-consistency warnings against the embedded schema.- An
implemented sw-req with a real unit/integration verification linked reaches lifecycle-coverage-complete (no permanent unfixable gap).
- A regression test over the embedded aspice schema asserts coverage-rule satisfier reachability.
Original report: #648. Facet 3 fix: #650.
Split from #648, which is being closed by #650 — but #650 only fixes facet 3 (the
rivet check bidirectionalvs. non-authorable-inverse contradiction). Facets 1 & 2 remain and are a distinct defect in the embedded aspice schema itself, not in any consumer project:Facet 1 — rivet warns against its own embedded schema
A clean
rivet validateon an aspice-schema project emits twocoverage-rule-consistencywarnings: coverage ruleswe1-has-verificationlistsunit-verificationandsw-integration-verificationasverifiessatisfiers forsw-req, but those types'verifieslink-fields only targetsw-detail-design/sw-arch-component— the satisfiers are unreachable. The consumer cannot fix this; the rule and the link-fields ship together inside the binary.Facet 2 — lifecycle coverage then demands exactly those unreachable satisfiers
Setting a
sw-reqtostatus: implementedyields... missing: unit-verification, sw-integration-verification. Per facet 1, no authorable link can ever satisfy this, so anyimplementedsw-req carries a permanent, unfixable coverage gap.Why this is real
Both facets originate in the embedded
aspiceschema (common@… + aspice@…), so no downstream project can remediate them. Together they mean the aspice schema can never reach a clean traceability state — a coverage gate on it is permanently yellow.Likely fix direction
Reconcile the embedded aspice schema so the
swe1-has-verificationcoverage rule's satisfier types (unit-verification,sw-integration-verification) actually declare averifieslink-field that targetssw-req— i.e. make the declared satisfiers reachable. Then facet 2 resolves for free (the demanded types become authorable satisfiers).Acceptance
rivet validateon an aspice project emits zerocoverage-rule-consistencywarnings against the embedded schema.implementedsw-req with a real unit/integration verification linked reaches lifecycle-coverage-complete (no permanent unfixable gap).Original report: #648. Facet 3 fix: #650.