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

​
One ask, one app

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.

An app is one file holding one default-exported React component. Saving it repaints the person’s screen.
app.tsx
useQuery is synchronous, so there is no await and no loading state, and it hands back your tool’s own result. tools.<name>(args) is the only way a screen changes anything.

​
When an ask is bigger than a screen

Most asks are one screen. When one is not, the tool says so and stops: it raises a standing approval card and returns, having spent nothing. The card waits for the person, however long that takes. On yes, a disposable sandbox builds the app once — npm from the registry, a coding agent inside the box, tested against reality — and then the box is released and dies. What comes home is sealed: an immutable, content-addressed bundle stored as blobs, alongside its source and lockfile. Every seal is a version.
The gate. A build is gated on one thing, a configured sandbox adapter — VENDO_API_KEY fills that slot. Without one the ask is refused rather than offered.
A sealed bundle renders in a sandboxed iframe: sandbox="allow-scripts" without allow-same-origin, so the frame has an opaque origin, and a Content-Security-Policy: default-src 'none' header, so it makes no network request at all. Your brand tokens and fonts are injected at render, never baked into the seal, so one seal follows your palette rather than pinning the one it was built under. Host data reaches the frame through one postMessage bridge into the guarded tool door, with the viewer’s own permissions. An edit reseals from the stored source in a fresh box.

​
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", input?), 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 computed tool name in useQuery
  • 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. Every control it drew also gets pressed, so a button that does nothing is refused. A refusal names the line and says what to write instead, and the last good screen keeps serving. By default a screen runs in a sealed sandbox. Approve a version and it runs as real code in your own page, which in-client venue & approvals covers.

​
Every copy is its own app

Import and fork each mint a fresh app_ id.

Nobody uses someone else’s app. Ana shares a link, and importing it mints a fresh id in your account that reads your rows under your approvals. Forking mints another id. A built app is the exception: sharing, forking, exporting, and placing one are all refused server-side. Import & fork has what a copy deliberately leaves behind.