@lotics/cli 0.311.0 → 0.311.2

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
@@ -216,6 +219,16 @@ other, so the second's bars are read over its own first step: they draw on one g
 edge and every value ending at another, each under its own label. A step no row holds a number in reads as not measured, so leave a count empty
 rather than typing a zero nobody measured.
 
+#### Priced lines
+
+A quote's items, an estimate's works, a repair sheet's damages are lines priced off a book: an entity whose
+`records` names each item, puts the code people type on its line and its price as its `figure`. The line links to
+it, asks the link and its quantities in its block's `create`, and copies the price (`default_from`), so the quote
+keeps what was quoted when the book moves. A line's amount is a formula, the record's total a rollup over the rows
+the block shows — what is not paid for is a second rollup, never a filter on the first, so each group subtotals.
+Group the lines by the parts the record is quoted in (a container, a room, a leg), a field the line asks. The book
+is its keeper's desk, an app of its own.
+
 ### The record
 
 #### Sections

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.2",
   "description": "Lotics SDK and CLI for AI agents",
   "type": "module",
   "bin": {