[osovv]

Why the change

The snapshot-plus-guard mechanism kept freezing configuration into a side store and then proving every request against that copy, which produced recurring runtime incidents, so families now simply live with their own settings recorded in native session metadata.

Special things to note

• Behavioral change (intended): a family root session no longer switches its own model or gains family-qualified model variants — roles apply only to newly created children at creation time (agent definitions plus a one-shot child reconciliation), and existing sessions keep whatever native model they have.
• One-time migration: the first start of the new version converts existing family bindings into root-session metadata, then deletes the legacy bindings/, snapshots/, and rebind/ directories; a failed write keeps them and retries on the next start. The old snapshot store is never read afterwards.
• The e2e host pin now targets the newest verified host (2.2.5, src/hosts.json) with the published binary's sha256; fresh live evidence for 2.2.6 was not obtainable in this environment, so the verified list is unchanged and the pin is override-driven (VVOC_E2E_V2_HOST_SHA256 / VVOC_E2E_V2_SOURCE_COMMIT, the source commit is no longer claimed by default because the published binary carries no verifiable commit metadata).

Change outline

Settings live under one metadata key of the family root; every write is a read-modify-write so foreign metadata survives the native replace-semantics write:

// metadata["vvoc:settings"] on the family ROOT (children carry none)
{ "version": 1, "preset?": "vv-zai",
  "roles": { "smart": "prov/m2#high", "...": "..." },
  "profile": "orchestrated",
  "plugins": { "secrets-redaction": true } }

resolve(session):  lineage to root (parentID / forkSessionID, cycle+depth guarded)
                   → decode(root.metadata["vvoc:settings"]) ?? live vvoc.json
birth(root):       first resolution → read fresh metadata → merge only the
                   settings key → session.update (serialized per family)
explicit change:   `vvoc session set --session <id>` / TUI `/vv-settings`
                   (preset | profile | role | plugin | pull-defaults) →
                   lineage to root → single RMW of that family only

The guard machinery is deleted outright — snapshot-store.ts, snapshots.ts, the rebind marker store, /vv-rebind, and the --force flags are gone, so the bind/admission error class can no longer occur:

- runtime.snapshots.configFor(session) → accept(...)   // bind + guard
- bindFor / guardResolvedModel / firstWorkPending / explicitSelections
- SnapshotAdmissionError | SnapshotUnboundError | SnapshotStoreError
+ runtime.settings.configFor(session)                   // resolve, fail-soft
+ migrateFamilyBindings(...)                            // one-shot migration

All plugin consumers (workflow, model-roles, system-context-injection, guardian, and the rest) resolve the projected family config through the one settings service; credentials keep coming from the live configuration and are never persisted in metadata. The real-host e2e harness asserts birth stability, config-change isolation, restart persistence, and lineage instead of snapshot ids.