PolymerOS — Update & Build Orchestration

• Fast security — a CVE in the kernel or VMM needs a same-day fix, not the next full release.
• No over-building — don't rebuild the world (or every VM) for every package change.
• No breakage — a running install, and every VM in it, must survive updates; subtle breakage is expected and must be caught.
• Two audiences — new users (fresh, fully-patched image) and existing users (live updates on their channel, secure but stable).

Two lanes: batched baseline + fast-track security overlay

The baseline lane is the whole-OS bump — fresh nixpkgs pin, full gauntlet, channel-promoted, cadenced. The security lane overrides just the vulnerable package on the current baseline (the cosmic-comp override technique), rebuilds only that sub-closure, re-signs, and ships as 0.0.5 → 0.0.5.1+sec. Nix means patching one CVE never requires a full pin bump.

A change rebuilds only the artifacts whose closure contains it

Shippable artifacts = the core OS image + each catalog VM (firefox, OSE, …), each its own closure. The trigger graph is computed from closures, not guessed:

• Firefox release → rebuild the firefox VM only (firefox isn't in the core OS).
• Kernel update → the core OS image (+ any VM pinning that kernel).
• openssl CVE → fans out to every artifact containing it — broad but precise.

Coalesce changes per window; a rebuilt path (patched openssl) is built once and substituted everywhere. No blanket rebuilds, ever.

Fast-track by exposure — compartmentalization is the mitigation

Tier 0 (TCB): kernel, VMM (cloud-hypervisor/crosvm), bond broker, verity/crypto, signing, compositor surface → always fast-track. Tier 1 (parsers/crypto/edge): openssl, image/font/media parsers → fast-track on high severity. Tier 2 (compartmentalized apps): FreeCAD, editors → batch; a bug is trapped in its VM behind the IOMMU. The isolation boundary earns the right to hold Tier 2.

The immutable store means VMs don't break on core updates

Store paths are content-addressed and immutable: an update creates a new path; the old one persists until GC. A VM is a pinned closure — lean (shares present paths) and stable (its exact paths never move). Updating a VM = a new generation (atomic switch, roll back to the prior one whose paths still exist); each generation is a gcroot that keeps its paths. A host security overlay just makes a patched path available; each VM adopts it on its own schedule, with rollback — never force-broken.

Test gating — it will break subtly, so catch it

No artifact ships until its test suite passes (never narrow the check). Core OS gauntlet: compile, headless boot, compartment-role checks, presence socket, trust rings, scene_fails=0, PLUS bond-grant flow and apply-then-rollback. Per-VM smoke test: its own done-criterion (firefox launches + renders; FreeCAD/KiCad open). Channel soak IS the extended test: chaos → alpha → … catches what the gauntlet misses before stable users see it.

• Baseline cadence (weeks?) + the overlay-debt threshold that forces a full bump.
• Security signing — expedited-but-scoped path on the 2-of-3 threshold, or a dedicated security-response key scoped to same-baseline overlays only.
• A/B verity + sysupdate — is the atomic switch + rollback wired, or still to build? Determines how much of the existing-user path is real vs to-do.
• Expose "security vs feature" update in the UX? (Recommendation: yes — trust + transparency.)