@lotics/cli 0.316.14 → 0.316.16

package/docs/agent_surface.md

@@ -60,7 +60,7 @@ splits by, or per day. Each row carries the alias of each field it splits by, `_
 day, `__count`, and `__sum` where it sums a number; its description states which. An average is `__sum`
 over `__count`, both over the rows holding a value.
 
-A Reading is called by its `key` (`model/reading-node`), so moving it in the tree changes no name. A log's Reading is called by the
+A Reading is called by its `key` (`reference/reading-node`), so moving it in the tree changes no name. A log's Reading is called by the
 log's table before the name: `<entity>_<key>`.
 
 A register reading's query reads the rows it names, whatever a screen has open: the rows of its `tab` where
@@ -259,7 +259,7 @@ and the runs before it stand. A refused read fails the same way, naming the para
 ## Declaring more
 
 What the business asks an agent in the app again and again, and no screen draws, is stated in the app's tree as Query and Workflow nodes, beside its
-Acts: every figure or list whose definition is the business's own (open orders, what a customer owes, low stock) and every recurring operation (close the month, send to the accounting service, chase overdue invoices), each with a `description` written for an agent. A question asked once stays on `aggregate_records`. A Workflow gets an Act only where a person presses it; work only an agent does has no button. Both are checked and compiled when the tree is written (`set_app`; `model/query-node`, `model/workflow-node`).
+Acts: every figure or list whose definition is the business's own (open orders, what a customer owes, low stock) and every recurring operation (close the month, send to the accounting service, chase overdue invoices), each with a `description` written for an agent. A question asked once stays on `aggregate_records`. A Workflow gets an Act only where a person presses it; work only an agent does has no button. Both are checked and compiled when the tree is written (`set_app`; `reference/query-node`, `reference/workflow-node`).
 
 **A query** — the rows of one table, or one figure of them, in the app's own aliases:
 
@@ -284,7 +284,7 @@ so never the table of an app that states Books, whose list reads several tables.
 optional param narrows nothing when the call leaves it out; no param compares a number read in each row's
 own unit or currency, or a date holding a span. `"reading"` in place of `"fields"` returns a count or a sum —
 `{ "value": "price", "by": "item" }` — as a Reading does. A Query, a Workflow and
-a Reading's `key` take no name the app generates (`model/app.generated-name`).
+a Reading's `key` take no name the app generates (`reference/app.generated-name`).
 
 **A workflow** — a write no Act of the record makes, typed in the app's tree and its code set on the app:
 

package/docs/app_bindings.md

@@ -131,7 +131,7 @@ keeps the type tracking the live field.
 `set_app_workflow` binds a workflow body to an alias: `{ app_id, alias, source, inputs?, outputs?,
 name?, description? }`. On an app written as a tree the alias is one the tree names — a Workflow node's
 `key` or an Act's `workflow` — and the node states `inputs`, `outputs` and `description`
-(`model/workflow-node`, whose value shapes differ from the **Inputs** below): a call stating any of
+(`reference/workflow-node`, whose value shapes differ from the **Inputs** below): a call stating any of
 them for it is refused, and outputs the node leaves out are derived from the body. An alias the tree
 names nowhere is archived by the next `set_app`. A Workflow node runs only for someone who holds the
 app: on an app shared by a public link, a visitor's call of it is refused as an alias the app does

package/docs/building_an_app.md

@@ -19,8 +19,8 @@ you tried it, stay where they are. Try a write on a throwaway record.
 - **An app stated as a tree** — the default, and the right one for almost every job. The tree (a
   JSON file, one per app) is a List of one table, whose rows are recognised by the
   table's own `records`, and the Record its rows open, with the logs that stand beside it (further Lists at the root, which a change may add at any time, read by the organization's own members alone): its columns and filters, its Sections in the order its work
-  reaches them, its Acts and the Checks that guard them (`lotics docs model/app-tree`,
-  `model/list-node`, `model/section-node`, `model/act-node`, `model/check-node`). The platform
+  reaches them, its Acts and the Checks that guard them (`lotics docs reference/app-tree`,
+  `reference/list-node`, `reference/section-node`, `reference/act-node`, `reference/check-node`). The platform
   compiles each app and draws it with the runtime every such app shares, so how each piece looks is
   the platform's, one way per concept, and no prop changes it. Every write the app makes is a
   generated workflow that re-checks on the server what the tables state.
@@ -71,7 +71,7 @@ Tables first, then apps. `set_tables` takes a list of table documents, one or ma
 none; `set_app` takes one app per call. Each creates when it is given no id and edits when it is given one.
 
 ```
-lotics docs model                       # the keys of a table document and the app tree's components, with a worked example
+lotics docs reference                       # the keys of a table document and the app tree's components, with a worked example
 lotics docs design                      # the treatment per kind of row
 lotics run set_tables @tables.json      # one call, every table: {"tables": [...]}
 lotics run set_app @orders.call.json    # one app: {"body": <the App tree>} to create (add "dry_run": true to check)
@@ -94,7 +94,7 @@ nothing; a refusal lists everything wrong in it at once.
 
 The App node is the app: its `name`, `description`, `icon` and `color` are props of it, and no other input of
 `set_app` states them. It names the tables and templates it uses by their aliases (an entity is a table's alias, a `template` a template's alias);
-`set_app` fills the `tables` and `templates` maps by id from them and `get_app` shows aliases (`lotics docs model/app-node`). A call that creates
+`set_app` fills the `tables` and `templates` maps by id from them and `get_app` shows aliases (`lotics docs reference/app-node`). A call that creates
 is `{"body": <the App tree>}`; one that changes a part is `{"app_id": "app_…", "nodes": {"<address>": <patch>}}`,
 each address a node's path of keys (`get_app` prints every one), a patch a JSON merge patch of that node's props
 and `null` removing the node; the App's own props change through `body`. A call stating `base_version_id` — the
