What each section of a project holds, and what it becomes on export. The conceptual overview is Projects and files; this is the detail.
IMAGES — image assets used across the project — copied into your assets, referenced by the components that use them.
DESIGN SYSTEM — Themes, Fonts, Images, Audios, Videos, Colors, Spacing, Radius — CSS custom properties plus typed helpers under design-system/.
MOCKUPS — exploration and sketches — nothing: deliberately never exported.
COMPONENTS — your component library, in atomic layers — one .tsx + .module.scss pair per component.
PAGES — whole pages, composed from components — a route with a default export.
APIs — endpoint definitions — a typed useApi hook per endpoint.
Documents — rich documents and document pages — a route tree plus a navigation manifest.
CMS — content models and their rows — static typed arrays.
DATABASE — tables, views and write actions, plus the built-in Users and Roles — not exported yet; see the limits note in its section.
Storage — shared state schemas and their values — one shared store.
SETTINGS — export targets, environments — not exported: it configures the export.
Organized in the four atomic layers — Atoms, Molecules, Organisms, Templates — plus Code. See Components.
Code is the exception to everything else in the section: a component under it is authored as React source rather than drawn, and it is the only kind that runs real JavaScript. See Code components.
The only section that never reaches your codebase. Mockups are a component file in every other respect — you can draw, style and arrange in them — but export skips them entirely.
That is the point: somewhere to think without polluting the generated output.
An API file is a definition, not a request you have written by hand.
Method — GET, POST, PUT or DELETE.
Request shape — host, path, query and body — each of which can be a bound expression rather than a literal.
Response shape — the fields you expect back, typed. Can be declared a list, so a repeat can iterate it.
Environments — named sets of values — development, staging, production — addressable from any expression.
Once defined, an endpoint is mounted into a component, where its response binds into the design. Loading and error state are bindable too, so a spinner or an error message is a condition rather than code.
Each mount can override the request, so one endpoint definition serves /posts/1 in one place and /posts/2 in another.
The canvas preview really fetches, so a design shows live data rather than placeholder rows.
Requests can carry headers, and a per-API Credentials switch sends the request with the browser's cookies — which a cookie-authenticated, cross-origin endpoint needs before it stops answering 401.
Limit: environment values are read from
process.envat runtime rather than shipped with your code.
Where an API brings data in from elsewhere, storage is state your product owns — schemas, and the values held against them.
The point of storage rather than component state is scope: several components can read and write the same store, so a value survives moving between screens and does not have to be passed down.
A storage file can own API loaders of its own, so changing a value re-issues a request and every mounted component sees the new response.
Each schema has a Persist setting. Memory, the default, lives for the page only. Local survives a reload and a browser restart — where a token or a signed-in user belongs. Session survives a reload and dies with the tab. The setting is per schema, so one storage file can hold a persisted session next to a transient ui.
Content, modelled. A model defines the fields; rows are the entries, edited in a spreadsheet-like grid.
Reach for CMS over storage when the data is content — things a person edits and the design displays. Reach for storage when it is state — things the running product changes.
CMS content mounts into a design the same way an API response does.
CMS content exports as static typed arrays, baked in at export time. It is not fetched at runtime, so publishing new content means re-exporting.
Real tables, and the auth to guard them. The section ships with two folders: Tables for your own, and Auth, which holds the built-in Users and Roles tables — locked in place, because sign-in resolves against them by path.
A table is typed columns and rows, edited in a grid. One column is the identity — a UUID or an auto-incrementing number — and a column can be marked secret; the Users table's Password is stored masked and can never be read back out.
What a component sees is never the table itself, but one of its actions:
View — a saved query: projection, filter, sort and row cap. Mounts into a component like any data source, so a repeat can iterate it.
Insert — adds one row, writing only the columns its writable list allows.
Update — writes cells on the rows its filter matches.
Delete — removes the rows its filter matches.
Every view carries an access rule — public, authenticated, or specific roles — and a non-public view returns nothing until someone is signed in. The writable allowlist is what keeps a form from setting columns it was never offered: an insert wired to a task form can set Title and Status, and Owner stays server-side.
Sign-up, sign-in and sign-out are logic actions against the Users table, so a working login form is drawn and wired like any other form. The canvas preview holds a real session — sign in and the restricted views fill; the preview toolbar's user picker switches who you are testing as.
Limits: the database currently runs in the editor and canvas preview. Export for database-backed pages — including the generated backend service — is in development, so a page that mounts a view will not compile from export yet.
Project configuration, and the one section whose job is to shape the export rather than be exported.
Export targets — the local folders and Git repositories your code is written to. A project can have several.
Environments — named variable sets, referenced from API definitions and expressions.
See Export your code.
Projects and files — the overview.
Export output — what the generated files contain.
MCP tools — every section above is agent-addressable.