Drafts, staging, publishing

The short version

Every change lands in the site's draft. Visitors do not see it.
Stage takes the changes from the draft, builds the staging site and runs the quality check.
You look at staging. When it is right and the check passes, a person clicks Publish live.

The AI may stage its own finished work. It never publishes. Publish live is always a human click, also when automatic redeploys are switched on.

One shared draft

All chats work in the same draft. Open two chats and each sees the other's unstaged changes in its preview. Chats are conversations, not separate copies of the site.

Two chats, same thing. If another chat changed a module or page after this chat last looked at it, the AI re-reads it and redoes its edit on the current version. Nothing is silently overwritten.
Stage a selection. Stage takes exactly the chosen chats' changes. If another chat changed the same module, that change comes along, and the result says so.

Experiments and migrations get their own branch

Ask the AI to try something ("try a redesign of the homepage"), or start a site migration, and that chat works on an isolated branch. Nothing it does shows up in the draft or in other chats until it is staged. You can start one yourself with New experiment (own branch) in the chat menu.

The shared draft is visible to every editor. An isolated branch is visible only to the editor whose chat it is, and to roles with the View all drafts permission (drafts.view_all, held by the Owner role).

Open changes

Open changes in the sidebar lists every chat with unstaged work: what it changed and what moved between chats. From there you can:

Stage all: stage all your chats in one go, with one build and one quality check;
tick some chats and Stage selected, so a half-finished chat stays out of staging;
Discard a chat: throw its unstaged changes away and close it. If another chat built on those changes, you are asked first.

Other editors' chats are shown read-only.

Stage

A Stage takes the selected changes into the site, rebuilds the staging site and starts the quality check. Before you confirm, the Stage dialog lists the pages, modules, templates, layouts and lists that will change.

Only published pages are built. A page with status Draft stays out of staging and live. The Stage result lists the drafts it left out. Switch the page to Published in the toolbar (or ask the AI) and Stage again. Setting a page to Published only means "include it". It still reaches visitors only through Publish live.
Meta description required. A published page without a meta description stops the Stage, and the message names the pages. The AI normally writes the description when it builds a page.
Broken pieces stop the Stage. If a section cannot be rendered, for example a card list that points at a deleted card, the Stage stops instead of publishing an empty section.
Quality check. Stages that can change how pages look or perform get a Lighthouse check on mobile, with 100 as the target. Every Stage also runs the page checks plugins add. New problems block Publish live. See Quality gate.

The staging site

Staging shows the site exactly as Publish live will ship it. It is never meant for visitors:

Staging is always noindex: robots.txt disallows everything, and every response carries X-Robots-Tag: noindex.
On Google Cloud with Firebase Hosting, staging has its own host (by default staging.<your domain>) and is password-protected from the start. Setting up the staging host turns on basic auth and prints the user name and generated password once. Admin users get in through Open staging or any staging link in the admin, without a password, for 12 hours. Crawlers and tools can also use a secret header or an IP allowlist. Everything is under Settings → Staging access.
On the other install types, the staging preview is served through the admin, so only signed-in admin users can open it.

The AI can read the staging address and propose access changes. Each change waits for an approval in the chat. It sees the password only when an Owner asks for it.

Publish live

Publish live needs the deploy.trigger permission. It stays disabled, with the reason shown next to it, while the quality check is running, has found unaccepted problems, or failed.

On Firebase installs, Publish live rebuilds the same content for the live host and compares it with the staged build file by file. If anything else differs, because something changed after the Stage, it stops and names the first differing files. Stage again, check, then publish.

Next to the button, Live matches staging or Newer staged build not yet live tells you where things stand.

Undo

Before you stage:

Undo a chat. Tell the AI "undo this chat". It removes all of that chat's unstaged changes from the draft. If another chat has since built on the same things, the AI tells you which chats and asks before going ahead.
You can also Discard a chat under Open changes.

After you stage or publish:

Revert from history. Every write is saved as a snapshot. Pages and modules each have a history, and Advanced history (/content/history) lists snapshots site-wide. Anyone with edit rights can revert a page, module or template, or the whole site, from there directly.
Ask the AI. The AI can prepare the same reverts. When the AI does it, it asks for approval in the chat, and an Owner or admin clicks Approve.
Roll back the live site. The AI can roll the live site back to an earlier published build, after an approval in the chat. This works on Google Cloud with Firebase Hosting and on your own server. On the gcp setup (load balancer) it does not work yet.

Approvals

About 50 actions always wait for a human click on an approval card in the chat before they run, among them site-wide undo, moving ten or more URLs at once, deleting five or more pages, new layouts and themes, users and roles, domains and plugins. The person who approves needs the same permission the action requires. If they lack it, the request stays pending for someone who has it. Requests that come from outside a chat collect under Settings → Pending approvals.