Merge origin/main (e35c40a) into claude/issue-21094-prod-deps-group

Claude-Session: https://claude.ai/code/session_018gA1pE6eJtwHhqx72G8U9X
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

.changeset/20281-connector-sync-moved-to-mapping.md

@@ -25,15 +25,16 @@ declared-connector item carried neither key, and the def a provider registers is
 own. The `latest_wins` and `soft_delete` defaults read as configured policy and did
 nothing; the platform has no soft delete.
 
-**Added (declared, not yet executed):** `mapping.connectorSource` — the pull
+**Added:** `mapping.connectorSource` — the pull
 binding on the target side, beside the mapping's existing `targetObject`,
 `fieldMapping`, `mode` and `upsertKey`: `connector` (a `rest` or `openapi`
 connector instance), `action` (the action that reads the records), optional
 `input`, optional `recordsPath`, and an optional `watermark` (`field` on the
 record, `param` on the request) for a timestamp-incremental pull. Version 1 is a
 one-way pull. It carries no cadence (a `job` sets that), no credential (the
-connector instance holds it) and no delete or conflict policy. Nothing executes it
-in this release, and `os validate` / `os build` warn when it is authored.
+connector instance holds it) and no delete or conflict policy. The connector sync
+executor, `@objectstack/service-automation`'s `pullConnectorSource` (#20919), reads
+it; nothing schedules a pull until the `job` stage lands.
 
 ### FROM → TO
 

.changeset/20965-analytics-expression-member-refused.md

@@ -0,0 +1,37 @@
+---
+'@objectstack/service-analytics': patch
+---
+
+fix(service-analytics): the analytics field-level read gate refuses a cube member whose `sql` names no field, instead of letting the query run (#20965)
+
+Clause-②: no
+
+**What changed.** Where the analytics field-level read gate judges a cube's
+object (a security service is registered and gives a field answer for that
+object), a query that names a cube member whose `sql` is neither a column
+reference (a field of the cube's object, or a relationship path ending in one)
+nor `'*'` is now refused `403 PERMISSION_DENIED` on
+`POST /api/v1/analytics/query` and `POST /api/v1/analytics/sql`, before either
+strategy runs. Whatever
+the caller may read, the member is refused. That covers an expression member
+of a cube that reached the service without the spec's parse (the cube
+registry never parses: `analyticsCubes` and `AnalyticsServicePlugin({ cubes })`
+arrive as written), a declared member with no `sql` string, and a member the
+query names itself that is not a column reference. The gate used to stand down
+on such a member, because it names no field, and the native-SQL strategy then
+compiled it into its statement as written: a read of fields no permission
+verdict was reached for. The refusal names the member and the object, and
+never the member's `sql`.
+
+**What is not affected.** A member that is a column reference is judged by the
+field it resolves to, as before. A `count` over `'*'` names no field and is
+served. A deployment with no security service, and an object the security
+service gives no field answer for, apply no field-level check, as before. The
+spec's parse already refuses an expression member, so a cube that parses is
+unaffected.
+
+**If a widget stopped answering,** its cube carries an expression member from
+before the parse refused one. Re-author the member as a column reference, or
+declare the derived value on an ADR-0021 dataset: a conditional count or sum
+is a dataset measure with its own `filter`, and a ratio of measures is
+`derived: { op: 'ratio', of: [...] }`.

.changeset/20981-aggregation-flag-comparand-refused.md

@@ -0,0 +1,21 @@
+---
+'@objectstack/objectql': minor
+---
+
+fix(objectql)!: a per-aggregation `filter` and a `having` refuse a non-boolean `$exists` / `$null` with `INVALID_FILTER` / 400, in the words every driver's `where` refuses it in, instead of reading `$exists` by truthiness and dropping `$null` (#20981)
+
+Clause-②: no (narrowing)
+
+<!-- adr-0087: not-required (already-registered filter-query-face-comparands-refused-at-save) this narrows the engine's own in-process evaluator to the rule that registered entry already records: its reason states that every query face refuses a non-boolean $null / $exists flag, its surface names a query having, the data-engine aggregate call's having and an aggregation filter among the carriers, and its replacement is this change's whole migration (a flag is the boolean itself; $null true is "has no value", $exists true is "has a value"). This change makes that statement true on the per-aggregation filter and having positions, which the engine evaluates itself after the driver. No authorable key, spelling, export or published type moves, and no stored row is read or rewritten; a stored filter carrying such a flag is already refused when it is saved, by that entry. -->
+
+**BREAKING**: this narrows what `aggregate` accepts in two positions, `aggregations[i].filter` and `having`, on every driver. A `$exists` or `$null` comparand that is not a boolean (a string such as `"false"`, a number, `null`, an array) is now refused with `INVALID_FILTER` / 400, before any driver is asked for a row, so an empty table refuses it too, at any depth under `$and` / `$or` / `$not`. A plain object or `undefined` there is refused first by the comparand-type check, in its own words, as before; a `{ $field }` reference there, already refused as a reference outside a scalar comparison, is now refused in this entry's words. The published `applyInMemoryAggregation(rows, ast, timezone, fields)` narrows the same way, per row: it throws the same refusal for a row its per-aggregation filter judges on the flag, with or without a `fields` map (an empty `rows` array, or a row a `$or` branch settles first, is not judged there; `engine.aggregate` judges the whole filter once before any row). It ships as `minor` under the launch-window convention for accept-set narrowings. No export or published type changes.
+
+**Why a refusal.** `FieldOperatorsSchema` declares both flags as booleans, and every driver's `where` refuses any other comparand. The engine evaluates a per-aggregation `filter` and a `having` itself, and it read one anyway. Measured through `engine.aggregate` on the in-memory driver and on `SqlDriver` (SQLite), with identical answers: `$exists` was read by truthiness, so `"yes"`, `1` and the string `"false"` selected the rows and groups WITH a value, and `0` / `null` the ones without; and `$null` tested only `true` / `false`, so any other value constrained nothing, and every row and every group came back.
+
+**What an author sees now.** The message `driver-sql` gives the same flag, beginning `Operator "$exists" on field "FIELD" requires a boolean comparand (true or false).`, naming what arrived and the position (`aggregations[1].filter.stage.$exists`, `having.stage.$null`). Unlike a `where` on `SqlDriver`, the field and the value are not withheld: a per-aggregation `filter` and a `having` never carry a merged read scope.
+
+**What to write instead.** Write the boolean itself. `"$exists": true` and `"$null": false` match a field that has a value; `"$exists": false` and `"$null": true` match one that has none.
+
+**Who is affected.** A caller that reaches `engine.aggregate` without the REST query door's schema parse (server-side code, a flow or hook, the analytics bridge that lowers a dataset measure's filter into an aggregation filter, a host calling `applyInMemoryAggregation` directly) and read the count as a real answer. `POST /api/v1/data/:object/query` already refused all three positions with 400 `VALIDATION_FAILED` before the request reached the engine, and still does.
+
+**Unchanged.** `$exists: true` / `false` and `$null: true` / `false` answer exactly as before, on both positions. `$empty` and every other operator, and `where`.