@@ -125,14 +125,14 @@ Readings over its rows, a record's Sections, an Act per status move, a picture w
 the file, apply it; or send `nodes` for one part. An Act whose write the tree cannot say names its own `workflow`; that workflow's code is
 the live one, and `lotics run set_app_workflow` changes it. A job no press starts — an agent or a
 service handing the app a file or a list of rows — is a Workflow node the app declares
-(`lotics docs model/workflow-node`): the node states what it takes and hands back, and `lotics run
+(`lotics docs reference/workflow-node`): the node states what it takes and hands back, and `lotics run
 set_app_workflow` sets its code with `inputs` and `outputs` left out.
 
 **What a person reads and does in the app, an agent reads and does through it.** Writing the tree generates a
 query for every List, record, child List and figure the screen reads, and a workflow for every add, edit,
 removal and act — `lotics run get_app` lists them, and `lotics docs agent_surface` names each
 family and how it is called. A question the screen never asks is a Query node the app declares
-(`lotics docs model/query-node`), beside its Workflow nodes. Both are part of the design: `lotics docs
+(`lotics docs reference/query-node`), beside its Workflow nodes. Both are part of the design: `lotics docs
 agent_surface`, § Declaring more.
 
 ## 5 — A custom-code app

package/docs/cli_reference.md

@@ -49,10 +49,10 @@ Per-command syntax, flags, contracts, and gotchas for the public `lotics` CLI. S
 | `lotics knowledge restore <id...>` | Bring deleted docs back via `restore_knowledge` (`{ knowledge_doc_ids }`), in one call: every id must be a deleted doc you manage, or nothing is restored. Refuses the no-argument form. |
 | `lotics app create <name> --custom [path]` | **A custom-code app**: creates the app (`POST /v1/apps`), scaffolds a Vite + React + TypeScript project into `[path]` (default `./<name>`, refused when not empty — before the app row exists) that depends on `@lotics/app-sdk` alone and draws with plain React, and installs it (`npm install --ignore-scripts`), then writes the declarations of the app's live bindings (`GET /v1/apps/{id}/types`) into `.lotics/`, which the project's `tsconfig.json` includes. `package.json#lotics` names the app and its workspace, which is how `app deploy` in that directory finds both. The app has no version until the first `lotics app deploy`. `--custom` is required: a JSON app is made by `lotics app apply` (the tool `set_app`). The SDK's reference is `node_modules/@lotics/app-sdk/AGENTS.md` inside the project. |
 | `lotics app pull [app_id] [path]` | **An app's live definition, pulled.** The app is read with `get_app`: its author is shown a body, a JSON **tree** (with the addresses of its nodes) pulled as that tree and a custom-code app (the identity alone) as its source; an app whose stored tree cannot be read is refused with the reason `get_app` gives, and so is an app that shows the caller no body (the caller does not author it, or it has no version). **A JSON app**: the tree is written as JSON to `[path]` (a directory receives `./<name>.app.json`; default `./<name>.app.json`), and the app's id and current version beside it in `<file>.lotics.json` (`{ "app_id": "…", "version_id": "…", "digest": "…" }`, the digest being the file as the CLI last left it; a record without all three is refused by `app apply`, naming `lotics app pull`) — a custom-code project records both in `package.json#lotics`, a single file has no such place — so the next `lotics app apply <file>` edits that app, and is refused if the app has since moved past that version. An existing file is overwritten only when its `.lotics.json` names this same app and the file is unchanged since it was last pulled or applied; a file with edits, or whose record names the app but no digest, is refused, naming `--force`, which overwrites it. `--force` is a flag of `app pull` alone. `--json` prints `{workspace_id, app_id, path, outcome}`. **A custom-code app**: its live source, as a project ready to deploy on it. The target is `[path]`, else this directory when it is the app's project (or no app is named), else `./<name>`. **The app's own project is brought up to date in place** — but only when it holds no edit since the version `package.json#lotics.current_version_id` names: its source (packed as a deploy packs it) is compared with that version's archive, ignoring `.lotics/` and `package.json#lotics`, and any difference refuses the pull, naming the changed files; a pull never merges, so local work is never lost. Already at the live version is a no-op that says so. **An empty or new directory receives the source whole**; any other directory is refused. Downloads come from `GET /v1/apps/{id}/versions/{version_id}/source`. `package.json#lotics` is then set to exactly the app, its workspace and the pulled version, dropping every other key an older CLI wrote there, so the next `lotics app deploy` builds on the live version; then `.lotics/` is written (`GET /v1/apps/{id}/types`) and dependencies installed (`npm ci` with a lockfile, else `npm install`, both `--ignore-scripts`). |
