Documentation

Build my site is the site assistant's biggest job: you describe the business in the assistant bubble, it plans the site and asks only what it cannot work out for itself, you approve the plan, and it builds the site in the background — business settings and the brand brief, branding, content types with their records, every page with copy, images and search text, the menu, and form notifications — then checks its own work and hands you a report.

You can also start it without a chat, from one page of questions — AI → Build my site — or straight from a client's onboarding form submission (see Building without the chat).

It is part of the AI Assistant feature (Settings → Features) and runs on the install's own AI provider or its managed AI. Visitors never see any of it until the build is over: every page it creates stays a draft until then.

Who can use it

	Who
Start a build — from the assistant bubble, or from AI → Build my site (including Build the site from this submission)	Admin and above — a build writes settings, branding, content types and navigation
Watch progress (the build card and the watch view) and read the report	Manager and above (anyone who has the assistant bubble)
Cancel a build	Admin and above
Fix these, Retry failed items, Look over the pages it didn't see, Publish these anyway and Undo this build	the Admin who started that build (still an Admin)

It needs the AI Assistant feature switched on and an AI provider (Settings → API Keys, or managed AI). Without a provider the bubble hides itself.

How a build runs

1. Ask. Open the assistant bubble and say what you want — "Build my site: we're a residential electrician in Austin", or "rebuild the site around our three services".
2. It reads before it asks. The assistant first looks at what the site already has — business settings, pages, content types, branding — so it never asks for something the site already knows. To rebuild an existing website, give it the old site's address: it reads that site first (see Rebuilding an existing site).
3. It asks, once. In a single message it asks only for what it could not find (see below).
4. It shows you the plan. The plan appears in the approval card: the pages it will build, each content type with how many records, the menu, the look, the image policy, which AI models do the work (two selects, when your site offers more than one model) and an estimate of what it will cost and how long it will take on those models — under a line that says plainly that the build runs without asking again. Approve starts it. "Change the About page first" is just another message — the assistant revises the plan and asks again.
   • A plan that cannot run never reaches you. The assistant's plan is checked before the card is shown; one that would not validate (say, a font named in two places the build cannot reconcile) goes straight back to the assistant with the reason, in the same reply, and you only ever see the corrected plan. If a plan on a card stops fitting before you approve it, the card says so in one plain sentence — never the assistant's own technical reason — and the assistant is told what to fix when it checks the plan again.
   • Approving after a while is fine. The approved build carries on the same conversation the plan came from, however long the card waited: the assistant resumes under exactly the instructions it planned under, which Claude requires to read its own earlier reasoning. (If the AI provider ever refuses a request, the chat shows one plain sentence — the service is busy, having trouble or could not answer (send the message again), or it refused the site's key, the AI allowance is used up, or the model is not on the site's plan (each says where to look) — and the site log records the provider's own reason — its error type, message and request id; never your key — under assistant chat: the AI provider refused the request.)
5. It builds in the background — and you can watch. The dashboard switches to the watch view: the page being built, live, beside the list of work and a running feed of what the builder is doing (see Watching it build). A build card also pins itself above the message box. You can keep using the dashboard, close the bubble, or reload the page — the card comes back while the build is running, with a Watch it build link back to the watch view.
6. It checks its own work. While it builds, it looks at each page in your browser — at desktop and phone width — fixes what it sees, and looks once more (see The build's eyes). At the end, every page it published is opened the way a visitor would open it — see The final check.
7. It reports. When it finishes, the card shows the report: links to every page, what the final check found, anything it could not finish, what the build used, and a short list of things only you can confirm. Fix these sends the assistant back for one pass over what it can fix; Retry failed items re-runs what did not finish; Look over the pages it didn't see gives the pages it built while nobody was watching their look (see Look over the pages it didn't see); Publish these anyway publishes the pages an unfinished item left as drafts (see Publish these anyway); Undo this build puts the site back to how it was before the build started (see Undo this build).

The build always waits for your go. The assistant's "Apply changes without asking" setting skips the approval card for ordinary edits, but not for starting a build: a whole-site build is minutes of unattended writes, so its plan is shown and approved every time, whatever the toggle says.

Rather fill in a form than chat? AI → Build my site asks the same questions on one page and starts the same build — see Building without the chat.

What the planner asks (and never assumes)

• Business basics it could not find — name, phone, address, service area, hours. Unknown hours become "Call to schedule"; it never invents them.
• Your services or offerings — these become a content type with one record each, so the pages that list them stay in step when you add one later. Services that group under a few main ones (Residential → Panel Upgrades) become the services pattern (below).
• Which pages you want.
• Whether to publish a contact email on the privacy page. It tells you the address is published on the public privacy page, suggests a role address (or none), and never uses your private business email for it.
• The state the business is based in — the privacy policy's jurisdiction.
• The image policy — key spots only, every image spot, or none — and that AI images use credit.
• Whether any default "never say" claims may be loosened — 24/7 or emergency service, bonded or insured, warranties, licence numbers, years in business.
• The design questions, in the same message — never one of their own: how the site should look and feel, in a few words (your own adjective, such as "professional", bounds the whole design); system fonts (the fastest, no download) or a heading font of your choice; a website you like the look of; and anything you do not want in the design. Any of them may be skipped. A site that already has a standing design direction is not asked them — the build keeps it unless you ask for a new look.

It asks once. Whatever you leave unanswered the build fills in itself — a design question left unanswered means the credible direction, named on the plan card before you approve — so there is never a second round of questions. Your design answers travel with the plan (design_answers), and every build item reads them: what you said you do not want never appears.

The plan is a closed list: the pages, menu links and widgets you asked for, nothing more. An idea of the assistant's own goes in the report as a suggestion.

Rebuilding an existing site

Most sites are not built from nothing — the business already has a website (WordPress, Wix, Squarespace, a page builder…) and wants it moved onto this one. Give the assistant the old site's address — "rebuild our site, the old one is at example-electric.com" — and it plans the rebuild from what is there.

What it reads. The assistant's read_website tool fetches the old site's pages: the ones its sitemap lists (sitemap.xml, sitemap_index.xml or wp-sitemap.xml), or — when it has none — the pages its home page links to, up to 30 pages (15 unless the assistant asks for more), at most 2 MB of each, and for no more than about 50 seconds in all, so the chat answers in time; when a cap stops it, it says so. From each page it takes the title, meta description, main headings and the start of its copy; from the site as a whole, the menu, photo candidates (with their alt text and size where the page says), and the phone numbers, email addresses and social profiles it shows. It reads only that one site: a link or a sitemap entry pointing at any other site is never followed, a redirect is followed only while it stays on the same site, and this site's own address is refused — the assistant reads the old site, never the one being built. Every request goes through the same address guard the rest of the site uses for addresses someone typed (public addresses only, no redirects followed blindly). Reading changes nothing on your site.

What is never copied. What the old site says is source material, not copy — and another site's words, so the assistant treats them as data, never as instructions: the assistant takes its facts — the services, the areas served, the history, the team, the photos — and writes every sentence fresh in your site's voice (your AI Brief), and nothing the "never say" list rules out comes across. Email addresses found on the old site are treated as private until you say one may be published. Before it starts, the assistant shows you the pages it read and the redirects it proposes, and asks only what is still unclear.

What the plan card shows. A rebuild's plan card adds Rebuilt from — the old site and every page read from it — the Redirects (each old address and the new page it will send visitors to) and how many Images to import. The approval line counts them too.

Redirects. Every old page whose new home is at a different address gets a permanent redirect (/about-us.html → /about), so links from Google and from other sites keep working. They are added after the pages and the menu, each through the same checks as the Redirects page: never from the home page, never from an address a page on the new site answers (that redirect would hide the page), never a second redirect from the same address, and always to a page the build makes or the site already has — a plan that points one anywhere else is sent back to the assistant before anything starts. The build never changes an existing redirect: an old address that already redirects somewhere else is left as it is, with a note on the plan (change it at Dashboard → Redirects if you want). A redirect to a new page starts working the moment the build publishes that page. Up to 50 redirects per build.

Imported images. The old site's real photographs (not its logos or icons, unless you want them) are copied into the media library before the pages are built — up to 40 per build, each through the media library's safe image import (public addresses only, it must really be an image, size-capped, stored at the library's width). An image named for a page is placed on that page by the page's own item (it uses those before generating anything); one named for a particular spot on a page that already exists is placed there straight away, and the page's item keeps it. Importing the same image again — a retried item — reuses the one already in the library.

What the report says. The report lists each redirect (added, already in place, or not added and why) and each imported image (imported, placed, or not imported and why). Anything that did not happen is also on Over to you.

Undo takes back the images the build imported (once nothing uses them) and the redirects it added, like everything else it created. The read itself happens in the planning chat, before the build — it writes nothing, so there is nothing of it to undo.

Building without the chat

AI → Build my site (/dashboard/ai/build, Admin) is the same build started from one page of questions instead of a conversation — handy when the answers already exist, such as a client's onboarding form. The AI Site page (Develop → Generate with AI) links to it too. The page starts filled in with whatever the site already knows — the business name, phone, address, hours and service area, the business summary, the privacy jurisdiction and your own "never say" lines — so nothing is typed twice.

What it asks.

• About the business — name, what kind of website it is (the same site types as the setup wizard; it decides which starter pages are offered), the business type, what you do, the audience, where you are based, and the tone of voice.
• Contact details — phone, street and city/state/ZIP, hours (or tick No set hours, and the site says to call to schedule — hours are never made up), and the service area.
• Services — the few to lead with, and every service you offer, one per line. They become records of the Services content type, so the pages that list them stay in step when you add one later. A line ending in a colon starts a group (Residential:), and the services under it nest beneath it. With Give each service its own page ticked (the default) the plan uses the services pattern: each group is a main service with its own page and its services nested under it; unticked, every service is a plain record with no page of its own.
• Pages — the site type's starter pages (home, about, its own pages such as Areas We Serve, contact), each ticked, plus any of your own, one page name per line. Pages the site already has are rewritten in place; new ones are laid out from the Page Library; legal pages are never touched. The Services list page comes from the services themselves. Set the main menu to these pages (on by default) makes the main menu home, about, Services, the rest, then contact.
• Privacy and claims — the state the business is based in (the privacy policy's jurisdiction), whether to publish a contact email on the privacy page and which (it says plainly that it is published), the five default claims the site never makes unless you tick them (24/7 or emergency service, bonded or insured, warranties or guarantees, licence numbers, years in business), and anything else it must never say. The five are recognised however they were written — by the Knowledge page or an earlier build, in any case or punctuation — so ticking one really loosens it and the list never grows a second copy; the chat planner writes them in the same words.
• The look — all optional: how the site should look and feel (a few words), Fonts (system fonts — the fastest; the build picks a serif or sans for headings to suit the feel — or a heading font of your choice from the font catalogue), a website you like the look of, and anything you do not want in the design. Left empty, the build follows the credible direction — or, on a site that already has a standing design direction, keeps that one (the section says which) — and the plan's notes say so.
• How it builds — the image policy, whether it may design new sections, the two models (when your site offers a choice of build models; each starts on Recommended: …, the model the build would choose), where form submissions are sent (private, never published), and anything else the build should know.

Your AI Brief is filled in, never overwritten. The answers go into the brief every build item reads. The site's AI Brief gets the identity, the voice (from the tone) and the audience only where those are still empty — anything you already wrote there is kept, and the tone list then offers Keep the voice in your AI Brief, chosen by default (if that voice has been cleared by the time you build, the build writes in a professional tone rather than none). The "never say" list is written as the page shows it: the default claims you did not tick, then your own lines.

Review the plan, then build. Review the plan checks the answers with exactly the checks a chat plan gets — a legal page, a model your site does not offer, services the site's existing Services type cannot nest — and shows each problem word for word; nothing starts. A plan that passes is shown on the page itself: which site it builds, the summary, the design direction it follows, every piece of work in order, the number of pages, content types and records, the estimate of what it will cost and how long it will take, any notes on the plan, and that it runs unattended — new pages stay drafts until it finishes, you can cancel it while it runs and undo it afterwards. Build the site starts it and opens the watch view. Change an answer after reviewing (or let the site move under the plan) and the plan is shown again before anything starts — what you checked is what runs. When the direction would lay out again a homepage you have changed since the theme installed it, the check offers Replace my homepage layout: ticking it shows the plan again as it will run (the homepage item becomes Lay out / again); left unticked, the homepage keeps its layout and only its words are rewritten. While another build runs, the page says so and links to its watch view; one build runs at a time.

Stay on the watch view. The build's eyes are the watch view of the admin who started it: with it open, every page is looked at and fixed as it is built; with it closed, the pages are built without being seen and the report lists them as unseen — Look over the pages it didn't see gives them their look afterwards.

Build the site from a form submission

A form with a services field — the onboarding form a client fills in with their industry and the services they offer — gives each of its submissions a Build the site from this submission button (the sparkles icon on the submission card under Forms → Submissions) for an Admin, when the AI Assistant is on. It opens Build my site filled in from the submission:

From the submission	Fills in
A company field (company, business_name …), else the person's name	Business name
A phone field	Phone
The industry (Electrician, Plumber, Lawyer, Accountant)	Business type, and the site type with its starter pages ("Other / not listed" leaves both for you)
The services' categories	Services to lead with
The categories with their services	Every service, grouped — a draft to edit
The email address	Send form submissions to — never the published privacy contact

Nothing is built from it until you have checked every answer, filled in what the form did not ask (what the business does, at least) and pressed Build the site on the reviewed plan. The look questions are on it too; a submission answers none of them, so left empty the build follows the credible direction and says so. A submission marked as spam, or one from a form with no services field, fills nothing in; one that has since been deleted says so. The answers are read through the submission itself, decrypted, exactly as the submissions list shows them, and the brief frames them as facts about the business — never instructions to the AI.

What the form cannot do

• Rebuild an existing website. That needs the assistant to read the old site, map its old addresses to redirects and pick the photos to import — ask in the assistant bubble instead (see Rebuilding an existing site). A form plan carries no old site, redirects or image imports.
• Branding and social links. Colours, the theme style and social profiles are not asked (the fonts are — under The look); set them on their settings pages, or ask the assistant.
• The footer menu, page-by-page purposes and page designs — the builder picks a design for each new page from its name and the brief.

The order of the work

The plan becomes a list of work items, run one at a time in this order — each one depends on the ones before it:

Order	Item	Why it comes here
1	Business settings and brand brief	Everything after is written in the voice and with the facts this sets
2	Branding	Colours, fonts, corner radius, shadows, theme style — and the design direction's fonts and button style, when the plan has a direction
3	The site-wide rows (a direction that changes one)	The header, footer, page-title band and closing banner the design direction changes, chosen to suit the brand just set, before the pages that sit with them
4	Each content type with its records	Pages bind to the records, so they must exist first
5	Import images (a rebuild)	The old site's photos go into the media library before the pages, so each page can use its own
6	Each page	A new page is laid out from a page design; a page that already exists is rewritten in place (see below). Then copy, images, meta title and description — then the builder looks at the page, fixes what it sees and looks once more
7	Navigation	Links pages that now exist
8	Redirects (a rebuild)	The old site's addresses point at the pages that now replace them
9	Form notifications	Where contact-form submissions are sent (kept private)

Then it publishes the new pages (see below), rebuilds the site's CSS, and runs the audit that becomes the report.

Items with nothing to do are skipped — a plan with no branding changes has no branding item.

How pages are laid out

A new page starts from a page design — a whole-page recipe from the Page Library: the page-title band, sections whose backgrounds already alternate, and the shared call to action. The planner names one for each new page, matched to its purpose, and the builder picks one itself when the plan doesn't:

Design	For
Service Detail	One service in depth — intro beside a photo, what's included, common questions (published as FAQ search markup), call to action
Services Landing	A group of services or a services overview — the service cards come straight from the Services records, so a new service appears without editing the page
FAQ	Questions and answers, published as FAQ search markup
Interior Page	Any other inner page — service areas, financing, why choose us, a policy in plain words

The backgrounds a design sets are the sections' ordinary Section preset setting (the paintbrush), so you can change any of them afterwards. If a design names a section this site can't use — a feature that is off, or a content type it lists that doesn't exist — that section is left out, the rest of the page is laid out, the builder says so in its closing note, and the sections either side are adjusted so two of the same background never end up touching.

A page that already exists is rewritten in place — the theme's home, about and contact pages, or a page of your own. Its layout is kept: the build rewrites the copy, gives a background to a section where two white ones touch, places images and sets the meta title and description, and never lays the page out again — the one exception is the homepage under a design direction that says so (see Laying the homepage out again). These show in the item list as Rewrite /about. A design named for such a page is dropped, with a note on the plan.

Sections of matching cards are filled card by card. A section whose cards share one design (a repeater — the features grid on the Interior and Service Detail designs, for example) is written as one set: the builder sets every card at once, as many as the content has (three service areas make three cards), each with its own title and text. It never writes one card field on its own, which would put the same text on every card.

The services pattern. When your services are records with pages of their own, the plan makes them the services pattern: the site's Services content type, every service on its own page, sub-services nested under their main service (/services/residential/panel-upgrades). The main services are always created before the ones under them, each record's own page reads its intro from the record (so the dashboard record stays the one place to edit it), each main service's page gets a Sub-Service Cards section listing the services under it straight from the records, and the Services list page at /services lists the main services by itself. A plan the build could not carry out this way is refused before anything starts — a page already sits at /services, the site's existing Services type doesn't allow records under other records, or a service names a main service that isn't in the plan or on the site.

An existing Services type is switched over for the build. The Services type most sites start with lets records nest but gives none of them a page of its own. When the plan asks for the services pattern (or for records with their own pages), the build's content-type item turns on what is missing on the existing type — records get their own pages, records nest under a parent, records keep a summary — so the records it adds get their pages. It only ever turns these on, never off; records the type already had keep their pages as they were. Undo this build turns them back to how they were.

The design direction

A plan can carry a design direction — the look you picked for the site, decided line by line, so the build stops falling back to the theme's defaults:

Line	What it decides
Volume	credible — the best-looking version of what a business in your trade normally looks like, with one touch of yours — or expressive: bolder type, colour fields and devices, still inside your own words
Picture	One sentence anyone can see ("the website is the shop window on Main Street, lit at dusk")
First screen, closing banner, page-title band, header, footer	Each either keep (what the site has stays) or the idea of the new one, in a sentence
Homepage layout	keep, or relayout — lay the homepage out again to the direction
Buttons	keep, or one of the button styles by name: classic, pill, tailored, square, raised
Fonts	system (no download — the direction still chooses the system serif or the system sans for headings; the body is the system sans unless it says the serif, and there is no accent face), custom (a heading face you chose, and optionally a body and an accent face — a body it does not name is the system sans, and there is no accent face unless you chose one), or keep

• Every new build has one. Picked by you, or — when nobody picked one — the credible direction, and the plan says which. Only a plan saved before directions existed builds without one, exactly as the rest of this page describes.
• Whole or not at all. A direction must decide every line (the name is optional). One that leaves a line out, or says "default" where it means keep, is sent back to the assistant before anything starts — a half-filled direction never applies half of itself.
• Every item works inside it. Each work item is told the direction. A page that already has its own layout is still rewritten in place — except the homepage when the direction says relayout and the build may replace it (see Laying the homepage out again). Pages are no longer told to leave alone a shared row (header, footer, page-title band, closing banner) the direction changes — but a page never edits a shared row itself: those are one row on every page, changed once for the whole site by the build's site-wide rows item (see The header, footer, title band and close).
• One answer for the fonts and the buttons. With a direction, its fonts line is the only one: the plan's branding names no fonts (heading, body or accent), and the branding item sets all three exactly as the direction gives them — so on system fonts the site's earlier body or accent web face goes too, and nothing is downloaded. The same goes for the button style. Inside the build, a branding call that names another font or another button style is refused, and one that leaves part of the direction's answer out gets it filled in. A direction whose fonts and buttons both say keep sets neither. When the assistant also names fonts under branding beside a direction that sets the fonts, the direction wins: those fonts are left out of the plan, its notes say which, and the plan still runs. Beside a direction whose fonts say keep, a branding font is sent back to the assistant, which must say whether the fonts change.
• Branding lands whole. Colours, fonts, corner radius, shadows and the button style are all checked before any is written, and written as one change: one bad value — or a write that fails halfway — leaves every brand setting as it was.
• No theme style switch. A theme style (variant) replaces the header, footer, page-title band and closing banner together and resets the colours and fonts. With a direction those are decided one by one, so a plan that names a theme style beside a direction is sent back before anything starts, and inside the build a branding call that switches one is refused.
• It stays after the build. When a build that carries a direction starts, its direction becomes the site's standing direction. The dashboard assistant, the page editor's assistant and the build's own page check are told it on every request, so later work stays inside it — your own explicit request still wins. Only one build runs at a time, so a second build can never replace the direction while the first is running; a build that keeps the standing direction (or a plan from before directions) leaves it as it is. (It is stored in the knowledge.design_direction setting, with the build that set it.)

When nobody picks a direction: the credible one

Every route into a new build — the assistant's plan, Build my site, the form a submission filled in, and the plan card's forecast of it — goes through one step that makes sure the build has a direction (SiteBuildPlan::forNewBuild(); a build started any other way is refused). When the plan names none:

1. Your design answers (the look questions) make the credible direction: the best-looking version of what a business in your trade normally looks like, in your words.
2. No answers, but a standing direction from an earlier build: the build keeps that one — the site already knows its look.
3. Neither: the credible direction from what the site already knows (the trade, the tone).

The plan's notes — on the plan card, on the Build my site check and in the report — say which, with the direction in one line. The credible direction is made the same way every time, with no AI call (SiteBuildCredibleDirection::for()):

Line	The credible direction
Volume	credible
Picture	"Looks like the best {your trade} websites, {your feel}: clear, trustworthy and quick to act on." — less any of those three your feel already says, so no word appears twice; its one-line form reads "Credible": … (the name already says the volume)
First screen	one real photo of the work or the place with a headline that says what you do and where, and your trade's first step (call, quote or book) as its one button — or words first, with no photo, when the build has no pictures
Closing banner	one short line and one clear button for your trade's first step — no form, no sign-up
Page-title band	a quiet band of brand colour with the page name and its breadcrumb — no photo
Header, footer	keep — they carry your menus, logo and contact strip
Homepage layout	relayout — only where laying it out again is allowed
Buttons	the style your words suit (the earliest of them decides: "professional" → tailored, "friendly" → pill, "bold" → square), else keep
Fonts	a heading font you chose, else system fonts — the serif stack for headings when your words or trade read classic or formal ("elegant", "traditional", a law firm…), the sans stack otherwise

It replaces only the theme's own closing banner and page-title band. A direction nobody picked — made from your design answers (no question asks about either row) or from what the site knows — changes each of the two only while it is still the theme's own row exactly as the theme shipped it, the same rule as the homepage. One switched to another design (on the Shared Rows page, another theme's, a theme style you saved yourself, an earlier build's), or whose words, photo or any other value were changed on any page — a translation included — is keep, and the plan's notes say so. When both are yours, the build has no site-wide rows step at all. "The theme's own" is the role's shipped row or the row a shipped style of your active theme names (SiteBuildDirectionCheck::isStockRow(), which also decides when a row left as it was is called the theme's own), and "as shipped" compares every value stored on the row with the theme's own copy (SiteBuildRelayout::rowCopyIsShipped(); a trashed page's values do not count). A change to the row's own markup in the page editor is not seen — nothing records the file the theme installed. A direction you pick, the plan's own, the site's standing direction and the credible option among the directions to pick from still name a new close and band — picking one is your choice.

A font the plan names under branding (the assistant's way before directions) becomes the direction's fonts answer; a theme style (variant) it names is set aside with a note, because it would replace the header, footer, title band and close and reset the colours and fonts the direction decides.

Directions to pick from

Before you build, you can see the plan in two or three looks and pick one. On Build my site the Check the plan step has Pick a look, with Show three looks to pick from; on the assistant's plan card Show design directions sits above the model selects. Each press makes one AI call on the site assistant's lane (the managed lane or your own key, exactly as the chat), at the build floor: on the assistant's own model when it is Claude Opus or above (or another provider's flagship), otherwise on the floor's model. It is told your AI Brief, your design answers, the pages and widgets the plan names, and — for the header, the first screen and the close — the library rows that fit what your site can supply, by their design tags, in your site's own order.

What comes back is checked before you see it (SiteBuildProposals):

• One is always credible — the best-looking version of what a business in your trade normally looks like. When none comes back credible, the credible direction is added. At most one is expressive; any more are left out.
• No two are the same site. Two directions that show the same rows on the header, first screen and close (only the colours, buttons or words differ), or that differ on fewer than two of what a visitor sees (volume, buttons, heading font, main colour, header, first screen, close), are one — the credible one kept.
• Every one is a whole direction, checked like any plan's. Its fonts follow your fonts answer (a web font only when you chose one — then your face for the headings). Colours only as plain hex or oklch() values the branding page takes (a lightness written as a percentage is kept as its fraction, oklch(62% …) → oklch(0.62 …)), and none when the plan already names your brand colours — each option's preview then shows those. A row only from that line's own list. Never a theme style. An answer with a few words around its JSON is still read. A direction that comes back incomplete is left out, and the note says which parts in plain words ("missing or unusable: the first screen and the closing banner").
• A bad, empty or failed answer (or no AI provider) offers the credible direction alone, and says why.
• What each row shows is part of the question. The provider is given each candidate row's library description beside its tags, and told that a header, first-screen or close line describes the row it names — so a direction never promises a contact banner over a header that has none.
• A plan that does not build the homepage gets only directions that keep the homepage's layout: laying out a page the plan never touches means nothing, and the pick then shows its first screen as not built.

On Build my site, Pick a look shows the options one at a time. On the left is a short list — each look's name, Credible or Bolder, its colours (New colours when it brings its own, Your colours otherwise), serif or sans, and its picture — with Replace my homepage layout under it. On the right is one large rendered preview of the look you are viewing, what it changes in plain words (header, first screen, closing banner, page titles, footer, buttons, fonts; what it keeps is said once, as Keeps your … as they are), Open the full-size preview ↗ and Use the look's name. Choosing a look in the list only shows it; Use picks it. Show three new looks instead (one AI call) replaces the options and clears your pick. The page says once which direction the build follows: the look you picked, or — with nothing picked — the credible one (or the plan's own). On the assistant's plan card each option is a card with its preview inline, where Open the preview opens it full size.

Every preview draws the look's header, first screen and close in its own colours, fonts and buttons, at a desktop width (so the header shows its full menu) and scaled to fit. On Build my site the frame is sized to what it shows — a page taller than the frame scrolls inside it, and says so under it — and on a phone the preview is drawn at a phone width so its words stay readable. A label over its top corner says the words are samples — the build writes yours; it steps aside while the pointer is over the preview. A line the direction keeps shows your site's own header or close. A preview is only ever yours (Admin, and only the Admin who asked), is never cached, and writes nothing: the colours and fonts are laid over your settings for that one page only, the buttons are compiled in memory, and the rows render straight from the library. A preview that cannot render shows the direction's text instead — the pick never depends on it.

A first screen the plan would not build is never drawn as if it would be. Each time a preview opens, its first screen is read against the plan and the site as they are then: the homepage keeps its layout under that direction (its own first row is rewritten to carry the idea), or the plan does not build the homepage — then the preview shows a placeholder where the first screen goes, saying it is not built. A first screen built only with Replace my homepage layout on (a homepage you have changed) is drawn with a note saying so. On Build my site the note follows the switch: with it on, the first screen is built and the note goes.

Use the look on Build my site (Use this direction on the plan card) writes it into the plan, with its colours (a theme style or branding fonts in the plan are set aside, with a note), and the plan is shown again as it will run; the report says it was your pick. The options are kept for you for 12 hours; a pick names one of them, never a direction the browser holds.

What you saw is what gets built. A pick also writes the header, first screen and close its preview showed into the plan (picked_rows, beside design — only for the lines the direction changes), and the build uses exactly those rows:

• the site-wide rows item is told the design you picked for the header and the close, and swap_shared_row takes no other for those two rows in that build (the page-title band and the footer, which a preview does not show, are still chosen by the tags);
• the homepage, when the build lays it out again or lays out a new one, opens with the first screen you picked — the very library row the preview showed, never a row of your own library under the same name — and scaffold_page refuses any other first row, and a page design for the homepage. If that row can no longer be used once the build has started, a homepage laid out again keeps the layout it has; a new homepage is laid out without it (so the site is never left without one), and the builder's note says so;
• a Retry failed items run is told the same rows and held to them.

Only an option kept for you can name a row: a plan's own picked_rows (from the planner, or a browser rewriting the plan) is never read, and a plan nobody picked a direction for — the credible direction included — has none, so it chooses by the tags as before. A header you picked that the site already has is the site's header kept: the build never "switches" to the header it has, so that line of the direction becomes keep, with a note. A pick names its close even on a site whose closing banner you customised — the automatic direction keeps a customised one, but a pick is your own choice.

When your first screen is not built, the plan says so plainly — beside that look's First screen on Build my site, under the direction on the plan card, and in the report: Your homepage keeps its layout, so the first screen you saw in the preview is not built — because the direction keeps the homepage's layout, because you changed your homepage and Replace my homepage layout is not ticked (tick it to build that first screen), or because the plan does not build the homepage.

A pick the plan no longer fits is cleared. The plan is checked against your pick every time it is made — when you review it again after changing the answers, when you press Build the site, and when you approve the plan card. The pick no longer fits when:

• it lays the homepage out again, and the plan no longer builds the homepage;
• a row it shows is no longer one the site can use: its feature was turned off, or it is no longer in the design library (the options are kept for 12 hours; the library can move under them);
• a row it shows needs pictures and the plan now has none (images set to none, no photos to import), or needs a form, a login, a shop, an offer or records the plan no longer names;
• its fonts contradict your fonts answer as it is now;
• it brings its own colours, and the plan now names your brand colours.

Then the build follows the credible direction (or the plan's own) instead, "Replace my homepage layout" is unticked with it (it was your yes for that pick's homepage), and both the check step and the plan card say why — as does the report. On the plan card, a pick that keeps the homepage's layout unticks it too. On Build my site the switch stays as you set it: the plan never carries it beside a look that keeps the layout, and the switch says it makes no difference to that look — so going back to a look that lays the homepage out again needs nothing turned back on.

The plan card also shows the direction the build will follow and where it came from, the widgets the plan names, the planner's suggestions (not built), and Replace my homepage layout where it decides something; your tick and your pick ride the Approve the way the model picks do.

The closed list

A new build adds only the pages, menu links and widgets its plan names. The plan lists the pages, the menu links (navigation) and the widgets (widgets) — what a visitor can use beyond the pages: form (a sign-up or quote form beyond the contact page), login (visitor logins), shop (a store) and offer (a real promotion or programme to announce). The widgets list holds only what you asked for, plus what the site already has (logins when Memberships is on, a store when E-commerce is on).

Every build item is told so, and inside the build the tools hold the line — each refusal names the reason and changes nothing:

• a new page at an address the plan does not build (a page the site already has is rewritten as before);
• a menu link the plan's navigation does not name;
• a content type the plan does not name, and public list and detail pages for a custom type whose pages the plan does not name (its records show inside the pages that list them; a ready-made type keeps its own pages, as the dashboard makes them);
• a section that needs a widget the plan does not name — a header with a Log In link, a cart, an announcement bar, or a closing banner with a sign-up form. The builder lists sections with the plan's own site_has, so it is never offered one.

No sample photos in a build without pictures. Some sections in the design library ship with a sample photo (an office interior, a dining room) so they look finished in the library — the photo-background and photo-beside-text heroes, the "visit us" closing banner, and the homepage designs that open with them. When the build has no pictures (images set to none, and no photos to import), the builder is refused those sections and the page designs that use them, and chooses a design without one instead — so no page goes live on a stock picture that has nothing to do with the business. A section with an empty picture spot is still used: it shows the plain grey placeholder you replace from the media library. With pictures on, these sections are offered as before.

Ideas become suggestions. An idea that would add a page, a link or a widget — the assistant's while planning (suggestions on the plan), or a builder's while it works (a "Suggestion:" line in its closing note) — is listed in the report under Suggestions — not built. Nothing builds it; add what you want yourself, or ask the assistant.

Laying the homepage out again

A direction whose homepage layout is relayout gives the homepage new sections chosen to the direction, instead of the theme's with new words. The item list shows it as Lay out / again.

• Only an untouched homepage, unless you say yes. The build replaces the homepage's layout on its own only while it is still exactly what the theme installed — the same page file, and none of its copy changed, added or removed (a value you set for the closing banner on the homepage alone counts too). Once you have edited it in any way, the plan must carry your yes to Replace my homepage layout (replace_home_layout); without it the build keeps the homepage's layout and rewrites its words, and the approval says so before you approve. With it, the approval says plainly that your homepage layout will be replaced. This is decided once, when the build starts, so what the build itself writes before it reaches the homepage (an imported photo placed on it, say) never counts as your edit.
• What it keeps. The new layout keeps, as the very same sections, everything the homepage can't do without: a section that lists records (your services, your team) stays bound to the records — never retyped into cards — the closing banner every page shares, a section holding a PHP or Livewire block, and a section from your own design library. The builder is refused a layout that leaves one out, and told which. Everything else is replaced, and the builder names the sections it replaced in its note.
• A version first. Before anything is replaced, the homepage's current layout and copy are saved as a page version — restoring that version from the page history (or asking the assistant to) brings it back exactly — and Undo this build puts it back too.
• Never twice, never under your editor. A build stopped and run again never lays the homepage out a second time, nor saves a second version. And while the homepage has unsaved changes in the page editor — yours or a colleague's, including changes left in a tab that was closed without saving (for 48 hours) — it is not laid out again at all: the builder leaves the page as it is and says why in its note. Save or discard them, then run the build again. The report says so plainly too, under Design direction, not carried out — whatever stopped it (unsaved editor work, page history turned off) — and the build's closing message counts it, so a homepage left on its old layout never reads as finished as planned. Its item stays finished, so Retry failed items does not run it again; a new build does.
• Photos. A photo the plan named for a spot on the old homepage is placed by the homepage's own item instead, on the new section it suits.
• The first screen you picked. When you picked a direction from its preview, the new layout opens with that preview's first screen and no other — and so does a homepage the build lays out new. The rows the homepage must keep are kept as before; the picked first screen only replaces what a new layout replaces anyway. Unsaved editor work on the homepage still decides first.

The header, footer, title band and close

When the direction changes any of the four rows every page shares — the header, the footer, the page-title band at the top of every inner page, the closing banner every page ends on — the build gets one extra work item, right after the branding: The site-wide rows the design direction changes. It is the only item allowed to change them, and only the rows the direction changes: a row it keeps is refused, and a page item never touches any of them.

For each row, the builder lists the designs that row can take (list_row_templates with slot header, footer, title_band or close), narrowed by the design tags that carry that line of the direction (see How the build tells rows apart), chooses among the ones that fit — the first of them when several fit equally well — and switches to it with swap_shared_row — then writes your business's copy into it: the heading, the buttons (each linked to a real page or your phone, never "#"). A header or close you picked from a preview is not chosen at all: the builder is told the design, and swap_shared_row takes no other for that row (see Directions to pick from). It checks the picked design again when it runs; if the site can no longer use it (its feature was turned off after the build started), it puts nothing in its place, and the report names it. Which designs it may choose:

Row	Designs
Header	The shipped header designs (Design → Header & Footer)
Footer	The shipped footer designs
Page-title band	The shipped page-title bands with a breadcrumb trail — so your pages keep their trail, and the search engines' breadcrumb data with it
Closing banner	The shipped call-to-action designs the Shared Rows page offers for the CTA

Only shipped designs (never one saved into your own library), and only ones whose feature this site has on — their styles are already in every site's stylesheet, so a new row never shows half-styled.

• It switches the way the dashboard does. The page-title band and closing banner get the build's own copy of the design, then every page is pointed at it (the Shared Rows page's "install and use"); the header and footer are installed if the site has never had that design, your saved values (logo, call button, links) are carried over to it, and it becomes the site default (the Header & Footer page's switch). No theme style is involved, so the colours, fonts and buttons the branding item just set stay exactly as they are. The rows it replaces are never edited — they stay in your library, ready to switch back to.
• Whole or not at all. Everything is checked before anything is written; the new design and its copy are written before the site is pointed at it, and the switch itself is one change. If anything fails, every page keeps the row it had; if the build is killed mid-switch, the most it leaves is an unused design, which Undo this build removes.
• Your own text stays yours. On a header or footer the site already had, a field you saved before the build is never written over — the builder is told so and leaves it. That includes the values carried over from the header or footer the site had when the build started: your call button travels to the new design and stays yours there, in that switch and in any later one.
• A change, or nothing. A direction that changes the header or footer is carried out by a different design: the one the site had when the build started is refused, and the builder takes the next design that fits. (Choosing it again would leave the row as it was, read as not carried out — and a Retry failed items taking the same first fit would never finish.) The one exception is a header you picked that the site switched to before the build started: while it is still the site's header, nothing is written and it counts as carried out; switched away from during the build, it is put back like any other pick.
• What it writes. Text only: headings, sentences, button labels and links. Never the page-title band's heading (each page's own name), a menu, a field that reads the site's name, an image or the row's colours — choose a design that reads well without a new photo.
• Run again, it lands on the same row. A second call for the same design — to write the copy, or after a kill — finds the copy it already installed rather than adding another.
• Left as it was, the build is not finished. When the report runs, each row the direction changes is read from the site, never from the builder's note. A page-title band or closing banner that is not the build's own copy of a design, or a header or footer that is still the design it was when the build started, means that line of the direction was not carried out: the site-wide rows item is marked unfinished with the reason, the report lists it under Not finished and Design direction, not carried out — naming what the row still is: the theme's own (the one every site on the theme ends on), one an earlier build chose, or one the site had — and Retry failed items chooses it again. A row the direction keeps is never a finding, whatever it is, and a row someone switched while the build ran (from Shared Rows or Header & Footer) stands: the owner's choice wins. A row you picked from a preview is held to the pick instead: it is carried out only when every page shows this build's copy of exactly the design you picked, and anything else — the row left as it was, another design, or one switched while the build ran — is a finding that names the design you picked, and Retry failed items puts that one in. A picked row the site can no longer use (its feature was turned off after the build started) is said as that: the row was left as it was, Retry failed items cannot put it in, and a new build chooses again — it is counted in the closing message but does not hold the item back.
• Undo puts it all back. See Undo this build.

How the build tells rows apart

The rows a direction chooses — the first screen (heroes), the closing banner, the page-title band, the header and the footer — each carry three design tags in the design library (the full list is in Design Library → Design tags):

Tag	What it says	Example values
leads	What carries the row	a hero: photo, person, type, device, collage, video; a header: nav, contact, wordmark, shop
volume	How loud it is, on the direction's own scale	credible, expressive
needs	What the site must supply for it to look right	photo, portrait, form, login, overlay, backend, menus, or none

list_row_templates shows each row's tags and filters by them — leads, volume (the direction's own) and site_has (what this site can supply: a row fits only when everything it needs is there).

• Every row that fits comes first. The list is capped at 60 rows; a filtered list puts all the rows that fit ahead of the rest, so the cap never hides them. A filter word outside the vocabulary is refused with the words it could have used, never read as "nothing fits".
• Untagged rows are listed, never hidden. A row with no tags — one from your own design library, or every row while a site's library has not been re-indexed since this release — comes after the rows that fit, marked untagged.
• A form someone has to wire up is never placed. Two closing banners (Two-Step Email, Schedule a Demo) carry a form that sends nothing anywhere until it is wired up by hand; their tags say so (backend), so a build never places one — even when the plan names a form — and never lists one as a fit. The newsletter rows (a first screen and two closing banners) post to the Marketing feature, so they are offered only while Marketing is on.
• A header that needs a second menu is never placed. Twenty centred-logo headers read the main menu into both sides of the logo, so with the one menu a build sets up the menu shows twice; their tags say so (menus), so a build never lists, proposes or switches to one, and a pick that names one is cleared with the reason. You can still choose them yourself on the Header page and give each side its own menu.
• Each site gets its own order. The rows that fit are listed in an order of this site's own, and the build is told to take the first of them when several fit equally well — so two sites given the same direction don't end up with the same rows. The order is fixed for the whole build: a second call, a later item, a run after a kill and Retry failed items all see the same order, so half the site never follows one choice and half another. A new build gets a new order. It is worked out from the site's install id (the one on the support page) and the build, never from a key or a password, and it only reorders rows the site may use: a row whose feature is off, a theme page's own copy of a row and a whole-page design are never offered.
• Where it is used. The site-wide rows item (above), the homepage's first screen when it is laid out again, a homepage the build lays out new, and the page editor's assistant (below) — except a header, first screen or close you picked from a preview, which is used as picked. A plan without a direction is unchanged.

The direction in the page editor

The page editor's AI panel works inside the standing direction too:

• Same row list. Its list_row_templates answers exactly as the build's does — the design tags on every first screen, closing banner and page-title band, the leads / volume / site_has filters, every row that fits first in this site's own order — held to the rows the open page can take (no header or footer rows on a page, only the sub-categories that page allows, never a row whose feature is off).
• Chosen by the tags. With a standing direction, a first screen, closing banner or page-title band the panel adds is chosen by the tags and the direction's own volume, the first that fits taken — and asked to build or lay out the whole page, the panel lays it out to the direction. Every other row is still the closest match by name. A site with no standing direction gets exactly the rule it always had.
• Told what really happens. With Apply edits without asking on (the default), the panel is told that a change to another page or to the site runs the moment it calls it and goes live at once, outside the editor's undo; with it off, that each one waits for your Approve.
• Lookups never wait for Approve. With Apply edits without asking off, only a tool that changes something waits on the checklist. A tool that only reads — listing row designs, reading a page, listing pages or media — runs at once, so the panel can look things up before it suggests a change. When one step both reads and changes, the checklist lists only the changes: Approve runs them with the lookups, Decline still runs the lookups and tells the panel the changes were declined.
• Never beneath your unsaved edits. The site-wide tools that write a page's rows or content (update_page_text, update_row_design, set_page_image, scaffold_page) refuse the page open in the editor — saved or not — and change nothing; the panel makes the same change with the editor's own tools, which stage it with your other edits until you save. A picture placed that way is handed the alt text set_page_image would have written beside it, for the panel to stage too; and a class the editor's own design tool is given is held to the same check update_row_design makes — a class the live site cannot show is refused, named, before anything is staged. They also refuse another page while someone (a colleague, or you in another tab, including a tab closed without saving, for 48 hours) has unsaved editor work on it, naming who: that editor's next Save would put its copy back over the change.
• The assistant bubble too. Outside the editor, the dashboard chat refuses the same writes to a page someone has unsaved editor work on, names who, and makes the change once they save or discard. A build's own writes are not held back this way (it runs unattended); its homepage relayout is (see Laying the homepage out again).

Button styles

A button style restyles every button on the site at once — the same class strings Design → Buttons edits, one per button type — from the shipped look:

Style	What it looks like
classic	The shipped look: gently rounded corners, semibold text, a thin edge and a faint inner highlight on the filled buttons, a neutral gray outline button
pill	Friendly and modern: fully rounded pill buttons, flat brand-colour fills with no edge or shadow, an outline button drawn in the brand colour
tailored	Quiet and professional: slightly rounded corners, medium-weight text, flat fills, a brand-colour outline button
square	Sturdy and direct: square corners, bold uppercase lettering with wide spacing, flat fills, a heavy 2px outline
raised	Bold and tactile: well-rounded corners, bold text, filled buttons with a soft shadow that lift on hover (when the visitor allows motion), a brand-colour outline button

The assistant applies one with set_branding (button_preset); read_branding says which style the buttons are on now (none, once they have been styled by hand) and lists the styles. A style replaces hand-made button styles — Undo this build puts them back.

Every style shows on the live site exactly as the editor preview shows it — including on a site with no build step, where a saved button reaches visitors only as the difference from the release's own buttons, generated without Node. Each style is checked against that before anything is written, every time it is applied: every class it changes must be one the site can generate, a class it drops must be replaced by one for the same property, it may not change the padding or text size (which the small and large button sizes set — changing them would resize every small and large button on the live site), and a hover or dark-mode state it keeps must be one the live site can carry over beside the changed class. A style that would fail is refused, and nothing in the call is written. A test runs the same check over every style, and a second compares, state by state, what the live site gets for each style with what the preview compiles, a row's own square corners included: a style changes a button's corners only where the row has not set its own, as in the preview.

Design → Buttons runs the same check, more loosely. Saving there is refused only when the save adds a class the live site can never show (one a site without a build step cannot generate, such as tracking-[0.2em] or a mistyped class); the class is named on its button and nothing is written. A class like that saved before, and every change that does show but differently (a padding or text size that also resizes the small and large buttons, two classes for one thing, a removed class the live site keeps showing), saves with a warning beside the button, which is also shown whenever the page opens. A style applied by the assistant never relies on that warning: it must pass the whole check. Details: Asset builds (the "Buttons page save" bullet).

New sections the build designs

By default a build makes every section from the design library — the shipped rows and any rows of your own. The plan has a second setting, rows: author, which the assistant uses only when you ask for it ("design your own sections where nothing fits"). The approval card says so in plain words before you approve.

With it on, a page that needs a section no library row gives can have one designed for it. The rules the builder follows:

• Library first. It looks at the design library before designing anything — your own rows come first in that list (including any this build already designed), and a shipped row, filled with your copy and given a background, always wins when one fits.
• Named for its purpose. A designed section gets a name that says what it is for ("Financing Steps Band") and a description from its brief.
• Never twice. The same section asked for again — by another page, or by an item that runs a second time — is the row already designed, not a near-identical copy.
• At most 12 per build (the same cap the AI Site generator uses).

What a designed section is. An ordinary row in your install's own design library (the custom library — see Design Library), filed under its category with an ai-… template name. It is placed on the page like any template, so every field is editable in the page editor's sidebar, and afterwards it shows up in the Insert Section drawer under My rows for any page. Like every custom row it survives CMS updates.

It is checked before it is saved, and never trusted. A row a model wrote is not treated like markup a person wrote. Before anything is saved it must pass, in order: the row linter (only the shipped x-dl building blocks, brand colours, no hard-coded colours, no scripts or Alpine, no PHP, no method calls, no strings built from variables — read from the source and again from what Blade really compiles it to; words in its copy, such as "new wiring" or "permits we require", are copy and never read as code), a structure check (every building block on a field of its own, and every set of cards loaded from the section's own card list and repeated card by card, so editing one card never changes another and the cards you edit are the ones that show), a check that every class it uses renders on the live site, a syntax check, and a test render. A row that fails any check leaves nothing behind (no file, no library entry); the builder is told what failed and may try once more, and otherwise uses the nearest library row.

Its classes reach the live site when it is on a page and the build compiles — the same CSS rebuild every build runs — so it renders the same on a host without Node.

Admin only: starting a build is Admin-only, and the design tool itself is too.

What runs unattended

Once approved, every change the build makes is applied without asking again — that is what the approval was for. Each item is its own short conversation with the AI, given the whole plan, a summary of what earlier items did, and that one item's instructions, plus the house rules it builds by:

• never invent prices, numbers, addresses, statistics or hours, and honour the "never say" list exactly;
• section backgrounds alternate — never two white sections next to each other;
• three or more matching cards are a looped or record-bound section, never hand-typed copies;
• meta titles never include the company name (the site adds it);
• legal pages (privacy, terms) are never created or rewritten;
• every page it builds or rewrites is looked at before the item finishes — look, fix, look once more, never a third time.

Your AI Knowledge Brief and notes ride along on every item, so anything you have taught the site applies to the build too.

Copy the build writes into a rich-text field is cleaned before it is saved. A rich-text field (a section's body, a record's description) renders exactly as stored, and what the build writes there is the model's output — from a prompt that may have read an old website or a visitor's form submission — not the admin's own markup. So scripts, frames, plugins, forms, event-handler attributes, script links and style sheets are stripped from it first; the words, headings, lists, links and images stay. It is the same line drawn for sections the build designs, and it applies to the assistant's update_page_text and create_content_items tools in a chat as well.

A build can be interrupted safely. If the server stops it mid-item, that item simply runs again, and every tool checks before it writes — a page or record that already exists is left alone rather than created twice.

While a build runs, the assistant's other site-changing tools are held (they explain why), so a chat edit can't land in the middle of the build and be overwritten. Questions still work — ask "how is the build going?" at any time.

New pages stay drafts until the build is over

A page the build creates is a draft from the moment it exists — a visitor who finds its address gets the site's normal "page not found" — so nobody sees a half-built page. That is every page any item creates, not only the pages the plan lists: a page the content-type item lays out for a service is a draft too, tied to the item that created it. When the build ends it publishes every page it created whose item finished (done, or ran out of steps), even when the build stopped early — and it does the same on a cancel, and when the build crashed (a step kept failing until the server gave up on it): the pages whose items had finished go live, the rest stay drafts, and the log says what stopped it. The approval card says so before you approve.

Records are different: a record the build adds is published as it is created, so the lists that read the records fill in as the build goes. A record's own page (the services pattern) shows the record's own content from the moment it exists, so it is never blank.

Two things keep a new page a draft, and the report lists each one with the reason under Still drafts:

• Its item did not finish (it failed, or the build stopped before reaching it).
• The accessibility publish gate refused it — with "Block publishing on accessibility errors" on (Accessibility settings), a page with error-level findings stays a draft until they are fixed, exactly as when you publish by hand.

Each draft in the report links to the page editor — Fix it in the editor for one the accessibility gate held back — and a page that stayed a draft only because its item did not finish can be published as it is with Publish these anyway (see Publish these anyway); otherwise publish a draft from the Pages list once it is ready. Pages that existed before the build — the theme's home, about and contact pages, or a draft you were already working on — are rewritten in place and never drafted or published by the build. The menu links the new pages while they are still drafts, so they appear in it the moment the build publishes them.

Watching it build

The watch view (Dashboard, /dashboard/assistant/build/watch) opens on its own when you approve a build, and the build card's Watch it build link reopens it at any time. It shows:

• The page being built, live in a short, wide frame across the full width — drawn at a desktop width (1280px, or wider when there is room) and scaled to fit, so the header shows its full menu; the work list sits underneath and scrolls. Live in that frame, reloaded each time the builder changes it and following the builder from page to page. While the page is still a draft the frame opens it through a preview link made for this build and for the address your dashboard is open on: it works only while the build is running, only for that one page, and for at most 30 minutes, and it is never cached or indexed by search engines. A visitor with no link — or with an old one — gets the normal "page not found". Open in a new tab opens the same link full-size. The frame shows the page as a visitor sees it — without your floating Edit Page bar, which would otherwise sit over the page and appear in every picture the build's eyes take of it.
• The work — every item with its state and, once it finishes, the builder's closing note on what it did and anything you should confirm.
• What it is doing — a running feed, one plain line per action ("Created /about with 4 rows.", "Update page text on /about"). The feed is kept with the build, so it is still there after a reload.
• Cancel the build (Admins only), with the same confirmation as the card, and Back to the dashboard.

When the build is over the view shows the pages it built — each one marked if it stayed a draft — the final check's findings, What it saw, page by page (the build's last look at each page: the pictures, the AI's critique and what was still wrong, or that nobody could look), Fix these, Retry failed items, Look over the pages it didn't see and, under Still drafts, Publish these anyway (all for the admin who started the build) and the editor button. Pressing any of them brings the build back to life in the same view: the frame follows the builder again and the feed carries on. Look over the pages it didn't see is offered while the build runs too, once a page has been built unseen — the view then says the build will look over those pages before it publishes them. Like the card, the watch view keeps a build moving on hosts without a background worker for as long as it is open.

The build's eyes

The build looks at every page it builds, in your browser — nothing renders a page on the server. Each page item ends the same way: once the page is laid out and its copy, backgrounds, images and meta are written, the builder asks to see it (its inspect_page tool), fixes what it saw with the same page tools it built with, asks to see it once more, and moves on. Two looks per page, never a third — a builder that asks again gets the last look back instead, and whatever the second look still finds goes into the report. A Fix these follow-up looks once, after its fixes.

When the build wants to see a page, the watch view of the admin who started the build does the looking:

1. It loads the page in its frame at desktop width (1280 px) and then phone width (390 px) — a draft through the same preview link — and waits for the page to settle: web fonts, then a scroll through the whole page so lazy images and entrance animations load, then a moment for the last ones.
2. It measures what is wrong in the real page: images that did not load, text wider than its box, blocks sitting on top of one another, empty sections, anything running off the screen (or a page that scrolls sideways), text below the WCAG AA contrast ratio against the colour behind it (text over a photo is not judged), and script errors the page logged while loading. Each problem is tied to the section it sits in.
3. It takes a picture of the page at each width and sends the problems and the pictures back to the build.

What the builder gets back:

• The problems measured in the page, each tied to the section it sits in — but only the page's own sections. A problem in the header or footer (or tied to a section that is not on the page) is left out and counted, because the page tools cannot fix it there.
• A critique of each picture. The build shows each picture (desktop, then phone) to the AI with the visual house rules — text cut off or hard to read, white sections running together, broken or badly cropped images, empty sections, placeholder copy, a layout that breaks at that width — your AI Knowledge Brief and your design notes, and a list of the page's sections with the opening words of each. The AI names each problem by the section it is in; a line naming a section that is not on the page is dropped. Its answer is a handful of lines at most.
• What to do next — fix and look once more, or (after the second look) finish.

Held to the design direction. In a build with a design direction, the same picture check also holds the page to it, with three checks: as loud as asked and no louder (a credible site that shouts, or an expressive one that is a plain stack of boxes), the trade's own action on the first screen (what a visitor came to do — call, book, get a quote — as a designed part of the first screen, not a lone generic button), and no repeated layout (two neighbouring sections built the same way; the section list says which neighbours share a design, since the picture shows only the top of the page). The AI is told the direction, how loud it is, its first screen and the trade, and answers what is off as separate direction points — no extra AI call, they ride on the picture check the look makes anyway. Taste never settles, so it is capped: the build's first look at a page that checks it is that page's one round, and the builder may bring back what its points name with the copy, a background or a photo — never a new section, a removed one or a new layout. Every later look's points — the second look, a look-over, a Fix these follow-up, a retry — are advice: handed back marked so, kept for the report under Design direction, advice, never counted as problems and never turned into work. The count is the whole build's, so no item, follow-up or retry starts it again. A build without a direction is sent exactly the critique it always was.

When it cannot look. If nobody who can look has the watch view open, the build doesn't wait: it carries on at once and says so in the item's closing note. If the watch view is open but no answer comes within a minute (the tab was closed, or sat in the background), the build gives up on that look and carries on. If the page would not open in the browser at all, that look counts as unseen too. Either way the report names every planned page the build never saw, under Over to you — and Look over the pages it didn't see gives those pages their look later (see Look over the pages it didn't see). While it waits, the build keeps telling the server it is alive, so a minute's wait never makes it look stalled — and if the build is cancelled meanwhile, it stops at once.

Which AI looks at the pictures. Inside a build the picture check runs at the build floor: on the model the build's pages run on, which is never below it — on Claude, Opus 5.5 by default even when the site assistant is on Haiku, Fable when the pages run on Fable — never on the site assistant's own model below it. That holds for every look: a page's, a look-over's, a Fix these follow-up's and a retried item's. A picture only ever goes to a model that can read one. Claude, OpenAI and Google models all can; DeepSeek's cannot, so a build whose pages run on DeepSeek checks its pictures on another provider's model at the floor when the site offers one (for example Opus, on a site with a Claude key too), or else on the best model the site has that can read pictures. Either way the report's Notes say which model the checks ran on and why. The prompt is the same whichever model reads it.

When the AI cannot read pictures (no model the site offers can — a DeepSeek-only site), or no picture came back (Safari's), the builder gets the measured problems alone — the build never stops over it. The same goes when every picture check fails, for example because the AI model saved in AI Settings is one the provider no longer serves: the feed and the report then say the pictures could not be checked, never "nothing wrong found".

Everyone watching sees the result under What it sees, below the frame: the two pictures (click one for full size), how they were taken, and the problems the browser measured. What the AI then sees in the pictures follows a few seconds later in the feed ("Looked at /about at desktop and phone: …"), and in the report's What it saw, page by page — so What it sees says "No problems measured", never that nothing is wrong. While a look runs, the line above the frame says what it is doing, and the frame changes width; it goes back to the page being built when the look is done.

The one-time permission. The first time the build wants to look, the watch view asks Let the build see the page as it works. Choose Let it see and your browser asks to share this tab (Chrome and Edge show "Share this tab"); from then on the pictures are real screenshots of the frame. You can stop sharing at any time from the browser's sharing bar. Choose Not now — or don't answer within a few seconds — and the build draws an approximate picture of the page instead. The question is asked once per build: a "no" is remembered for that build even after a reload; a "yes" has to be given again after a reload, because reloading ends the sharing.

When it draws the picture instead. Firefox and Safari cannot share a single tab this way, so they are never asked; neither is a dashboard opened over plain http (the browser only allows sharing on a secure address). The drawn picture is close but not exact — web fonts and images from other sites do not come along. Safari cannot draw the page at all, so there the build gets the list of problems without a picture. The problems themselves are measured the same way whichever picture is taken.

A developer's dev server blinds it. While the Vite dev server runs (npm run dev, which writes public/hot), every page loads its styles from the dev server's own address, which the picture cannot read: each look sees an unstyled page and reports it. Build my site and the watch view say so in a warning while public/hot exists (SiteBuildLooks::devServerBlindsLooks()); stop the dev server before building. An install never runs it, so the warning never shows there.

Open the dashboard on the site's own domain. The build can only see into the frame while the page there is on the same address as the dashboard. The links are made for whatever address the dashboard is open on, so an alias domain or an http/https mix works; but a page that redirects to a different domain (a "www" redirect, say) cannot be seen into, and the watch view says so below the frame.

Good to know.

• Only the admin who started the build answers its looks; anyone else watching sees what it saw but never does the looking. If nobody has the watch view open, the build carries on without looking — the watch view tells the server it is open each time it checks on the build, every few seconds.
• Keep the watch view's tab in front while the build runs. Browsers slow a tab in the background right down and stop drawing it — unless it is being shared — so a background tab may be too slow to look in time, and the build then carries on unseen.
• The pictures are kept privately on the server — never in the media library or anywhere public. An earlier look at a page is cleared the moment a later look at the same page lands (only the last is ever shown again), and the rest until the next build's first look clears them. The finished build's report shows the last picture of each page (see The report).
• Sharing the tab needs the site's Permissions-Policy header to allow display-capture for the site itself, which the default does. An install that sets its own CMS_PERMISSIONS_POLICY must include display-capture=(self).

The build card

While a build is running the card shows:

• a progress bar and the step it is on ("Building Page /about (5 of 9)");
• the last few log lines;
• every item with its state — working (spinner), waiting, done (✓), ran out of steps (!), or failed (✕);
• Stalled, when nothing has reported progress for a while (see below);
• Cancel the build (Admins only), which asks for confirmation first.

The card keeps checking every few seconds even with the bubble closed, and a small dot on the bubble shows a build is running. On hosts without a background worker those checks are also what keep the build moving, so leaving a dashboard tab open speeds a build along there.

While the build runs, and after it, the card has a Watch it build link to the watch view. When the build is over the card shows the report, Fix these when the report has something the assistant can fix, Retry failed items when an item did not finish, Look over the pages it didn't see when a page was built while nobody was watching (pressing it opens the watch view, which does the looking — it is offered while the build runs too), Publish these anyway when a page stayed a draft because its item did not finish, Undo this build (all of them for the admin who started the build — Undo asks for confirmation first), an Open the editor button for the first page it built, and a dismiss button. A press on the card while the watch view is open in the same tab refreshes the watch view, and the other way round. When an undo is not possible the card says why underneath; once a build is undone the card says what went back and is marked Undone. A dismissed report stays hidden in that browser; a report you never dismiss stops appearing on its own after a few days. The report is always available by asking the assistant.

The report

No AI is involved in the check — it is a fixed list, the same things a person verifies before handing a site over:

• Pages — every planned page with a link, flagged when it was not built or is still a draft.
• Still drafts — new pages the build left as drafts, with why (an unfinished item, or the accessibility publish gate) and a link to the page in the editor (Fix it in the editor for the accessibility gate). Publish these anyway publishes the ones an unfinished item left, as they are; publish the rest from the Pages list once they are ready.
• Not finished — items that ran out of steps or failed, with the reason — and the site-wide rows item when a row the direction changes was left as it was (see The header, footer, title band and close).
• Design direction, not carried out (a build with a direction) — each line of the direction the build left undone, and why: a site-wide row still the one it was (the theme's own, an earlier build's, or the site's), or a homepage the direction lays out again still on its old layout. Each line says what runs it again, and names the row in your dashboard's language. While one is listed, the build's closing message says something needs attention, never that the site is simply built — and when an item needs attention as well, it says both.
• Design direction, advice (a build with a direction) — what the build's last look at each page would still change for the direction: points the build was told not to act on, for you to judge in the page editor. They never hold the build up, and Fix these never runs them.
• White sections next to each other — pages where two default-background sections touch, judged by the surface each section really renders with (the one the build or the editor set), not the template's default.
• Forms that notify nobody — forms with no recipient, whose submissions would go unseen.
• Pages without a meta description.
• Over to you — what only you can confirm: placeholder testimonials, the hours, phone and address shown on the site and whether the street address should be public, missing pages, and pictures to replace when images were off.
• Final check — what the final check found on the published pages (below), or that every page passed.
• What it saw — the build's last look at each page it looked at: the pictures (click for full size), the AI's critique in a line, and the problems still measured — or "not seen" when no browser was looking. A page the last look still found problems on is mentioned under Over to you, and so is every planned page the build never saw — Look over the pages it didn't see gives those their look.
• Redirects (a rebuild) — each old address: redirecting now to its new page, already in place before the build, or not added and why (a page answers that address, another redirect already holds it, or its item did not finish).
• Imported images (a rebuild) — each image from the old site: in the media library (and for which page), placed in the spot the plan named, or not imported and why. Both lists are read from the site itself when the build ends, not from the builder's notes.
• Notes — anything the plan changed on the way: where its design direction came from when nobody picked one (your design answers, the site's standing direction, or the credible direction), a theme style set aside for it, or AI images being turned off because no image provider was available to you — and when the screenshot checks did not run on the build floor's own model: on another model because that one cannot read pictures, or below the floor because nothing at it that can is offered (see The build's eyes).
• Suggestions — not built — the ideas set aside because the plan did not name them (see The closed list).
• What it used — the build's AI use in money, priced item by item on the model each item ran on (and the pictures the build's eyes checked on the model that checked them), at the site's AI prices. On managed AI it is "of your AI allowance".

The final check

After the report's list is drawn up, every page the build published — each planned page, and up to 30 record pages of its own that the build created — is opened the way a visitor opens it, inside the site itself (never over the network, so a site whose own address points back at a private server checks the same as any other), signed out, and freshly rendered rather than served from the page cache. For each page it checks:

• the page opens (it does not answer "not found" or an error);
• no error message shows on it (the text around anything that looks like one is quoted, so a false alarm in real copy reads as one);
• the browser title ends with the site name — once: a meta title that already holds the company name shows it twice;
• the row templates' placeholder copy is gone from the page's own sections (a repeater's cards and the page-title band fill themselves in per card and per page, so they never count as placeholder copy);
• every link on the page — in its own sections, and in the header, footer and listings — leads somewhere real, redirects included;
• every image it shows is really there;

and, once for the whole site, that every menu item leads somewhere. A page that stayed a draft, or is not published, is listed as such and not opened. A link or image that sits in the header or footer is reported once, not on every page.

Fix these

Fix these appears on a finished build's report (done, or stopped early) when the report holds something the assistant can fix with its own tools. Pressing it runs one pass of follow-up items, then the report and the final check run again:

• each page with white sections side by side, leftover placeholder copy, a dead link or a missing image in its own sections, or a browser title without (or with a doubled) site name gets one item that fixes exactly those things and nothing else;
• the pages without a meta description get one item between them;
• forms that notify nobody get one item — only when the plan named a recipient;
• dead menu items get one item.

It leaves alone, and says so in the build's log: pages that stayed drafts, pages that would not open, broken links or images in the header, footer or a listing (fix those where they live), forms with no recipient in the plan, and unfinished items (that is what Retry failed items is for).

One pass per press, never a loop. Fixing one thing can surface another — breaking up one white pair can make a new pair with the next section — so after its pass the report simply shows what is still there. Press again for another pass if you want one; a report with nothing fixable left has no button.

Retry failed items

Retry failed items appears when an item of a finished, stopped or cancelled build ran out of steps or failed (or was never reached). It re-runs exactly those items — the finished ones are passed over — and then the report and the final check run again. The tools pick up where the first attempt stopped rather than duplicating anything, and a new page whose item finishes on the retry is published then, as it would have been the first time.

Both buttons work on the same build — the card and the watch view simply see it come alive again — and neither works while it is running, while another build runs, once a newer build has replaced it, or after the build was undone.

Look over the pages it didn't see

The build looks at each page through the watch view of the admin who started it. A page built while nobody was watching — the view was closed, its tab sat in the background, or the page would not open there — was built unseen, and the report lists it under What it saw and Over to you. Look over the pages it didn't see gives those pages the look they missed: one pass, one follow-up item per page, each doing what a page item does at its end — look at the page at desktop and phone width, fix what the look found with the page tools, look once more. Then, on a finished build, the report and the final check run again.

Who sees it. Only the admin who started the build — only their watch view can do the looking — and only when a page was built unseen. The looks happen in the watch view, so keep it open and in front while they run (the button's hint says so); pressing it on the card opens the watch view.

Which pages. Every page the plan names that exists, whose own item finished (done, or ran out of steps) and that no look has seen yet. A page whose item did not finish is left to Retry failed items — its re-run looks at it — and a page deleted since has nothing to look at; the build's log names both.

What a look may change. Only what the look at that page found — the same line Fix these draws, and held by the tools themselves, not just by the instructions: nothing changes on the page until a look has really seen it, and then only the page's copy, its sections' styling (backgrounds, spacing, classes) and its images (and, if your image policy allows, a generated picture) — never another page, its layout or rows, or its page settings. So a page whose look still finds nobody watching changes not at all: it stays unseen and stays listed. Your own edits since the build are no more at risk than with Fix these (and, like Fix these, a run after you edited the site blocks the undo — see Undo this build).

One pass per press, never a loop. A page still unseen after the pass (nobody was watching again) stays on the report; press again when you are in front of the watch view. On a finished build the button works like Fix these: never while another build runs, once a newer build has replaced it, or after the build was undone.

While the build is still running. Came back to the watch view halfway through? The button is there too, once a page has been built unseen. The build cannot be handed new work in the middle of an item — the running item owns the build's progress record and rewrites it when it ends — so the press is kept as a request and the build takes it up after its last item, before it publishes: it looks over every page it built unseen (pages it builds while you watch get their own look as they go), then publishes and runs its report as usual. The watch view says the looks are coming. A request made after the build has started publishing is refused — press the button on the report instead; a cancelled build, or one that stops early, drops the request (the log says so). In the rare case the site's cache cannot be reached for about a minute at that moment, the build moves on without checking for a request — none could have been left without the cache either — and its log says so.

Publish these anyway

A new page whose item did not finish stays a draft when the build ends — it may be half-built. When you have looked at it and are happy to show it as it is, Publish these anyway (under Still drafts in the watch view, and on the card) publishes every page that stayed a draft only because its item did not finish. It goes through the build's own publish step — the same writer and the same checks that publish a finished page — and then the report and the final check run again, so the newly live pages are checked as a visitor sees them (and Fix these can then offer to fix what the check finds).

• Never past the accessibility gate. With "Block publishing on accessibility errors" on, a page with error-level findings stays a draft whatever the button says — listed with the reason and Fix it in the editor. The gate is asked about every unfinished draft whenever the build publishes, so a page it refuses is listed as the gate's (even though its item did not finish either) and the button does not offer it again until the gate would let it through; fix the errors, then publish it from the Pages list.
• Only the build's own drafts that are still drafts. A page you have published, taken down or deleted since is left as it is.
• After a crash or a cancel too. A build that crashed or was cancelled has its drafts but no report: the drafts are still listed (on the card and in the watch view, with their editor links), and Publish these anyway publishes the unfinished ones the same way — running the build's publish step and, for the first time, its report and final check. A crashed build stays marked as stopped early.
• The admin who started the build only; the button disappears once there is nothing left for it, and pressing it twice publishes nothing more. Like Fix these it is not available while another build runs, once a newer build has replaced this one, or after an undo.

Undo this build

Undo this build puts the site back to how it was before the build started. Before the first item runs, the build takes a snapshot:

• an earlier version (copy and layout) of every page the plan names that already exists — a homepage the build lays out again included — and of every page of a services-pattern type — plus each one's page settings (name, search title and description, status, header and footer…), which a page version does not hold;
• the stored value of every setting a build can write — business details, social links, the AI brief, privacy and terms facts, search-engine visibility, branding (and a theme style switch), which header, footer, page-title band and closing banner every page shows, the menus, the layouts a new content type records, and the standing design direction — including which of them did not exist yet;
• every form's recipients, and what existed of content types, records, images, designed sections, redirects, site-wide row designs and installed headers and footers, so the end of the build can tell what it created — including a rebuild's imported images and redirects, and the header, footer, band and banner designs a direction made it add.

Pressing Undo this build (confirm in the dialog) then, in this order: deletes the records the build added; deletes the pages it created (with their copy); deletes the content types it created; removes its redirects; puts every setting back (a setting that did not exist before is deleted, not blanked) — so every page shows the header, footer, page-title band and closing banner it had, and the standing design direction is the one from before; removes the site-wide designs the build added (the band and banner copies it installed, a header or footer the site never had — once nothing uses it — and the copy it wrote on them); puts the form recipients back; puts back how an existing content type gives its records pages (if the build switched it over); puts each rewritten page's settings and its earlier version back — a page the build never actually changed is left exactly as it is; deletes the images it added once nothing on the site uses them; and deletes the sections it designed into your library. Each step goes through the same delete or restore the dashboard itself uses, so routes, search, sidecars and caches follow. The earlier versions it puts back are saved in the page history first, so a single page's undo can itself be undone from the editor.

Your later edits are never overwritten. When the build ends (finished, stopped, cancelled or crashed) it records how it left everything an undo would touch. If anything there has changed since — a page edited, a setting saved, a form's recipients changed, a record the build made renamed, a site-wide row the build chose reworded in the editor — nothing is undone: you are told exactly what changed instead. Put it back, or keep the build and edit by hand.

It is not available when:

• the build is still running (cancel it first), or another build is running;
• a newer build has run — only the newest build can be undone, and starting a build drops the older build's snapshot;
• page history is turned off (the page editor's version history settings), so the pages the build rewrote have no earlier version to go back to — the build says so in its log as it starts;
• the site was edited between the build and a Fix these, Retry failed items, Look over the pages it didn't see or Publish these anyway run on it — after that run, your edits and the build's can no longer be told apart (a run on an unchanged site keeps the undo: what it changed goes back with the rest);
• it was already undone.

What an undo leaves, and says so: an image the build added that is now used somewhere else, a form the build's content types brought that has collected submissions, and an existing page outside the plan that the build changed anyway (it had no earlier version). A theme style switch puts back which header, footer and styles are active; a header or footer design the style installed is removed again once nothing uses it (one a page still names is kept, and said), and its page-title band and banner designs stay in your library, unused. Edits made while the build was running count as the build's and go back with it.

The snapshot lives in a private file on the server beside the build's screenshots (storage/app/private/site-builds/{task}/snapshot.json), not in the database row the build updates as it works.

Costs and the model

• A build never runs below the newest Claude Opus. On another provider the floor is that provider's flagship: OpenAI's gpt-6-astra (its sol is the middle rung), Google's gemini-4-argon, DeepSeek's deepseek-v4-pro. The floor is a tier the AI model catalog gives each model (AiModelCatalog::TEXT_TIERS), never a model id, so when a newer Opus ships and the catalog is updated, it becomes the floor. Only the newest version of a line counts (a dated snapshot of it, such as claude-opus-5-5-20261101, is the same model): an older Opus a managed allowlist still carries is below it. It covers both build models, the Show design directions call and the build's screenshot checks (The build's eyes: on the pages model, or one standing in for it that can read pictures); the planning chat itself keeps the chat's own model.
• Two models do the work. The pages and the content types with their records — what visitors read — run on one model: by default the one your chat was using when you approved (the install's default, or whatever you picked in the bubble's model picker) when it is at the floor, otherwise the floor's model. Settings, branding, navigation, forms and the meta-description pass run on another: by default the floor's model (Opus rather than Fable on Claude; the build stays on the provider your site assistant uses where that provider has one). The selects on Build my site and the plan card list only models at the floor or above, and show them when there is a choice; change either before you press Approve. A model your site does not offer is refused before anything starts. A model below the floor (named by the planner, or sent by an old card) is raised to the floor, and the plan's notes say so ("…which this site offers but is below the build floor, so it was raised to Opus"). The planner may name a model the way you did — "Haiku", "Claude Haiku 5.5" — and it is matched to the one model your site offers by that name; only a name that fits none, or several, is refused; on the plan card, a model the planner named that the card does not offer is replaced by the recommended one, and the card says which. Each item is set to its model as it starts, so an item never changes model halfway, and if a picked model stops being offered during the build (a managed allowlist changed) that item runs on the floor's model instead — the site assistant's lane only when the site offers no model at all.
• A site with no model at the floor still builds, on the best model it has (the highest tier, then the newest). The plan's notes, the approval line, the plan card, Build my site and the report all say it runs below the usual floor. If items ran below the floor although the plan's models did not (a picked model stopped being offered and nothing at the floor was left), the report says that too.
• The estimate on the plan card (and in the approval line, and the start reply) prices each item on the model that will run it: an item's step budget is the most it can use, and the forecast is 60% of it until a build has run on your site — after that, your site's own measured average for that kind of item, and its own average tokens per call (13,700 in / 160 out until then). The pictures the build's eyes check are priced on the model that will check them — the pages model, or the model standing in for it when that one cannot read pictures — and not at all on a site where no model can (none are made). Time is roughly 25 seconds per AI call. On managed AI it is set against what is left of your AI allowance — a figure from the licence check, which runs about every 6 hours, so the line says when it was taken. The site assistant may use only its share of the monthly allowance (the mothership refuses it past that share even with credit left overall, unless you hold bought credit), so when less is left of that share than of the whole, the estimate is set against the share and says so — "of the site assistant's $1.50 monthly share (… left)". The estimate is "about": the meter that bills is the provider's (or, on managed AI, the mothership's).
• What it used is on the report, priced the same way from the tokens each item actually used, and every finished build feeds the averages the next estimate uses.
• Each item is one AI turn with a step budget — 15 for settings and branding, 25 per content type, 50 per page (40 for the page's own work and room for its two looks and the fixes between them), 10 for navigation and for forms, and for a rebuild 25 for the image import and 12 for the redirects (both run on the settings model, and do several imports or redirects per step). Reading the old site happens in the planning chat, on the chat's model; its digest is kept short (about 12,000 characters, each page's text shortened first) because the planning turn pays for every word of it. An item that runs out gets one chance to continue, and the whole build is capped at twice the sum of its items' budgets plus a small margin, so a build can never run away with your credit.
• Each look at a page costs up to two more AI calls — one picture check per width — counted in the item's steps and the build's call budget like any other call, metered as the site assistant, on the pages model (see The build's eyes). On Claude that is Opus 5.5, which always thinks before it answers, so each check is given room for that thinking on top of its own short answer. A look that could not happen costs nothing.
• Fix these, Retry failed items and Look over the pages it didn't see are new AI work and are budgeted the same way, for exactly the items they run: a page fix 25 steps (its one look included), a page look-over 25 (its two looks included, on the pages model), the meta descriptions 15, forms 6, the menu 10; a retried item its usual budget. Publish these anyway makes no AI calls of its own; the final check after it is not AI either.
• On managed AI the build draws on the site assistant's share of your monthly AI credit — when that share runs out the build stops and keeps what it finished. On your own key it is billed by your provider. Either way it is metered as the site assistant in AI Usage & Costs.
• Images are the slow and expensive part. Each AI image takes roughly ten seconds to over a minute and uses image credit. "Key spots" generates the hero and a few others; "every spot" can multiply a build's time several times over; "none" leaves placeholders to replace from the media library.

Limits

• One build at a time. Starting a second while one runs points you at the running one instead.
• Admin only to start or cancel.
• Up to 30 pages, 10 content types and 100 records per type per build — and, with rows: author, at most 12 newly designed sections; for a rebuild, up to 50 redirects and 40 imported images.
• Reading an old site takes up to 30 pages of that one site, 2 MB of each, in about 50 seconds; a site that only shows its content once scripts run (some page builders) reads as nearly empty — tell the assistant what is on it instead.
• Legal pages and the addresses the system reserves are refused — a plan that would touch the privacy policy or a system route is sent back to the assistant before anything starts.
• Headers and footers come from your theme; the build does not swap them.
• Undo is for the newest build only, and only while nothing it touched has changed since it ended.
• The audit and the final check cannot judge a turn of phrase, and the build's eyes see only the top of each page, at two widths — the "Over to you" list and your own read-through cover the rest.
• From the dashboard only — the assistant bubble or AI → Build my site. The page editor's assistant cannot start a build or change a page's settings: the editor holds a page in memory, and a Save there would write it straight back over what the build just laid down.
• Build my site cannot rebuild an existing website, set the branding or social links, or plan page by page — see What the form cannot do.

Cancelling

Cancel the build (confirm in the dialog) stops it after the step it is on. Everything it has already written stays — pages, settings, records — because you have paid for that work; the cancel itself rolls nothing back. The new pages whose items had finished are published at that moment; the page it was in the middle of stays a draft. The card then shows the build as cancelled with the items it got through. A cancelled build does not run its audit; Retry failed items picks it up from where it stopped (and runs the report at the end), Publish these anyway publishes the page it was in the middle of as it is, and Look over the pages it didn't see gives the pages it built unseen their look (either runs the report for the first time) — or run a new build, or Undo this build takes back everything it wrote. A Look over the pages it didn't see asked for while the build ran is dropped with the cancel.

When it stops on its own

• Out of credit, licence or model refused, provider not set up, or the admin who started it lost permission — the build stops, publishes what it has built, and the card says why: its heading reads The build stopped early — 2 of 6 items finished, with the reason under it. Fix the cause, then press Retry failed items to finish it; finished work is kept, and the tools skip what already exists.
• The provider is busy or rate-limited — that item waits two minutes and tries again, up to three times, then is marked failed and the build moves on.
• A step keeps failing (an error in the site itself, not the AI — a full disk, say) — the server retries it a few times, then gives up on the build. It still publishes the new pages whose items had finished, leaves the rest as drafts (listed, with Publish these anyway for the unfinished ones), records how it left the site (so it can be undone), and the card reads stopped early with the error under it. While it is publishing, the report's buttons wait — a press in those few seconds is turned away with "already being started again"; press again a moment later. Retry failed items picks it up once the cause is fixed.

A stalled build

Stalled means the process running the build stopped reporting — usually because the server ended it. It is not lost: it is picked up again automatically — by the card's next check, or by the site's scheduled task runner — and that item runs again (an item is given ten minutes before it counts as stalled). If it stays stalled for more than a few minutes, cancel it and start again — what was built is kept.

The assistant's design tools

The site assistant (the dashboard bubble, and the page editor's AI panel) works on the look through a small set of tools, the same in a chat and inside a build:

• read_branding / set_branding — the brand colours, the heading, body and accent fonts, the surface and the button style (one of the named presets — see Button styles). A change is checked whole and written together, or not at all. Inside a build with a direction, the direction's fonts and preset are the ones it may set.
• list_row_templates — the design library, with each row's design tags; it filters by leads, volume and site_has, and with slot lists exactly the designs a site-wide row can take. Rows that fit come first, in this site's own order.
• swap_shared_row — build-only: points the header, footer, page-title band or closing banner at another library design, with this build's own copy of its words. Undo puts every one back.
• Design directions on the plan card — two or three looks to pick from, each with its preview inline (see Directions to pick from).

The bubble's panel can be made bigger: the arrows button in its header widens it to about twice the width and nearly the full height of the window, which makes a plan card and its previews readable. The choice is remembered in this browser; the page editor's AI panel keeps its own size.

Asking the assistant about it

The assistant can read the build at any time with its get_site_build_status tool — the same information the card shows, including the full report (what the build saw on its last look at each page comes as words; the picture links stay on the dashboard). "How is the build going?", "what's left?", or "what did the build skip?" all work, including while the build has its other tools held.

Claude and OpenAI

The build is provider-agnostic: it works on Claude and on OpenAI models (and on managed AI brokering either), and its two models may even come from different providers. The model needs to support tool use — every chat model the picker offers does. To build the pages on a particular model, pick it in the bubble's model picker before you ask (or in the plan card's select); the build keeps its two models for every item even though it runs without the bubble.

Related

• AI Knowledge — the Brief and notes every build item reads
• AI Site Generation — the earlier one-shot generator on its own dashboard page
• Background Tasks — the resumable task runner the build runs on
• Design Library — the Page Library designs new pages are laid out from, and the custom library a designed section lands in
• AI Usage & Costs — where the build's AI calls show up