Merge remote-tracking branch 'origin/main' into claude/issue-14945-flow-end-node-refused-outcome

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/app-plugin-flat-bundle-seed-double-collect.md

@@ -0,0 +1,32 @@
+---
+"@objectstack/runtime": patch
+---
+
+fix(runtime): a flat-manifest bundle no longer collects every seed dataset twice
+
+`AppPlugin.start()` collects seed data from two locations — the top-level
+`data` field, then the legacy `manifest.data` for backward compatibility. The
+legacy read resolves its base as `this.bundle.manifest || this.bundle`, so on a
+FLAT bundle — manifest fields written directly on the bundle rather than nested
+under `manifest:`, a shape `AppPlugin` supports by design and this repo's own
+tests construct — it re-read the very array the top-level read had just
+contributed. Every dataset landed in the collection twice.
+
+`mergeSeedDatasets` is a plain `push` with no de-duplication, so both copies
+reached the shared `seed-datasets` registry, the inline boot seed, and every
+later per-org replay. For an `upsert` dataset with an `externalId` the second
+pass is idempotent and the cost is doubled work; for a `mode: 'insert'` dataset
+it is the dataset APPLIED TWICE per boot — measured here as two `insert` calls
+for one record.
+
+The legacy read now carries the same reference guard its sibling collector has
+always carried: `loadTranslations()` performs the identical two-location read
+and skips the legacy half when `manifest.translations` IS the array the top
+level already contributed. That asymmetry between the two collectors was the
+whole defect, so the repair is the sibling's guard rather than a third spelling
+of the same idea.
+
+⛔ Not a removal of the legacy read: a bundle whose `manifest.data` is a
+genuinely different array from its top-level `data` still contributes both, and
+a bundle that nests its manifest is unaffected either way. Nothing is added to
+or removed from any published surface.

.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/filter-text-operator-declared-type-door.md

@@ -0,0 +1,17 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec)!: a text operator over a field whose DECLARED type can never store a string is refused at the engine's field-aware door — the contract rows (#15661)
+
+<!-- adr-0087: not-required (no-migration-prescription) nothing is renamed, retired or respelled: no metadata key, export or operator changes shape, so `objectstack migrate meta` has nothing to rewrite; an author's remedy is to drop or retarget the mistaken filter condition, which is a change to the query they meant, not to a spelling -->
+
+**BREAKING** accept-set narrowing, declared here and enforced at the engine door: a text operator (`$contains` / `$notContains` / `$startsWith` / `$endsWith` / `$icontains` / `$like` / `$ilike`) over a field whose DECLARED type is numeric, boolean, temporal (`date` / `datetime` / `time`) or structured JSON is refused before any driver runs — `INVALID_FILTER` / 400, naming the field and its declared type — instead of answering `[]` or a dialect accident. Shipped as `minor` under the repo's launch-window convention for breaking changes. Maintainer ruling 2026-09-05 on #15661 (director decision batch #43, verbatim 「同意」): option C-deny.
+
+The refused set is the union of six EXISTING classes in `field-value.zod.ts`, by reference — `NUMERIC_VALUE_TYPES` ∪ `BOOLEAN_VALUE_TYPES` ∪ `CALENDAR_DATE_TYPES` ∪ `INSTANT_TYPES` ∪ `CLOCK_TIME_TYPES` ∪ `STRUCTURED_JSON_TYPES` — so no new vocabulary is minted and a member added to one of those sets later is refused without a change here. String-valued classes pass: `STRING_VALUE_TYPES`, `autonumber`, the option-code classes (single and multi — `tags` included), the record-id classes, and the file classes. `formula` is judged as the field type its declared `returnType` names (`text` passes; `number` / `boolean` / `date` are refused) and is deferred — not judged — when `returnType` is absent. A dotted path into a structured-JSON field stays unjudged, as `filter-dotted-head` already declares.
+
+New on `@objectstack/spec/data` (`filter-text-operator-declared-type.ts`): `TEXT_FILTER_OPERATORS` (pinned equal to `StringOperatorSchema`'s keys), `TEXT_OPERATOR_DOOR_REFUSED_TYPES` / `TEXT_OPERATOR_DOOR_PASSING_TYPES`, `FORMULA_RETURN_TYPE_AS_FIELD_TYPE`, the pure verdict `textOperatorDoorVerdict`, the class table `TEXT_OPERATOR_DOOR_TYPE_CLASSES` (every `FieldType` member exactly once — pinned as a census), the fixture object `TEXT_OPERATOR_DOOR_FIXTURE`, and the derived case table `TEXT_OPERATOR_DOOR_CASES` the engine suite consumes.
+
+The door itself lands in `@objectstack/objectql` under its own engine-lane card (beside the `INVALID_FIELD` unknown-field door, judged against the object's real field map, before any driver dispatch); this changeset is the contract half. Beneath the door nothing moves: a direct driver call — and every evaluator no door fronts — keeps answering `FILTER_TEXT_CASES`' stored-value row (#14079), and the SQL faces' compile-time type-gate set `NON_TEXT_STORED_VALUE_TYPES` stays numeric + boolean, deliberately narrower than the door's set.
+
+What an author sees after the door lands: a condition such as `{ amount: { $contains: '5' } }` over a `number` field, which used to answer an empty list with no signal, is refused with a message naming `amount`, `number` and `$contains`. The condition was a mistake in every measured occurrence (a substring over a number can never match); drop it, or aim it at the text field that was meant.

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