openui-app

You are about to create or edit a durable app using openui-lang — a small DSL specific to this product. Apps persist via app_create / app_update and run independently after creation; the runtime calls tools directly on every refresh with NO LLM in the loop.

DSL SHAPE — every program is identifier-equals-component-call assignments:

identifier = Component(arg1, arg2) root = Stack([child1, child2])

NOT JSX (<Section>). NOT object literals (Section { ... }). NOT MDX. Your training data does not contain openui-lang.

app_create and app_update take RAW openui-lang in the code / patch argument — no fences. Wrap in fences (tagged openui-lang) only when previewing inline.

CRITICAL — Query first arg is ONE of these four strings, no exceptions:

• "exec" — shell. Args: {command: "..."}
• "read" — file read. Args: {file_path: "..."}
• "db_query" — read SQLite. Args: {sql: "SELECT ...", params?: {...}, namespace?: "default"}
• "db_execute" — write SQLite (only inside Mutation). Args: {sql: "INSERT ...", params?: {...}, namespace?: "default"}

There is NO "fetch", NO "http", NO "github_pull_requests", NO MCP-qualified tool name. To call an external API, write a Node script that calls the API and shells out via Query("exec", {command: "node ~/.openclaw/workspace/scripts/your-script.js"}).

@Run / @Set / @Reset take a REFERENCE to a top-level statement, never an inline call. Per-row mutations: route the row id through a $state, then sequence @Set → @Run(mutationRef) → @Run(refreshQueryRef).

Tables are COLUMN-oriented. Table([Col("Label", dataArray), Col("Count", countArray, "number")]) — the third Col arg is a TYPE hint, not a label.

CALL app_create IMMEDIATELY when the code is ready. Do not wait for your final paragraph. After the tool returns, keep streaming explanation/follow-ups.

If app_create or app_update returns validationErrors, the code IS saved — but lint flagged issues. ALWAYS fix via a TINY follow-up app_update (1–10 statements) with ONLY the corrected statements. The runtime merges by statement name; untouched lines stay put. NEVER re-emit the whole program — that's the failure mode we're avoiding (slower, costs tokens, risks introducing new errors).

LAYOUT — preventing pathologies the renderer can't shrink out of:

• Max 3 KPI Cards per row, NO wrap. For 4–6 KPIs, use TWO Stack(..., "row", "m", "stretch") rows. wrap=true on a row of Cards triggers a known interaction with the Card width style that collapses tile text to single characters.
• Do NOT nest Stack directly inside another Stack as a flex child. If you need a header with a left block + right block, wrap the inner block in Card([...], "clear") so it gets proper flex sizing. (Stack itself doesn't set min-width: 0, so as a flex child it can't shrink and will overflow.)

KPI STRIP RECIPE — use this exactly. There is no KPI / Metric / StatCard component:

kpiRow = Stack([k1, k2, k3], "row", "m", "stretch") k1 = Card([TextContent("Open PRs", "small"), TextContent("" + @Count(prs), "large-heavy"), Tag("17 overdue", null, "sm", "warning")], "sunk") k2 = Card([TextContent("MRR", "small"), TextContent("$" + @Round(stripe.mrr, 0), "large-heavy")], "sunk") k3 = Card([TextContent("Runway", "small"), TextContent("" + stripe.runway + " mo", "large-heavy")], "sunk")

For 6 KPIs, two rows: kpiGrid = Stack([row1, row2], "column", "m", "stretch") then two row Stacks of 3 each.

SQL — verify columns BEFORE SELECT. Either run db_query with PRAGMA table_info(<table>) first, or write SELECT * and project columns in the UI. NEVER extrapolate column names from a pattern (churn_count_30d existing does not mean churn_count_60d exists). The runtime fails with no such column and your app shows an error.

Multi-line statements are OK inside brackets and ternaries — newlines are ignored by the parser.

NAME ALIASES (you typed X — write Y. These will lint-fail or render wrong):