@lotics/cli 0.315.17 → 0.316.0

package/docs/field_values.md

@@ -1,6 +1,6 @@
 # Field values — what a write takes for each field type
 
-The value `create_records` and `update_records` take for a field.
+The value `create_records` and `update_records` take for a field. A field is named by its alias, as `get_table` shows it, and a select option the same way. `dry_run: true` on `create_records`, `update_records` and `delete_records` runs the write in a transaction that is rolled back: every check, rule and stage owner is judged, no number is consumed, and the answer says what would be written or why it is refused. Every write meets the table's rules (`model/write-rules`): a refusal lists every broken rule at once, and a locked record answers under `blocked` in `update_records`' result.
 
 ## Values by type
 
@@ -13,23 +13,26 @@ The value `create_records` and `update_records` take for a field.
 | `datetime` | a `date` of this format: `"2025-03-14T09:00"`, never a month or a year |
 | `date_range` | a `date` of this format: `"2025-03-01/2025-03-15"`, both halves full dates |
 | `datetime_range` | a `date` of this format: `"2025-03-01T09:00/2025-03-15T17:00"`, both halves full |
-| `select` | `["opt_…"]` |
-| `select_member` | `["mbr_…"]` |
-| `select_record_link` | `["rec_…"]` |
+| `select` | `["open"]`, the option's alias |
+| `member` | `["mbr_…"]` |
+| `link` | `["rec_…"]` |
 | `files` | `["fil_…"]`, ids of uploaded files |
 | `formula`, `rollup`, `lookup`, `autonumber`, a `date` with `derive_from` | none — the platform writes them, and a write naming one is refused |
 
 ## Lists
 
-`select`, `select_member`, `select_record_link` and `files` store an ARRAY, even where the field holds
+`select`, `member`, `link` and `files` store an ARRAY, even where the field holds
 one value.
 
-- A single-select is a ONE-element array; a bare `"opt_…"` is accepted and wrapped. A single
-  `select_member` takes a bare `"mbr_…"` the same way.
-- `select_record_link` and `files` take an array only.
+- A single-select is a ONE-element array; a bare `"open"` is accepted and wrapped. A single
+  `member` takes a bare `"mbr_…"` the same way.
+- A single `link` takes a bare `"rec_…"` the same way; a multi `link` and `files` take an array only.
 - A `files` id the write adds must name a live file of this workspace, or the whole write is refused;
   an id that cell already holds stays, though its file was archived since.
-- Two options on a single-select, or two members on a single `select_member`, are refused.
-- `update_records`' `add_to`, `remove_from` and `replace` take arrays of the same items: `opt_` keys
-  for a select, member ids for a `select_member`, record ids for a `select_record_link`, file ids for
+- A file previews by its kind: an image zooms; a PDF scrolls, zooms sharp and turns by page, its text selectable; a DXF
+  drawing shows read-only in 2D with a toggle per layer. A DWG stays a stored file with no preview; attach its plotted
+  PDF beside it.
+- Two options on a single-select, two members on a single `member`, or two records on a single `link`, are refused.
+- `update_records`' `add_to`, `remove_from` and `replace` take arrays of the same items: option aliases
+  for a select, member ids for a `member`, record ids for a `link`, file ids for
   `files`.

package/docs/filters.md

@@ -9,7 +9,7 @@ to an app's query.
 A filter is a single condition, or a group of conditions.
 
 ```
-{ "node_type": "condition", "field_key": "Status", "operator": "has_any_of", "value": ["Done"] }
+{ "node_type": "condition", "field_key": "status", "operator": "has_any_of", "value": ["done"] }
 { "node_type": "group", "logic": "and" | "or", "children": [ …conditions or groups ] }
 ```
 
@@ -24,7 +24,32 @@ Groups nest up to 4 levels. AND(OR(status = A, status = B), age > 40):
 
 Every `field_key` resolves against the table being filtered — read each table's fields (`get_table`)
 and carry no name across tables: sibling tables holding the same concept routinely name it
