Mantle Docs

Appearance

Quickstart: Builder with your agent ​

Builder at mantle.tools/builder is a browser page that exposes WebMCP tools to your agent. This page is for people who want to design and verify a Manifest without writing code first, then hand the result to a coding agent.

1. Open Builder with your agent ​

Open Builder in a browser that supports WebMCP. Choose Intake, Reservation, Transaction, Procurement, or Blank and copy the starting prompt into your agent chat.

Without WebMCP, the page offers two explicit paths: open Builder with a ChatGPT Codex deeplink for the hosted coding-agent path, or copy a separate coding-agent prompt for Claude Code, Cursor, or another agent. The coding-agent prompt builds and runs the service locally; it does not contain Builder WebMCP tool calls. This is not ChatGPT Sites.

2. Describe the workflow ​

Tell your agent who uses the service, what they submit, what staff can do, and which changes need approval. The agent calls builder_get_started before editing. That call returns the pinned grammar summary, the preset list (each with its Core docs/examples/builtin-*.md source), the active project and its revision, and the exact next tool calls. Reference sections overview, schema, view, procedure, trigger, builtin and auth return the corresponding full page from the installed @aotter/mantle handbook. builtin and procedure share the Procedure page; no Markdown-heading extraction is used.

Builder accepts two kinds of edit:

ToolApplies toInput
builder_apply_presetAn empty project onlyOne preset name: intake, reservation, transaction, procurement. Each loads the matching Core builtin-* example (transaction → builtin-commerce). blank skips the preset. Missing or unreadable Core examples fail closed; there is no host-owned Manifest fallback.
builder_apply_manifest_patchAny projectAn RFC 6902 JSON Patch against the committed Manifest; validated before it is committed.

Both require baseRevision. Builder rejects a patch whose base is older than the current revision, so an agent cannot overwrite work it has not seen. Builder authors declarative Views and builtin Procedure handlers only; handler refs need generated TypeScript in a real project.

3. Inspect and exercise the preview ​

Use the Admin graph to inspect atoms and their connections. Ask your agent to run builder_execute_preview: it resets or seeds the persistent preview sandbox in the browser, calls the projected capabilities as a mock anonymous, member or owner actor, and reports the persisted entries before and after. Verify both allowed operations and denied access. With navigation: "walkthrough" the agent can step you through each call and the affected Admin page.

Preview data belongs to the sandbox, not production. Nothing runs on a Worker, no D1 is touched, and no identity is real. The small graph shown on the public homepage is a separate read-only example.

Every accepted edit also returns a draft-delta D1 preview: source and target storage fingerprints, additive/destructive risk, ordered SQL, and an immutable checksum. Builder verifies the checksum but does not call this a deployment artifact. Builder also shows the summary after an accepted edit; Cloud rebuilds the deploy artifact from the last active revision and shows its deployed baseline summary during publish. Preview execution stays on Mantle's IndexedDB adapter, with no second SQLite/WASM runtime. Destructive changes remain visible for export/reset review; CI executes additive SQL against SQLite and Mantle Cloud/D1 verifies it before upload.

4. Hand off the service ​

Download the handoff ZIP from the project menu. Builder refuses to build it when the project has no atoms or when the project changed since the snapshot was taken.

What the handoff contains ​

  • manifests/site.yaml — the committed Manifest. This is the source of truth.
  • HANDOFF.md — the pinned @aotter/mantle* version, the source revisions, links to the pinned develop skill and grammar, and the steps a coding agent follows.
  • DEPLOY.md — local verification, pushing to GitHub, the first wrangler deploy, and choosing production email OTP or GitHub OAuth.
  • examples/register-webmcp.example.ts — a reference for registering the service's own WebMCP tools in a page; every placeholder must be replaced from the Manifest.

The ZIP is a coding-agent handoff, not a runnable application. It deploys nothing and contains no secrets. Do not copy sandbox identities or preview records into the real service.

From handoff to deployment ​

  1. Give the ZIP to a coding agent. It authors the project around manifests/site.yaml: package.json pinned to the version in HANDOFF.md, the Worker entry, provider configuration, and the frontend the Manifest cannot express. See Project layout and the CLI loop.
  2. The agent runs only the checks the project declares, then starts Wrangler with local email OTP through ConsoleEmailSender. You enter the OTP from the Worker console at /admin/sign-in and inspect /admin/dev; the agent never bypasses sign-in or handles the OTP.
  3. Follow Deploy and operate for the first deploy and the verify loop.
  4. Follow Authentication for production: replace console delivery with a real email sender, or use self-managed GitHub OAuth as the free fallback when the application has no email provider. Admin and /mcp/staff fail closed until production auth is complete.

Source ​