@lotics/cli 0.316.27 → 0.317.0

package/docs/agent_surface.md

@@ -11,9 +11,9 @@ reach them, over MCP and as `lotics run <tool>`:
 | `run_app_workflow` | One write — or several in order — or a dry run of it that writes nothing |
 
 An app generates this surface from its tree; Query and Workflow nodes declare what the screen never
-asks (§ Declaring more). An app's logs (its further Lists at the root, which a change may add at any time) are part of it: a log's list, its rows by id, its record's
-Lists and its Acts are queries and workflows of the same app, named by the log's table as the register's
-are by its own — `get_app` lists them in the one roster, and nothing of a log is another app's. What only a log reads or runs answers the organization's own members alone, never a caller through the app's public link. A custom-code app's surface is the queries and workflows bound on it
+asks (§ Declaring more). An app's further root Lists (which a change may add at any time) are part of it: such a List's list, its rows by id, its page's
+Lists and its Acts are queries and workflows of the same app, named by that List's table as the register's
+are by its own — `get_app` lists them in the one roster, and nothing of a further List is another app's. What only a further List reads or runs answers the organization's own members alone, never a caller through the app's public link. A custom-code app's surface is the queries and workflows bound on it
 (`app_bindings`).
 
 ## Finding what an app offers
@@ -82,6 +82,8 @@ the screen already holds.
 | `<entity>_count_by_<scope>` | How many <entity> rows each <scope entity> holds. |  | an app stating `scope` |
 | `<task>_progress_by_<link>` | How many <task> rows each <entity> row handed in holds, at each status. | `<entity>_ids` | rows whose task rows are counted done |
 | `<rows>_measured_by_<link>` | The share of each <entity> row handed in its <rows> rows add, day by day. | `<entity>_ids` | a Progress node stating `measured` |
+| `<entity>_sub_counts_by_<link>` | How many <entity> rows stand under each <entity> row handed in, through <link>, at each status. | `<entity>_ids` | a record's rows block over a hierarchy (`nests`), for the rows it draws |
+| `<entity>_plan_places` | Every <place> the <entity> rows stand at, with what the plan draws of each. |  | a register laid out as a `plan`: the places its rows stand at |
 | `<lane>_lanes` | The <lane> rows of one <scope entity>, each a lane of the board. | `<scope entity>_id` | a lanes board inside an app stating `scope` |
 | `<entity>_same_<link>` | The <entity> rows naming one "<link>". | `same`; `before` where its line reads rows before a moment | a statement line that carries rows (`parts`) |
 

package/docs/building_an_app.md

@@ -18,7 +18,7 @@ you tried it, stay where they are. Try a write on a throwaway record.
 
 - **An app stated as a tree** — the default, and the right one for almost every job. The tree (a
   JSON file, one per app) is a List of one table, whose rows are recognised by the
-  table's own `records`, and the Record its rows open, with the logs that stand beside it (further Lists at the root, which a change may add at any time, read by the organization's own members alone): its columns and filters, its Sections in the order its work
+  table's own `records`, and the page its rows open (`pages`), with the further Lists that stand beside it at the root (which a change may add at any time, each a register of its own, shown to the organization's own members alone): its columns and filters, its Sections in the order its work
   reaches them, its Acts and the Checks that guard them (`lotics docs reference/app-tree`,
   `reference/list-node`, `reference/section-node`, `reference/act-node`, `reference/check-node`). The platform
   compiles each app and draws it with the runtime every such app shares, so how each piece looks is
@@ -116,9 +116,10 @@ carry your edits over. Applying a tree the app already has mints nothing.
 write would grant and remove, writing nothing. Every write's answer states those permissions: the saves, adds,
 Deletes and act writes the new tree grants and removes, from the previous tree to the new one.
 
-**Nothing is written into the tree for you.** The answer notes a treatment the rows call for that the tree leaves out —
+**What the tree leaves out is drawn, never stored.** The answer shows a treatment the rows call for that the tree leaves out —
 Readings over its rows, a record's Sections, an Act per status move, a picture where its rows hold photos
-(`lotics docs design`) — and the tree states the ones the job needs.
+(`lotics docs design`) — and the tree states the ones the job needs. What it states with one fix, the write places
+and says (`lotics docs reference/changing-an-app`); edit only the difference.
 
 **The tree changes after the app exists, and applying it again is how it lands.** Pull the tree, edit
 the file, apply it; or send `nodes` for one part. An Act whose write the tree cannot say names its own `workflow`; that workflow's code is

package/docs/design.md

@@ -29,7 +29,7 @@ author: state the ones the job needs. A note refuses nothing.
 | Booked on a resource | List `layout: {"lanes": {"by": …}}`, and the table's `no_overlap` | `reference/lanes`, `reference/write-rules` |
 | A log of what happened | a child List with `layout: "timeline"` | `reference/layouts` |
 | Opened to be worked on | the Record's Sections, in the order the work reaches them — `at` where it moves in steps; fields only one kind of row holds (a delay's cause, a safety issue's hours lost) in a Section whose `when` names that kind | `reference/section-node` |
