Merge remote-tracking branch 'origin/main' into claude/issue-15731-type-check-gates-skip-gitignored

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/blueprint-strict-mirror-value-parity.md

@@ -0,0 +1,15 @@
+---
+"@objectstack/spec": minor
+---
+
+The model-facing solution-blueprint mirror can no longer generate an identifier the applier rejects.
+
+`SolutionBlueprintSchema` (what `apply_blueprint` validates against) and `SolutionBlueprintStrictSchema` (the OpenAI-strict structured-output contract the design model generates against) are two declarations of one shape. Their KEYS were pinned by an existing parity test; their VALUES had never been. Every identifier in the lenient schema carried `.regex(/^[a-z_][a-z0-9_]*$/)` and not one identifier in the strict mirror carried it — 20 leaves apart, measured.
+
+The consequence was a build whose approval did nothing. Asked for a CRM, the design model emitted a `company_size` select whose option values came straight off the labels — `1_49` for 「1-49人」. Generating that was legal. Applying it was not: on the turn the user clicked 「确认，开始搭建」 the deterministic confirm replay handed that exact blueprint to `apply_blueprint`, which refused it wholesale (`objects.0.fields.2.options.0.value: Invalid string: must match pattern /^[a-z_][a-z0-9_]*$/`) and staged nothing. The app appeared only because the model noticed the error card and retried with a repaired blueprint the user had never seen.
+
+Every identifier leaf in the strict mirror now carries the same `SNAKE_CASE` constraint the lenient schema enforces — object / field / view / dashboard / widget / app / nav names, `reference`, `nameField`, `columns`, `groupBy`, `measure`, roll-up `object` / `field` / `relationshipField`, condition `field`, and select option `value`. The constraint is emitted into the JSON Schema the model is given (`pattern`), so an out-of-pattern identifier is refused at generation instead of after approval. Option `value` additionally spells out the case that produced the incident: it may never start with a digit, so 「1-49人」 is authored as `size_1_49` — the `label` keeps the human wording untouched, and only the stored value is an identifier.
+
+A new `strict mirror ↔ lenient schema — VALUE parity` test walks both schemas leaf by leaf and fails on any future divergence, the value-side twin of the key-parity gate that already guards this pair.
+
+Refs cloud#1967.

.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/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/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.

.changeset/serve-unlinked-database-file-watch.md

@@ -0,0 +1,11 @@
+---
+"@objectstack/cli": patch
+---
+
+`os serve` now says so when the SQLite file it is serving is no longer the file at its configured path.
+
+Deleting the data directory under a running server — `rm -rf .objectstack/data`, which is what a `demo:reset` script does and what a fresh-database repro starts with — unlinks the inode without touching the process. SQLite keeps reading and writing the now-invisible file, health keeps answering `200`, and a later boot creates a brand-new database at the same path. From that moment every filesystem inspection of that path describes a *different* database than the running server answers from, and nothing anywhere says so: a row edited there has no observable effect on the live server, and a user who authenticates against the live server is not in that file. Both readings are true, both look like a broken write path, and one investigation that reported them as evidence cost a full P0 cycle.
+
+A boot that serves an on-disk SQLite file now records that file's identity once the boot is complete and re-checks it on a 30-second interval. When the file is gone, or the path holds a different file, it reports **once** at `error` — naming the path, the consequence (every external observation of this deployment is now false, and it will keep looking healthy) and the fix (restart the server so it opens the file that is at that path now).
+
+It refuses nothing and retries nothing: the running server is still correct, merely invisible, and breaking a working dev loop to fix a reporting gap would trade a bad hour for a worse one. Nothing is added to any payload, endpoint or state file. Silence from the check is not a claim that the file is intact — every uncertainty in it resolves toward staying quiet, because a false report would send an operator to restart a server whose database is fine.