Merge remote-tracking branch 'origin/main' into claude/pagination-tie-breaker-missing-p98qf0

# Conflicts:
#	.changeset/paged-read-determinism.md
#	packages/plugins/driver-memory/src/memory-pagination-conformance.test.ts
#	packages/plugins/driver-mongodb/src/mongodb-driver.ts
#	packages/plugins/driver-mongodb/src/mongodb-pagination-conformance.test.ts
#	packages/plugins/driver-sql/src/sql-driver-pagination-conformance.test.ts
#	packages/plugins/driver-sql/src/sql-driver.ts
#	packages/spec/api-surface.json
#	packages/spec/src/contracts/data-driver.ts
#	packages/spec/src/data/index.ts
#	packages/spec/src/data/pagination-conformance.ts

Author: claude

.changeset/action-record-writes-runtime-report.md

@@ -0,0 +1,42 @@
+---
+"@objectstack/runtime": minor
+---
+
+feat(runtime): the sandbox reports an action body's discarded `ctx.record` writes at invocation time (#4345)
+
+#4362 closed the author-time half of #4345: `action-record-write-discarded`
+warns when a body assigns to `ctx.record` and the snapshot is provably dead.
+This is the run-time half, and it exists because a parse cannot reach three
+things a running action can:
+
+- **computed keys and aliases** — `ctx.record[k] = v`, `const r = ctx.record;
+  r.x = 1`, which the lint deliberately skips rather than guess at;
+- **a wholesale replacement** — `ctx.record = {…}`;
+- **bodies no lint ever sees** — metadata authored through Studio or the API
+  never passes through `os validate` / `os lint` / `os compile`.
+
+The sandbox installs a `set`/`deleteProperty`/`defineProperty` proxy over the
+snapshot, behind an accessor so a wholesale replacement cannot swap the recorder
+out, and surfaces the touched keys as `ScriptResult.droppedRecordWrites`.
+`actionBodyRunnerFactory` logs a warning naming the discarded fields and the
+`ctx.api.object(...).update(...)` remedy. Writes still work *inside* the VM, so
+a body using the snapshot as scratch keeps its reads coherent — only the silence
+is removed.
+
+**Only dead writes are reported**, on the same reading #4362 uses: a snapshot
+that leaves the body as a value may have carried the write with it, so
+
+```js
+ctx.record.stage = 'won';
+await ctx.api.object('crm_deal').update(ctx.record);   // lands — stays quiet
+```
+
+is not reported, while a plain property read does not rescue a write (the
+`ctx.recordId || (ctx.record && ctx.record.id)` guard idiom real action bodies
+are written with still reports). An `ownKeys` after a write marks the escape.
+A wrong "discarded" asserts something false about the stored record, which is
+worse than a miss.
+
+Hooks carry no `record`, so they install no proxy and pay nothing. `ctx.record`
+remains read-only; whether the runtime should instead refuse or honour the write
+is still open — reporting a discard prejudges neither answer.

.changeset/drop-require-auth.md

@@ -32,7 +32,7 @@ switch:
   `RestApiConfigSchema` and the stack `api` block, so authoring it now fails with
   a fix-it message rather than being silently stripped (the ADR-0104 / #3733
   quiet-failure this whole line of work has been closing). `os migrate meta`
-  drops it via the protocol-18 conversion `stack-api-require-auth-removed`.
+  drops it via the protocol-17 conversion `stack-api-require-auth-removed`.
 - `shouldDenyAnonymous` (@objectstack/core) no longer takes a `requireAuth`
   input; it denies any anonymous, non-system caller outside the control-plane
   allowlist.

.changeset/engine-callsites-canonical-keys.md

