List what you can read: the database tables and columns query_data can use (with estimated row counts), and the app's named data sources for use_source. Call it before writing SQL against tables you have not seen.

Draw a ready-made board in one call: name a recipe and its values (lists as arrays). Use one whenever it fits the question; draw makes new kinds of boards. note puts your text at the top (quote only figures you have read); title replaces the recipe's. No recipes yet: draw with save_as adds one.

Draw a board on the user's screen in one call. items, in reading order:

• a part: sql (one read-only SELECT), dataset or source, with an optional title. The chart is picked from its rows: dates with numbers → line, labels with numbers → bars, one row → headline numbers, else a table; rows like (date, name, value) get a line per name. Choose yourself with show, x, y, series and formats, or draw it with any component and props (its dataset is filled in).

• {note, title?, tone?}: your text. Quote only figures you have read.

• {row: [parts]} side by side; {section, subtitle?, items} a titled group. The database computes every number: aggregate, rebase and round in SQL. Put values the user may change in params (:name in the SQL) and add save_as to keep the board as a recipe, so the same board for other values is one recipe call. Returns the rows of each part (the first and last of long ones) to check. Components: Grid {columns?}: Places its children side by side in equal columns, wrapping to new rows. Section {title, subtitle?}: A titled group of children, stacked. Metric {label, dataset, field, row?, format?, caption?}: One headline number read from a dataset cell (row 0 unless row is set). LineChart {dataset, x, y, title?, format?}: Lines over x (dates or ordered labels), one line per y column. BarChart {dataset, x, y, title?, format?, horizontal?}: Bars per x category, one bar per y column. horizontal suits long labels. PieChart {dataset, label, value, title?, format?}: Donut of value by label; beyond 7 slices the rest are grouped as Other. Table {dataset, columns?, limit?, title?}: Rows of a dataset. columns picks and orders them (all when omitted): column names, or { field, label?, format? }. Note {text, title?, tone?}: Your explanation in plain text. Lines starting with '- ' become bullets; bold works. tone colours it. ActionButton {label, action, input?}: A button that runs one of the app's actions (see get_screen) with the given input. The app can add its own components; get_screen lists them.

Run one read-only SQL SELECT against the app's SQLite database and keep the rows as a dataset named name that boards can draw. The database computes every number: aggregate, sort and round in SQL, not in your head. Returns the columns, the row count and the first rows. At most 5000 rows per query. Reusing a name replaces that dataset.

The long form of draw: a json-render spec you wire yourself, for what draw cannot say. Pass only id to reopen a saved board. { "root": "", "elements": { "": { "type": "", "props": {…}, "children": ["", …] } } }, with the components listed under draw. Every number comes from a dataset (query_data or use_source): components take a dataset name and column names, and any other prop can read a cell with { "$state": "/data///" }. Do not type figures into props. In a Note, only quote figures you read from a dataset. Pass id (from an earlier board) to change that board in place.

List saved boards, newest first. show_board with an id reopens one.

What the user's browser shows now: the page and app state the app publishes, the actions you can run with ui_act (with their inputs), any components the app adds for boards, and the board on screen. Call it before ui_act, and to see what the user is looking at.

Run one of the app's actions in the user's browser: open a page, set a filter, select something. get_screen lists the actions and their inputs. Returns what the action returned.