@lotics/cli 0.299.0 → 0.301.0

package/AGENTS.md

@@ -11,7 +11,7 @@ conventions are, and where the traps are.
 | `lotics docs model` · `lotics docs model/<section>` | How to write a `model.json` — the file a workspace is built from: its tables, how a row of each is recognised (`records`), and the apps stated over them. Every top-level key, every field type with the config it needs, the row format, the rules, and a worked example; complete example models of several trades are listed at `https://lotics.ai/presets/index.json`. `lotics model apply` checks the file (every problem in one run), applies its tables and mints a version of each app; the WORKSPACE remembers what each alias became, so every later apply binds by id and a relabel on either side is a rename it reports rather than a second table it adds. `lotics model pull` goes the other way — the workspace's model, rebuilt from what owns each part. |
 | `lotics docs design` · `lotics docs design/<section>` | Designing an app — where an app starts: the method, the treatment each kind of row takes with the `model` page stating its keys, the visual bar, and looking at what an apply built. A finding of the apply names its section. |
 | `lotics docs examples` · `lotics docs examples/<treatment>` | Each treatment worked through in an app of a complete model: the job, the keys to read, where it is the wrong one, and the excerpt. |
-| [docs/building_an_app.md](./docs/building_an_app.md) | The SEQUENCE — clarify, model, apply or build, prove, look — for an app stated in a model and for a custom-code app. Read it once before starting an app. Looking is `lotics run screenshot_app`, then `lotics download` for each PNG. |
+| [docs/building_an_app.md](./docs/building_an_app.md) | The SEQUENCE — clarify, model, apply or build, prove, look — for an app stated in a model and for a custom-code app. Read it once before starting an app. Looking is `lotics run screenshot_app '<json>' -o <dir>`, which saves each PNG and its text snapshot there. |
 | [docs/cli_reference.md](./docs/cli_reference.md) | Per-command contracts, flags, exit codes, and gotchas — the detail `--help` compresses. |
 | [docs/data_model.md](./docs/data_model.md) | Tables, their fields, and how they relate — one fact per column, one entity per table and the NAME-OVERLAP probe that says when a split has broken, one vocabulary wherever values are copied, a copy boundary that accounts for every source field, provenance as a link, a declared natural key, history as rows, and why derived DEPTH costs more than row count; then every field type, its properties, computed fields, and what `update_fields` takes. Separate from building_an_app because every workspace starts with tables and many never get an app. |
 | [docs/filters.md](./docs/filters.md) | The one filter grammar every filter-taking tool, view and rollup reads — conditions, groups, and the operators per field type. |
@@ -30,8 +30,8 @@ conventions are, and where the traps are.
 - **Tools** (`lotics tools`, `lotics run <tool>`) — the *agent tool registry*: what an agent, workflow,
   or automation may call. Workspace data, templates, knowledge, admin.
 - **Commands** (`lotics --help` § COMMANDS) — the CLI's *own verbs*: auth and org/workspace scoping,
-  file upload and download, and the five that touch a local file for an app — `model apply`,
-  `model pull`, `app create --custom`, `app pull` and `app deploy`.
+  file upload and download, and those that touch a local file for an app — `model apply`,
+  `model check`, `model pull`, `app create --custom`, `app pull` and `app deploy`.
 
 Several capabilities exist **only** as commands and appear nowhere in `lotics tools` — downloading a
 file is the one most often mistaken for missing. Concluding "the platform can't do X" from the tool