-| `lotics app apply <file> [--app <app_id>] [--check] [--json]` | **A JSON app, one at a time, through the tool `set_app`.** The file is an app's tree (`lotics docs model`: the App node with the nodes under it, its tables and templates named by alias). **No app known** (no `--app`, no `<file>.lotics.json` beside it): the file is sent as `{ "body": … }` to make a new app, named by the body's `name`, and the id made is printed, then recorded with its version in `<file>.lotics.json`. **An app known**: its current tree is read (`get_app`) and the **RFC 7396 merge patch** that turns it into the file is sent as `body` with the `app_id` and the version the patch was computed against as `base_version_id` — a key the file drops is `null` in the patch, a list is replaced whole, what the file leaves alone is left alone, and a tree the app already has sends nothing and says so. **A file pulled at a version the app has since left is refused** before anything is sent, naming both versions and `lotics app pull <app_id> <path>`: pull the current tree into another path, carry the edits over, apply that file. `--app` naming an app other than the sibling file's is refused too. A write that races the apply is refused by the server, which names the app's current version. A file that sets an object key to `null` is refused naming the key, since a merge patch reads `null` as a removal. `--app` names the app, else the sibling file does; an app whose `get_app` shows no body (it is not yours) or whose stored tree cannot be read is refused, and a custom-code app takes its identity (name, description, icon, colour) only, and no `<file>.lotics.json` records it, since an identity write makes no version — its source deploys with `app deploy`. **The file is never rewritten**: a node the tree leaves out draws as the rows call for it and is stored nowhere (`lotics docs design`). It prints what `set_app` answered and reports its `outcome`: its notes and findings, every finding at once, and the saves, adds and Deletes the write grants and removes. **`--check` sends `dry_run`** (a flag of `app apply` alone, as is `--app`) — what would refuse the tree, and what it would grant and remove — and writes nothing, the file and its sibling included; an `outcome` of `refused` exits 1. A tree the app already has, or one `set_app` answers `unchanged`, records the version the app stays at in the sibling. **To go back to an earlier version, apply the earlier tree again.** Resolves and ANNOUNCES its workspace first. `--json` prints `{workspace_id, app_id, outcome, write}`, `outcome` being `set_app`'s: `created`, `updated`, `unchanged` or `refused` (with `--check`, what it would be). |
+| `lotics app apply <file> [--app <app_id>] [--check] [--json]` | **A JSON app, one at a time, through the tool `set_app`.** The file is an app's tree (`lotics docs reference`: the App node with the nodes under it, its tables and templates named by alias). **No app known** (no `--app`, no `<file>.lotics.json` beside it): the file is sent as `{ "body": … }` to make a new app, named by the body's `name`, and the id made is printed, then recorded with its version in `<file>.lotics.json`. **An app known**: its current tree is read (`get_app`) and the **RFC 7396 merge patch** that turns it into the file is sent as `body` with the `app_id` and the version the patch was computed against as `base_version_id` — a key the file drops is `null` in the patch, a list is replaced whole, what the file leaves alone is left alone, and a tree the app already has sends nothing and says so. **A file pulled at a version the app has since left is refused** before anything is sent, naming both versions and `lotics app pull <app_id> <path>`: pull the current tree into another path, carry the edits over, apply that file. `--app` naming an app other than the sibling file's is refused too. A write that races the apply is refused by the server, which names the app's current version. A file that sets an object key to `null` is refused naming the key, since a merge patch reads `null` as a removal. `--app` names the app, else the sibling file does; an app whose `get_app` shows no body (it is not yours) or whose stored tree cannot be read is refused, and a custom-code app takes its identity (name, description, icon, colour) only, and no `<file>.lotics.json` records it, since an identity write makes no version — its source deploys with `app deploy`. **The file is never rewritten**: a node the tree leaves out draws as the rows call for it and is stored nowhere (`lotics docs design`). It prints what `set_app` answered and reports its `outcome`: its notes and findings, every finding at once, and the saves, adds and Deletes the write grants and removes. **`--check` sends `dry_run`** (a flag of `app apply` alone, as is `--app`) — what would refuse the tree, and what it would grant and remove — and writes nothing, the file and its sibling included; an `outcome` of `refused` exits 1. A tree the app already has, or one `set_app` answers `unchanged`, records the version the app stays at in the sibling. **To go back to an earlier version, apply the earlier tree again.** Resolves and ANNOUNCES its workspace first. `--json` prints `{workspace_id, app_id, outcome, write}`, `outcome` being `set_app`'s: `created`, `updated`, `unchanged` or `refused` (with `--check`, what it would be). |
 | `lotics app deploy [-m <message>]` | **Build this directory and upload it as a new version of the live app.** Rewrites `.lotics/` with the declarations of the app's live bindings (`GET /v1/apps/{id}/types`, replacing each file there), then runs the project's `npm run typecheck` (warned about when absent; a type error in the app's own files stops the deploy, one inside an installed package is reported and does not) and `npm run build`, tars the source (without `node_modules`, `dist`, `.git`, `*.tsbuildinfo`) and `dist/`, and posts both to `POST /v1/apps/{id}/versions` on the version `package.json#lotics.current_version_id` names, then stamps the new one there. The version carries the app's queries, workflows, agents and capabilities forward unchanged — those are written through their tools. A project with no `build` script, or whose `package.json#lotics` still declares `queries`, `workflows`, `agents` or `capabilities`, is refused before anything is built; the refusal names the tool that sets each. **A 409 because another version went live since this directory's last deploy** (a deploy from elsewhere, a rollback) prints the server's sentence and the version that is live, and names `lotics app pull`: run in this directory, it brings an unedited project up to date, and lists the files a project with edits changed, to carry over into a fresh pull. `-m` (or a bare positional) is the version's message, optional. The workspace comes from `package.json#lotics.workspace_id` unless `--workspace` / `LOTICS_WORKSPACE` names another. |
 | `lotics docs` \| `lotics docs <area>[/<section>]` \| `lotics docs [<area>[/<section>]] --grep <text>` | **This CLI's own references, carried inside the binary** — the model reference, this index, and every doc under `docs/` — so the doc a reader opens describes the binary answering, listed by the job a reader comes to do. Capped at ONE PAGE: a doc that does not fit prints its opening and the addresses of what it holds (`lotics docs <area>/<section>`, each section's size beside it, or a table's row names), and every address prints within a page. **A reference the binary's copy lacks, or a part of one the server serves, is read from the server's `docs` tool** with this machine's credential, after the copy's refusal — a page the server added since this binary was built, which a server refusal can cite. A name matching more than one reference, or a part missing from a guide to this CLI, is answered by the copy alone. **`--grep` searches the references the server serves** (not this CLI's own guides, which it refuses), with this machine's credential, narrowed to the area or section named: literal text unless `--regex`; a literal search that finds nothing while the pattern read as an expression matches (`a|b`) returns those lines under a note saying so, and `--literal` keeps the literal zero; with `--case-sensitive`, `--diacritic-insensitive`, `--context-lines <n>` and `--limit <n>` — the dialect the knowledge lines of `get_workspace` with `search` are read in — each hit under the address that opens its page; any of those options without `--grep` is refused. A custom-code app's SDK reference ships inside `@lotics/app-sdk` in the app's `node_modules`. |
 | `lotics upgrade` | Update this CLI in place. Runs the same installer a person would, chosen by how THIS copy arrived: an npm install upgrades through npm, a script install re-runs the script — the runtime knows which (the executable is compiled, the npm bin runs under node), so nobody has to. It downloads nothing itself; resolving a version, verifying the checksum and replacing a running executable already exist in the installers, and a second copy of that inside the binary would be a second thing to get right. Replacing the binary while it runs is safe — a rename leaves the running image mapped on unix, and on Windows the installer moves the old aside precisely because the file is in use. Already current is a no-op that says so. Needs no auth. |
