Website preview

Preview + revisions[] (the chat) + the draft URL.

Every revision carries its OWN ``preview_url`` (the Worker version uploaded for its checkpoint sha), and the top-level ``preview_url`` is the current revision's — a new build means a NEW URL, so the console no longer has to cache-bust a reused host, and past revisions stay viewable (History). Both are None until the version lands, a minute or two after the revision goes ready.

``live`` is the edit-pool slot serving this preview (live edits), which the console frames instead while it is set; ``session_enabled`` whether this preview's edits run live at all.

202: rows are committed and revision 0's generation is spawned; poll GET.

Also the "start over" path — an existing (unconfirmed, not in-flight) preview is replaced with a fresh one on the same repo/worker, and the onboarding website stage the replaced draft's failure left ``failed`` runs again with the new one (``reopen_onboarding``: an owner's start-over, which auto-onboarding's own re-entry is not).

The preview's live run as SSE, in website-mod's frame shape: its events after ``after_seq``, ``reset`` when the run changes, ``done`` when it ends. The console opens it when an edit is sent.

What the agent did for each past chat turn, and for the full build once it has run, so the account of the work survives a page reload and outlives the stream (which only ever narrates the one live run).

Joined to the chat by ``revision``; the prompts, replies and timings come from the preview read, which the console already has. ``build`` is the launch's own account, filed under the confirm.

Every 60 s while the preview chat is open: a lease nobody extends lapses and the slot returns to the warm floor. ``live: null`` when the preview holds no lease (pre-warm is what claims). 404 when edits do not run live.

Called once when the preview chat opens, so the slot has cloned, installed and booted the draft before the first edit. Idempotent: a slot already serving the current draft is left alone, and a run in flight keeps what it serves. Nothing to warm (no ready draft yet, or the chat is closed) answers ``live: null``. 404 when the preview's edits do not run live.

Keystone staff only: the reason and what the check had found are kept in ``website_check_overrides``. 409 when nothing is held back.

202: the edit slot looks again, without the site agent, at the pages a check that never reached the browser was to look at. The read shows ``rechecking`` until the new check lands. 409 while a revision generates, without live edits, or for a check a look cannot settle.

202: preview → confirmed, draft PR closed (never merged), seeded full build fired after commit. Only a ready preview confirms (409 otherwise).

The body is optional and additive: ``{"text": ...}`` persists the customer's confirming chat message on the preview as ``confirm_text`` (it IS the confirmation, in the prototype's conversational shape); no body keeps the original behaviour exactly.

With ``website_preview_engine_enabled``, a confirm while a revision is generating answers 202 with ``queued: true`` instead of 409: it runs when that revision settles ``ready``/``no_change``.

202 with revision n+1 spawned; 409 while any revision is generating.

The message's INTENT is decided server-side first (see ``website_preview.intent``): a message that reads as approval ("looks good, ship it", "finish my website") runs the SAME confirm flow the dedicated /confirm route runs — the service function is reused, never duplicated — and answers with ``intent: "confirm"`` and no revision. Any other message runs the edit flow exactly as before, with ``intent: "edit"``. The /confirm route itself is untouched (the console chip may still call it directly).

A confirm-labelled message the preview cannot confirm (409: not ready, nothing built yet) FALLS THROUGH to the edit flow instead of erroring: the label was the classifier's guess, and dropping the customer's words on the floor because the guess outran the preview's state was a real lost-message bug. The dedicated /confirm route keeps its honest 409 — there the caller SAID confirm.

Idempotent: a request no longer queued answers ``removed: false``.

The owner's Stop: the site agent's turn ends at its next step, and what it changed so far settles as the revision (nothing changed: no change). 409 when no edit is being made on a session pod (the job cannot be stopped) or the pod cannot be reached; an edit still on its way to its pod is stopped once it gets there. ``revision`` names the edit the Stop is for: a late Stop, once that edit settled, never stops the queued one.

The owner's Undo: the draft goes back to the edit before the current one (the first draft at the earliest), and the next edit builds on it. 409 while an edit is being made or a finish is queued, and with nothing to undo.