@lotics/cli 0.316.20 → 0.316.22

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/AGENTS.md CHANGED
@@ -8,7 +8,7 @@ conventions are, and where the traps are.
8
8
  | `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. |
9
9
  | `lotics tools` · `lotics tools <name>` | The agent tool registry and one tool's full JSON Schema. |
10
10
  | `lotics docs` · `lotics docs <area>[/<section>]` · `lotics docs [<area>] --grep <text>` | This CLI's references, carried inside it so each describes the binary answering. 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. A page the copy lacks — one the server added since this binary was built, which a refusal can cite — is read from the server's `docs` tool with this machine's credential, and so is every `--grep`, over the references the server serves. A custom-code app's SDK reference is `node_modules/@lotics/app-sdk/AGENTS.md` inside the app. |
11
- | `lotics docs reference` · `lotics docs reference/<section>` | The keys of a table document and the components of an app tree: a table's fields keyed by alias, how a row of each table is recognised (`records`), and the apps stated over them. Every key, every field type with the config it needs, the rules, and a worked example; example files of several trades are listed at `https://lotics.ai/presets/index.json` — read one and pass its tables to `set_tables`. |
11
+ | `lotics docs reference` · `lotics docs reference/<section>` | The keys of a table document and the components of an app tree: a table's fields keyed by alias, how a row of each table is recognised (`records`), and the apps stated over them. Every key, every field type with the config it needs, the rules, and a worked example. |
12
12
  | `lotics docs design` · `lotics docs design/<section>` | Designing an app — the treatment each kind of row takes with the `model` page stating its keys, the visual bar, and looking at what a write built. Opens on the common treatments; a finding names its section. |
13
13
  | `lotics docs examples` · `lotics docs examples/<treatment>` | Each treatment worked through in an app of a complete workspace: the job, the props to read, where it is the wrong one, and the excerpt. |
14
14
  | [docs/getting_started.md](./docs/getting_started.md) | What a workspace holds, and the one page to open for each job: building a workspace, changing an app, a rule on a table, a document, data and questions, a connected service, sharing. The first page an agent outside the product reads. |
@@ -95,7 +95,7 @@ something exists, read `lotics --help` § COMMANDS — the whole section, not a
95
95
  agent-readable summary to the full structured object.
96
96
  - **Every tool is invoked one way — `lotics run <tool>`.** Including the ones that RUN something
97
97
  (`run_app_workflow`, `run_app_query`) and every one that builds
98
- (`set_tables`, `set_app`, `set_app_queries`, `set_app_workflow`). A command
98
+ (`set_tables`, `set_app`, `set_app_queries`, `set_workflow`). A command
99
99
  exists only for work that touches a local file.
100
100
  - **Building is two tools, each a writer that creates without an id and edits with one.** `set_tables`
101
101
  takes `{ "tables": [...] }` — always a list, one or many, all or nothing — each table a document keyed
@@ -107,10 +107,9 @@ something exists, read `lotics --help` § COMMANDS — the whole section, not a
107
107
  to change a node, refused with `base_version_id` when the app has moved past the version you read. `dry_run` checks
108
108
  without writing, a refusal lists everything wrong in the call, and every answer states the permissions the write
109
109
  granted and removed. The answer notes the treatments an author leaves unstated; nothing is written into the tree for them. A new workspace: one `set_tables` call with
110
- the tables, then every `set_app` call, then fixes. The example files under `https://lotics.ai/presets/index.json` are read and their tables passed to
111
- `set_tables`.
110
+ the tables, then every `set_app` call, then fixes.
112
111
  - **Every change to an app mints a version of it, and applying the earlier tree again is the undo.** An apply, a
113
- deploy, a single `set_app_*` or `remove_app_binding`: each is a new version. Applying the earlier tree again restores the app — never a table change or a row a workflow wrote,
112
+ deploy, a single `set_app_*`: each is a new version. Applying the earlier tree again restores the app — never a table change or a row a workflow wrote,
114
113
  so try a write on a throwaway record.
115
114
  - **Exit codes are assertable, and they report the WORK rather than the call.** `lotics run` exits
116
115
  non-zero when a `run_app_workflow` result's own envelope carries a failed
package/README.md CHANGED
@@ -69,10 +69,7 @@ both tables. A table is edited by an RFC 7396 merge patch of its document, where
69
69
  given no id and edit when given one, and `dry_run` checks without writing. Every answer states the permissions the
70
70
  write granted and removed.
71
71
 
72
- A new workspace: one `set_tables` call with the tables (at most 50, 200 first rows each, a call), then every `set_app` call, then fixes. Example
73
- files of several trades are listed at `https://lotics.ai/presets/index.json` (each at
74
- `https://lotics.ai/presets/<slug>.json`) — read the closest one, write your own in your business's
75
- words, and pass its tables to `set_tables`.
72
+ A new workspace: one `set_tables` call with the tables (at most 50, 200 first rows each, a call), then every `set_app` call, then fixes.
76
73
 
77
74
  ```bash
78
75
  lotics docs reference # the keys, with a worked example
@@ -203,7 +200,7 @@ Unset, nothing is stored, nothing is sent, and no spool file is created.
203
200
  ### Reporting a problem
204
201
 
205
202
  ```bash
206
- lotics report '{"goal":"rename a view","actual":"no command does it","wanted":"lotics run update_view"}'
203
+ lotics report '{"goal":"rename a view","actual":"no command does it","wanted":"lotics run set_tables"}'
207
204
  lotics report @report.json # a long one, from a file
208
205
  cat report.json | lotics report - # or from stdin — `-` is required, see below
209
206
  lotics report # the frame, and what is worth reporting
@@ -280,7 +277,6 @@ lotics download <file_id> -o ./reports/
280
277
 
281
278
  # What is in the store, newest first — one page, with the command for the next one
282
279
  lotics file list --limit 50
283
- lotics file delete <file_id> # refused while anything still references it
284
280
 
285
281
  # CI / non-interactive (key inline)
286
282
  LOTICS_API_KEY=ltk_... lotics run get_workspace '{}'
@@ -318,7 +314,7 @@ lotics app pull # in the project: bring it up to the
318
314
 
319
315
  # What the app reads and writes is bound on the app, and each change mints a version:
320
316
  lotics run set_app_queries '{"app_id":"app_...","queries":{"openInvoices":{...}}}'
321
- lotics run set_app_workflow '{"app_id":"app_...","alias":"issueInvoice","source":"..."}'
317
+ lotics run set_workflow '{"source":"on({ type: \"app\", app_id: \"app_...\", alias: \"issueInvoice\" });\n..."}'
322
318
 
323
319
  # Running an app's alias is a TOOL call, like every other tool. Exits non-zero
324
320
  # when the RUN failed, not only when the call did.