Merge remote-tracking branch 'origin/main' into claude/sync-12718-local

Author: claude

.changeset/action-param-excess-keys-compile.md

@@ -0,0 +1,22 @@
+---
+"@objectstack/spec": patch
+---
+
+fix(spec): `ObjectSchema.create()` rejects unknown keys on nested action-param literals at compile time (#12615)
+
+`create()` infers its generic from the argument, so TypeScript's
+excess-property (freshness) checking never fires at any depth; the existing
+`NoExcessObjectKeys` map compensated only at the top level. A typo'd key on an
+`actions[].params[]` literal (measured: `carryOverX` on
+`sys-permission-set.object.ts`) therefore passed `tsc` clean and was caught
+only by `ActionParamSchema`'s strict parse at module load.
+
+The same `Record<excess-key, never>` map is now mirrored over each element of
+each action's `params` array, so the typo becomes a located `tsc` error at the
+authoring site (`error TS2322 … 'true' is not assignable to 'never'` pointing
+at the unknown key).
+
+Compile-layer signal only — shipped as `patch` because no working code
+changes meaning: the strict parse at module load stays the enforcement of
+record, nothing changes in what parses or when, and every literal the new
+constraint refuses was already refused (later, at import) by that parse.

.changeset/analytics-bridge-engine-aggregate-vocabulary.md

@@ -0,0 +1,33 @@
+---
+"@objectstack/service-analytics": patch
+---
+
+refactor(service-analytics): derive the analytics auto-bridge's engine view from the declared contracts (#11833)
+
+`plugin.ts` named the data engine through a consumer-local structural
+`DataEngineLike` — the second of the two sites #11833 records, after the
+datasource half that landed as PR #12011. It is now derived from the declared
+contracts: `IDataEngine.aggregate` / `execute?` /
+`resolveEffectiveDatasource?` / `getDriverForObject?` and
+`IObjectQLEngine.getObject`. Optionality is preserved exactly — `aggregate`
+required, everything else `Partial<>` — because these probes are the plugin's
+graceful-degradation seam.
+
+**Why this is `patch` and not a type-only no-op.** Four of the five members
+substitute with no behaviour change. The fifth does not: the deleted structural
+type declared `aggregations[].function` as `string`, while the contract
+declares the six-value `AggregationFunction`. The bridge therefore forwarded
+whatever method string reached it. That forward is now parsed with the spec's
+own enum, so a method the engine contract does not declare is refused at the
+bridge — loudly, naming the aggregation and the legal vocabulary — instead of
+reaching the engine, where `driver-sql` blamed a `function` key the author
+never wrote and the in-memory evaluator answered `null` for every bucket under
+the author's own measure name.
+
+No authored analytics can trigger the new refusal: the one reachable producer
+of a non-aggregate method — a custom-SQL measure (`AggregationMetricType`
+`number` / `string` / `boolean`) — is already refused earlier, caller-facing,
+by `ObjectQLStrategy.resolveMeasureAggregation` (#12209). What is left is host
+drift (a cube object registered without meeting `CubeSchema`), which is why
+the new refusal is a bare `Error` in the undeclared-500 tier rather than an
+ADR-0112 400 that would blame the caller for something they did not write.

.changeset/analytics-dataset-query-user-message.md

@@ -0,0 +1,75 @@
+---
+"@objectstack/rest": patch
+---
+
+fix(rest): `/analytics/dataset/query` carries a producer-marked `userMessage` on its three hand-built terminals (#12710)
+
+`POST /api/v1/analytics/dataset/query` (and its environment-scoped twin) builds
+its error envelopes by hand and shares no exit with the `/data` door, so #9934's
+producer-marked `userMessage` — a channel that door applies once at its exit,
+branch-agnostically, through `withDeclaredUserMessage` — was applied at none of
+them. A producer's caller-facing sentence reached the client on
+`POST /data/:object` and vanished here for the identical throw.
+
+**Scope is by ARM.** Four terminals live in that route's catch; three dropped
+the mark and one did not:
+
+| arm | envelope | before |
+| :-- | :--- | :--- |
+| ① declared 4xx ADR-0112 passthrough | hand-built `{ code, message }` | ⛔ no mark |
+| ①b `classifiedRefusalAnswer` re-dress | `{ ...refusalFields, message }` | ✅ carried it |
+| ③a declared 5xx relay | `declaredServerFaultAnswer`'s body, sent verbatim | ⛔ no mark |
+| ③b generic `500 ANALYTICS_QUERY_FAILED` | hand-built `{ code, error }` | ⛔ no mark |
+
+①b already carried it because its body comes from `resolveErrorResponse`, whose
+arms ride the mark already. The other three hold no classification to ride on.
+
+Measured on `4af6c4419` before the repair, one marked producer per arm, driven
+through the real route against the flat `/data` door for the identical throw:
+
+```text
+throw { code: 'INVALID_FILTER', status: 400, userMessage: 'Check the filter…' }
+  ① analytics : 400 {"code":"INVALID_FILTER","message":"…"}          — no mark
+  /data door  : 400 {"error":"…","code":"INVALID_FILTER",
+                     "userMessage":"Check the filter…"}              — mark carried
+
+throw { code: 'READ_SCOPE_COMPILE_FAILED', status: 500, userMessage: '…' }
+  ③a analytics: 500 {"error":"Internal server error",
+                     "code":"READ_SCOPE_COMPILE_FAILED"}             — no mark
+  /data door  : 500 {…, "userMessage":"…"}                           — mark carried
+
+throw Error('[Analytics] no strategy can handle query …') + userMessage
+  ③b analytics: 500 {"code":"ANALYTICS_QUERY_FAILED","error":"…"}    — no mark
+  /data door  : 500 {"code":"INTERNAL_ERROR","userMessage":"…"}      — mark carried
+```
+
+Nothing invalid shipped — every body parsed as `ApiErrorSchema`, which already
+declares the optional field — and that is what made the loss silent and
+one-directional: a console told by ADR-0112 to render `userMessage` verbatim
+found nothing at these three arms and fell back to its generic substitution, for
+the same throw the twin door rendered.
+
+**What callers see change:** exactly one optional key is ADDED, and only when
+the producer marked one. No existing key moves or changes value, at any of the
+four arms — pinned as an explicit key-order assertion per arm for an unmarked
+producer.
+
+The value comes from `boundedDeclaredUserMessage` (exported by #12693) —
+`declaredUserMessage`'s presence answer with #5423's bound applied — resolved
+once for the whole catch rather than at each terminal, so this door has one
+answer to "is there a mark, and how long may it be" and shares it with `/data`
+rather than copying it. ①b is deliberately untouched: a second application there
+would be one rule applied twice.
+
+**Unchanged:** the prose withhold (#5367/#5437/#5811) — a declared server fault's
+message is still replaced by the generic sentence and still reaches the operator
+in full through the `logError` line that runs before every arm; the statuses and
+`code`s all four arms answer; and #5667's tiering, which leaves a self-authored
+undeclared fault readable.
+
+**Not reachable from in-repo producers today.** Censused at claim: no package
+under `packages/services/**` sets a `userMessage` of any kind, and
+`service-analytics` dispatches no sandbox hook, so the QuickJS side-channel — the
+other in-repo carrier — does not reach this door either. This wires up a declared
+channel the published contract already promises on this route's envelope; the
+intended producer is an app author's analytics datasource or strategy.

.changeset/approval-escalation-enabled-default-flip.md

@@ -0,0 +1,48 @@
+---
+"@objectstack/spec": minor
+"@objectstack/plugin-approvals": minor
+---
+
+feat(spec,plugin-approvals): `escalation.enabled` defaults to `true` and the SLA sweep finally reads it (#12278)
+
+**BREAKING** semantic default flip on a published authorable key, shipped as
+`minor` under the repo's launch-window convention for breaking changes.
+Maintainer ruling 2026-08-27 (Option C), explicitly reversing the 2026-08-26
+"spec stays as declared" ruling with fresh analysis.
+
+`ApprovalEscalationSchema.enabled` declared `default(false)` while the
+plugin-approvals escalation sweep never read the key: any escalation block
+with a positive `timeoutHours` escalated, and with `action: 'auto_approve'`
+that silently approved requests their author had declared off the clock —
+the ADR-0049 declared-but-unenforced shape, failing open. Worse, the
+approval-node executor parses node config through the schema before
+snapshotting it onto the request row, so the old default **materialized**
+`enabled: false` into storage for every author who omitted the key, making
+"authored off" and "defaulted off" byte-identical at the sweep site.
+
+One change, both halves:
+
+- **spec**: `enabled` now defaults to `true` (stays `z.boolean()`; no
+  tri-state). The feature-level switch is whether an `escalation` block
+  exists at all; within a block carrying `timeoutHours`, escalation is on
+  unless explicitly turned off — which is what the runtime, its eleven
+  behaviour tests, and every teaching surface have always meant. Declared in
+  `DEFAULT_CHANGES_BY_MAJOR` (17) and registered as the
+  `approval-escalation-enabled-default-flip` semantic migration entry.
+- **runtime**: `runEscalations` skips a request whose snapshot carries an
+  explicit `escalation.enabled === false` — the declared switch is enforced.
+  Request snapshots created **before** the flip cutoff
+  (`ESCALATION_ENABLED_FLIP_CUTOFF_MS`, 2026-08-28T00:00:00Z) ride a
+  read-side legacy window and keep escalating exactly as they do today: their
+  stored `false` is overwhelmingly the old schema default materialized onto an
+  author who never wrote the key, every such stored row is escalating today,
+  and the window retires itself as pending requests drain — zero tenant rows
+  rewritten.
+
+Deployed metadata that omits `enabled` does not change behaviour (it
+escalated before, it escalates after). What changes is that writing
+`enabled: false` finally binds for newly opened requests — the declared
+intent being honoured. To keep an SLA off, write `enabled: false`; to
+escalate on timeout, an `escalation` block with `timeoutHours` is enough.
+
+<!-- adr-0087: registered approval-escalation-enabled-default-flip -->

.changeset/approval-recall-admin-override-arm.md

@@ -0,0 +1,34 @@
+---
+"@objectstack/plugin-approvals": patch
+---
+
+fix(plugin-approvals): the `approval_recall` action shows for the #3424 admin override (#12716)
+
+`ApprovalService.recall` has admitted two callers since #3424 — the submitter,
+and a platform/tenant admin releasing a stuck request — and `isOverrideActor`'s
+own doc block names recall as one of the four override levers in so many words.
+The declared action that reaches that endpoint did not agree: `approval_recall`'s
+`visible` predicate was submitter-only, while its three siblings
+(`approval_approve` / `approval_reject` / `approval_reassign`) each OR in
+`record.viewer.can_override`.
+
+So recall was the one lever the override covers whose button never appeared. An
+admin rescuing an approval routed to an unstaffed position could approve or
+reject their way out — writing a decision nobody made — or reassign it, but
+could not simply withdraw it. This is declared-vs-enforced drift in the less
+usual direction: a capability the server grants that no UI entry exposed.
+
+`approval_recall`'s `visible` now ORs in `record.viewer.can_override`, spelled
+byte-identically to the three siblings.
+
+Not a permission change: the service's authorisation set is untouched, and
+`can_override` was already computed server-side for every viewer.
+
+**Pending-only, and enforced rather than asserted.** The new arm carries no
+status test of its own — neither do the siblings — because the flag is already
+status-scoped where it is computed: `attachViewers` sets
+`can_override: row.status === 'pending' && isOverrideActor(...)`, ANDed, so the
+flag can never be true off `pending` and the arm is pending-only in effect
+however CEL groups the expression. The submitter's own `returned` (revise
+window) arm is unchanged. Pinned in both directions, with the flag's own scoping
+pinned against the real service on a genuinely `returned` row.

.changeset/approval-recall-refusal-localized.md

@@ -0,0 +1,41 @@
+---
+"@objectstack/plugin-approvals": minor
+---
+
+fix(plugin-approvals): the non-submitter recall refusal renders through the
+Operation Message Catalog instead of a hardcoded English sentence (#11993, the
+services-side half of the shape-A ruling)
+
+A user who opened a record someone else had submitted for approval, clicked
+Recall and was correctly refused read the reason in English regardless of their
+own locale. `@objectstack/rest`'s `handleApprovalError` ships this service's
+thrown reason as the 403 body's human-readable `error`, and Console splices it
+under its own localized label — so an operator in a fully Chinese deployment
+read a Chinese prefix glued onto an English sentence they could not act on
+(`撤回审批失败: <English>`).
+
+The refusal now renders through the shared Operation Message Catalog in
+`@objectstack/spec/system` under the key `approval_recall_not_submitter` that
+#12493 landed for it — the same mechanism `plugin-security`'s denial gates
+already use, with the same resolution ladder (deployment override → the
+caller's locale → `en` → the key) and the same guarantee that a misbehaving
+i18n service cannot turn a 403 into a 500. All four platform locales (`en`,
+`zh-CN`, `ja-JP`, `es-ES`) ship copy that names who *can* recall, rather than
+dead-ending the reader.
+
+`ApprovalServiceOptions` gains an optional `messageTranslator` — a lazily
+resolved, `II18nService.t`-compatible lookup, wired by `ApprovalsServicePlugin`
+the same way `tenancyPosture` and the field-visibility source are, because the
+i18n service is contributed by another plugin and may start later. It is what
+makes the override address the catalog documents,
+`errors.approval_recall_not_submitter`, actually take effect for this emitter;
+a stack without an i18n service still renders the built-in catalog in the
+caller's locale.
+
+**Not changed: who may recall an approval.** The gate is byte-identical — the
+submitter, or a privileged admin releasing a stuck record (#3424). Only the
+sentence the refusal carries is different, and the `FORBIDDEN:` code prefix
+that the REST layer maps to 403 is untouched.
+
+The button-visibility half of #11993 — a non-submitter seeing a live recall
+button at all — is not addressed here; see the issue for the measurement.

.changeset/broken-sweep-filter-not-detector.md

@@ -0,0 +1,50 @@
+---
+"@objectstack/service-automation": patch
+---
+
+fix(service-automation): the documented broken-sweep predicate is a first FILTER, not the detector (#12685)
+
+`patch`, and not empty: `sys_automation_run`'s field descriptions are shipped,
+translated, operator-facing text — they are what an admin reads in Setup while
+wiring an alert they will then trust for months. No counter, no schema and no
+engine behaviour changes here; the run summary measured by #4354 is correct and
+untouched.
+
+## The wrong claim
+
+`acted_count` advertised `selected_count > 0 AND acted_count = 0 AND
+unmeasured_count = 0` as *the* broken-sweep signal, unqualified. Measured A/B on
+one graph pair through the real engine — a healthy idempotent sweep (re-select
+the same records, gate each one on "was this already handled") and a dead gate
+(#4347's shape, the gate sitting in front of the lookup) — **both** report
+`selected > 0, acted 0, unmeasured 0`. The predicate cannot make the one
+distinction it was advertised to make.
+
+"Over N consecutive runs" does not rescue it either: the healthy steady state
+trips it on *every* run for as long as the outstanding work stands, so it is
+persistent rather than transient. Consecutiveness filters flapping, which is a
+different failure.
+
+Why a wrong sentence here is worse than a wrong sentence elsewhere: a detector
+that fires during normal operation gets muted, and a muted broken-sweep detector
+is the same silence #4347 produced — with the added cost that it now *looks*
+monitored.
+
+## What the descriptions say now
+
+- `acted_count` states the predicate as the **first filter** and names the
+  discriminator: a healthy skip is accounted for by a read the run performed
+  (the lookup the gate depends on shows `runs > 0` and `selected > 0` in
+  `summary_json.nodes[]`), while a dead gate skips just as often with nothing
+  behind it (`runs: 0`, or `selected: 0`).
+- `skipped_count` points at the same fold — `gates[]` names which edge closed
+  and how often, `nodes[]` says whether the lookup behind it found anything.
+- `unmeasured_count` keeps its own point (why the third clause exists) and now
+  calls the query a filter rather than an alert.
+
+The discriminating data was already shipped by #4354; nothing new is measured
+and no detector is implemented in the platform. `run-summary.test.ts` pins the
+pair as executable evidence: both shapes match the filter, and the per-node fold
+separates them. `content/docs/automation/flows.mdx` carries the same correction
+with the measured table and the two authoring shapes that make a sweep's signal
+quiet in its healthy steady state.

.changeset/changesets-repo-name-and-spec-badge.md

@@ -0,0 +1,32 @@
+---
+"@objectstack/spec": patch
+---
+
+fix(spec,repo): address the changesets `repo` option and the spec README's StackBlitz badge to `objectstack-ai/objectstack` (#12488)
+
+Two places still name `objectstack-ai/spec`, which is not the repository this
+monorepo lives in:
+
+- `.changeset/config.json` — `changelog[1].repo`
+- `packages/spec/README.md` — the "Try Online" StackBlitz badge target
+
+The README badge is the user-visible half. `README.md` is listed in this
+package's `files`, so it ships in the npm tarball and every reader of
+`@objectstack/spec` on npm gets a "Try Online" button addressed to a repository
+that is not this one. The path the badge names —
+`examples/app-todo/objectstack.config.ts` — exists here, so correcting the
+owner/repo segment is the whole fix.
+
+The `.changeset/config.json` half is hygiene with a measured expiry date rather
+than a bug that is firing. The configured generator `@changesets/cli/changelog`
+re-exports `@changesets/changelog-git`, whose `getReleaseLine(changeset)` and
+`getDependencyReleaseLine(changesets, dependenciesUpdated)` do not read the
+third argument — the options object that `@changesets/apply-release-plan`
+passes as `config.changelog[1]`. So `repo` has **no reader today**, and the
+wrong value has never produced a wrong link in any CHANGELOG this repo has
+generated. It acquires a reader the moment anyone swaps in
+`@changesets/changelog-github` — which is the usual reason to touch that block
+— and from then on every generated release line would link into the wrong
+repository, with nothing in the diff looking wrong.
+
+No runtime behaviour changes.