Skip to main content
Your user asks for something. One app.tsx screen comes back, live on real data.

​
One ask, one app

The plan’s skeleton paints in seconds. The finished screen replaces it in place.
A savings goals screen built in the Maple panel, one card per goal with the amount saved, the target, and a progress bar

The screen re-runs on every open, so it opens on today's numbers. There is no snapshot to go stale.

An app is one file, holding one default-exported React component. Saving it repaints the person’s screen.
app.tsx
useQuery is synchronous and hands back the tool’s own result, so field names come off the tool’s schema. tools.<name>(args) is the only way a screen changes anything.

​
One screen, three layers

Most apps never leave layer 1. The agent climbs only when the instruction demands it.

1. Screen app

No server anywhere. The screen renders in the host surface and acts through guarded host tools.

2. Screen plus machine

The same screen, plus a persistent sandbox where execution lives. The machine never draws UI.

3. Machine everything

The machine also serves a real web app, and the host embeds that URL as the surface.
The gate. Layers 2 and 3 are gated on one thing, a configured sandbox adapter.Nobody picks a layer by hand, and the last working surface keeps serving while the next one builds.
A machine sleeps as a snapshot and auto-sleeps after five minutes idle. A served layer-3 app also needs the wire mounted, so /apps/:appId/serve/** answers on your own origin.

​
What a screen may write

A small closed surface, enforced at save rather than advised in a style guide.

Allowed

  • react and @vendo/screen, and nothing else
  • useQuery("tool_name", { literal }), read tools only
  • tools.tool_name(args), from a handler
  • <Stack> <Row> <Grid> <Text> <Stat> <Button>
  • the components you registered
  • <div> <p> <h2>, children and an inline style
  • React state through useState

Refused

  • any third import, import(…), require(…)
  • a query input from a prop, state, or another query
  • a write tool inside useQuery
  • a tool call in the render body
  • document fetch setTimeout process
  • <img> <script>, or className on a display tag
  • a component you never registered
Every save is compiled, scanned, type checked, run once, and its tree validated. The first stage that finds something is the last one that runs, and the last good screen keeps serving. A refusal names the line and says what to write instead. Nothing paints, and no app row lands.

​
Own it

Nobody uses someone else’s app. They get their own copy of it.

Import and fork each mint a fresh app_ id.

Ana shares a link, and the link carries the app and nothing else. Importing it mints a fresh id in your account, reading your rows under your approvals. Fork it and you mint another id. The copy drops the machine and the owner’s approved egress, so it re-approves its own before it can run.

​
Where to go next

In-client venue & approvals

An approved version can render in your page instead of the sandbox.approve → pinned version hash

Host components

Register your own components and a screen renders your real UI.Kit + the ones you registered

Import & fork

How a copy is minted, and what it deliberately leaves behind.import → app_c0d6b562…