-| `lotics docs model` \| `lotics docs model/<section>[/…]` | **The reference for tables and apps, from inside the binary** — at this CLI's version; `lotics docs` lists it under "Build an app", after `design`. Its first page is what the documents compose with, the working order (jobs → tables and fields → `records` → one app per job → one `set_tables` call with every table, then every `set_app` call) and the section addresses; every page of it is whole. Every key of a table document and an app body, every field `type` with the config each one needs, the option / view / inline-template shapes, `records` (how a row of a table is recognised), `write_rules`, the apps (each register, record, act and check), the row format (relative dates `@today` / `@month-start` with whole-day offsets; links as `"<table-ref>:<row-ref>"`), the rules, the caps of one `set_tables` call, and a worked example; it points at `https://lotics.ai/presets/index.json` for example files of several trades, which an agent reads and passes to `set_tables`. **Offline, no account.** |
+| `lotics docs reference` \| `lotics docs reference/<section>[/…]` | **The reference for tables and apps, from inside the binary** — at this CLI's version; `lotics docs` lists it under "Build an app", after `design`. Its first page is what the documents compose with, the working order (jobs → tables and fields → `records` → one app per job → one `set_tables` call with every table, then every `set_app` call) and the section addresses; every page of it is whole. Every key of a table document and an app body, every field `type` with the config each one needs, the option / view / inline-template shapes, `records` (how a row of a table is recognised), `write_rules`, the apps (each register, record, act and check), the row format (relative dates `@today` / `@month-start` with whole-day offsets; links as `"<table-ref>:<row-ref>"`), the rules, the caps of one `set_tables` call, and a worked example; it points at `https://lotics.ai/presets/index.json` for example files of several trades, which an agent reads and passes to `set_tables`. **Offline, no account.** |
 | `lotics report '<json>'` \| `lotics report @report.json` | File a report with the Lotics team about what got in your way. **Covers the classes telemetry structurally cannot see**: a capability that does not exist (no command ran, so nothing was recorded), a command that exited 0 having done the wrong thing, an error whose message did not name the remedy, and anything that made authoring slower than it should be. **A frame, not a paragraph** — `{goal, actual, expected?, tried?, wanted?}`, `goal` and `actual` required, unknown keys dropped rather than refused. **No severity or category.** Ingest is inline JSON, `@file`, or `-` for stdin. A bare sentence is refused with the frame printed beside it, so the fix is one step; a bare invocation prints the frame BEFORE asking for a credential, since someone whose key will not resolve is exactly who has something to report. **Not spooled**: unlike telemetry it posts inline, prints whether it landed, and exits non-zero if it did not, echoing the report back so a failed send never loses it. Runs regardless of `LOTICS_TELEMETRY` — invoking it IS the consent that passive collection needs an opt-in for — but with telemetry off there are no recorded commands to attach, and it says so rather than implying context it does not have. Requires auth. Never paste records, file contents, or credentials. **Prints the id of each frame filed** — a filing nobody can cite cannot be answered about. The ids come from the server, so an instance that only logs the frames prints the count alone; the CLI never mints one of its own, which would hand back a token that resolves to nothing. |
 

package/docs/data_model.md

@@ -79,7 +79,7 @@ row beside it.
 
 ## Say what makes two rows the SAME row
 
-State it as the table's `natural_key` (`model/write-rules`); a text key is also `unique`.
+State it as the table's `natural_key` (`reference/write-rules`); a text key is also `unique`.
 
 Anything that imports, reconciles or de-duplicates has to decide identity, and with no declared key it falls back to
 comparing displayed text — which is how one company arrives three times under three spellings. Name the key: a reference