.changeset/21046-discovery-auth-families.md

@@ -0,0 +1,17 @@
+---
+'@objectstack/spec': minor
+'@objectstack/runtime': patch
+'@objectstack/metadata-protocol': patch
+---
+
+feat(spec): discovery reports which optional `/auth` route families are mounted, starting with the better-auth admin family (`authFamilies.admin`) (#21046)
+
+Clause-②: yes
+
+**New key.** `DiscoverySchema` declares an optional `authFamilies` block, `{ admin: boolean }`. `admin` says whether the better-auth admin family (`{routes.auth}/admin/*`: `list-users`, `set-role`, `update-user`, `ban-user`, …) is mounted on this deployment. On a deployment that does not enable the admin plugin those routes answer a plain `404`, the same as a mistyped path, so a caller checks `authFamilies.admin` before building a URL into the family. `@objectstack/spec/api` also exports the block's schema (`AuthFamiliesSchema`, type `AuthFamilies`) and its reader, `readAuthFamilies(authService)`.
+
+**Same answer as `/auth/config`.** The value is the auth service's own `getPublicConfig().features.admin`, the object `GET /api/v1/auth/config` serves. Both discovery producers read it through `readAuthFamilies`: `getDiscovery()` in `@objectstack/metadata-protocol` (served by `@objectstack/rest` at `GET /api/v1/discovery`) and `getDiscoveryInfo()` in `@objectstack/runtime` (served at `GET /.well-known/objectstack`). Neither re-derives whether the admin plugin is on, so on one boot the two documents and `/auth/config` agree. On a stock boot `authFamilies.admin` is `false`. With the admin plugin on (`plugins.admin: true`, or SCIM, which forces it on) it is `true`.
+
+**When the key is absent.** A producer that cannot read the answer emits no `authFamilies`, rather than a guessed `false`. That happens when no `auth` service is registered (then `routes.auth` is absent too), when the registered service has no `getPublicConfig()`, or when that call throws (`/auth/config` answers `500 AUTH_CONFIG_ERROR` in that state). Treat an absent block as "not known to be mounted".
+
+**What did not change.** No existing key, route or status moved. The unmounted admin routes still answer a plain `404`.

.changeset/21062-picker-queryable-key.md

@@ -0,0 +1,44 @@
+---
+'@objectstack/rest': minor
+---
+
+fix(rest)!: a public form's lookup picker searches and sorts by the first display field the caller may query, so a picker whose first display field is masked for its caller serves its rows instead of answering 403 (#21062)
+
+Clause-②: yes (narrowing)
+
+<!-- adr-0087: not-required (no-migration-prescription) a change of which display field the public lookup picker (`GET /forms/:slug/lookup/:field`) searches and sorts by: the first display field the caller may query, by the security service's answer, where it used to be the first display field. No authorable key, spelling, export or stored shape moves: `@objectstack/rest` exports nothing new and nothing less, `FormFieldPublicPickerSchema` keeps parsing every value it parsed, and no stored row is read or rewritten. A picker's `displayFields` keep their meaning as the projected fields. The other categories are closed on facts: the package publishes (not `unpublished`); no ADR-0087 id covers which field a picker keys on (not `already-registered`); and the change is route behaviour, not a declaration (not `runtime-interface-only` / `type-surface-only`). -->
+
+**BREAKING**: this widens what the public lookup picker serves and narrows it in one composition. The narrowing: with a security service that lacks `ISecurityService.getQueryableFields`, or that answers no answer for the object, the picker passes over every display field whose declaration carries a `maskingRule`, for every caller, including a caller the rule is lifted for. So its search and order move to the next display field that declares no rule, and a picker whose display fields all declare a rule is refused `403 PERMISSION_DENIED` without the engine being asked, where it used to be served. The security service this repository ships implements the method, so a deployment using it is not narrowed. It ships as `minor` under the launch-window convention for accept-set narrowings. No export or published type changes.
+
+**What changed.** The public lookup picker (`GET /forms/:slug/lookup/:field`)
+matches the visitor's search and orders its rows by one key. That key used to
+be the first entry of `publicPicker.displayFields`. It is now the first entry
+the caller may query on, as the security service answers it
+(`ISecurityService.getQueryableFields`). A field whose masking rule applies to
+a caller is served to that caller masked, and the engine refuses to search or
+sort on it with `403 PERMISSION_DENIED`. A picker whose first display field
+declares such a rule therefore answered `403` to every caller the rule applies
+to, on every request. It now serves its rows, sorted and searched on the next
+display field the caller may query. The masked field is still returned in each
+row, masked, as before.
+
+**When no display field is queryable** for the caller, the picker answers
+`403 PERMISSION_DENIED` with the engine's refusal for those fields, without
+running a query.
+
+**Unchanged.** A picker with no masked display field, and a caller the masking
+rule is lifted for, keep the first display field as the key, with the security
+service this repository ships. A deployment with no security service keeps the
+first display field.
+
+**What to do.** Nothing. To choose the field a picker searches when its first
+display field is masked for some of its callers, list a field those callers may
+query among `displayFields`: the first such entry is the one searched and
+sorted on. A picker whose only display fields are masked for its callers is
+refused, so give it one they may query.
+
+**What to do after upgrading, if your security service predates `getQueryableFields`.**
+Implement `getQueryableFields` on it: it answers which fields a caller may filter,
+sort, group or aggregate by, and the picker then keys on the first display field
+in that answer. Until it does, give each picker at least one display field that
+declares no `maskingRule`, or the picker is refused for every caller.

.changeset/21081-activity-field-values.md

@@ -0,0 +1,13 @@
+---
+'@objectstack/plugin-audit': patch
+---
+
+fix(plugin-audit): an activity row serves a parent field's value only to a reader the security service serves that field (#21081)
+
+Clause-②: no
+
+The activity stream's CRUD mirror composes each row once, at write time, as the system. The row's summary, its record label and its recorded change can carry the values of the parent record's fields. The activity read gate keeps a row for every reader who can read the parent record, so a reader who may not read one of that record's fields was served the field's stored value through the row. This held for a field served masked to the reader, a field gated by `requiredPermissions` the reader does not hold, and a field a permission set the reader holds marks non-readable. The data plane answered the same reader masked or without the key.
+
+The rows are now redacted at read time, keyed on the reading caller, through the security service's own answer: the read projection intersected with the query-side answer, whose difference the contract defines as exactly the fields served masked. The recorded change drops every key the reader is not served. The summary and the record label are each served whole or dropped whole: the mirror now declares, in the row, which parent fields each was composed from, and a text composed from a field the reader is not served is dropped. A text composed only from served fields is kept. The full row stays at rest, and system reads are unchanged.
+
+Rows written before this release carry no such declaration. Their summary and record label are served only to a reader who is served every field of the parent record, until the rows age out with the stream's retention. Rows an app writes itself are served as written, except that a recorded change in the mirror's shape is narrowed the same way.

.changeset/21106-error-code-ledger-provenance-rows.md

@@ -0,0 +1,14 @@
+---
+'@objectstack/spec': minor
+---
+
+`ERROR_CODE_LEDGER['@objectstack/service-automation']` now lists `MAPPING_NOT_FOUND` and `UNSUPPORTED_TRANSFORM`, the two registered codes the connector sync executor (`pullConnectorSource`) stamps onto `ConnectorPullError.code` (#21106).
+
+Clause-②: yes
+
+Provenance, not identity. The per-package face of `ERROR_CODE_LEDGER` changes in this release in two steps, and neither changes the `ErrorCode` union, the wire or any HTTP answer:
+
+- The bulk-import runner, the mapping pipeline and the data-error classification moved out of `@objectstack/rest` (#20919), and each code's row moved to the package that now stamps it. `@objectstack/core` gains `AMBIGUOUS_MATCH`, `BLANK_MATCH_KEY`, `NO_MATCH`, `SUMMARY_RECOMPUTE_FAILED` and `UNSUPPORTED_TRANSFORM`. A new `@objectstack/types` key lists `CONCURRENT_UPDATE`, `ERR_DATASOURCE_UNAVAILABLE` and `UNIQUE_VIOLATION`. `@objectstack/rest` no longer lists those seven, because it stamps none of them now; it keeps `UNSUPPORTED_TRANSFORM`, which it still stamps.
+- `@objectstack/service-automation` gains the two rows above. Both codes were already registered, under `@objectstack/rest` (and `UNSUPPORTED_TRANSFORM` under `@objectstack/core` as well).
+
+So a consumer reading `ERROR_CODE_LEDGER['@objectstack/rest']` sees seven fewer entries, and one reading the `@objectstack/core`, `@objectstack/types` or `@objectstack/service-automation` key sees the new ones. Nothing to migrate: every code keeps its wire value and its status.

.changeset/21113-turso-remote-autonumber.md

@@ -0,0 +1,42 @@
+---
+'@objectstack/driver-turso': minor
+'@objectstack/driver-sql': patch
+---
+
+feat(driver-turso): the remote transport issues `auto_number` values (#21113)
+
+Clause-②: yes (widening)
+
+A `create()`, `bulkCreate()` or `upsert()` on the Turso REMOTE transport that
+leaves an `autonumber` field empty (`undefined`, `null` or `''`) now gets a
+generated value. It used to be refused with `NOT_IMPLEMENTED` / 501, so on a
+hosted tenant database — which is on this transport — no object declaring an
+`auto_number` field could get a new record at all. Nothing is declared anew in
+the spec or in the package exports; `supports.autonumber` stays `true` and is
+now honoured.
+
+- The value comes from the same persistent `_objectstack_sequences` counter the
+  local and embedded-replica transports use, rendered by the same format rules
+  (`autonumberFormat` / `format`, organization scope, date and `{field}`
+  tokens), bootstrapped from the table's highest existing value by the same
+  reading, and re-seeded the same way after rows land above the counter by a
+  seed replay or import. A remote driver and an embedded replica of one
+  database draw from one counter row.
+- The counter moves in one statement over the connection (`UPDATE … RETURNING`,
+  or on a cold counter `INSERT … ON CONFLICT (key_hash) DO UPDATE … RETURNING`),
+  so writers in different processes never draw the same number.
+- An `upsert()` that merges into an existing row keeps the number already in
+  the row; a row that carries its own number is written unchanged.
+- A `_objectstack_sequences` table in the pre-`key_hash` shape is refused in
+  remote mode with `DATABASE_ERROR` / 500 and the remedy in the message (open
+  the database once through the local or embedded-replica transport, which
+  migrates it); remote mode does not migrate it and does not key by the legacy
+  rule.
+- `RemoteTransport.upsert()` takes an optional fifth argument naming columns
+  that are written on insert and left alone on merge.
+
+`@objectstack/driver-sql`: the sequence rules a second transport shares are
+now `protected` members of `SqlDriver` (`resolveSequenceTenantId`,
+`defineSequencesTable`, `maxAutonumberCounter`, `escapeLikePrefix`,
+`sequencesTableName`, `autoNumberCollisionRetries`). No export is added and no
+behaviour changes on any dialect.