fix(aspice): seed validates clean after init#233
Merged
Conversation
… + add stakeholder-req parent
Round-3 fresh-user dogfood (sandbox /tmp/aspice-seed-only) confirmed
that `rivet init --preset aspice && rivet validate` ships a seed
that fails validation with 2 errors out of the box:
ERROR: [SYSREQ-001] link 'derives-from' requires at least 1 target,
found 0
ERROR: [SWARCH-001] link type 'allocated-from' is not defined in
the schema — declare it in link-types: or
remove the link
Result: FAIL (2 errors)
Two real bugs in the shipped aspice preset:
1. The `common` schema declares `allocated-to` with `inverse:
allocated-from`, registering only the forward token `allocated-to`.
ASPICE's SWE.2 traceability rule (`swe2-allocated-from-swe1`)
uses `allocated-from` as the *forward* direction (sw-arch-component
allocates from sw-req), and the seed's SWARCH-001 uses it the
same way. The validator correctly rejects the use because no
schema registers `allocated-from` as a forward link-type. This
is exactly the gotcha-G.3 footgun the quickstart documents.
2. `system-req` requires `derives-from -> [stakeholder-req]` per the
ASPICE `sys2-derives-from-sys1` rule. The seed had SYSREQ-001
with no `derives-from`, so the rule fails on the first
`rivet validate` post-init.
Changes:
- `schemas/aspice.yaml`: declare `allocated-from` as a forward
link-type in ASPICE's `link-types:` block, with `inverse:
allocated-to`, restricted to `source-types: [sw-arch-component]`
/ `target-types: [sw-req, system-arch-component]`. This matches
what the existing `swe2-allocated-from-swe1` traceability rule
already requires and what artifact-types' link-fields already
reference (lines 97-98, 142-143). Schema is now internally
consistent.
- `rivet-cli/src/main.rs` (`ASPICE_SAMPLE` const): add a
STKHR-001 stakeholder-req as the V-model root, wire SYSREQ-001's
`derives-from` to it. The chain
STKHR-001 (stakeholder-req)
← derives-from
SYSREQ-001 (system-req)
← derives-from
SWREQ-001 (sw-req)
← allocated-from
SWARCH-001 (sw-arch-component)
satisfies all three left-V ASPICE rules
(sys2-derives-from-sys1, swe1-derives-from-sys,
swe2-allocated-from-swe1).
Verified locally:
$ rivet init --preset aspice && rivet validate
INFO: [SWREQ-001] Every SW requirement should be verified by at
least one verification measure
INFO: [SYSREQ-001] Every system requirement should be verified by
at least one verification measure
Result: PASS (0 warnings)
Result PASS with 0 errors and 0 warnings. The two remaining INFOs
are lifecycle-coverage hints — they suggest the natural next step
(authoring sw-verification / sys-verification artifacts) and do
not block the validate gate.
Implements: REQ-007, REQ-010
Refs: FEAT-001
📐 Rivet artifact deltaNo artifact changes in this PR. Code-only changes (renderer, CLI wiring, tests) don't touch the artifact graph. |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
4 tasks
avrabe
added a commit
that referenced
this pull request
Apr 28, 2026
* chore(release): v0.5.1 — first-contact polish Workspace, vscode-rivet, and npm root package versions bumped to 0.5.1. Platform packages stay on the release-npm.yml override path (per the 0.5.0 convention). What's in 0.5.1 (post-0.5.0 dogfood polish): - docs(quickstart): rewrite for fresh-user clarity (#230). Two clean-room dogfood passes + three scenario-based passes surfaced six confusion points; all fixed. Wall-time wins: STPA bring-up 13min -> 36s; Polarion -> ASPICE overlay 7min -> 3.8min. - fix(aspice): seed validates clean after init (#233). Two real bugs in the shipped aspice preset (undeclared `allocated-from` link-type, missing stakeholder-req parent) — `rivet init --preset aspice && rivet validate` now returns PASS. - feat(mcp): discoverability (#231). New `rivet mcp --list-tools` and `rivet mcp --probe` flags (no JSON-RPC required to enumerate the tool catalog or smoke-test the server) plus a new ~1400-word `rivet docs mcp` topic covering wire format, handshake, tool catalog, and the response-envelope gotcha. Verified: cargo check, cargo clippy --workspace -- -D warnings, cargo test -p rivet-cli, `rivet init --preset aspice && rivet validate` returns PASS, `rivet docs mcp` prints the new topic. Trace: skip * chore(release): fix CHANGELOG ArtifactIdValidity false-positives PR #235's Docs Check failed because the 0.5.1 changelog mentioned aspice preset SEED artifact IDs (SWARCH-001, SWREQ-001, SYSREQ-001, STKHR-001) in prose. Those IDs live in the embedded preset string constant, not as artifacts in this repo's store, so the rivet docs check ArtifactIdValidity invariant correctly flagged them as broken references. Fix: replace the seed IDs with their artifact-type names (sw-arch-component, sw-req, system-req, stakeholder-req). Reads better as prose anyway; no information loss. Trace: skip
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Round-3 fresh-user dogfood discovered that
rivet init --preset aspice && rivet validateships a seed that fails validation with 2 errors:```
ERROR: [SYSREQ-001] link 'derives-from' requires at least 1 target, found 0
ERROR: [SWARCH-001] link type 'allocated-from' is not defined in the schema
Result: FAIL (2 errors)
```
This PR fixes both —
rivet init --preset aspice && rivet validatenow returns PASS with 0 errors and 0 warnings.Two bugs, two fixes
1. Undeclared
allocated-fromlink-typeThe
commonschema registers only the forward tokenallocated-to(withinverse: allocated-from). ASPICE's SWE.2 rule (swe2-allocated-from-swe1) usesallocated-fromas the forward direction (sw-arch-component → sw-req), and so does the seed's SWARCH-001. The validator correctly rejects it because no schema declaresallocated-fromas a forward link-type.This is exactly the gotcha-G.3 footgun the quickstart documents. Fix: declare
allocated-fromas a forward link-type inschemas/aspice.yamllink-types block, withinverse: allocated-to, restricted tosource-types: [sw-arch-component]/target-types: [sw-req, system-arch-component].2. Missing stakeholder-req parent
ASPICE's
sys2-derives-from-sys1rule requires everysystem-reqto derive from astakeholder-req. The seed's SYSREQ-001 had noderives-from. Fix: add a STKHR-001 stakeholder-req as the V-model root and wire SYSREQ-001'sderives-fromto it.V-model chain after fix
```
STKHR-001 (stakeholder-req)
← derives-from
SYSREQ-001 (system-req)
← derives-from
SWREQ-001 (sw-req)
← allocated-from
SWARCH-001 (sw-arch-component)
```
This satisfies all three left-V ASPICE rules:
sys2-derives-from-sys1,swe1-derives-from-sys,swe2-allocated-from-swe1.Verification
```
$ rivet init --preset aspice && rivet validate
Result: PASS (0 warnings)
```
Two INFOs remain (lifecycle-coverage hints suggesting verification artifacts) — they're advisory, not errors.
Test plan
rivet init --preset aspice && rivet validatereturns PASS in CI integration testrivet init --preset stpa/dev/ other presets🤖 Generated with Claude Code