docs(schemas): recipe for extending a built-in artifact type with project fields (REQ-149, #350)#395
Merged
Merged
Conversation
…ject fields (REQ-149, #350) #350 suggestion 4: a project's `crate:` field on an ASPICE `sw-req` produced dozens of `INFO: field 'crate' is not defined in schema` advisories, and the reporter asked for an easy per-project field extension without forking the schema. Verified the mechanism already exists — `ArtifactTypeDef::merge_in_place` unions `fields` by name across schemas sharing a type name, so a project-local schema re-declaring the built-in type with only the extra field (registered after the built-in in `project.schemas`) adds the field without forking. Confirmed empirically: with the extension the `crate` INFO disappears; without it, it's present. It was just undocumented. Added the "Extending a built-in artifact type with project fields" recipe to docs/schemas.md (copy-pasteable, plus the `--min-severity warning` alternative), and corrected the merging-behavior note (same-named artifact types merge fields by name; they don't replace wholesale). `rivet docs check` PASS. Implements: REQ-149 Refs: REQ-010 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
📐 Rivet artifact delta
Graphgraph LR
REQ_149["REQ-149"]:::added
classDef added fill:#d4edda,stroke:#28a745,color:#155724
classDef removed fill:#f8d7da,stroke:#dc3545,color:#721c24
classDef modified fill:#fff3cd,stroke:#ffc107,color:#856404
classDef overflow fill:#e2e3e5,stroke:#6c757d,color:#495057,stroke-dasharray: 3 3
Added
Posted by |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
⚠️ 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: 85fcfdf | Previous: b097e49 | Ratio |
|---|---|---|---|
traceability_matrix/1000 |
60797 ns/iter (± 237) |
44599 ns/iter (± 1060) |
1.36 |
query/10000 |
120169 ns/iter (± 670) |
95635 ns/iter (± 615) |
1.26 |
This comment was automatically generated by workflow using github-action-benchmark.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
avrabe
added a commit
that referenced
this pull request
Jun 2, 2026
…cile REQ-149 duplicate, file REQ-150 (#396) Used `rivet list --type requirement` + `--explain` to audit the REQs filed over recent iterations. Findings, each verified against merged code (not flipped blindly): - REQ-134 (per-project field extension) → implemented: both acceptance criteria are met — the schema-merge field-union mechanism works (verified empirically) and it's documented in docs/schemas.md (#395). - REQ-149 was an accidental duplicate of REQ-134 (filed before noticing the pre-existing one). Linked REQ-149 -> REQ-134 and tagged it so the relationship is explicit rather than a stray parallel item. - Left correctly-draft: REQ-128 (orphans filter shipped, but the inbound-count ranking report is still outstanding), REQ-132 (single-hop link naming done in REQ-147; the multi-hop chain naming is not), REQ-135 (validate/modify enforcement built but inert pending the maintainer's canonical status set + artifact reconciliation). - Filed REQ-150 (draft): `rivet add` warns on no near-duplicate, only duplicate id — the gap that let me file REQ-149. A non-blocking "similar to <ID>" advisory would catch it. `rivet validate` PASS. Implements: REQ-134 Refs: REQ-149, REQ-150, REQ-010 Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
Closes the documentation half of #350 suggestion 4.
Context
A project's artifacts carried a
crate:field the built-in ASPICEsw-reqdoesn't declare → dozens ofINFO: field 'crate' is not defined in schemaadvisories drowning the actionable diagnostics. The reporter asked for "an easy per-project field extension... without forking the schema."Finding (verified, no code change needed)
The mechanism already exists:
Schema::merge/ArtifactTypeDef::merge_in_placeunionfieldsby name across schemas that share a type name. So a project-local schema re-declaring the built-in type with only the extra field — registered after the built-in inrivet.yamlproject.schemas— adds the field without forking.Confirmed empirically:
INFO: field 'crate' is not defined in schema for type 'sw-req'project-extschema declaringsw-req { fields: [crate] }in the schemas list: the INFO is gone; all built-in fields/links/rules preserved.It was simply undocumented.
Change (docs-only)
docs/schemas.md— the copy-pasteable recipe + therivet validate --min-severity warningalternative.rivet docs checkPASS;rivet validatePASS.Implements: REQ-149
🤖 Generated with Claude Code