Merge remote-tracking branch 'origin/main' into claude/issue-15705-screen-headless

Author: claude

.changeset/analytics-text-family-case-exact-per-dialect.md

@@ -0,0 +1,18 @@
+---
+"@objectstack/service-analytics": minor
+"@objectstack/driver-sql": minor
+---
+
+The analytics SQL compilers compile the case-sensitive text family per dialect, so a `$contains` policy on SQLite stops admitting rows it excludes (#15684)
+
+`$contains` / `$notContains` / `$startsWith` / `$endsWith` are case-SENSITIVE on every backend (#4706 Q2 = A). All three of `service-analytics`' SQL compilers emitted `col LIKE ? ESCAPE ?` on every dialect, and SQLite's `LIKE` folds ASCII case unconditionally — the fold cannot be turned off per statement, because `PRAGMA case_sensitive_like` is a connection-global switch. Measured on sql.js over the shared `FILTER_TEXT_ROWS` fixture, `{ name: { $contains: 'acme' } }` answered `['1','2']` — `ACME Corp` **and** `acme corp` — where `FILTER_TEXT_CASES` says `['2']`.
+
+On two of the three compilers that is a wrong chart. The third is `read-scope-sql.ts`, the ADR-0021 D-C read scope: a scope that **admits** rows the policy's case-sensitive predicate excludes is over-reach, not a loose filter — the same reading that file already applied to its own `LIKE` escaping. The `/analytics/sql` echo was wrong in a third way: it printed `LIKE` while the statement it claims to reproduce ran through a driver that has emitted `GLOB` on the SQLite dialects since #6518.
+
+What changed:
+
+- **The construct is chosen per dialect** (`text-match-sql.ts`), arm for arm with `driver-sql`'s own table: `GLOB` on SQLite (case-exact by definition, with its own `*` / `?` / `[` escaped class and no `ESCAPE` clause), `LIKE` over `CAST(… AS BINARY)` on MySQL, and `LIKE` **unchanged** on Postgres, where it is already exactly the ruled semantics. There is no single construct that is case-exact and parses on all three, so the dialect had to become an input rather than a guess.
+- **The dialect arrives from the driver that will execute the statement.** New optional `AnalyticsServiceConfig.sqlDialect`, wired by `AnalyticsServicePlugin` from `IDataEngine.getDriverForObject`. `SqlDriver.dialectName` is now public so that answer can be read without a second dialect-resolution table drifting behind the driver's own knex spellings; it is derived and read-only.
+- **A host that answers no dialect keeps the `LIKE` it always got** — "cannot answer, do not block". Postgres deployments see byte-identical SQL.
+
+`$icontains` is untouched: it keeps its own ASCII-only fold on both sides, and collapsing the two families onto one path would hand the case-exact family back the fold the ruling took away from it. `LIKE` escaping is unchanged wherever a `LIKE` is still emitted.

.changeset/bulk-event-batch-organization.md

@@ -0,0 +1,51 @@
+---
+"@objectstack/objectql": patch
+---
+
+fix(objectql): a published `BulkDataEvent` now names the ONE organization the tenant wall named for the batch
+
+`BulkDataEventSchema.organizationId` (`@objectstack/spec/api`, declared by the
+contract half) is one organization for a whole predicate write, or absent. The
+only bulk producer — `publishBulkDataEvent`, behind the `multi: true` branches
+of `update()` / `delete()` — never set it, so every `data.records.updated` /
+`data.records.deleted` event read "not asserted" and a tenant-scoped consumer
+could deliver nothing per organization on the bulk path. This is the bulk half
+of the cross-tenant webhook fan-out leak; the single-record half (`DataEvent`)
+landed separately.
+
+The producer now stamps the key from what it already holds — no second query
+on the publish path: under `isolated` the caller's active organization (the
+Layer 0 wall's equality term), under `group` the caller's membership set when
+it names exactly one organization. It is OMITTED — never the caller's active
+organization standing in — on a `single`-posture deployment, on an `isSystem`
+context (no wall composed), on a multi-membership `group` sweep, when no
+enforcement layer injected a posture (the `OS_TENANCY_POSTURE` env fallback is
+deliberately not consulted), when the caller may have crossed the wall as a
+`PLATFORM_ADMIN` or carries no resolved posture rung, and on an object the wall
+does not key on. `absent` here means "the producer did not assert one
+organization for the batch", deliberately NOT the `DataEvent` reading
+"belongs to no organization".
+
+Which objects "the wall does not key on", stated exactly rather than claimed as
+a mirror: plugin-security's Layer 0 composes no wall when its `tenancyDisabled`
+input is true or the object carries no `organization_id`, and it folds THREE
+clauses into `tenancyDisabled` — `tenancy.enabled === false`,
+`systemFields.tenant === false`, and the deployment's `platformGlobalObjects`
+carve-out. The producer reads the registry's binding of that predicate
+(`carriesTenantScopeColumn`: the first two clauses plus the column clause) and
+answers absent on a federated (`external`) object; a custom
+`tenancy.tenantField` is therefore not an exit by itself — the object is walled
+iff it carries `organization_id`, and the key follows the wall. The third
+clause is deployment-declared and not readable by the engine: a
+deployment-exempted object under an armed wall is still stamped with the
+caller's organization by this producer alone, and that population's exact
+answer is decided by the seam ruled on in #15706.
+
+`patch`, not `minor`: the act adds no member to this package's published
+surface. `carriesTenantScopeColumn` is exported at module level inside
+`registry.ts` only — `@objectstack/objectql`'s entries (`.`, `./core`) re-export
+named members and never `export *`, so `dist/index.d.ts`, `dist/core.d.ts` and
+both entries' runtime export lists are unchanged (measured on the built `dist`,
+with a firing control) — and the emitted event's member was declared, typed
+and paid for at `minor` by the spec half. Producer conformance to an existing
+optional member under `fix(` changes no public surface of this package.

.changeset/flow-edge-id-uniqueness.md

@@ -0,0 +1,64 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec)!: `FlowSchema` refuses a flow whose `edges[]` declares the same id twice (#14964)
+
+<!-- adr-0087: not-required (no-migration-prescription) No authorable key is renamed, retired or re-typed: `edges[].id` keeps its name, its type and its describe, and every flow whose edge ids are unique parses byte-identically. The only newly refused shape is two edges sharing one id — a collision, not a spelling — and its remedy is to renumber one of the two, which is authoring intent no `objectstack migrate meta` rewrite can choose for the author. The Zone-2 census over this repo (776 `edges[]` arrays, 1,098 edges under `packages/**` and `examples/**`, with a lit control) found zero instances, so there is no in-repo file to name. -->
+
+**BREAKING** accept-set narrowing on `FlowSchema` — a flow whose `edges[]`
+carries two edges with the same `id` is now **refused at parse time** — by
+`FlowSchema.parse` / `safeParse`, `defineFlow`, and every door that validates a
+flow through the schema (`objectstack validate`, the runtime publish gate, a
+stack's `flows[]`) — where it used to parse on green. Shipped as `minor` under
+the repo's launch-window convention for breaking changes. Maintainer ruling
+2026-09-05 on #14964 (director decision batch #40, verbatim 「同意」): option
+A — an `error`, not a `warning`; no opt-out, no transition window.
+
+Every reader of an edge id assumes the ids in a flow are unique — a designer,
+a BPMN export, a flow diff, any traversal that dedupes by id — and nothing
+enforced it. A real duplicate (`id: 'e20'` on two edges of one flow) shipped
+through two releases of green CI in a downstream app and was inert only
+because the engine keys out-edges by `source`, never by `id`: the collision is
+invisible until something keys on ids, and then silently wrong rather than
+loudly broken. The id space is hand-authored, so the next author picking a
+"free" id from the sequence had no way to know it was taken.
+
+**What changes** (`packages/spec/src/automation/flow.zod.ts`): a `superRefine`
+on the flow's `edges[]`. Each later occurrence of an already-declared id raises
+one `custom` issue, anchored at `edges[N].id` of the *later* edge and naming
+both positions, so the formatted error points at the edge to renumber:
+
+```text
+✗ edges.7.id: Duplicate edge id `e20` — `edges[7]` reuses the id already declared by `edges[3]`; every edge id in a flow must be unique. Renumber one of them: …
+```
+
+**What does NOT change:** `edges[].id` keeps its name, type and describe; the
+node vocabulary, the edge `type` enum and every other refusal are untouched;
+a flow with unique edge ids (or no edges) parses exactly as before. Node ids
+are not covered by this change.
+
+The shape that is refused, and what the author does about it — a two-edge
+excerpt, the later edge renumbered:
+
+```ts
+// before — parsed on green, both edges keyed 'e20'
+edges: [
+  { id: 'e20', source: 'qualify', target: 'convert' },
+  { id: 'e20', source: 'convert', target: 'end' },
+]
+
+// after — refused at parse (edges.1.id: Duplicate edge id `e20` …); renumber the later one:
+edges: [
+  { id: 'e20', source: 'qualify', target: 'convert' },
+  { id: 'e21', source: 'convert', target: 'end' },
+]
+```
+
+**Remedy.** Renumber the later edge to an id no other edge in that flow
+carries; nothing else in the flow needs to move. The census over this
+repository found no flow to migrate, so this is a release note, not a
+migration: no shipped example, fixture or seed in `packages/**` or
+`examples/**` declares a duplicate edge id, and the pinned objectui tree
+carries none in its authored flows. The one known downstream instance was
+renumbered before this change (hotcrm PR #1571).

.changeset/great-clouds-repair.md

@@ -0,0 +1,7 @@
+---
+'@objectstack/plugin-hono-server': patch
+---
+
+`GET /auth/me/localization` answers the deployment's resolved `currency` and `timezone` instead of `null`
+
+The handler read both off the request `ExecutionContext`, citing ADR-0053, but the resolver serving this surface is a hand-rolled envelope that never carried them — so every authenticated caller was answered `currency: null, timezone: null` whatever the `localization` settings said, and the console's regional-formatting seed was fed nulls. All three values now come from one reading of the same `resolveLocalizationContext` cascade the dispatcher's shared assembler uses. `locale` resolution is unchanged. `timezone` now always answers (cascade floor `UTC`); `currency` still answers `null` when the deployment configures none — that value has no floor.

.changeset/i18n-declared-fallback-chain-rest.md

@@ -0,0 +1,27 @@
+---
+"@objectstack/rest": patch
+---
+
+fix(rest): metadata label lookup honours the stack's declared `i18n.fallbackLocale` / `defaultLocale` instead of falling through to the `en` bundle (#14882)
+
+On a workspace whose labels are authored in `zh-CN` (`defaultLocale: 'zh-CN'`,
+`fallbackLocale: 'zh-CN'`) and which ships only a courtesy `en` translation bundle,
+`GET /api/v1/meta/object/:name`, the `/meta/:type` list, `GET /api/v1/meta` and the
+public-form schema served the ENGLISH bundle labels to a `zh-CN` request (`Entry Sheet`
+for an authored `填报单`, `KPI Assessment` for `KPI 考核管理`). The document translators walk
+`requested locale → fallback chain → authored label` and default the chain to a literal
+`['en']`; every REST seam passed none, so the declared fallback never reached the chain
+and `en` was consulted before the authored label.
+
+Every metadata translation seam now passes `fallbackChain: [i18n.getFallbackLocale()]` —
+the locale the i18n service's own `t()` falls back to, which `I18nServicePlugin` receives
+from the stack config as `fallbackLocale || defaultLocale || 'en'`. For the workspace
+above a `zh-CN` request now resolves `zh-CN → zh-CN → authored label` (the authored
+Chinese labels), an `en` request still gets the `en` bundle, and a `zh-CN` bundle, when one
+is shipped, still wins over the authored label.
+
+Feature-detected: an i18n service that does not declare a fallback (the method is
+optional on `II18nService`; the core in-memory fallback has none) gets no chain and the
+resolver's own default applies exactly as before. A stack declaring `defaultLocale: 'zh-CN'`
+with `fallbackLocale: 'en'` is likewise unchanged — the declared `en` is honoured as it
+reads.

.changeset/i18n-declared-fallback-chain-service.md

@@ -0,0 +1,11 @@
+---
+"@objectstack/service-i18n": minor
+---
+
+feat(service-i18n): `FileI18nAdapter.getFallbackLocale()` reports the `fallbackLocale` the adapter was constructed with (#14882)
+
+Implements the new optional `II18nService.getFallbackLocale()`. `I18nServicePlugin`
+already receives `fallbackLocale || defaultLocale || 'en'` from the stack's `i18n`
+config on both boot paths (`os serve`, the dev plugin); this makes that declaration
+readable, so the REST metadata reads pass the document translators the same fallback
+locale `t()` itself consults. Returns `undefined` when no `fallbackLocale` was given.

.changeset/i18n-declared-fallback-chain-spec.md

@@ -0,0 +1,26 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec): `II18nService.getFallbackLocale()` — the declared fallback locale is readable, so the metadata-document translators can be handed the chain the deployment declared (#14882)
+
+`ResolveOptions.fallbackChain` on the `@objectstack/spec/system` label
+resolvers (`translateMetadataDocument`, `translateObject`, `translateApp`,
+`resolveViewLabel`, …) is the ordered list of locales consulted after the
+requested one and BEFORE the authored label. Nothing on `II18nService`
+exposed the deployment's declared fallback (`i18n.fallbackLocale`, else
+`defaultLocale`), so no serving layer could thread it, and every caller fell
+to the resolver's literal `['en']` default. A `zh-CN` workspace that shipped a
+courtesy `en` bundle therefore served English bundle text to a `zh-CN`
+request ahead of its own authored Chinese labels.
+
+- New optional contract member `II18nService.getFallbackLocale?(): string | undefined`
+  — the locale the service's own `t()` consults second. `undefined` (or the
+  method absent) means nothing was declared, and a serving layer must then
+  leave the resolver's default in place rather than invent a chain.
+- The `fallbackChain` documentation now states who supplies it (the serving
+  layer, from `getFallbackLocale()`) and that the `['en']` default applies
+  only when a caller declares no chain at all. The resolver's behaviour for
+  a caller that passes nothing is unchanged.
+
+Additive: no existing implementation or caller changes shape.

.changeset/injected-system-column-labels-localised.md

@@ -0,0 +1,7 @@
+---
+"@objectstack/spec": patch
+---
+
+The tenant-scope and owning-business-unit system columns now render a localised display name on the `/meta` read exits, as the other platform-injected columns already did.
+
+`translateObject` carries a built-in label table for the columns the platform injects onto every eligible object, applied while a column still carries its injected English default, so a `zh-CN` / `ja-JP` / `es-ES` request never sees the English label on a custom object that ships no translation entries of its own. The table covered `owner_id`, `created_at`, `created_by`, `updated_at` and `updated_by` but not the two remaining injected columns, `organization_id` (`Organization`) and `owning_business_unit_id` (`Owning Business Unit`), so those two leaked English on every locale. Both rows are added, with the wording the platform bundles already use for the same columns on platform objects. The identity-stable column definitions are untouched, no new authorable key is introduced, and a label a tenant or author customised is still never overridden.

.changeset/lint-non-record-collection-entry.md

@@ -0,0 +1,11 @@
+---
+"@objectstack/lint": patch
+---
+
+No authoring rule throws on a non-record entry of any stack collection.
+
+A collection is authored either as a list or as a name-keyed map, so every rule that reads one coerces `unknown` into an array of records first. That coercion had been hand-copied into 39 modules, and 23 of the copies spelled the array branch as an unchecked cast — every member was asserted to be a record. A YAML list item left empty deserialises to `null`, so a single stray `-` under `flows:`, `pages:`, `dashboards:`, `datasets:`, `apps:`, `permissions:`, `capabilities:`, `data:`, `hooks:`, `views:`, `actions:`, `translations:` (or a per-object `fields:` / `actions:` / `views:`) reached a property read on `null` and threw a stack trace out of `os lint` / `os validate` instead of reporting a finding. The rules are pure `(stack) => Finding[]` running on the raw path, so nothing upstream had judged the entry's shape.
+
+Twenty-two of those readers now read through the shared, guarded `recordsOf`, which drops a non-record member of the array shape whole and keeps the author's key on the map shape. Nothing else about what the rules judge changes: a valid entry standing beside a junk one is still read, and still draws exactly the findings it drew before.
+
+The remaining copies are pinned by a new source-text test in the package, so the predicate cannot be pasted back in: it asserts that `recordsOf` is the only collection coercion, that every module still holding a private one is named in a dated ledger that is exact in both directions, and that no coercion outside a dated single-file allowance casts its array branch unchecked.

.changeset/report-chart-axis-own-selection.md

@@ -0,0 +1,27 @@
+---
+"@objectstack/lint": patch
+---
+
+`chart-axis-not-selected` resolves a report chart against its own `chart.yAxis`, not `report.values` (#15734)
+
+**Behaviour change — one false finding removed on the report surface.** A report chart whose `chart.yAxis` names a declared measure that `report.values` does not select no longer raises a `chart-axis-not-selected` warning. Nothing else about the rule moves, and no other surface moves at all.
+
+The warning stated a query consequence the renderer refutes. Read at the `@object-ui` revision this repo pins (`.objectui-sha`), `plugin-report/src/DatasetReportRenderer.tsx` does not query `report.values` for the chart at all — it runs the chart's own, narrower query out of the two axis strings:
+
+```
+const state = useDatasetRows(
+  dataset,
+  plan.kind === 'series' && xAxis ? [xAxis] : [],
+  wantsQuery && yAxis ? [yAxis] : [],
+```
+
+and says so in that file's own words at the `scopeOrder` docblock: *"the embedded chart queries only `chart.xAxis` × `chart.yAxis`"*. So the measure the warning said "the query does not return" is exactly the one the query asks for, and the chart plots it. `report.values` is the selection of the TABLE beneath the chart.
+
+Both limbs follow from that one measurement:
+
+- **No not-selected check at the report `chart.yAxis`.** That position IS the chart's query, so it cannot fail to select itself. `chart-measure-unknown` there is untouched: an UNDECLARED measure is still no column at all, and still an `error`.
+- **`chart.series[].name` resolves against the singleton `{ chart.yAxis }`.** The entry is a display-name override paired with a DERIVED series, and the chart derives exactly one (`buildChartSeries(…, [xAxis], [yAxis], …)`). An entry naming `chart.yAxis` now lands however the table is selected, and one naming any other declared measure is still reported — including a measure `report.values` does select, which it could not reach before.
+
+The list-view and page-component surfaces are unchanged, and carry firing controls that say so: on both, `values` IS the measure set the query asks for (`ObjectView` hands it to the chart; `ObjectChart` queries `{ dimensions: schema.dimensions, measures: schema.values }`), so the existing resolution is the right one there.
+
+The per-position tier and consequence wording is untouched — only the SET the report surface resolves against moves.