-differently. A field is named by its `fld_…` key or by its name (`"Status"`).
+differently. A field is named by its alias (`"status"`), as `get_table` shows it, and a select option the same way
+(`"done"`). A traversal's `path` and the field of its condition are named the same way, each on the table the
+path has reached.
+
+## One family of operators
+
+A condition may state these operators; each reads as the type's own below. Which field kinds take each:
+
+| Operators | Field kinds | Meaning |
+|---|---|---|
+| `is`, `is_not` | a field holding one value: text, number, date, yes/no (`is` only, or `is_not` with a yes/no value), a select or member that is not multi, a link of cardinality one | equal to one value; on a select, member or link, to the one option, member or record |
+| `is_any_of`, `is_none_of` | text, number, date, select, member, link | equal to any of a list; on a select, member or link, `has_any_of` and `has_none_of` |
+| `lt`, `lte`, `gt`, `gte` | number, date | below, at most, above, at least |
+| `is_empty`, `is_not_empty` | every kind but yes/no | no value, or one |
+
+`is` and `is_not` on a field that holds several options, members or records (a multi select, a many-link) are refused:
+state `has_any_of`, `has_none_of` or `has_all_of`, which say whether the row must hold exactly them or just some.
+A date is `"2026-10-15"` for that whole day, whatever time a value holds. An `is_any_of` or `is_none_of` on a number
+or a date, and an `is_not` on a date, stand for a group of conditions, which a traversal's single condition cannot hold;
+a list that a workflow computes is expanded when the step runs, so a saved workflow states it as it states any list.
+The depth a filter may nest is the depth you write: the groups an operator stands for do not count.
+
+```
+{ "node_type": "condition", "field_key": "due", "operator": "gte", "value": "2026-10-01" }
+{ "node_type": "condition", "field_key": "status", "operator": "is_any_of", "value": ["done", "shipped"] }
+```
 
 ## Text
 
@@ -36,7 +61,7 @@ differently. A field is named by its `fld_…` key or by its name (`"Status"`).
 | `is_empty`, `is_not_empty` | none |
 
 ```
-{ "node_type": "condition", "field_key": "Title", "operator": "is_any_of", "value": ["hello", "world"] }
+{ "node_type": "condition", "field_key": "title", "operator": "is_any_of", "value": ["hello", "world"] }
 ```
 
 A text value is a string, never an array; `is_any_of` matches several. Its array has no length cap —
@@ -55,7 +80,7 @@ value is in.
 Rows holding another option are out; measured units of one dimension convert.
 
 ```
-{ "node_type": "condition", "field_key": "Amount", "operator": "greater_than", "value": 100, "unit_option": "USD" }
+{ "node_type": "condition", "field_key": "amount", "operator": "greater_than", "value": 100, "unit_option": "USD" }
 ```
 
 ## Boolean
@@ -66,11 +91,11 @@ Rows holding another option are out; measured units of one dimension convert.
 
 | Operators | Value |
 |---|---|
-| `has_any_of` (any of them — "A or B"), `has_none_of`, `has_all_of` (a multi-select only) | an ARRAY of option names, even for one |
+| `has_any_of` (any of them — "A or B"), `has_none_of`, `has_all_of` (a multi-select only) | an ARRAY of option aliases, even for one |
 | `is_empty`, `is_not_empty` | none |
 
 ```
-{ "node_type": "condition", "field_key": "Status", "operator": "has_any_of", "value": ["Done", "In Progress"] }
+{ "node_type": "condition", "field_key": "status", "operator": "has_any_of", "value": ["done", "in_progress"] }
 ```
 
 ## Member
@@ -90,7 +115,11 @@ Rows holding another option are out; measured units of one dimension convert.
 | `duration_equals`, `duration_greater_than`, `duration_less_than` | `{ amount, unit: "minutes" \| "hours" \| "days" }` |
 | `is_empty`, `is_not_empty` | none |
 
