Deploy

How the packages fit together, and how a generated site ships as a headless frontend with a CMS backend.

Architecture

Four library packages, two of them machinery, two of them content — plus the studio app. Content depends on the engine; the engine depends on the substrate.

• @repo/foundation — the styling substrate: the a17 Tailwind config, the CSS, the design tokens, and the shared UI primitives. Everything renders on it.
• @repo/blocks — the section components (heroes, CTAs, features). The atoms the engine assembles.
• @repo/engine — the render engine, in two stages:
  • compose turns a template spec into a block tree,
  • render wraps that tree in a design skin (colors, fonts, radius) and makes it a live, themed document. A shot skips compose (it's already a bespoke tree); a site uses both stages.
• @repo/templates / @repo/shots — pure content: specs + registry, pages + registry. They consume the engine; nothing depends back on them.

Deploying a site (headless)

A generated site ships as a standalone frontend that renders content from a headless CMS (WordPress). The site's own dependencies are exactly foundation + blocks + engine plus its spec and design.

• WordPress owns the editable content (pages, copy, media) — the marketing team's home.
• This frontend owns the rendering: the engine composes the template's blocks and applies the site's design, pulling copy/media from WordPress at request time (or build time for static export).
• The visitor gets a fast SSR/static page — no WordPress theme, just blocks on the foundation.

The WordPress backend

WordPress runs headless on WordPress 7: wp-admin is the editor, and everything programmatic goes through two typed surfaces — the Abilities API as the control plane and the REST API as the data plane. No theme, no PHP rendering — WordPress never serves a page to a visitor.

• Abilities, not ad-hoc endpoints — the install registers what it can do (create a page, set fields, upload media, manage taxonomy) through the Abilities API: every ability is discoverable and carries a typed input and output schema.
• MCP is the control plane — the MCP adapter exposes those abilities as an MCP server. The studio connects as an MCP client (per-organization connection, application-password auth, one default per org) and provisions the backend by calling abilities: it pushes generated pages, copy and media into the install, and mirrors content back into its own tables (posts, categories, tags), logging every sync run with counts and errors.
• REST is the data plane — the deployed frontend never speaks MCP. At request time the engine's boxes stage hydrates block slots from /wp-json. WordPress owns the copy and media; the template spec decides where each piece lands.
• Publishing — an editor hits publish in wp-admin, or an agent does it through an ability; either way the frontend revalidates and re-renders. Content changes never require a redeploy.

Folder structure

Server and CLI code (content generation, APIs) import only @repo/engine/spec — the blocks-free spec language — so the block registry never lands in a server bundle.