@lotics/cli 0.305.0 → 0.305.1

package/dist/src/client.d.ts

@@ -119,7 +119,7 @@ export interface ToolExecuteResult {
      *  failure was not a typed error, and from any server older than it. */
     error_code?: string;
     /** A refused input addressed per field: one sentence from a typed alias, a
-     *  list from a rejecting table workflow. */
+     *  list from a refusing table check. */
     field_errors?: Record<string, string> | Record<string, string[]>;
     breaking_changes?: readonly ToolBreakingChange[];
 }

package/docs/data_model.md

@@ -94,8 +94,7 @@ it — and a date column per state holds until something re-enters a state it al
 
 Measuring time-in-state or conversion needs one ROW per move: a link to the subject, the state left,
 the state entered, when. Hold those states as the source field's own `opt_` keys so the log carries
-no second vocabulary, and write the rows from that table's own lifecycle workflows, which covers
-every writer rather than one app's.
+no second vocabulary, and write the row in the workflow that makes the move.
 
 ## Keep derived chains shallow
 

package/docs/workflows.md

@@ -6,16 +6,13 @@ Only the forms below are accepted; anything else is refused at save with the lin
 what to write instead. A save that succeeds may still return `warnings` — advisory hints such as a
 loop that may never end. Read them.
 
-The same grammar serves an automation, a table's lifecycle workflow and an app's workflow, and the
-expressions of a table check. Only an automation's source opens with a trigger declaration; a
-lifecycle workflow takes its trigger from its table and event, an app workflow from the app that calls
-it.
+The same grammar serves an automation and an app's workflow, and the expressions of a table check.
+Only an automation's source opens with a trigger declaration; an app workflow takes its trigger from
+the app that calls it.
 
 ## Triggers
 
-An automation answers an event outside the records: a schedule, a webhook, an inbound email. A
-reaction to a record being created, updated or deleted is a table lifecycle workflow (see
-**Table lifecycle workflows**).
+An automation answers an event outside the records: a schedule, a webhook, an inbound email.
 
 ```
 on({ type: "recurring_schedule", cron_expression: "0 9 * * MON" });
@@ -70,8 +67,8 @@ connections and the steps each opens.
 
 `return` is a call, not a JavaScript `return` statement. `validate` ends the workflow with an error
 when a check's `fail_when` is truthy; the check's `field_key` names the control its message lands on —
-in an app workflow a declared input, or the `fld_` key of a field on a table the body names; a field of
-the trigger table in a lifecycle workflow; in an automation it is not checked.
+in an app workflow a declared input, or the `fld_` key of a field on a table the body names; in an
+automation it is not checked.
 
 The name in `const x = await tool({...})` is the step's id; later expressions read its output as
 `x.records`, `x.id` and so on. A `// id: my_step` comment directly above a statement sets an explicit
@@ -95,8 +92,8 @@ Bind it to branch on the decision:
 
 ```
 const approval = await wait_for_approval({
-  approvers: record["fld_approvers"],
-  prompt: `Approve the quote for ${record["fld_name"]}?`,
+  approvers: trigger.app_workflow.inputs.approvers,
+  prompt: `Approve this quote?`,
 });
 
 if (approval.status == "approved") {
@@ -120,7 +117,7 @@ step — summarize a record, classify, draft text.
 
 - `instructions` — a fixed string.
 - `input` — an object literal; its fields are expressions, evaluated and handed to the model (`{}` for
-  none). It is the ONLY workflow data the agent sees: read `record`, prior steps, `runtime` or the loop
+  none). It is the ONLY workflow data the agent sees: read the trigger, prior steps, `runtime` or the loop
   item here, never inside `instructions` or `tools`, which are fixed literals and read no binding.
 - `tools` — the names of the tools it may call.
 - `model` — optional; omit it to follow the platform's default model.
@@ -141,13 +138,9 @@ Only `x` comes back: in text mode `x` is the string itself, in object mode `x.fi
 
 ## What an expression reads
 
-- `record` — the trigger record (on an update, the record as it now stands).
-- `prev_record` — the record before the change, same shape (updates and deletes only).
-- `changes` — the fields an update changed, a PARTIAL map: `changes["fld_x"]?.next_value` and
-  `?.prev_value`, the `?.` required (updates only).
-- `trigger` — what a non-record trigger carries (see **Triggers**). `trigger.data`,
-  `trigger.prev_data` and `trigger.changes` are the same three roots spelled long; a saved body reads
-  back in the short form.
+- `record`, `prev_record`, `changes` — in a table check, the write it checks (see **Table checks**).
+  `changes` is a PARTIAL map: `changes["fld_x"]?.next_value` and `?.prev_value`, the `?.` required.
+- `trigger` — what the trigger carries (see **Triggers**).
 - a loop's item name, and `index`, the iteration's 0-based index.
 - `<step id>` — an earlier step's output (`dup.records`).
 - `runtime.timezone`, `runtime.workflow_id`, `runtime.execution_id`, `runtime.workspace_id`,
@@ -277,8 +270,9 @@ const found = await query_records({
   filters: { node_type: "condition", field_key: "fld_name", operator: "equals", value: "ACME Corp" },
 });
 const customer = first(found.records);
+const order = await get_record({ table_id: "tbl_orders", record_id: trigger.app_workflow.inputs.order_id });
 
-if (customer && includes(record["fld_customer"], customer.id)) {
+if (customer && includes(order.data["fld_customer"], customer.id)) {
   // …
 }
 ```
@@ -323,41 +317,6 @@ for (let start = 0; start < sheet.row_count; start += 50) {
 }
 ```
 
-## Table lifecycle workflows
-
-A lifecycle workflow is bound to one table and one event, and its source has no `on({...})` line:
-
-- `after_create` — a create, and a draft's submit (the moment it becomes a record).
-- `after_update` — every field edit, a draft's included.
-- `after_delete`.
-
-A lifecycle workflow runs after the write commits, with every step; its errors are logged and never
-fail the write. What refuses a write before it lands is a table check (see **Table
-checks**). An `after_update` workflow that writes its own table saves with a `loop_potential`
-warning: its write fires it again.
-
-| reads | on |
-|---|---|
-| `record` | every event — the new record on create, the record as it now stands on update, the deleted record on delete |
-| `prev_record` | updates and deletes — the record before |
-| `changes["fld_x"]?.next_value` / `?.prev_value` | updates — the fields that changed |
-
-### Gating with `if_source`
-
-`if_source` is one JavaScript expression, reading what the body reads, tested before the workflow
-runs. When it is falsy the workflow does not run at all — no execution, no log. Use it so a workflow
-that cares about some events only skips the rest:
-
-- a status reaching an option: `changes["fld_status"]?.next_value == "opt_done"`
-- a field cleared: `isNull(record["fld_assignee"])`
-- a direct write, not a workflow's cascade:
-  `includes(["member", "chat_agent", "api_client"], runtime.change_origin.type)` — name every
-  direct-write origin rather than testing for one: `member` is a person in the browser, and the same
-  edit over MCP, the CLI or the API arrives as `api_client`.
-
-In `if_source`, `runtime.change_origin` is the origin of the write that fired it; in the body, it is
-the workflow's own.
-
 ## Table checks
 
 A table check is one condition its table's record writes must not meet, declared beside the table's

package/package.json

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