-A point is one of:
+A date value is a point. A bare `"YYYY-MM-DD"` is the point of that whole day (`"YYYY-MM-DDTHH:mm"` of that minute),
+and a stated date is compared as written, with no timezone shift: `on "2026-10-15"` matches every value from 00:00 to
+23:59 of that day, on a date or a datetime field. `before` the day is earlier than its start, `after` later than its end,
+`on_or_before` and `on_or_after` include it. A relative or period point counts today in the field's timezone. The
+objects below say the same, and add a time, an offset or a period:
 
 ```
 { "type": "exact", "date": "2025-03-14", "time": "09:00" }                       time optional
@@ -107,9 +136,18 @@ A point is one of:
 | `is_empty`, `is_not_empty` | none |
 
 ```
-{ "node_type": "condition", "field_key": "Customer", "operator": "has_any_of", "value": ["rec_abc123"] }
+{ "node_type": "condition", "field_key": "customer", "operator": "has_any_of", "value": ["rec_abc123"] }
+```
+
+## Through a link
+
+A traversal chooses records by a field of the records they link to. `path` lists link fields, each of the table
+before it (up to 3), and `condition` names a field of the last table reached:
+
+```
+{ "node_type": "traversal", "path": ["customer"], "condition": { "field_key": "tier", "operator": "has_any_of", "value": ["gold"] } }
 ```
 
 ## Sort
 
-A view's sort is a list, applied in order: `[{ "field_key": "Due", "order": "asc" | "desc" }]`.
+A view's sort is a list, applied in order: `[{ "field_key": "due", "order": "asc" | "desc" }]`.

package/docs/first_build.md

@@ -0,0 +1,180 @@
+# First build — a whole workspace, call by call
+
+A bakery takes custom-cake orders at the counter. An order is a customer and the cakes on it, one line per cake from the menu; it moves taken, baking, ready, collected, and a slip of the cakes prints when it is ready. Six steps, in the order every workspace is built.
+
+Step 0, before the first write: ask the owner once, in one message, only what you cannot settle yourself. Usually: their papers and lists — a photo, a spreadsheet or a file is fine; they answer most questions (what they send and receive, customers, items, prices) — and what no paper tells you that would change the tables or who does which step. The owner answers by hand, so every question costs them time: ask nothing they gave already or a paper settles. Each question is one sentence, no sub-questions or bullets under it; nothing else in that message. Wait for the answer, then build; never build first and ask after. Never ask about stages or design: take a default for everything else and list it in your report so the owner can correct it. Load the owner's own rows. `get_workspace` shows what already exists; what no one could guess from the data goes into a knowledge doc with `set_knowledge` (`knowledge_docs`).
+
+## 1. Tables and their checks: `set_tables`
+
+One call, linked tables together; a call names a table by its alias, a new table in the call by its `ref`, which becomes its alias; a link names the other table so. Three kinds appear: a book lines are chosen from (`menu_item`), the record the work moves (`cake_order`) and its lines (`cake_line`). One table per kind of thing, one column per fact, a link wherever one record points at another. A status is the stage of the work, six options or fewer; a touch ("called") is a log row, a money fact ("paid in full") a formula, a quantity a number with its unit in `notation`. Every table people work states `singular` (an app with an Add over a table lacking it is refused), `title` (who or what a row is; a code only where nothing else names it) and `records` (an app over a table without it is refused).
+
+```json
+{
+ "tables": [
+  {
+   "ref": "customer", "label": "Customers", "singular": "Customer", "title": "name",
+   "fields": {"name": {"type": "text", "label": "Name", "required": true}},
+   "records": {"party": "person"}
+  },
+  {
+   "ref": "menu_item", "label": "Menu", "singular": "Menu item", "title": "name",
+   "fields": {
+    "name": {"type": "text", "label": "Cake", "required": true},
+    "photo": {"type": "files", "label": "Photo"},
+    "price": {"type": "number", "label": "Price", "required": true, "notation": {"style": "currency", "currency": "USD"}}
+   },
+   "records": {"figure": "price", "image": "photo"}
+  },
+  {
+   "ref": "cake_order", "label": "Cake orders", "singular": "Cake order", "title": "reference",
+   "fields": {
+    "reference": {"type": "autonumber", "label": "Number", "prefix": "CK-", "padding": 3},
+    "customer": {"type": "link", "label": "Customer", "table": "customer", "multi": false, "required": true},
+    "due_on": {"type": "date", "label": "Pickup on"},
+    "pay_by": {"type": "date", "label": "Pay balance by"},
+    "lines": {"type": "link", "label": "Cakes", "table": "cake_line", "multi": true, "pair": "order"},
+    "total": {"type": "rollup", "label": "Total", "via": "lines", "op": "sum", "field": "amount"},
+    "prepaid": {"type": "number", "label": "Prepaid", "notation": {"style": "currency", "currency": "USD"}},
+    "balance": {"type": "formula", "label": "Balance", "expression": "{total} - {prepaid}", "notation": {"style": "currency", "currency": "USD"}},
+    "paid": {"type": "formula", "label": "Paid", "expression": "{total} > 0 && {balance} <= 0", "output_type": "boolean"},
+    "slip": {"type": "files", "label": "Slip"},
+    "stage": {"type": "select", "label": "Stage", "default": ["taken"], "options": [
+     {"alias": "taken", "label": "Taken", "color": "slate"}, {"alias": "baking", "label": "Baking", "color": "amber"},
+     {"alias": "ready", "label": "Ready", "color": "blue"}, {"alias": "collected", "label": "Collected", "color": "green"}
+    ]}
+   },
+   "records": {"subtitle": ["customer"], "figure": "total", "due": ["pay_by"], "settled": "paid", "status": {"field": "stage", "closed": ["collected"]}},
+   "checks": {"pay_by_before_pickup": {"on": ["create", "update"], "field": "pay_by",
+    "when": "!isNull(record.pay_by) && !isNull(record.due_on)", "fail_when": "record.pay_by > record.due_on",
+    "message": "\"The balance is due on or before the pickup day\""}}
+  },
+  {
+   "ref": "cake_line", "label": "Cakes on orders", "singular": "Cake", "title": "item",
+   "fields": {
+    "item": {"type": "link", "label": "Cake", "table": "menu_item", "multi": false, "required": true},
+    "order": {"type": "link", "label": "Order", "table": "cake_order", "multi": false, "required": true, "pair": "lines"},
+    "quantity": {"type": "number", "label": "Quantity", "required": true, "min": 1},
+    "unit_price": {"type": "number", "label": "Unit price", "default_from": "item.price", "notation": {"style": "currency", "currency": "USD"}},
+    "amount": {"type": "formula", "label": "Amount", "expression": "{quantity} * {unit_price}", "notation": {"style": "currency", "currency": "USD"}}
+   },
+   "unique": [["order", "item"]],
+   "records": {"subtitle": ["quantity"], "figure": "amount"}
+  }
+ ]
+}
+```
+
+`stage` is the table's status. `party` (`"person"` or `"organization"`) draws a face; `image` is the files field that pictures a row, never the one an Act files its paper in; `settled` is a yes/no that ends the `due` deadlines, so it needs a `due`; `figure` is a number. `unique` is two fields or more no two rows share (one line per cake on an order). A line copies the menu's price with `default_from` when made, so a later price change leaves taken orders alone. `min`, `unique` and the check hold on every write, from any app or tool; a check's language is `workflows/table-checks`, an effect after any write a table workflow (`workflows/table-workflows`). Every key is in `model/tables`.
+
+## 2. The paper: `set_template`
+
+The app's Act names the template by its alias, made from its name (`order_slip`): the paper comes first.
+
+```
+set_template {"type": "html", "name": "Order slip",
+  "template": "<h1>Order {{reference}}</h1><p>{{customer}} — pickup {{date due_on}}</p>{{#each lines}}<p>{{item}} × {{quantity}} — {{money amount \"USD\"}}</p>{{/each}}<p>Total {{money total \"USD\"}}</p>",
+  "variables": {"reference": "string", "customer": "string", "due_on": "string", "lines": "array", "total": "string"}}
+```
+
+Every paper the owner sends is made, one template each. A slot is named after a field of the record; the order's cakes loop under the name of its link to them (`lines`). Fields, loops, layout and papers over many rows: `document_templates`.
+
+## 3. The app and its acts: `set_app`
+
+**Which apps.** An app is one person's job: the desk they open each day on a list of their own. Does a person open a list the owner names first to do their day's work? An app, that list its register. Part of one record (a vehicle's papers)? A Section or child List of that record's app. Used only while doing another job (the rates a quote is priced from)? A picker on that job's lines, price copied by `default_from`; a book with a keeper or Acts of its own is an app. Same person, another record or rhythm? Another app. Never an app per table; a record passing between people's steps is one app per person over the same table, each register narrowed by `where` to their steps.
+
+**The view per kind of row**, chosen before writing the List (a plain register needs none):
+
+| The rows are | The treatment | Keys |
+|---|---|---|
+| People or organisations | `records.party`, photo or logo as `image` | `model/records` |
+| Photos people look at | `records.image`; List `layout: "cards"` | `model/cards` |
+| Held on a day people schedule by | List `layout: "calendar"` | `model/calendar` |
+| Booked on a resource over time | List `layout: {"lanes": {"by": …}}`, table `no_overlap` | `model/lanes` |
+| Standing at places on a floor or yard | List `layout: {"plan": …}` | `model/plan` |
+| People across days | List `layout: "roster"`, the cells' List inside | `model/roster` |
+| Expected against counted, before against after | a List with `compare: {"before": …, "after": …}` | `model/list-node` |
+| Ranked by a figure | List `sort: {"field": …, "desc": true}` | `model/list-node` |
+| Moved through a status (stages) | an Act per move, `status.dates`, Readings | `model/act-node` |
+| Each belonging to another row | a child List on its Record | `model/list-node` |
+| Counted over a period | Tabs over one `period`; Readings | `model/tab-node` |
+| Papers a case gathers | a List with `expect`; an Act's `template` | `model/list-node` |
+
+Any other screen: `design/treatments`.
+
+Here one app, the counter's job, naming the tables and the template by the aliases above. The register lists the orders; opening one shows a Section per stage, and each Act sets the next stage. The cakes are a child List of the open order, added in place with `create`. Starting to bake asks for the deposit, readying makes the slip, collecting waits for payment.
+
+```json
+{
+ "body": {
+  "type": "App", "key": "counter", "name": "Counter", "color": "amber",
+  "children": [
+   {"type": "List", "entity": "cake_order", "filters": ["customer"], "create": ["customer", "due_on", "pay_by"], "children": [
+    {"type": "Record", "door": "page", "children": [
+     {"type": "Section", "key": "order", "title": "Order", "at": ["taken", "baking"], "children": [
+      "due_on",
+      "pay_by",
+      {"type": "List", "entity": "cake_line", "create": ["item", "quantity"]},
+      {"type": "Act", "key": "start_baking", "label": "Start baking", "when": {"stage": ["taken"]}, "requires": ["due_on"], "asks": ["prepaid"], "set": {"stage": "baking"}},
+      {"type": "Act", "key": "ready", "label": "Ready", "when": {"stage": ["baking"]}, "set": {"stage": "ready"}, "template": "order_slip", "into": "slip"}
+     ]},
+     {"type": "Section", "key": "pickup", "title": "Pickup", "at": ["ready"], "children": [
+      {"field": "balance", "edit": false},
+      {"field": "slip", "edit": false},
+      {"type": "Act", "key": "collect", "label": "Collected", "when": {"stage": ["ready"], "paid": true}, "set": {"stage": "collected"}}
+     ]}
+    ]}
+   ]}
+  ]
+ }
+}
+```
+
+`set_app` answers with a note for what the rows call for that the tree leaves out; these fold with one: a read-only copy of a placed Field, `create`/`remove: false` on a read-only List, its `app` where one app is over its table, a lone text field's `unique`, a patch address unlike the node's `key`. **What the check refuses**, each with its id (`model/<id>` is its page):
+
+- `record.placed-once`: a Field, child List, Reading, Statement or Act stands once in a Record, whose head draws the title, subtitle, image, status, figure.
+- `register.filter-unshown`: a `filters` entry (at most 3) is a select, member, link, date, yes/no or number the rows show, or a formula of such; never text, and the status is the chips already.
+- `register.columns-budget`, `block.columns-budget`: `columns` fit the room a desk leaves beside the name, status, deadline and figure.
+- `act.requires-drawn`: an Act's `requires` field is drawn in its Section or asked by it.
+- `app.logs`: a further List at the App's root is a log (at most 3) with its own `key`, over another table than the register's.
+- `act.makes-or-runs`: an Act makes a `template` or runs a `workflow`.
+- `reading.list-app`: a List's `app` has its register over that List's table.
+- `block.list-opens`: a read-only child List opens its rows in the drawer, so its table is one a List of the app draws, or its `app` names the app that works it.
+- A Field's `label` or `when` stands only on a gallery or prose Field (files, markdown text, or `block: true`).
+- `entity.unique`: a `unique` set holds two fields or more of one value each (text, number, date, single select, one-row link).
+- `model.names-declared`: each alias a key names exists (a table, field, option, Act `key`, template).
+- A Query's `sort` is `{"field": …, "desc": true}` (`desc` optional) or a list of them, beside `fields`.
+- A workflow writes a link as ids, `[x.id]`; a whole record or bare value is refused.
+
+Then `set_access` gives the app to the people whose job it is: a `principal_type` of `member` (id from `get_workspace`, `kind: "member"`), `member_group` (an admin lists them: `kind: "group"`) or `organization`, a `role` of `user` or `manager`; none loses access.
+
+```
+set_access {"resources": [{"resource_type": "app", "resource_id": "app_…"}], "principals": [{"principal_type": "member", "principal_id": "<member id>", "role": "user"}]}
+```
+
+## 4. What the owner will ask an agent: Query and Workflow nodes
+
+Read the brief again for what the business asks its assistant again and again: a figure or list whose definition is its own (orders waiting for pickup), an operation (chase overdue balances). Declare each as a Query or Workflow node of the app, with a `description` for an agent that has not seen the screen (`agent_surface` § Declaring more); a connected service (MISA, a carrier) is reached by a Workflow node's step (`workflows`); a question asked once stays on `aggregate_records`.
+
+## 5. The owner's rows: `create_records`
+
+The owner's own list goes in as rows, in the batches the tool allows: the customers and menu first, then the orders, linked by the ids those calls return, then each order's cakes, linked to the order and a menu item. A row created past the first stage (`records.status.stages`) is refused unless that owned stage's owner or a workspace admin makes it, so load the owner's rows as an admin. Example rows the papers ask for and do not list come from the owner's lists and sample, marked as examples, each created at the stage it should show; pressing rows proves the app and never spreads examples across steps; a placeholder ("Demo customer") is never made where the owner's own rows exist. The value each field type takes is in `field_values`.
+
+```
+create_records {"table_id": "menu_item", "field_keys": ["name", "price"], "rows": [["Lemon cake", 24], ["Chocolate cake", 28]]}
+create_records {"table_id": "customer", "field_keys": ["name"], "rows": [["Ana Lopez"]]}
+create_records {"table_id": "cake_order", "field_keys": ["customer", "due_on", "pay_by"], "rows": [["<Ana's record id>", "2031-03-14", "2031-03-12"]]}
+create_records {"table_id": "cake_line", "field_keys": ["order", "item", "quantity"],
+  "rows": [["<that order's record id>", "<Lemon cake's record id>", 2]]}
+```
+
+## 6. Verify: `run_app_workflow`, `screenshot_app`
+
+Move the owner's own rows through the app as their person would, in stage order. An Act runs as `act_<key>` (or under the alias of the `workflow` it names), handed what it asks; dry-run first, then press. To prove a rule, send the write with `dry_run: true`; never make a test row or switch a check off. A row ends at the stage the owner says it is at, so press each only that far; where the owner gave no rows, ask for a few.
+
+```
+run_app_workflow {"app_id": "app_…", "alias": "act_start_baking", "inputs": {"record_id": "rec_…", "prepaid": 20}, "dry_run": true}
+run_app_workflow {"app_id": "app_…", "alias": "act_start_baking", "inputs": {"record_id": "rec_…", "prepaid": 20}}
+screenshot_app {"app_id": "app_…"}
+```
+
+Fix a failure in the table or app that causes it. Leave standing instructions with `set_workspace` (`instructions`, one entry per rule): who the business is, the words its people use, what any agent working here must keep to. As an admin, invite the people the brief names with `set_member` (`members` keyed by email, role `member` or `admin`); where the tool is missing, say whom to invite. Then show the owner what you built, job by job, each paper they sent and what makes it, with the choices you made for them to change.

package/docs/getting_started.md

@@ -0,0 +1,15 @@
+# Getting started
+
+A workspace is where one business keeps what it knows and does its daily work. **Records** are what it tracks, one table per kind of thing and one row per entry. **Apps** are the screens a team works in, one per person's job, drawn over the tables. **Documents** are the quotes, invoices and slips it sends, each a template filled from a record, or from the many rows of a period or a statement. A paper is the workspace's once it is made from a template or uploaded and filed on its record; a file left on the host's own disk, the user's included, reaches no one in the workspace. A procedure or policy no table holds is a **knowledge doc**; a price list, a customer list or the open orders are rows.
+
+Open the one page for the job. Pages are read with the `docs` tool (`docs path="design"`; `lotics docs design` on the CLI).
+
+- **Build a workspace from a description:** `docs path="first_build"`. Ask the owner once, only what their papers and your defaults cannot settle, usually their papers and lists first, then a whole bakery built call by call: tables with a check, the paper, the app (which apps, a treatment per kind of row, what the check refuses, who gets it), the owner's rows, then pressing it.
+- **Change an app:** `docs path="model/changing-an-app"`. `get_app`, then `set_app` with `nodes` and `base_version_id`. A table is changed with `get_table`, then `set_tables` with its `table_id` (`data_model`).
+- **Enforce a rule on a table:** `docs path="workflows/table-checks"`. A condition no create, update or delete may meet, whoever makes it, and the language it is written in.
+- **Make a document:** `docs path="document_templates"`. A template, its slots and loops, and the act that files it on a record.
+- **Enter data, count, answer a question:** `docs path="working_in_a_workspace"`. The right tool for each job; the value each field takes is `field_values`, choosing rows is `filters`.
+- **Reach a connected service, or do what a button cannot:** `docs path="workflows"`. Triggers, steps and expressions; each service step is in `workflow_steps`.
+- **Share an app:** `docs path="first_build"`, § 3. `set_access`, and which app each person gets.
+
+Which apps a business needs is `first_build`, § 3 (a worked split: `app_architecture`); how each record is drawn is `design`; every key is in `model`; each screen in a complete workspace is `examples`.