In-app UI preview

A live, interactive render of any page in your spec — a design checkpoint, not production code. · Recommended

VibeMap renders a working preview of each page directly in the browser, inside a Sandpack sandbox. Use it to sanity-check the shape of a page — right sections, right order, sensible empty states — before your coding agent implements it for real. Skip it if you're happy reading the spec, but it's the fastest way to walk a teammate through a screen.

Opening a preview

1. Open the Pages page — the Sitemap tab shows every page as a card.
2. Click a card's edit button (hover it) to open that page at its own URL, /project/<project>/pages/<page>.
3. The Sandpack panel renders it live, with mock data so the page isn't empty.

Each page having its own address is the point: the back button works, and you can share a link to one screen. (There used to be a separate Preview tab with a page list down the left; it rendered the same thing at a URL that didn't name the page, so it was retired.)

The first render for a page takes a few seconds; reopening is near-instant. The preview shows the section layout from your spec, interactive states (hover, loading, empty, validation) where the spec calls for them, and adapts to a mobile / desktop breakpoint as the panel resizes.

Trace any element back to its spec

Hovering the preview is its default mode, and it's the fastest way to see how the rendered screen connects to your spec. Move your pointer over any element and its linked spec appears in the Details panel beside the preview — the section it sits in, the user story and acceptance criteria behind it, its interactions, the data it reads or writes, its access rules, and any open questions still to be decided about it. The panel follows whichever element you point at, so you can sweep across the page and watch the spec update in step.

Two small controls sit at the top-right of the preview:

• Inspect (the crosshair) — toggles hover tracing. It reads Inspecting while on; turn it off if you'd rather click straight through the rendered app without the trace panel updating.
• Pin — latches click-to-pin. With it on, clicking an element holds its details open and targets that element for an edit in the page's chat, instead of activating the app's own button or link. (Holding Alt while you click does the same thing without latching the mode on — the way it always has.)

The panel does more than report: it also shows which parts of each element's spec are settled, which the model assumed for you, and which are still open — and gives you the controls to decide them. That's a page of its own → Element details and decisions.

For the whole picture at once, the Details button opens a drawer listing everything the page carries — sections, acceptance criteria, related pages, API endpoints, state requirements, UI states, interactions, access rules, and form validation — in a single scroll. (These used to be a stack of always-on panels below the mock; they're one click away now so the preview itself stays uncluttered.)

Why this isn't your production code

It's tempting to copy code out of the sandbox. Don't — for three reasons:

1. It doesn't match your stack. The preview uses a fixed component set inside Sandpack; your real project uses its own patterns, tokens, and conventions.
2. It doesn't know your data layer. The mock data is invented — production hits your real APIs and schema.
3. The MCP handoff is strictly better. Your IDE agent reads the page spec directly, makes decisions for your codebase, and submits work for review. That loop improves with use; pasted preview code doesn't.

For the production-code path → Handoff to your AI agent.

⚡ Power-user hints

• Regenerate after editing the spec. An open preview won't pick up section or metadata changes — reopen the page to refresh.
• Judge structure, not pixels. The preview's job is layout and flow; your agent handles real styling from the Branding tokens in your own codebase.
• Use it as an approval gate. Walking the sandbox is faster than reading a section list aloud in review.

↔ The traditional way

A designer normally builds clickable Figma prototypes to validate layout before dev starts — a separate tool, a separate artefact, and one more thing to keep in sync with the spec. Here the preview is generated from the spec, so what you approve is exactly what your coding agent receives.

What's next

• Decide what each element still owes → Element details and decisions
• See the whole project as one map → Graph view
• Design the data behind these pages → Generating the database schema