6j. Live deploy stages

A deploy request's stage — queued, building, rehearsing, rehearsal staged, the copy of production, landing, done, failed, blocked — reaches the portal's Releases screen and the console's Rollout as it happens (DESIGN.md §17, "Live deploy stages"). Nothing here is by hand: the first control-plane deploy that carries the stages Worker creates the STAGES queue, uploads the Worker with the migration that creates its two room classes, binds the portal and the console to one each, and attaches the consumer.

How it moves: every write of a request's row goes through staged() in packages/control/src/deploy-requests.ts, which records a row in platform_deploy_stage — numbered for the fleet (seq) and for the account (account_seq) — exactly when the stage changed, and puts the notice on STAGES: from the portal's and the console's producer bindings, and from the runner over the REST API (controlPlaneFor, named for its instance). The stages Worker hands each notice to the account's room and to the operators'.

What to look at when a screen is not live. The screen says so beside "What has been asked for" (portal) or under "Fleet update" (console): Live, Connecting, or Checking for changes when it has fallen back to reading itself every thirty seconds. Then, in order: the stages Worker's logs (stages: … retried is a room it could not reach); the queue's backlog in the dashboard; whether the portal and console Workers carry PORTAL_STAGES / CONSOLE_STAGES and STAGES (a deploy that predates them answers the socket with 503 and the screens are static — correct on every reload). Nothing is lost while it is down: the rows are the record, a missed number makes the screen read itself again, and a reload always shows the truth.

Latency is the queue's batch wait: an event reaches a screen within a few seconds of the write, not instantly. The consumer's max_wait_time_ms is Cloudflare's default; the deployer does not set consumer settings yet.