Using the library

Components live under @/components/ui/<Name>, with shell pieces — Sidebar, Panel, PageHeader, UserCard — under @/components/layout. Each component's page lists its exact import line.

import { Button } from "@/components/ui/Button";
import { Dialog, DialogContent, DialogTitle } from "@/components/ui/Dialog";
import { Sidebar, UserCard } from "@/components/layout";

Compound components export their parts from the same module — import them together rather than reaching into subpaths.

Each component imports its own CSS file, so there is no stylesheet to register and no class names to remember. The token layers load once from src/styles/index.css in the root layout.

Every component takes className for the cases the variants do not cover. When you use it, name tokens rather than values — see Using components.

src/builder/renderer/ and src/templates/render the user's site content, not Sitefold's interface. Nothing from this library belongs in either. A Sitefold Buttoninside the renderer puts Sitefold's CSS into a customer's exported site.

This is the product's central constraint rather than a style rule: the user's source files are the truth, and the builder is a view over them. The line between “our chrome” and “their page” is what keeps that true.

The dashboard is auth-gated, so several surfaces have auth-free development routes for exactly this reason:

• /dev/builder — the builder shell
• /dev/cms — the CMS, on its green accent
• /dev/settings — project settings, by section (?section=seo)
• /library — this site

For anything visible, look at it — and measure with getComputedStylerather than trusting the CSS you just wrote. A refactor that changes how something looks is a design change wearing a refactor's clothes.