@lotics/app-sdk 0.120.1 → 0.120.2

package/dist/index.js

@@ -25051,7 +25051,7 @@ var tableDateFieldSchema = tableFieldBaseSchema.extend({
   format: dateFormatSchema.optional(),
   timezone: zod_default.string().optional().describe("IANA timezone"),
   derive_from: zod_default.enum(["created_at", "updated_at"]).optional().describe(
-    "Auto-populate from the row's system timestamp. `created_at` stamps once at insert time; `updated_at` re-stamps on every record edit. A derived field is read-only: a write naming it is refused, as for formula/rollup/lookup. Replaces the per-table after_create workflow pattern."
+    "Auto-populate from the row's system timestamp. `created_at` stamps once at insert time; `updated_at` re-stamps on every record edit. A derived field is read-only: a write naming it is refused, as for formula/rollup/lookup."
   ),
   // A derived date is read-only, so derive_from and default_value are mutually
   // exclusive — enforced in validateFieldDefaultValue.

package/docs/mutations.md

@@ -397,8 +397,8 @@ Why a full-form snapshot save is a bug, not a style choice — three independent
    moment *any* field is touched — there is no value-equality pass (deep equality over stored
    shapes would be a silent lock bypass). A snapshot touches every field, so it turns every
    save against a locked record into a total rejection even when nothing changed.
-2. **A table's checks and `after_update` workflows run on the write.** They run on every
-   write that touches the record — a snapshot save runs them for fields the user never edited.
+2. **A table's checks run on the write.** They run on every write that touches the record —
+   a snapshot save runs them for fields the user never edited.
 3. **Snapshots clobber concurrent edits.** An update writes exactly the fields present in the
    payload; unsent fields keep their current value. A diff therefore coexists with a
    colleague's concurrent edit to a *different* field — a snapshot overwrites it with the

package/docs/workflows.md

@@ -51,9 +51,7 @@ compile-time "cannot find name", not a runtime `undefined`.
 |---|---|---|
 | `trigger` | every context | the trigger namespace. For an app workflow: `trigger.app_workflow.inputs.<name>` |
 | `runtime` | every context | execution context — see the key table below |
-| `record` | button + table-lifecycle workflows | the record the trigger fired on (merged data on update) |
-| `prev_record` | table `*_update` / `*_delete` | the prior record state — same shape as `record` |
-| `changes` | table `*_update` | per-field diff — a *partial* map, so read it `changes["fld_x"]?.next_value` / `?.prev_value` |
+| `record` | button workflows | the record the button was pressed on |
 | `index` | inside a `for-of` body | the current 0-based iteration index — always the **innermost** loop's. To use an outer loop's index in a nested body, bind it in the outer one (`const outerIdx = index;`) and read that |
 | `<bind_name>` | inside a `for-of` body | the current item. Each loop keeps its own, so a nested body reads the outer loop's item by its own bind name |
 | `<name>` | its block, after the declaration | a `const` — a step's output (`rows.records`, `approval.status`, …) or a bound value |
@@ -61,10 +59,6 @@ compile-time "cannot find name", not a runtime `undefined`.
 | `<param>` | inside a helper callback | that lambda's parameter |
 | `(await <tool>({…}))` | anywhere the call runs unconditionally | that call's output, read in place (see *`await` inside a statement*) |
 
-`record`, `prev_record` and `changes` are the **canonical** roots. `trigger.data`,
-`trigger.prev_data` and `trigger.changes` are accepted and lower onto them, so a saved body prints
-back in the bare form. Write the bare form.
-
 A body bound to an app alias is an app workflow: it sees `trigger` and `runtime` only. There is
 no `record` — an app workflow is not attached to a table. Pass the record id in as a
 `record_link` input and `get_record` it.
@@ -72,11 +66,9 @@ no `record` — an app workflow is not attached to a table. Pass the record id i
 `runtime` keys: `timezone`, `now`, `workflow_id`, `execution_id`, `workspace_id`,
 `organization_id`, `triggered_by_member_id` (`null` for a system trigger or an anonymous
 public-app caller), and `change_origin` — a discriminated union over how the **execution** was
-started: `button` · `automation` · `app_action` · `app_workflow` · `table_workflow`. It describes
+started: `button` · `automation` · `app_action` · `app_workflow`. It describes
 the dispatch, never the person, and it is fixed per attachment — an app workflow always reads
-`app_workflow`, a table workflow always `table_workflow`. To branch on *who wrote the record*,
-read `trigger.change_origin` on a table workflow (that one carries the originating write's
-origin, and spans every write path: `member`, `chat_agent`, `app_workflow`, …). `runtime`
+`app_workflow`. `runtime`
 is never null, so `runtime?.x` is rejected outright. Prefer the helper `now()` over
 `runtime.now`.
 
@@ -118,16 +110,13 @@ is a second call (`linked(linked(order.data["fld_a"])[0]["fld_b"])[0]`). A linke
 deleted, or that the run may not read, stays a positional `null`, so `linked(P)[i]` is always the
 row `P[i]` names.
 
-The argument is a path ending on a link field, off anything record-shaped: `record` /
-`prev_record`, a `for-of` item, a lambda parameter, a `let` binding, or a `get_record` /
+The argument is a path ending on a link field, off anything record-shaped: `record`, a `for-of` item, a lambda parameter, a `let` binding, or a `get_record` /
 `query_records` output. The server checks the far field at save only where it can name the table
 before the run — a call with a **literal** `table_id` — and the fetch works either way. Guard **inside** the
 argument — `linked(record?.["fld_link"])[0]` — never on the call: `linked(P)?.[i]` is rejected,
 because the call always returns an array and the guard could never fire. Two more rejections:
 `const ids = record["fld_link"]; linked(ids)`, since the field name comes from the argument's last
-member access (`linked(row["fld_link"])` off a bound ROW is fine), and
-`linked(changes["fld_link"]?.next_value)`, since a diff is not a record — read
-`linked(record["fld_link"])` or `linked(prev_record["fld_link"])`, which hold the same ids.
+member access (`linked(row["fld_link"])` off a bound ROW is fine).
 `linked` is grammar, not a helper: it cannot be shadowed, bound, called as a method, or awaited.
 
 ## Step forms
@@ -257,13 +246,12 @@ only the dialog. What it may name depends on who renders the refusal:
 | Workflow | `field_key` may name |
 |---|---|
 | app workflow | a declared INPUT name (`order_code`, a key of the binding's `inputs`), or the `fld_` key of a field on a table the body names as a literal (a `table_id: "tbl_…"`, or a `const` holding one) |
-| table-triggered (lifecycle, button) | the `fld_` key of a field on the trigger table |
+| button | the `fld_` key of a field on the button's table |
 | recordless automation (schedule, webhook, email) | anything — nothing renders it, so nothing checks it |
 
 An app workflow whose alias declares no inputs leaves input-shaped keys unchecked, so a body can
 be written before its declaration. A key outside its row is refused when the body is SAVED — by
-`set_app_workflow`, by an agent binding one, by a table workflow's save — and by a
-`verify_only` call before that. `return({ field_errors })` keys are not checked.
+`set_app_workflow`, by an agent binding one — and by a `verify_only` call before that. `return({ field_errors })` keys are not checked.
 
 ### `wait_for_approval` — the one wait worth binding
 
@@ -657,9 +645,8 @@ linked record id as `RecordId<"tbl_…">`. They come out branded from a record r
 or from a workflow input declared `member` / `file` / `record_link` — a `rec_*` string carried in
 a plain `text` input does *not* type-check into a link field, so declare the input for what it is.
 
-A link **read** is an id array, so it feeds straight back: `set: { fld_link: record["fld_link"] }`,
-and the same for `prev_record["fld_link"]` and for a diff's `changes["fld_link"]?.next_value` /
-`?.prev_value`. What does not feed back is a ROW: a link field takes ids, so from rows you already
+A link **read** is an id array, so it feeds straight back: `set: { fld_link: record["fld_link"] }`.
+What does not feed back is a ROW: a link field takes ids, so from rows you already
 hold write `pluck(rows.records, (r) => r.id)`, or `[x.id]` for one. Never route a link read through
 `linked(...)` to get its ids back — it holds them already, and the fetch costs one read per row and
 yields `null` where a row is deleted or unreadable, which the write then rejects.
@@ -796,8 +783,7 @@ The rules that are easy to get wrong because the failing code looks correct.
   `` `Status: ${record["fld_status"]}` `` prints "Done" while
   `record["fld_status"] == "opt_done"` compares keys — both correct, and neither substitutes for
   the other. It holds on every route a record arrives by — a `let`, a callback parameter, a row
-  from a variable `table_id` — and a change-diff read (`changes["fld_status"]?.next_value`)
-  behaves exactly like the same field read off the record.
+  from a variable `table_id`.
 - **Multi-select `==` quietly desugars.** On a multi-select field,
   `record["fld_tags"] == "opt_urgent"` rewrites to `includes(…)` at save. Either spelling is
   fine — but a `switch` on a multi-select discriminant is **rejected**, because its value is an
@@ -810,15 +796,6 @@ The rules that are easy to get wrong because the failing code looks correct.
   `xs = concat(xs, someArray)` fails to typecheck; appending a whole *array* has no `push`
   spelling. Start that binding from the first array instead of seeding it `[]`. Appending single
   **items** (`xs.push(item)`) works on a bare `[]` seed.
-- **A mutation on the trigger table of an `after_*` workflow can re-trigger itself** — a lint
-  warning, not an error. Gate it on `trigger.change_origin` — the originating write's origin —
-  and name every origin you mean to let through, rather than testing for one. `member` is a
-  person in the browser and **only** that: the same edit made over MCP, the CLI, or a direct API
-  call arrives as `api_client`, and one made by the chat agent as `chat_agent`. A gate meaning
-  "someone did this by hand" is
-  `includes(["member", "chat_agent", "api_client"], trigger.change_origin.type)`. Not
-  `runtime.change_origin`: that is the execution's own origin, always `table_workflow` here, so
-  it discriminates nothing.
 - **Expressions are bounded.** A helper that builds an array — `range`, `list`, `flatten`,
   `concat` of arrays, `split`'s parts — makes at most 100,000 elements, and a callback helper
   takes an array of at most 100,000. `join`, `replaceAll`, `padStart`, `padEnd`, `toString`,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lotics/app-sdk",
-  "version": "0.120.1",
+  "version": "0.120.2",
   "description": "The SDK a Lotics custom-code app reads and writes through — typed hooks over the host bridge, cell readers, mount() and AppRouter",
   "type": "module",
   "exports": {