@lotics/cli 0.311.0 → 0.311.1

package/docs/agent_surface.md

@@ -182,9 +182,9 @@ An act that states `review` runs a workflow that only proposes: call it with the
 writing nothing, the changeset its body proposes in `data.review` — `table_id`, `creates` (each with its `key`) and
 `updates` (each with its `record_id`), each row's `data` holding only the fields that change, by field key, with an
 optional `note` and `ticked` (`false` where the body leaves it for a person to choose), and `unplaced`, what was read
-and matched nothing. Call it again with the same inputs and `approved`,
-`{ "updates": [{ "record_id", "sha" }], "creates": [{ "key", "sha" }] }` — `sha` the SHA-256, in hex, of the row's `data`
-as canonical JSON (every object's keys sorted) as it was read — and the platform writes those rows as that second call
+and matched nothing; the platform adds a `sha` to every row. Call it again with the same inputs and `approved`,
+`{ "updates": [{ "record_id", "sha" }], "creates": [{ "key", "sha" }] }`, listing the rows to write with the `sha` each
+carries in the proposal, copied as it came — never computed — and the platform writes those rows as that second call
 proposes them, each only where it proposes the values read:
 
 ```

package/docs/design.md

@@ -47,7 +47,10 @@ rows in time, a template's act — until the model states it or declines it.
    in — and beside each the query or workflow of the app that answers it (`agent_surface`). What the screen
    reads and does is generated. An ask no screen makes is declared: a read in `queries` (`model/queries`),
    a write in `workflows` (`model/workflows`). A figure an agent calls states its `alias`. An ask with
-   nothing to answer it is a gap in the model, closed before the apply.
+   nothing to answer it is a gap in the model, closed before the apply. An app is built to be run by an agent:
+   every flow a person works can be driven end to end through its workflows, the person is asked only where
+   their judgement or authority is needed, and the screens show what was done and let a person do or put back
+   any step by hand.
 6. **A treatment for every list and every entity** — the next section. Choose it from what the rows ARE,
    before writing any register.
 7. **Plan, apply, look.** The `check_model` tool (`lotics model check` on the CLI) checks the

package/docs/workflows.md

@@ -517,9 +517,10 @@ proposes: its body calls steps that read and no other, and runs no agent — eit
 and returns in `data.review` one changeset of the act's table, which the platform writes the approved rows of. Called
 with what the act asks, it answers the proposal and nothing is written; called again with
 `approved: { updates: [{ record_id, sha }], creates: [{ key, sha }] }`, the body runs again and the platform writes
-those rows as this second run proposes them, so the body never reads `approved`. `sha` is the SHA-256, in hex, of the
-row's `data` as canonical JSON (every object's keys sorted) as the caller read it: a row the second run proposes with
-other values is left unwritten (`changed`), so the body must propose the same for the same inputs and the rows it reads.
+those rows as this second run proposes them, so the body never reads `approved`. The platform adds a `sha` to every row
+of the proposal it answers — the body states none, and one it states is dropped — and the caller echoes the `sha` of
+each row it approves. A row the second run proposes with other values than the `sha` was read from is left unwritten
+(`changed`), so the body must propose the same for the same inputs and the rows it reads.
 An update is of a record the act is run over (`record_id`, or one of `record_ids`): one of any other record is left
 unwritten. An act over every row in view is handed no rows: its body reads the rows it may change, and any of them may
 be proposed. A create carries a `key`, a text of the body's own that names the same line on every run

package/package.json

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