@@ -93,7 +93,7 @@ table-backed (`records.status.dates`, `records.status.history`, an event table a
 
 When the business reports, filters or prints the moment a row reached a stage (completed on, cancelled on), that
 moment is a `date` field of the row, as `completed_at` and `canceled_at` are in SQL. State it as `records.status.dates`
-(`model/status`): option → date. The record write path stamps it as a row is made at the option or moved into it,
+(`reference/status`): option → date. The record write path stamps it as a row is made at the option or moved into it,
 whoever writes, so no one has to remember; a value the same write states wins, which loads past data as it happened. The
 platform never clears a stamp: each date is when the row last entered the option, and leaving keeps it, and putting a
 change back restamps nothing. A date range is a span, never a moment, so it is refused. It is the one way a status is
@@ -114,7 +114,7 @@ rollup over a formula over a formula is paid three times on every touch, and aga
 
 A field is stated inside its table's document in a `set_tables` call, keyed by alias. Every field `type`, the
 keys each one takes (notation, defaults, options, links, formulas, rollups, lookups, copies) and a worked
-example are in `docs path="model/field"`; this page holds the choices around them.
+example are in `docs path="reference/field"`; this page holds the choices around them.
 
 ### Types and formats
 
@@ -141,12 +141,12 @@ or a `notation` on another type, never a `type`:
 Read the table with `get_table`, which answers its document exactly as `set_tables` takes it, then send `set_tables` with
 the `table_id` and only what changes. The table is edited by an RFC 7396 merge patch of its document, so what the patch
 leaves alone is left alone and `null` deletes the field it names. Every key a table and a field take is in
-`docs path="model/tables"` and `model/field`.
+`docs path="reference/tables"` and `reference/field`.
 
 A table is named by its alias wherever a call names one (`table_id`, a link's `table`, a lookup, `records.history`), and a new table in the call is named by its `ref`, which becomes its alias. The alias is kept while the table exists, archived or not: asking for one an archived table holds is refused, offering to restore that table or to choose another alias. A filter in a table document (a rollup's `filter`, `options_where`, a colour's condition, a check's lookup) takes the record tools' operators and values (`is`, `is_any_of`, `gte`, a plain date as a day). An `autonumber` field takes `next` (`"next": 232`): the number its next row gets, refused below the highest already issued.
 
 - **A list is replaced whole**, so an option cannot be nulled. To rename, recolour, add or remove an option, restate the
-  field's whole `options` list, each option with its alias (`model/field/select`). A rename changes the label and every
+  field's whole `options` list, each option with its alias (`reference/field/select`). A rename changes the label and every
   record keeps its value; an alias left out is removed, which needs `force` while rows hold it.
 - **A number field becomes an `autonumber`** when every row holds its own whole number of 1 or more: the numbers are kept
   and the next row takes the one after the highest (a `next` must be above it). Otherwise the call is refused, saying how

package/docs/design.md

@@ -23,38 +23,38 @@ author: state the ones the job needs. A note refuses nothing.
 
 | The rows are | The treatment | Its props |
 |---|---|---|
-| People or organisations | `records.party`, with a photo or logo as its `image` | `model/records` |
-| Things with a photo, a scan or a paper | `records.image`; List `layout: "cards"` where the picture is how a row is found | `model/records`, `model/cards` |
-| Read by their day | List `layout: "calendar"`; on a record, a child List with `layout: {"agenda": …}` | `model/calendar`, `model/layouts` |
-| Booked on a resource | List `layout: {"lanes": {"by": …}}`, and the table's `no_overlap` | `model/lanes`, `model/write-rules` |
-| A log of what happened | a child List with `layout: "timeline"` | `model/layouts` |
-| Opened to be worked on | the Record's Sections, in the order the work reaches them — `at` where it moves in steps; fields only one kind of row holds (a delay's cause, a safety issue's hours lost) in a Section whose `when` names that kind | `model/section-node` |
-| Rows that each belong to another row | a child List on that row's Record, with `create` and `remove` — and a child's own rows a List in that child List's Record, as deep as the data goes; a List with `same` or `app` where read-only, for rows another app works | `model/list-node` |
-| A related row's value on the list (the newest contract's end date) | a `lookup` field of the table, ordered, as a column | `model/lookup` |
-| Moving through a status | an Act per move, `status.dates` for the moment of each stage, and the register's Readings | `model/act-node`, `model/status`, `model/reading-node` |
-| Counted over a period | the register's Tabs over one `period`; a Tab's `totals` for a child's sums before, during and through it; an open Tab's `where` reads only what was true at the period's end, never a status the row moves on from | `model/tab-node` |
-| Papers a case gathers | a List with `expect`; the papers made, an Act's `templates` | `model/list-node`, `model/act-node` |
-| A plan of spans | List `layout: {"gantt": {"start": …}}` | `model/gantt` |
-| Stood at a place on a plan, flat or in 3D — pallets, bins | List `layout: {"plan": …}`; places state `plan_place` | `model/plan` |
-| Checked item by item against a standard | a List with `checklist: {"photo": …, "clause": …, "failed": […], "passed": …}`: each row a mark (passed at `closed`, failed at a `failed` option, or by the yes/no `passed` names — a measured verdict, no task or status needed), its photo and the clause it is checked against; with `expect` on the standard's items, each item is a line marked the same way and filled by the block's columns | `model/list-node` |
-| A place before and after the work | a List with `compare: {"before": …, "after": …}`: two files fields read side by side, or two value fields read as one struck-then-new column | `model/list-node` |
-| Spots on a drawing | `records.pin: {"on": …, "x": …, "y": …}` on the spots' table: a record listing rows that link to them draws the picture with a numbered pin at each; the picture is the `on` row's `records.image` | `model/record-places-pins-and-cadence` |
-| Photos that must be taken on site | `records.on_site: {"photos": […]}`: a photo taken through the camera keeps where the device stood, and a record holding one taken away says so | `model/record-places-pins-and-cadence` |
-| The real size of the thing (a carton, a piece of furniture, a pallet) | `records.size: {"across": …, "along": …, "up": …}`: three number fields in one length unit, read as one fact "400 × 300 × 250 mm" after the subtitle; a plan register draws each box at that size | `model/record-places-pins-and-cadence`, `model/plan` |
-| A number painted on the thing, or a barcode or QR code on it | `records.scan: "iso6346"` or `"text"` (read off one photo by an agent), or `"code"` (decoded on the device, no agent): the title read on a phone, beside each search matching it | `model/record-places-pins-and-cadence` |
-| Who did what on which day | List `layout: "roster"` with the List of its cells inside | `model/roster` |
-| Someone with no seat signs off one record (a buyer approves a proof, a client signs a handover) | the Record's `Outside`: the Fields and Lists the link shows as they are, and Acts that each move the status out of its `at` — a link a member makes of the record, never a seat | `model/outside-node` |
-| A record whose page is its own arrangement of pieces the app already states | Record `compose` | `model/composed-page` |
-| Steps people drop out of between | a Reading with `steps` on the record whose child rows count them | `model/reading-node` |
-| A record's own numbers nobody keys, read at a glance | consecutive Readings with no `entity` (two to eight tiles) | `model/reading-node` |
-| Rows that are each a place a record is sent | a List with `expect` on the link to those places and `post`: each ticked, the post written there and read as its feed shows it | `model/publish-desk` |
-| Papers an agent reads, where the owner asked for one | an Act's `intake` with `fills` | `model/act-node` |
-| Calls and visits | an Act's `record` | `model/act-node` |
-| A tool on a record that the model cannot draw (a drawing editor, a folded-box preview) | a custom-code app over the same table, opened by an Act's `open` | `model/act-node` |
-| Changes a workflow proposes that a person approves row by row — a price list applied, a statement matched to what is owed | an Act's `workflow` with `review`, its body returning a changeset in `data.review` | `model/act-node` |
-| Documents covering lines | a List with `under` | `model/list-node` |
-| Rows on file a record takes in | a List with `pick` | `model/list-node` |
-| One owner's question across jobs | an App of Tabs and Readings and no register | `model/app-node` |
+| People or organisations | `records.party`, with a photo or logo as its `image` | `reference/records` |
+| Things with a photo, a scan or a paper | `records.image`; List `layout: "cards"` where the picture is how a row is found | `reference/records`, `reference/cards` |
+| Read by their day | List `layout: "calendar"`; on a record, a child List with `layout: {"agenda": …}` | `reference/calendar`, `reference/layouts` |
+| Booked on a resource | List `layout: {"lanes": {"by": …}}`, and the table's `no_overlap` | `reference/lanes`, `reference/write-rules` |
+| A log of what happened | a child List with `layout: "timeline"` | `reference/layouts` |
+| Opened to be worked on | the Record's Sections, in the order the work reaches them — `at` where it moves in steps; fields only one kind of row holds (a delay's cause, a safety issue's hours lost) in a Section whose `when` names that kind | `reference/section-node` |
+| Rows that each belong to another row | a child List on that row's Record, with `create` and `remove` — and a child's own rows a List in that child List's Record, as deep as the data goes; a List with `same` or `app` where read-only, for rows another app works | `reference/list-node` |
+| A related row's value on the list (the newest contract's end date) | a `lookup` field of the table, ordered, as a column | `reference/lookup` |
+| Moving through a status | an Act per move, `status.dates` for the moment of each stage, and the register's Readings | `reference/act-node`, `reference/status`, `reference/reading-node` |
+| Counted over a period | the register's Tabs over one `period`; a Tab's `totals` for a child's sums before, during and through it; an open Tab's `where` reads only what was true at the period's end, never a status the row moves on from | `reference/tab-node` |
+| Papers a case gathers | a List with `expect`; the papers made, an Act's `templates` | `reference/list-node`, `reference/act-node` |
+| A plan of spans | List `layout: {"gantt": {"start": …}}` | `reference/gantt` |
+| Stood at a place on a plan, flat or in 3D — pallets, bins | List `layout: {"plan": …}`; places state `plan_place` | `reference/plan` |
+| Checked item by item against a standard | a List with `checklist: {"photo": …, "clause": …, "failed": […], "passed": …}`: each row a mark (passed at `closed`, failed at a `failed` option, or by the yes/no `passed` names — a measured verdict, no task or status needed), its photo and the clause it is checked against; with `expect` on the standard's items, each item is a line marked the same way and filled by the block's columns | `reference/list-node` |
+| A place before and after the work | a List with `compare: {"before": …, "after": …}`: two files fields read side by side, or two value fields read as one struck-then-new column | `reference/list-node` |
+| Spots on a drawing | `records.pin: {"on": …, "x": …, "y": …}` on the spots' table: a record listing rows that link to them draws the picture with a numbered pin at each; the picture is the `on` row's `records.image` | `reference/record-places-pins-and-cadence` |
+| Photos that must be taken on site | `records.on_site: {"photos": […]}`: a photo taken through the camera keeps where the device stood, and a record holding one taken away says so | `reference/record-places-pins-and-cadence` |
+| The real size of the thing (a carton, a piece of furniture, a pallet) | `records.size: {"across": …, "along": …, "up": …}`: three number fields in one length unit, read as one fact "400 × 300 × 250 mm" after the subtitle; a plan register draws each box at that size | `reference/record-places-pins-and-cadence`, `reference/plan` |
+| A number painted on the thing, or a barcode or QR code on it | `records.scan: "iso6346"` or `"text"` (read off one photo by an agent), or `"code"` (decoded on the device, no agent): the title read on a phone, beside each search matching it | `reference/record-places-pins-and-cadence` |
+| Who did what on which day | List `layout: "roster"` with the List of its cells inside | `reference/roster` |
+| Someone with no seat signs off one record (a buyer approves a proof, a client signs a handover) | the Record's `Outside`: the Fields and Lists the link shows as they are, and Acts that each move the status out of its `at` — a link a member makes of the record, never a seat | `reference/outside-node` |
+| A record whose page is its own arrangement of pieces the app already states | Record `compose` | `reference/composed-page` |
+| Steps people drop out of between | a Reading with `steps` on the record whose child rows count them | `reference/reading-node` |
+| A record's own numbers nobody keys, read at a glance | consecutive Readings with no `entity` (two to eight tiles) | `reference/reading-node` |
+| Rows that are each a place a record is sent | a List with `expect` on the link to those places and `post`: each ticked, the post written there and read as its feed shows it | `reference/publish-desk` |
+| Papers an agent reads, where the owner asked for one | an Act's `intake` with `fills` | `reference/act-node` |
+| Calls and visits | an Act's `record` | `reference/act-node` |
+| A tool on a record that the model cannot draw (a drawing editor, a folded-box preview) | a custom-code app over the same table, opened by an Act's `open` | `reference/act-node` |
+| Changes a workflow proposes that a person approves row by row — a price list applied, a statement matched to what is owed | an Act's `workflow` with `review`, its body returning a changeset in `data.review` | `reference/act-node` |
+| Documents covering lines | a List with `under` | `reference/list-node` |
+| Rows on file a record takes in | a List with `pick` | `reference/list-node` |
+| One owner's question across jobs | an App of Tabs and Readings and no register | `reference/app-node` |
 
 ### Faces and pictures
 

