6q. The fleet update at scale: rings, lanes, and one build per model

(The 2026-09-28 full analysis, A1; docs/proposals/65-fix-fleet-scale.md.)

Rings. After the canary, an update moves through internal, then 1%, 10% and 50% of customers' companies (first, early, half), then everyone (FLEET_RINGS in packages/control/src/rings.ts). Each ring opens when the one before has landed, answered healthy on the new engine, and baked; each is trusted with more upgrades in flight at once (bound: 2, 4, 12, 30, 60). The Fleet screen's Rings table shows each ring's bound under At once.

Two lanes. A customer's deploy, promote or rollback is always taken before any upgrade, and the fleet may hold all but one of the deployer's instances (fleetSlots: DEPLOY_SLOTS − CUSTOMER_SLOTS, 4 − 1). If a customer says their rollback is waiting, the rollout is not why: look at the deployer's log for the request, not the Fleet screen. DEPLOY_SLOTS must equal the deployer Container's maxInstances in infra/control-plane.json; the manifest test refuses them apart, so raising one means raising both.

A frozen rollout also stops what was already raised. Upgrades a ring raised ahead of the executor stay queued, and none is claimed until you resume (upgradeHold). The deployer log line for one says held and why.

One build per model. Targets whose revision is the same model over the same history share one build (build.shared in the audit log names the revision whose build serves them). A target whose bytes turn out different asks for its own when its runner finds no green build, as before.