version of schemas

[avrabe]

We currently don't the ave a version of schemas or pinning them to a sha5 or anything. Especially when using the builtin we have this problem. Also if we introduce we need a way to mark if new versions are out or if we don't have this version in anymore and would need to download or so.

[avrabe]

Triage pass (issue-triage agent run 2026-06-14).

Substantial overlap with #431 (embedded schemas are binary-versioned, not pinned — upgrading rivet silently changes validation) and its in-flight PR #537 (rivet init --vendor-schemas writes the resolved schema set to schemas/.yaml so the project's git pins it). #537 closes the pin-against-upgrades half of this body. So before AC, two routing questions:

1. Close-as-dup-of-Embedded (builtin) schemas are binary-versioned, not pinned — upgrading rivet silently changes validation (new diagnostics on unchanged artifacts) #431? If the only ask here is "let me pin a schema version so upgrading rivet doesn't silently change validation," then feat(init): --vendor-schemas pins built-in schemas on-disk against upgrades (#431) #537's --vendor-schemas flag plus Embedded (builtin) schemas are binary-versioned, not pinned — upgrading rivet silently changes validation (new diagnostics on unchanged artifacts) #431's REQ-176/177 version surface (rivet schema sources shows embedded|on-disk + version) covers it. In that case, this can be closed pointing at Embedded (builtin) schemas are binary-versioned, not pinned — upgrading rivet silently changes validation (new diagnostics on unchanged artifacts) #431 (no AC needed).

2. Or keep this scoped to the parts Embedded (builtin) schemas are binary-versioned, not pinned — upgrading rivet silently changes validation (new diagnostics on unchanged artifacts) #431 doesn't cover — the "mark if new versions are out" / "we don't have this version anymore and would need to download" half. That's a genuinely new surface: freshness/staleness detection + a download/upgrade UX. Different design call, different blast radius from --vendor-schemas (which is pure-local + immune-to-drift; this is the opposite — a network/registry posture).

Per "one PR per issue, keep PRs focused" the second half (if you want it) needs an explicit ## Acceptance Criteria block. Sketch — feel free to revise / re-scope:

## Acceptance Criteria — freshness detection only (no download UX)
- [ ] `rivet validate` (or a new `rivet schema check`) reports each loaded schema's version alongside the latest known-embedded version; if the project's vendored on-disk schema is older than the embedded copy, surface a `schema-out-of-date` info/warning (severity is your call — info matches the existing `rivet schema sources` surface, warning makes it a gate signal). Test: a project with a vendored `common@0.1.0` against a binary embedding `common@0.2.0` produces the warning; same version produces silence.
- [ ] The same diagnostic suggests the upgrade path (`rivet init --vendor-schemas --force` or whatever the canonical re-vendor command becomes — coordinate with #537 so the suggestion stays valid).
- [ ] `rivet schema sources` (REQ-178) gains a `latest` column showing the latest embedded version available, so the staleness is visible from one command. Golden-file test on the table output.
- [ ] **Explicitly out of scope (file separately if wanted):** network fetch of a newer schema version (the "would need to download" half — that's a registry/transport posture, not a one-PR slice); an `rivet.yaml` `min-rivet-version`/version pin (#431 option 2 — that's a separate fuller fix); auto-upgrade of a vendored schema (destructive — needs its own UX call).
- [ ] `rivet validate` PASS on the rivet repo unchanged; `cargo test -p rivet-core -p rivet-cli` green; `cargo fmt --check` / `clippy --all-targets -- -D warnings` clean.
- [ ] Commit trailers: `Implements: REQ-NNN` (file a new REQ for schema freshness detection) + `Refs: #538, #431`.

## Acceptance Criteria — download/fetch UX (if you want the bigger fix)
- [ ] Define what "available to download" means — registry shape (HTTPS index? GitHub release assets? OCI?). This is a design call that probably wants its own design issue before AC, similar to the #490 sharding design.
- [ ] All AC bullets from the freshness half above, PLUS:
- [ ] `rivet schema fetch <name>@<version>` (name TBD) downloads a named version into `schemas/<name>.yaml`, verifies against a checksum/signature, refuses on mismatch.
- [ ] **Explicitly out of scope:** auto-fetch on `rivet validate` (network-on-validate is a footgun — needs an explicit opt-in flag at minimum).

If you'd rather collapse this to "close in favour of #431 + the rivet schema sources/--vendor-schemas surfaces already cover what we need today," that's also a clean disposition — say which and the agent will route accordingly next pass.

Process side-rail (carried from every recent triage thread): https://pulseengine.eu/blog/ is still HTTP 503 (the expired-TLS / site-infra symptom flagged on #420, #468, #456, #436, #431, #422, #479, #482, #488, #490, #500, #508, #509, #516, #522, #523, #530, #532 — verified again at the start and end of this run). The binding workflow guidance can't be consulted, so per the run's hard rule no PR will land from this triage regardless. Comment is the AC ask only.

Not implemented this run.

---

Generated by Claude Code — issue-triage agent run 2026-06-14.

---

Generated by Claude Code