package/docs/document_templates.md

@@ -101,7 +101,7 @@ the `set_template` description for the reference; here is the capability:
 - **Conditional sections** — a block shown only when a condition holds (a "paid" stamp, an
   optional notes block). Excel/HTML/email use `{{#if}}…{{else}}…{{/if}}`; Word uses `{{IF name}}…{{END-IF name}}`.
 
-The `html` and `email` types print a raw value through a helper in the template's `locale` (`vi` or `en`; none prints in the organization's language): `{{money total "VND"}}`, `{{number qty}}`, `{{date issued_on}}`, `{{words total "USD"}}` (`model/groups-and-templates` lists what each prints). `{{date (add_days issued_on -1)}}` prints the day before, `add_days` shifting a date by whole days. A value a helper cannot read fails the render.
+The `html` and `email` types print a raw value through a helper in the template's `locale` (`vi` or `en`; none prints in the organization's language): `{{money total "VND"}}`, `{{number qty}}`, `{{date issued_on}}`, `{{words total "USD"}}` (`reference/groups-and-templates` lists what each prints). `{{date (add_days issued_on -1)}}` prints the day before, `add_days` shifting a date by whole days. A value a helper cannot read fails the render.
 
 A field can also print as a **QR code** or a **Code 128 barcode** (a picture a phone's camera or a scanner reads back): `{{qr link}}` or `{{code128 position 6}}` in html (never email: mail clients do not show the picture, and a save refuses it), `{{position | qr}}` or `{{position | code128:6}}` as a whole Excel cell (its row grows to the picture), `{{IMAGE qr(position)}}` or `{{IMAGE code128(position, 6)}}` in Word. The optional number is the picture's width in centimetres. Without it the width follows the value's length — each module prints 0.5 mm in a QR code and 0.33 mm in a barcode, so a longer value prints wider; a width that would shrink a module below what a scanner reads (0.3 mm, 0.19 mm) is refused, naming the least width that scans. An empty field draws nothing.
 
@@ -179,8 +179,8 @@ figure adds it, any other cell (blank, an errored formula, a lookup's list) adds
 reader (`"me"`) is refused, and so is a name a rows List and a `list` List both reach: give the `list` a `key`. A record
 bound narrows what is listed and is never an access bound; the table's row rules are.
 
-A paper over many rows (a client's month, a statement) is that: a record of the period whose List is windowed by its dates, made by the Act's `template`; or a List `Export` with `template` and `per` (`model/export-node`).
-`model/groups-and-templates` has the rest.
+A paper over many rows (a client's month, a statement) is that: a record of the period whose List is windowed by its dates, made by the Act's `template`; or a List `Export` with `template` and `per` (`reference/export-node`).
+`reference/groups-and-templates` has the rest.
 
 ## Discovering and managing templates
 

package/docs/examples.md

@@ -16,7 +16,7 @@ among them: the `design` reference. Every key: the `model` reference, at the pag
 
 **Read.** `layout: "calendar"` on the List; each visit stands over its span because its `records` line holds two dates (`scheduled_for`, `ends_at`).
 
-**Keys.** `model/calendar`
+**Keys.** `reference/calendar`
 
 **Not when.** Rows booked on a resource that two may not share at once — that is `lanes`. Rows with a date nobody plans by (an invoice's date) stay a table.
 
@@ -184,7 +184,7 @@ among them: the `design` reference. Every key: the `model` reference, at the pag
 
 **Read.** `layout` `lanes` with `by` naming the one-row link to the resource (the engineer); every engineer stands as a lane, empty or not.
 
-**Keys.** `model/lanes`
+**Keys.** `reference/lanes`
 
 **Not when.** The resource is not a row of the model (a free-text room name), or rows never compete for one — a `calendar` reads them by day.
 
@@ -334,7 +334,7 @@ among them: the `design` reference. Every key: the `model` reference, at the pag
 
 **Read.** `layout` `gantt` with its `start`; with no end stated, the bar ends at the entity's first `due`. The day a hire comes back (`ngay_tra`) is stamped by the status's `dates`, so no act sets it.
 
-**Keys.** `model/gantt`
+**Keys.** `reference/gantt`
 
 **Not when.** Rows that last a day or less (a visit, a shift) — `calendar` or `lanes`; a plan with no dates set yet.
 
@@ -452,7 +452,7 @@ among them: the `design` reference. Every key: the `model` reference, at the pag
 
 **Read.** `layout: "roster"` over the people; the child List (`lich_truc`) is the rows that fill the days — one link back and a date on its line.
 
-**Keys.** `model/roster`
+**Keys.** `reference/roster`
 
 **Not when.** Rows that are themselves the bookings (a stay over several days) — a `calendar` or `lanes` draws them; a roster's row is what the days are filled for.
 
@@ -531,7 +531,7 @@ among them: the `design` reference. Every key: the `model` reference, at the pag
 
 **Read.** `layout: "cards"` over rows whose `records.image` is a photo; `scope` keeps the app inside one warehouse at a time.
 
-**Keys.** `model/cards`, `model/records`, `model/app-node`
+**Keys.** `reference/cards`, `reference/records`, `reference/app-node`
 
 **Not when.** Rows with no picture — cards of words are a table drawn worse.
 
@@ -684,7 +684,7 @@ among them: the `design` reference. Every key: the `model` reference, at the pag
 
 **Read.** `records.customer.party: "organization"` and its `image` (the logo); a List with `layout: "timeline"` for the touches, a Reading `by` the day placed for its orders, and its papers `expect`ed by kind.
 
-**Keys.** `model/records`, `model/layouts`, `model/list-node`, `model/reading-node`
+**Keys.** `reference/records`, `reference/layouts`, `reference/list-node`, `reference/reading-node`
 
 **Not when.** A list of customers is not a job by itself: the customer is a link on the desk whose rows name it, unless the job is the account itself.
 
@@ -1047,7 +1047,7 @@ among them: the `design` reference. Every key: the `model` reference, at the pag
 
 **Read.** Lists with `expect` for the papers brought (one line per kind, the missing ones empty), an Act's `templates` for the forms made (ticked and made at once, kept in `into`), and `intake` reading the papers brought.
 
-**Keys.** `model/list-node`, `model/act-node`
+**Keys.** `reference/list-node`, `reference/act-node`
 
 **Not when.** A record that needs no papers, or one paper made once — a single `template` act.
 
@@ -1434,7 +1434,7 @@ among them: the `design` reference. Every key: the `model` reference, at the pag
 
 **Read.** An Act's `record` (into the `timeline` child: audio, transcript, when and who) and `fills` (the touch's fields an agent fills from the transcript).
 
-**Keys.** `model/act-node`, `model/layouts`
+**Keys.** `reference/act-node`, `reference/layouts`
 
 **Not when.** Calls made and logged elsewhere — a `timeline` with its own add keeps the note.
 
@@ -1801,7 +1801,7 @@ among them: the `design` reference. Every key: the `model` reference, at the pag
 
 **Read.** `records.de_nghi.status` with its `history` (each move: when and who), Sections staged by `at`, and the List's Readings leading with the headline number. The history stays because the business reads who signed each move; where only the day a stage was reached matters, the status stamps a date on the row instead (the Gantt above).
 
-**Keys.** `model/status`, `model/section-node`, `model/reading-node`
+**Keys.** `reference/status`, `reference/section-node`, `reference/reading-node`
 
 **Not when.** Rows that never move — a reference list (a price list, a catalog) has no status and no headline number.
 
@@ -1988,7 +1988,7 @@ among them: the `design` reference. Every key: the `model` reference, at the pag
 
 **Read.** An App of Readings and no List: Readings with `over` (the period windows them), a Reading `by` the day, Readings `by` a field, and a List of rows to act on that opens in its `app`.
 
-**Keys.** `model/app-node`, `model/reading-node`
+**Keys.** `reference/app-node`, `reference/reading-node`
 
 **Not when.** One job's headline numbers — those lead that job's List as its Readings.
 

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. 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.
+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 (`reference/write-rules`): a refusal lists every broken rule at once, and a locked record answers under `blocked` in `update_records`' result.
 
 ## Values by type
 

package/docs/first_build.md

@@ -64,7 +64,7 @@ One call, linked tables together; a call names a table by its alias, a new table
 }
 ```
 
-`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`.
+`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 `reference/tables`.
 
 ## 2. The paper: `set_template`
 
@@ -86,18 +86,18 @@ Every paper the owner sends is made, one template each. A slot is named after a
 
 | 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` |
+| People or organisations | `records.party`, photo or logo as `image` | `reference/records` |
+| Photos people look at | `records.image`; List `layout: "cards"` | `reference/cards` |
+| Held on a day people schedule by | List `layout: "calendar"` | `reference/calendar` |
+| Booked on a resource over time | List `layout: {"lanes": {"by": …}}`, table `no_overlap` | `reference/lanes` |
+| Standing at places on a floor or yard | List `layout: {"plan": …}` | `reference/plan` |
+| People across days | List `layout: "roster"`, the cells' List inside | `reference/roster` |
+| Expected against counted, before against after | a List with `compare: {"before": …, "after": …}` | `reference/list-node` |
+| Ranked by a figure | List `sort: {"field": …, "desc": true}` | `reference/list-node` |
+| Moved through a status (stages) | an Act per move, `status.dates`, Readings | `reference/act-node` |
+| Each belonging to another row | a child List on its Record | `reference/list-node` |
+| Counted over a period | Tabs over one `period`; Readings | `reference/tab-node` |
+| Papers a case gathers | a List with `expect`; an Act's `template` | `reference/list-node` |
 
 Any other screen: `design/treatments`.
 
@@ -129,19 +129,19 @@ Here one app, the counter's job, naming the tables and the template by the alias
 }
 ```
 
-`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):
+`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 (`reference/<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.
+- `list.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.
+- `list.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.
+- `list.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).
+- `app.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.
 

package/docs/getting_started.md

@@ -5,7 +5,7 @@ A workspace is where one business keeps what it knows and does its daily work. *
 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`).
+- **Change an app:** `docs path="reference/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`.

package/docs/migration.md

@@ -29,7 +29,7 @@ roles are the workspace's own.
 | `@lotics/xlsx` / `@lotics/docx` to build a template's file | any `.xlsx` / `.docx` library, then `lotics upload` (`lotics docs document_templates`) |
 | `lotics file preview` | `lotics file download <fil_id>`, then open it |
 | `lotics library list` / `library show <slug>`, `lotics preset list` / `preset show <slug>` | the example files at `https://lotics.ai/presets/index.json`, each read and its tables passed to `set_tables` |
-| `lotics library init <apg_id>`, `lotics app upgrade`, `lotics library fixtures` | nothing copies a package any more: state the tables (`lotics docs model`) and pass them to `set_tables` |
+| `lotics library init <apg_id>`, `lotics app upgrade`, `lotics library fixtures` | nothing copies a package any more: state the tables (`lotics docs reference`) and pass them to `set_tables` |
 
 `lotics tools` lists every tool, and `lotics tools <name>` prints its input.
 

package/docs/workflows.md

@@ -449,8 +449,8 @@ holding many rows: one holding a single row would make the line that plant's own
 lines belong to is not moved to the trash.
 
 These tables are shown beside the plants, in the same app: the sheets as a log of the plants' register
-(a further List at the root, `model/app-node`), a sheet's lines on the page it opens. A line keeping what a cell held
-and what it holds now in two fields reads one against the other (`compare`, `model/list-node`).
+(a further List at the root, `reference/app-node`), a sheet's lines on the page it opens. A line keeping what a cell held
+and what it holds now in two fields reads one against the other (`compare`, `reference/list-node`).
 
 ```
 const sheet = await excel_get_rows({ // a workflow step

package/docs/working_in_a_workspace.md

@@ -33,7 +33,7 @@ and says why (`agent_surface` § A refusal).
 
 `create_records` takes 50 records a call, 20 or more of one shape in columnar form (`field_keys` once, then `rows`);
 `update_records` changes one or many. Both name fields and select options by alias, and `field_values` gives each
-type's value. Every write meets the table's rules (`model/write-rules`): every broken rule is listed at once, and a
+type's value. Every write meets the table's rules (`reference/write-rules`): every broken rule is listed at once, and a
 locked record answers under `blocked`. The owner's own lists (a menu with prices, customers, open orders) are rows of their
 tables, loaded this way after `set_tables`.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lotics/cli",
-  "version": "0.316.14",
+  "version": "0.316.16",
   "description": "Lotics SDK and CLI for AI agents",
   "type": "module",
   "bin": {