@lotics/cli 0.238.1 → 0.240.0

package/AGENTS.md

@@ -8,7 +8,7 @@ conventions are, and where the traps are.
 | `lotics --help` | The verb inventory (§ COMMANDS) and global flags. The verb LIST is generated and never stale; the prose beside each verb is hand-written, so where it disagrees with `docs/cli_reference.md`, the reference wins. |
 | `lotics tools` · `lotics tools <name>` | The agent tool registry and one tool's full JSON Schema. |
 | `lotics docs` · `lotics docs <area>[/<section>]` | Every reference the packages installed beside the project actually ship — `@lotics/app-runtime`, `@lotics/ui` and the document engines each carry their own, and this index only covers THIS package. Discovered by looking, not by a list, so it reports the installed VERSION of each: a doc always describes the code that is really there. Capped at a page: a doc that does not fit hands back its opening and the addresses into it, so the next call is smaller than the last. |
-| `lotics scaffold docs` | How to write a `model.json` — the file a workspace is built from. Two forms: `{"from": "<preset-slug>", "variants", "rename", "entities", "rows", "apply"}`, which names a preset by slug and carries only what this business differs by, and the full one, spelled out, for when no preset is the trade: every top-level key, every field type with the config it needs, the row format, the rules, and a worked example. Offline, and not part of `lotics docs`. It also covers the `apply` list — published packages copied in after the model's own tables, each with an optional `bind` onto them — and the `preset` block a published model carries. `lotics scaffold check` then proves the file — offline, except for the one read a `from` file's preset needs — including every branch of a preset merged onto its base; `lotics setup` applies it and refuses a table name the workspace already has, `lotics scaffold apply` adopts that table and adds what is missing, and the WORKSPACE remembers what each alias became, so every later run binds by id and a relabel on either side is a rename it reports rather than a second table it adds. `lotics scaffold export` goes the other way — a workspace printed as one of these files, to edit into another business's model; a starting point, never a source of truth. |
+| `lotics docs model` · `lotics docs model/<section>` | How to write a `model.json` — the file a workspace is built from, and the apps planned over it. Carried inside this CLI at its own version, since it describes this CLI's plan checker, and paged like every doc: the first page is the working order and the section addresses. Two forms: `{"from": "<preset-slug>", "variants", "rename", "entities", "rows", "apply"}`, which names a preset by slug and carries only what this business differs by, and the full one, spelled out, for when no preset is the trade: every top-level key, every field type with the config it needs, the row format, the rules, and a worked example. Offline. It also covers the `apply` list — published packages copied in after the model's own tables, each with an optional `bind` onto them — and the `preset` block a published model carries. `lotics scaffold check` then proves the file — offline, except for the one read a `from` file's preset needs — including every branch of a preset merged onto its base; `lotics setup` applies it and refuses a table name the workspace already has, `lotics scaffold apply` adopts that table and adds what is missing, and the WORKSPACE remembers what each alias became, so every later run binds by id and a relabel on either side is a rename it reports rather than a second table it adds. `lotics scaffold export` goes the other way — a workspace printed as one of these files, to edit into another business's model; a starting point, never a source of truth. |
 | [docs/building_an_app.md](./docs/building_an_app.md) | The SEQUENCE — scaffold, model, types, queries, workflows, screens, ship — and the deploy-free inner loop. The other references describe contracts; this one is the order they go in and why. Read it once before starting an app. |
 | [docs/clauses.md](./docs/clauses.md) | Every clause a plan's app or screen can state, what it draws, and a plan fragment stating it — generated from the schema, so it lists no clause the schema lacks and misses none it has. |
 | [docs/cli_reference.md](./docs/cli_reference.md) | Per-command contracts, flags, exit codes, and gotchas — the detail `--help` compresses. Read it before hand-building a `set_app_*` payload: several tools REPLACE rather than patch, and a CLI verb already owns the safe assembly. |

package/README.md

@@ -86,7 +86,7 @@ restating it:
 No preset is your trade? Write the full form instead, spelling the tables out. Either way:
 
 ```bash
-lotics scaffold docs                 # how to write one, both forms, with a worked example. Offline
+lotics docs model                    # how to write one, both forms, with a worked example. Offline
 lotics scaffold check model.json     # prove it — every problem at once, offline unless it names a preset
 lotics setup model.json --email you@company.com
 ```
@@ -437,10 +437,10 @@ lotics run run_app_workflow '{...}' --cleanup   # also deletes created records (
 # edit the body, then push it back through set_app_workflow — the server verifies it
 # (a deploy calls the same verb for every alias the project holds ahead of the app, so
 # this is the one-alias spelling of it). `app workflow check` runs the server's own
-# JS-subset parser + type-check locally, so a body that passes is one `set` will accept
-# (`set` still adds name resolution + lint + structural checks, which need the workspace):
+# JS-subset parser + type-check locally, then asks the server for every check `set`
+# makes (`verify_only`, nothing written), so a body that passes is one `set` will accept:
 lotics app workflow pull                    # rewrite src/workflows/*.ts + globals from the server
-lotics app workflow check                   # parse + typecheck every body locally ([alias...] for some)
+lotics app workflow check                   # every check `set` makes, writing nothing ([alias...] for some)
 lotics app workflow diff issueInvoice       # how the local body differs from the one the server runs
 lotics app workflow set issueInvoice        # push the edited src/workflows/issueInvoice.ts