-| Rows that each belong to another row | a child List on that row's Record, with `create` and `remove` — and a child's own rows a List in that child List's Record, as deep as the data goes; a List with `same` or `app` where read-only, for rows another app works | `reference/list-node` |
+| Rows that each belong to another row | a child List on that row's Record, with `create` and `remove` — and a child's own rows a List in that child's page, as deep as the data goes; a List with `same` or `app` where read-only, for rows another app works | `reference/list-node` |
 | A related row's value on the list (the newest contract's end date) | a `lookup` field of the table, ordered, as a column | `reference/lookup` |
 | Moving through a status | an Act per move, `status.dates` for the moment of each stage, and the register's Readings | `reference/act-node`, `reference/status`, `reference/reading-node` |
 | Counted over a period | the register's Tabs over one `period`; a Tab's `totals` for a child's sums before, during and through it; an open Tab's `where` reads only what was true at the period's end, never a status the row moves on from | `reference/tab-node` |
@@ -90,15 +90,17 @@ lands them on its not-found.
 ### Rows in time
 
 Rows that each stand on a day, or hold a run of days or hours, are read where they stand in time — never
-as two date columns. A row holds a span when its `records` line (title and subtitle) holds two dates, its
-`records.frees` names the day it ends, or the table's `no_overlap` books it on a row its `by` links to (a
-chair, a machine). A `no_overlap` by a person or a value alone keeps one row at a time each — a member's periods in
-turn — read by what they hold.
+as two date columns. A row holds a span when two dates a person states are ordered, the second after the first by a
+`min` or a table check, both required or the second the row's `due`; else it is an appointment when one required date
+is stated that no Act stamps, that a new row does not start at `today` and that is not derived. A stamp is an event,
+and a `due` is a deadline, never the day a row is held on. A `no_overlap` by a person or a value alone keeps one row at
+a time each — a member's periods in turn — read by what they hold.
 
 #### Calendar
 
-`layout: "calendar"`: the rows by their day — a month, a week, a day or a list; an entry at its
-hour where its date holds one, over its span where its line holds a second date. An entry pressed opens a card on
+`layout: "calendar"`, or `{ "calendar": { "date": "starts_at", "end": "ends_at" } }`: the rows by their day — a
+month, a week, a day or a list; an entry at its hour where `date` holds one, over its span where `end` names the date it
+runs to. The bare word takes both from the rows' facts and is refused, naming `date`, where they name none. An entry pressed opens a card on
 it: the row, Delete, its Acts, Reschedule (the day alone moves; its hour and its length stay) and Open. Worked:
 `examples/calendar`.
 
@@ -107,14 +109,16 @@ it: the row, Delete, its Acts, Reschedule (the day alone moves; its hour and its
 `layout: {"lanes": {"by": …}}` with `by` naming a one-row link whose target's rows are the lanes (a chair, a
 machine, a room), each drawn even when empty: every row a block from the first date on its line to the
 second, and a free stretch adds a row there. `loads` reads what a lane carries against what it holds. A
-`no_overlap` `by` the same link refuses two rows on one resource at once. Worked: `examples/lanes`.
+`no_overlap` `by` the same link refuses two rows on one resource at once. A lane per person: `by` a member field
+and `of` a role of the model, each member of it a lane, idle ones too. Worked: `examples/lanes`.
 
 #### Gantt
 
 `layout: {"gantt": {"start": …}}` (and `end`, else the table's first `due`; a `due` is a deadline, never an appointment date): one bar a row over
 its run of days — a shipment, a hire, a task of a project — read against today. `milestones` marks
 dates on the bar, `planned` the plan under it, `progress` how far it is done, `after` the rows it waits on;
-the List's `group` is its lanes. Worked: `examples/gantt`.
+the List's `group` is its lanes; a table holding rows under rows nests each bar under its row above, folded as the
+register's outline is. A child List on a record with this layout draws the bars of the rows its link names. Worked: `examples/gantt`.
 
 #### Roster
 

package/docs/document_templates.md

@@ -186,6 +186,12 @@ figure adds it, any other cell (blank, an errored formula, a lookup's list) adds
 reader (`"me"`) is refused, and so is a name a rows List and a `list` List both reach: give the `list` a `key`. A record
 bound narrows what is listed and is never an access bound; the table's row rules are.
 
+A List that reads by a path (`via: "<link>.<link>"`) hands its rows the same way. A List the screen draws as an outline (a record's own
+sub-rows, in a table whose rows nest, with no `where`, total, group, long-text column or other narrowing) hands every sub-row, depth first, each after the row it is filed under and its
+siblings in the List's order, with its depth as `level` (1 for the rows filed under the record): `{{#each tasks}}{{level}} {{name}}{{/each}}`.
+A paper that lists an outline whose table has a field named `level` is refused. A link arrives as the titles of its rows, so an html or Word loop over one that prints a
+field of each item is refused, naming the key a List hands those rows under: loop over that key. A Word template is read for this when it is next saved.
+
 A paper over many rows (a client's month, a statement) is that: a record of the period whose List is windowed by its dates, made by the Act's `template`; or a List `Export` with `template` and `per` (`reference/export-node`).
 `reference/groups-and-templates` has the rest.