varve v0.10.0

varve v0.10.0 — realms: the pin names its trust universe

REQ-REALM-001 verified. Parallel toolchain universes — different organizations, different trust roots, different registries — coexist on one machine with isolation by construction.

What's in

• realm = "name" in varve.toml, defined by a committed varve-realms.toml (same walk-up discovery as the pin, so trust travels with the code): each realm maps to a registry and a trust root (inline hex key or a relative key file)
• A named realm is authoritative: its trust root applies — the ambient environment cannot substitute one — and varve install defaults to its registry, so a realm project needs no flags and no env vars
• Isolation by fingerprint: all per-realm state (core, anti-rollback marks, status cache) lives under $VARVE_ROOT/realms/<trust-root-fingerprint>/ — two realms with identical layer names and counters cannot cross-talk, and cross-acceptance is cryptographically impossible
• One shim directory serves every realm: resolution is per-invocation, so cd between projects of different realms switches tool universes

Falsification statement

This release claims: no byte from realm A can be accepted, resolved, or executed in a project pinned to realm B. To falsify: construct any layer signed by one realm's root that installs into, resolves for, or dispatches from a project naming another realm. The e2e test runs two realms with identical layer names and counters through one shim and demonstrates the refusal.

Verify this release

cosign verify-blob \
  --certificate-identity-regexp 'https://github.com/pulseengine/varve/.github/workflows/release.yml@.*' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  --bundle SHA256SUMS.txt.cosign.bundle SHA256SUMS.txt
varve self-verify --archive varve-v0.10.0-<triple>.tar.gz --envelope SHA256SUMS.txt.dsse.json

This machine took the release via varve self-update — 0.9.0 verified and installed 0.10.0 through the old-verifies-new chain.