@@ -0,0 +1,52 @@
+---
+"@objectstack/plugin-sharing": patch
+"@objectstack/runtime": patch
+"@objectstack/plugin-approvals": patch
+"@objectstack/plugin-auth": patch
+"@objectstack/plugin-reports": patch
+"@objectstack/plugin-webhooks": patch
+"@objectstack/spec": patch
+---
+
+fix(sharing,runtime): a `sort` passed straight to the engine never ordered anything; migrate every in-repo engine call to canonical QueryAST keys (#4346)
+
+Two changes with different weights, from one sweep of every in-repo engine
+call site that still speaks a deprecated alias.
+
+**The bug — three dropped sorts.** #4346 made the engine fold `filter`→`where`
+and `top`→`limit` on all six methods. The other four pairs in
+`RPC_QUERY_ALIAS_SLOTS` (`select`, `sort`, `skip`, `populate`) are folded at
+the RPC/wire layer only — their values need shape lowering that belongs to
+those layers — and a **direct `engine.find()` never crosses that layer**. Three
+call sites passed `sort` there, so it rode onto the AST untouched, every
+driver's `Array.isArray(query.orderBy)` guard declined to emit an ORDER BY, and
+the query returned an ordinary-looking, arbitrarily-ordered result:
+
+| call site | asked for | actually got |
+|---|---|---|
+| `share-link-routes.ts` | shared AI conversation messages, `created_at asc` | messages in arbitrary order |
+| `runtime/domains/share-links.ts` | same route, runtime-domain copy | same |
+| `share-link-service.ts` `listLinks` | the 200 most recent share links | an arbitrary 200 |
+
+All three combine the dropped sort with a `limit` — the "latest N" shape whose
+failure #4226 spelled out: an unapplied sort returns rows in arbitrary order,
+which `limit` then slices into an arbitrary page. #4226 fixed that in the wire
+normalizer; these calls sit one layer below it. `listLinks` had no test at all,
+which is why it went unnoticed. Now pinned — on the option bag the engine
+receives, not on row order, because the failure is that the key never becomes
+`orderBy` and a fake engine honouring either spelling would pass either way.
+
+**The cleanup — 27 no-op renames.** Every remaining in-repo engine call passing
+`filter` now passes `where` (approvals 5, auth 2, reports 6, sharing 11,
+webhooks 2, plus the one `filters` in a spec doc example). These are strict
+no-ops since #4346 folds the alias — the point is that the framework stops
+depending on a spelling it asks users to migrate off, which is a prerequisite
+for ever retiring the aliases. Service-level `filter` PARAMETERS (each
+service's own public API, e.g. `listRequests(filter)`) are deliberately
+untouched — those are not engine option bags.
+
+Two of the renamed calls were live victims of the #4346 bug rather than
+cosmetic: `auth-manager`'s `stampIdentitySource` read the table's first row via
+`findOne({filter})` and counted the whole table via `count({filter})`, so a
+federated sign-in never stamped `source: 'idp_provisioned'`. #4346 already
+corrected the behaviour; this makes the call say what it means.

.changeset/flow-create-record-write-lint.md

@@ -0,0 +1,49 @@
+---
+"@objectstack/lint": patch
+---
+
+feat(lint): `flow-node-write-unknown-field` covers `create_record` too (#4271)
+
+#4369 shipped the flow write-set gate on `update_record` alone and parked
+`create_record` in `FLOW_WRITE_NODE_TYPES_DEFERRED` with its reason — a gating
+rule earning its severity one measured surface at a time, recorded as data
+rather than left as silence. This measures the other half and moves it across.
+
+**The INSERT path fails the same way, one notch harder.** Same literal
+`config.fields` map, same `objectName` binding, same journey to the driver — the
+engine hands an undeclared key to `driver.create` verbatim, alongside the audit
+stamps. On SQLite/knex it becomes `table deal has no column named stagee` and
+the statement is rejected whole, so the correctly named fields in the same
+payload never land either. The extra harm is what does *not* exist afterwards:
+the row is never created, so every later node reading `{<node>.id}` from that
+node's `outputVariable` is working from a record that was never written. An
+`update_record` failure at least leaves the record intact.
+
+So the message now names that consequence on `create_record` and only there —
+"…and the record is never created at all" — instead of one sentence blurred to
+fit both.
+
+Nothing else moves: same rule id, same `error` severity, the same silent bails
+(templated `objectName`, non-literal `fields`, cross-package objects, objects
+declaring no fields, dotted keys), and `runAs` is still not consulted. Each skip
+is now pinned on the create surface as well as the update one, so the two node
+types cannot drift into different behaviour.
+
+**`FLOW_WRITE_NODE_TYPES_DEFERRED` is now empty and deliberately kept.** The
+partition test derives the full `fields`-write-map set behaviourally from the
+spec's executor-written config schemas, so a node type that grows one later
+belongs to neither list and fails that test until someone classifies it.
+Deleting the empty array would turn that forced decision back into a default.
+
+Two non-members are now excluded on the shape of their failure rather than by
+omission, both stated in the module header and one pinned by a test:
+`get_record.fields` is a projection (`z.array(z.string())`) — a READ, where an
+unknown entry narrows the selection instead of breaking the statement — and
+`screen.defaults` is forwarded into the `ScreenSpec` the client renders, so an
+unknown key is a prefill the renderer ignores. That inert "skips it and renders
+the rest" case is exactly what this rule's `error` severity is defined against.
+
+Verified against the repo's own apps: app-crm, app-todo and app-showcase all
+still validate clean with `create_record` covered — including crm's
+convert-lead flow, which creates an account and an opportunity before updating
+the lead.

.changeset/flow-node-write-set-lint.md

@@ -0,0 +1,85 @@
+---
+"@objectstack/lint": minor
+"@objectstack/spec": patch
+---
+
+feat(lint): a flow `update_record` node writing an undeclared field gates the build (#4271)
+
+The write-set family #4305 (hooks) and #4344 (actions) opened had a third
+surface, and it was the one the docs had spent the longest recommending as the
+safe alternative to the other two. A flow `update_record` node whose
+`config.fields` names a field the target object never declares was caught by
+**nothing**: `validate-readonly-flow-writes.ts` walks that exact map and
+explicitly stepped over the unknown key (`if (!meta) continue; // a
+form/field-layout lint concern` — a referral to a rule that does not check
+writes), and `validate-flow-template-paths.ts` checks the `{record.<path>}`
+READ tokens interpolated into node config, never the write-side key. So the
+surface `hook-bodies.mdx` pointed authors at — "prefer a flow `update_record`
+node, whose structural `fields` config is checked" — was the least checked of
+the three.
+
+**New rule — `flow-node-write-unknown-field`, and it is an `error`.** Wired into
+`REFERENCE_INTEGRITY_RULES`, so `os validate`, `os lint` and `os compile` report
+it at once (one more place than the hand-wired readonly rule next door reaches).
+
+**Why it gates where its two siblings advise.** The hook and action rules are
+advisory because they PARSE JavaScript: the finding is only as good as the
+extractor, and a false positive kills an advisory lint. Nothing here is parsed —
+`config.fields` is a literal map next to a literal `objectName`, the same
+certainty `flow-update-readonly-field` already gates on one config key over. A
+rule that errors on a write the engine *strips* while only warning on a write
+that names no column at all would be incoherent in the same `fields` map.
+
+And the runtime consequence is not the benign "consumer skips the unknown name
+and renders the rest" that keeps `page-field-unknown` / `form-field-unknown`
+advisory. Both halves were measured, not inferred:
+
+- Through the engine, an undeclared key reaches `driver.update` verbatim — the
+  flow executor calls the data engine directly, the UPDATE path strips only
+  readonly/readonlyWhen, and the SQL driver's `formatInput` /
+  `applyWriteColumnMap` pass an unrecognized key straight through (`m[k] ?? k`).
+- On SQLite/knex it becomes `update "deal" set "name" = 'n2', "stagee" = 'won' …
+  → no such column: stagee`. The statement is rejected **whole**: `name` —
+  spelled correctly, in the same payload — does not land either, and the step
+  fails with a driver error naming a column, far from the authoring mistake.
+- On a schemaless datasource nothing rejects it, so the stray key is persisted
+  into a column the object never declares, where no schema-driven read returns
+  it.
+
+That is the call `validate-searchable-fields` makes for a stale entry and
+`validate-flow-template-paths` makes for a filter-position token: gate when the
+miss breaks or corrupts the operation, advise when it merely narrows the output.
+
+**One field index and one implicit-field set across all three surfaces.**
+`indexObjectFields` and `IMPLICIT_FIELDS` are imported from the hook rule rather
+than copied, so the three rules cannot drift on what is writable without being
+authored — the shape #4330 collapsed one package over.
+
+Every skip exists so the gate only ever fires on a certainty, and each is
+silent: a templated `objectName`, a non-literal `fields` map, an object this
+stack does not define, an object that declares no fields at all (external /
+datasource-introspected schemas, the same skip `validate-searchable-fields`
+takes), and dotted keys (a nested-path write, not a top-level column). `runAs`
+is deliberately NOT consulted, unlike the readonly rule that skips
+`runAs:'system'` — an elevated identity bypasses the readonly strip, but no run
+identity conjures a column.
+
+**Scope is declared as data, not left as silence.** `FLOW_WRITE_NODE_TYPES`
+(today `update_record`) and `FLOW_WRITE_NODE_TYPES_DEFERRED` (`create_record`,
+with its reason) are partition-tested against the CRUD node types that carry a
+`fields` write map — derived behaviourally from the spec's executor-written
+config schemas, not restated — so a node type that grows one later fails that
+test until someone classifies it.
+
+`@objectstack/spec`: `ScriptBodySchema`'s "prefer a flow `update_record` node,
+whose structural `fields` config is error-checked" note now names the rule that
+makes it true. Doc comment only — no schema or generated-artifact change.
+
+Docs: #4355 had just rewritten `automation/hook-bodies.mdx` to record this gap
+honestly — "**Prefer a flow `update_record` node when the write set is fixed —
+but not for *this* check** … writing a field the object never declares is
+currently reported by nothing at all. On that one axis an L2 body is now the
+better-checked surface." That bullet, and the matching note in
+`automation/hooks.mdx`, are the two sentences this change makes false. Both now
+say the axis has flipped back — and why the flow side lands a level *stronger*
+than the body side rather than merely level with it.

.changeset/query-ast-inert-request-surface.md

@@ -41,7 +41,7 @@ non-strict `BaseQuerySchema`, so authoring either fails `tsc` (input type
 `never`) and a query still carrying one — even as an empty array — fails to
 parse with the prescription itself. `QueryAST` is a request shape, never stored
 in stack metadata, so there is no `os migrate meta` step: the removals are
-registered as protocol-18 **semantic** migrations (`query-joins-retired`,
+registered as protocol-17 **semantic** migrations (`query-joins-retired`,
 `query-window-functions-retired`), the #4196 precedent.
 
 Compat note for the REST boundary: both names remain **reserved** list-query

.changeset/query-cursor-removed.md

@@ -25,7 +25,7 @@ Mechanics: `retiredKey()` tombstones on both declaration sites
 (`QuerySchema.cursor` and `EngineQueryOptionsSchema.cursor`, one shared
 prescription), so authoring the key fails `tsc` and a query still carrying it
 fails to parse with the fix. `QueryBuilder.cursor()` is deleted. Registered as
-the protocol-18 semantic migration `query-cursor-retired` (request surface —
+the protocol-17 semantic migration `query-cursor-retired` (request surface —
 nothing stored to rewrite). The caller-built `Record<string, unknown>` shape
 would not survive a real keyset design anyway: a first-class cursor, if ever
 built, will be a response-minted opaque token (the pattern the

.changeset/query-distinct-removed.md

@@ -29,7 +29,7 @@ The one-line fix: **delete the key**; deduplicate with `groupBy` /
 Mechanics: `retiredKey()` tombstones on both declaration sites
 (`QuerySchema.distinct` and `EngineQueryOptionsSchema.distinct`, one shared
 prescription); `QueryBuilder.distinct()` is deleted; registered as the
-protocol-18 semantic migration `query-distinct-retired`. **Observable REST
+protocol-17 semantic migration `query-distinct-retired`. **Observable REST
 change (`@objectstack/metadata-protocol`):** the count-suppression branch is
 deleted — a list request that used to carry `distinct` now gets a real
 `total`/`hasMore` again (that restoration is the point, not a side effect).

.changeset/query-field-node-object-form-removed.md

@@ -50,7 +50,7 @@ depth 3).
 There is no `os migrate meta` step, and deliberately so: `QueryAST` is a request
 shape, never stored in stack metadata, so the chain has no source to rewrite. It
 is registered as an ADR-0087 D3 **semantic** migration
-(`query-field-node-object-form-retired`) on the protocol-18 step instead — the
+(`query-field-node-object-form-retired`) on the protocol-17 step instead — the
 `EnhancedApiError.fieldErrors` / `BatchOptions.validateOnly` precedent. Callers
 move their own select lists, and both channels tell them how:
 

.changeset/retire-batch-validate-only.md

@@ -24,7 +24,7 @@ deliberately when there is a real need.
   rather than being silently stripped (the ADR-0104 / #3733 quiet-failure class).
   The `BatchOptions` type's `validateOnly` becomes `never`.
 - The retirement is HTTP-only (the key never appeared in stored stack metadata),
-  so it is recorded as a semantic migration on the protocol-18 chain step
+  so it is recorded as a semantic migration on the protocol-17 chain step
   (`batch-options-validate-only-retired`) — a TODO for API callers, not a stack
   conversion.