Build with AI

A company should be able to point an AI coding agent at this site and get a working mini app of its own ERP, without a specialist who already knows the platform. That is a design goal of the documentation, not an afterthought — and it is why every page here states its constraints in prose rather than assuming background knowledge.

Point an agent at the docs

Give the agent this line:

Read https://miniapp.sollar.com/llms.txt and build a Sollar mini app that <what you want>.

Artifact	What it is
/llms.txt	An index of the whole site, plus the rules an agent needs before writing a line
/llms-full.txt	Every page concatenated, for an agent with room for it
<any page>.md	The Markdown source of that page — e.g. /reference/manifest.md
/schemas/manifest.schema.json	JSON Schema 2020-12 for the manifest
/schemas/sollar.d.ts	The canonical bridge type definitions

The .md twins are generated from the source Markdown, not scraped back out of rendered HTML. An agent fetching /reference/manifest.md gets what the author wrote, with the tables intact.

Scaffold a project

sollar create-mini-app acme-erp --template react
cd acme-erp

The scaffold writes two files that matter to agents:

AGENTS.md      ← the instructions
CLAUDE.md      ← one line: @AGENTS.md

Why two. AGENTS.md is the filename Codex, Cursor, Jules, Factory and Aider look for. Claude Code reads CLAUDE.md and does not read AGENTS.md. Rather than maintaining the same instructions twice and letting them drift, CLAUDE.md imports the other:

CLAUDE.md

@AGENTS.md

One file is the source; the other is a pointer. Never duplicate the content by hand — a duplicated instruction file is worse than none, because half of it will be a year out of date and nothing will say which half.

See AGENTS.md for what to put in it.

What an agent gets wrong without being told

Every one of these has a page that explains it; an agent that has not read that page will get it wrong in a way that looks plausible. Put them in your AGENTS.md.

It will invent bridge methods. sollar.getLocation(), sollar.camera.take(), sollar.requestPayment() — all reasonable-looking, none real. The bridge covers only Sollar’s own domain; device capabilities are standard Web APIs. → Bridge API

It will trust the client. sollar.identity.get() returns an app_user_id, and an agent will happily authorise against it. It is UI convenience. Authorisation happens on the server, against the token. → Authentication

It will post to a room from the server. The obvious design for “notify the channel when the order is approved” is a server-side call, and it does not work in an encrypted room — which, in the Enterprise and Sovereign tiers, is every room by default. → Messaging and rooms

It will fetch a host that is not in the manifest. The network allowlist is enforced natively and the failure is ERR_HOST_NOT_ALLOWED. Adding a host means a new version. → Manifest

It will write a permission check in JavaScript. Permission decisions are made in native code against the signed manifest. A JavaScript check is not a check. → Permissions

It will guess the version. Do not let it. Run sollar --version and read the baseline.

Verify, do not trust

An agent will produce a mini app that looks right. Two commands decide whether it is:

sollar validate --strict     # the same checks the submission gate runs
sollar test --conformance    # the ES2022 floor, the CSS baseline, every bridge method

--strict applies the store review checks — purpose strings, justifiable hosts, SBOM, no remote scripts, no eval. Running it in CI turns a review rejection three days from now into a red build in ninety seconds.

Writing actions an agent uses correctly

The other half of “build with AI”: your mini app’s actions[] are tools that other agents will call. Writing a description is engineering, and the rules are in Agent actions:

• Make implicit context explicit — “only the current user’s queue, never another’s”.
• Fully qualify parameter names — purchase_order_id, not id.
• State units and formats — amount_minor, currency_code in ISO 4217.
• Say what is irreversible. It is what makes an agent stop and ask.
• Return errors that teach: “Order 4471 was already approved on 2026-08-30 by another approver” beats ERR_CONFLICT, which teaches nothing and invites a retry.
• Prefer a few coarse actions to many fine ones.

An honest note about this site

The platform described here is specified, not built. An agent reading these pages is reading a design contract. Everything is internally consistent and evidence-backed, and none of it has been run in production or audited by an independent team.

If you are generating code against it, generate against the schemas — they are machine-checkable — and expect the surface to move before launch.