Builder

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.

No diagram code provided

@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.

No diagram code provided

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.

No diagram code provided

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.

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.

No diagram code provided

@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)

No diagram code provided

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

No diagram code provided

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.