@object-ui/react 16.1.0 → 17.1.0

package/CHANGELOG.md

@@ -1,5 +1,643 @@
 # @object-ui/react
 
+## 17.1.0
+
+### Minor Changes
+
+- c4db402: refactor(views): ListView's `aria` and `sharing` are the spec sub-shapes (#2890 scope A step 5)
+
+  Last rename batch in the ListView vocabulary migration.
+
+  **`aria`** is now the spec's `AriaPropsSchema`: `label` → `ariaLabel`,
+  `describedBy` → `ariaDescribedBy`, folded at the ListView boundary like every
+  other legacy key. Two things fall out of adopting the spec shape:
+
+  - `role` becomes authorable. The list region hardcoded `role="region"`; it now
+    reads `aria.role` and falls back to `region`.
+  - `aria.live` stays as a documented local extension — it has no spec
+    counterpart, and dropping it would silently disable a shipped capability.
+    Promote it rather than growing that extension.
+
+  **`sharing`** is now the spec's `ViewSharingSchema` (`{ type, lockedBy }`),
+  imported by reference — the local four-key object is gone. The legacy pair folds
+  in: `visibility` collapses onto the two ownership kinds the spec models (only
+  `private` is `personal`; `team` / `organization` / `public` are all
+  `collaborative`), and a bare `enabled: true` maps to `personal`, which is the
+  badge the user already saw (the old title fell back to `'private'`).
+
+  _Visible change_: the share badge's tooltip shows the spec ownership type, so a
+  view authored with `visibility: 'team'` reads "Sharing: collaborative" instead
+  of "Sharing: team". The four-value audience has no spec home and nothing but
+  that tooltip consumed it; keeping a second audience enum alive would re-open the
+  fork this issue closes.
+
+  Also fixes the **spec bridge**, which was doing the opposite of its job: given a
+  spec-shaped `sharing`, `transformListView` _downgraded_ it — inventing a legacy
+  `visibility` audience and an `enabled` flag that the renderer then had to fold
+  back. Both sides speak `ViewSharing` now, so it passes through.
+
+  `conditionalFormatting` and `exportOptions` are deliberately **not** folded.
+  Both objectui shapes are supersets carrying capability the spec cannot express —
+  the `{ field, operator, value }` rule form, and `maxRecords` / `includeHeaders`
+  / `fileNamePrefix`. Folding them onto the narrower spec shapes would delete
+  working features; they want promotion upstream, not a rename.
+
+- 07de839: fix(notifications): the config, `position` and action `variant` are read instead of forked or ignored (#3014 follow-up)
+
+  The last of the notification contract. After `displayType` (#3071) and `icon`
+  (#3076), four gaps of the same family were left:
+
+  - **the config was 3/4 inert** — only `defaultDuration` was ever read.
+    `maxVisible` and `stacking` were carried and ignored, while
+    `NotificationBanners` capped at a hard-coded `3` of its own;
+  - **its field names forked from `NotificationConfigSchema`** — `position` vs
+    `defaultPosition`, a renderer-local `stacking` boolean with no spec
+    counterpart, and no `pauseOnHover` at all;
+  - **a notification could not declare a `position`.** The #3008 parity guard
+    asserted the position _vocabulary_ matched the spec while nothing positioned
+    anything by it — a guard passing over an unused value;
+  - **`NotificationActionButton.variant` was the shadcn Button vocabulary**
+    (`default | destructive | outline`) under a spec-shaped name, forking
+    `NotificationActionSchema.variant` (`primary | secondary | link`).
+
+  **How positioning resolves now** — `notification.position ?? config.defaultPosition
+?? nothing`, and "nothing" is a real answer:
+
+  - **declared** → the surface pins itself there, always. `presentNotificationToast`
+    passes it per-toast so the contract wins over the container;
+  - **undeclared** → the surface keeps its own anchor (a snackbar's bottom edge) or
+    defers to the host's toast chrome.
+
+  That asymmetry is the design decision. The host's sonner container also serves
+  toasts that are _not_ spec notifications (the console action runtime's own
+  `toast.*` calls), so it stays the fallback authority for placement — never a
+  competing one. A declared position a component prop could silently override
+  would be the same "validates, then does nothing" shape this whole area is about.
+  Hence `defaultPosition` has no fabricated default: "the host didn't say" has to
+  be representable.
+
+  Also: `maxVisible` / `stackDirection` now drive every stacking surface through
+  one shared `visibleNotificationStack` (cap keeps the NEWEST, stack grows in the
+  declared direction); `pauseOnHover` holds a transient notification's timer and
+  resumes it with the time it had left, which needed the provider to track live
+  timers rather than fire-and-forget `setTimeout`s. Legacy spellings still resolve:
+  `position` folds into `defaultPosition`, and `stacking: false` reads as
+  `maxVisible: 1` rather than being ignored.
+
+  `onToast` now receives the resolved config as a second argument, so the delegate
+  can apply the parts of the contract only it can. Existing one-argument handlers
+  are unaffected. The spec-parity guard gained the action-variant vocabulary, the
+  one notification enum it did not cover.
+
+- 2a40b5e: feat(notifications): each spec `displayType` gets its own presentation instead of a toast (#3014)
+
+  #3008 closed the **contract** half of this: `NotificationContext`'s union matched
+  `NotificationTypeSchema`, and `notify()` materialized the declared type so a
+  consumer _could_ branch on it. Nothing did. `NotificationProvider` handed every
+  item to the host's `onToast` delegate regardless of type, so an author picking
+  `banner` or `inline` got a transient overlay — plausible output, wrong output.
+
+  Each of the five spec types now has a presentation of its own:
+
+  | `displayType` | Presentation                                           | Rendered by                        |
+  | ------------- | ------------------------------------------------------ | ---------------------------------- |
+  | `toast`       | transient overlay (unchanged)                          | the host's `onToast` delegate      |
+  | `snackbar`    | bottom-anchored bar, one at a time, at most one action | `<NotificationSnackbar />`         |
+  | `banner`      | page-width strip **in the content flow**               | `<NotificationBanners />`          |
+  | `alert`       | blocking acknowledgement dialog, FIFO queue            | `<NotificationAlerts />`           |
+  | `inline`      | in place, at the raising surface                       | `<NotificationInline scope="…" />` |
+
+  The four surface components ship from `@object-ui/components` and subscribe via
+  `useNotificationsByPresentation(type, scope?)`.
+
+  **Answers to the three questions the issue left open:**
+
+  1. **Banner/inline placement is the host's.** They are not overlays: a banner takes
+     space at the top of the content area and an `inline` notification belongs next to
+     the thing that raised it. So the context exposes the items and the surfaces
+     subscribe, rather than one `onToast`-style delegate positioning everything. An
+     `inline` notification carries a `scope` that pairs it with its outlet, so two
+     forms on one page don't show each other's messages.
+  2. **`alert` is modal-ish but NOT the action system's `ModalHandler`.** That handler
+     resolves a page/object, renders it, and reports an `ActionResult` back to the
+     `ActionRunner`; a notification alert has no schema, no target and no result.
+     Routing it there would mean synthesizing a page just to say "OK". It renders
+     through the `AlertDialog` primitive instead — no second action-modal path.
+  3. **`snackbar` earns its own component.** It supersedes rather than stacks, anchors
+     bottom regardless of the toast position config, and takes at most one action.
+     Making it a sonner variant is what "presents as a toast" means.
+
+  **Also fixed:** auto-dismiss now follows the presentation. `toast`/`snackbar` keep
+  the transient timer; `banner`/`alert`/`inline` are persistent unless the raiser sets
+  `duration` explicitly — a persistent banner used to evaporate on the shared 5s toast
+  timer. `dismissible` is honored on the persistent surfaces (an `alert` always keeps
+  its acknowledge button; `dismissible: false` only closes the Escape route).
+
+  `onToast` now receives **only** `toast` items. A provider with no `onToast` remains
+  the supported store-only mode (a bell reading `notifications`/`unreadCount`), but
+  raising one of the other four types with its surface unmounted warns in dev, naming
+  the component to mount — that failure used to be silent.
+
+  `NOTIFICATION_PRESENTATIONS` is typed `Record<NotificationPresentation, …>`, so a new
+  member in the spec enum fails type-check until its presentation is decided; a parity
+  test additionally asserts the table covers `NotificationTypeSchema` exactly and that
+  no two types share a surface.
+
+- ce08d55: chore(deps): upgrade `@objectstack/*` to 17.0.0-rc.0, and let the spec take back what it now owns
+
+  `spec` / `client` / `formula` / `lint` move from `^16.x` to `^17.0.0-rc.0`. Two
+  groups of v17 changes reach this repo, and they pull in opposite directions —
+  the spec pruned surface objectui re-exported, and adopted surface objectui had
+  been carrying locally.
+
+  **The spec pruned dead Theme config (objectstack#3494), so the re-exports went
+  with it.** `ThemeSchema` dropped `spacing`, `breakpoints`, `logo`, `density`,
+  `wcagContrast`, `rtl`, `touchTarget` and `keyboardNavigation` — authorable but
+  never enforced, so authoring them was already a silent no-op. `@object-ui/types`
+  re-exported those sub-schemas _by reference_ (issue #2231), so they could not
+  survive the prune without becoming hand-written mirrors — exactly the second
+  de-facto contract AGENTS.md #0.1 forbids. Removed from the public surface:
+
+  - Types: `Spacing`, `Breakpoints`, `DensityMode`, `WcagContrastLevel`,
+    `ThemeLogo`, and the deprecated `SpacingScale` alias
+  - Schemas: `SpacingSchema`, `SpacingScaleSchema`, `BreakpointsSchema`,
+    `ThemeLogoSchema`, and the `SpacingSchemaType` / `BreakpointsSchemaType` helpers
+  - `Theme.spacing`, `Theme.breakpoints` and `Theme.logo`
+
+  `mergeThemes` no longer merges the three dropped keys. `generateThemeVars` is
+  unaffected — it never emitted them, which is why the liveness audit called them
+  dead. The one real consumer was `ThemeProvider`, which set the favicon from
+  `theme.logo.favicon`; that path is gone, because v17 strips the key at parse and
+  it could never arrive again. The live favicon is unaffected: it comes from
+  operator branding (`getFaviconUrl()`), applied in the console's `index.html`,
+  `main.tsx`, and on route change.
+
+  Nothing else read the pruned types. In particular the list-density feature is
+  untouched — `useDensityMode` and `rowHeightToDensityMode` use `@object-ui/core`'s
+  own local `DensityMode`, which never came from the spec.
+
+  **The spec adopted objectui's ListColumn extensions (objectui#2231), so the
+  extension collapsed.** `ListColumnSchema` used to `.extend()` the spec with two
+  fields, each carrying a note to promote it upstream rather than grow the
+  extension; v17 did exactly that. `summary` is now the spec's
+  `union([ColumnSummarySchema, ColumnSummaryConfigSchema])` — the same enum ∪
+  `{ type, field }` form `useColumnSummary` reads — and `prefix` is the spec's
+  `ColumnPrefixSchema`. `ListColumnSchema` is now a plain by-reference re-export.
+  One behavior change rides along: `prefix.type` defaults to `'text'` on parse
+  instead of staying `undefined`, so the cell renderer always gets a value.
+
+  **Node 22 is now the floor.** Every `@objectstack` package declares
+  `engines.node: ">=22.0.0"` (objectstack#3825; Node 20 reached EOL 2026-04-30).
+  This repo claimed `>=20` and ran CI on Node 20.x, so it promised — and validated
+  — a runtime its own core dependency does not support. `engines.node` is now
+  `>=22`, CI runs Node 22.x, and the CI/deployment docs say so.
+
+  The major stays 17: per AGENTS.md the major tracks `@objectstack`'s major, which
+  is also 17, and that convention deliberately outranks semver purity — so the
+  removals above ship as a minor rather than desyncing the two.
+
+- 0ded602: fix(form): a server rejection that names fields now marks those fields (objectstack#3896)
+
+  The server has always said which field it rejected. `@objectstack/objectql`'s
+  validators throw `VALIDATION_FAILED` with `fields[]` — one entry per offending
+  field, each with a human `message` — and both the REST layer and the runtime
+  dispatcher serve that as a 400 with the entries intact.
+
+  Every form dropped them. The submit handler caught the rejection, ran the
+  message through `extractWriteErrorMessage`, and showed **one undirected toast**:
+  the user was told something was wrong but not _what_, on a surface that already
+  knows how to mark an input — and already does exactly that for client-side
+  validation. On a long form the offending field was often off-screen, so "创建"
+  appeared to do nothing.
+
+  **Now the two failures behave identically, because they share one
+  implementation.** The per-field marking, the toast naming the fields, and the
+  scroll-and-focus of the first offender (#2793) were extracted from the
+  client-side invalid handler; the server path calls the same function. As far as
+  the person filling in the form is concerned these are the same event — only the
+  referee differs.
+
+  Three layers, each of which was dropping the detail:
+
+  - **`@object-ui/react`** — new `extractFieldErrors(err)` (exported alongside
+    `extractWriteErrorMessage` / `isPermissionError`) normalises the three shapes
+    the error can arrive in: a typed `ValidationError` from the ObjectStack
+    adapter, the raw `@objectstack/client` error (whose `details` falls back to the
+    whole response body, which is where `fields[]` lands), and a hand-rolled error
+    carrying `fields` directly — the server duck-types that shape identically, so
+    the client must not be pickier than the server. Entries with no usable `field`
+    are **dropped rather than guessed at**: marking an innocent input is worse than
+    the generic toast.
+  - **`@object-ui/data-objectstack`** — `normaliseClientError` now maps a 400
+    `VALIDATION_FAILED` onto the `ValidationError` class that has sat in
+    `errors.ts` since the package was written, exported and **never once
+    constructed**. Its `validationErrors: Array<{ field, message }>` shape was
+    already exactly right. `create` also now normalises at all: only `update` did,
+    so a rejected insert reached callers as the raw client error — and a create is
+    the path that most often trips required-field validation.
+  - **`@object-ui/components`** — the form renderer maps the entries onto
+    `form.setError` and takes over the failure, **but only when every rejected
+    field has a visible input to carry it**. If the server also rejected something
+    the form does not render, it falls through to the banner, whose top-level
+    message concatenates every field's reason — so the part the user cannot see
+    inline is still said out loud instead of silently dropped.
+
+  This also removes the need for the client-side predicate mirroring added in
+  #2962: a form no longer has to guess what the server will reject in order to
+  warn about it beforehand, and mirrored predicates drift.
+
+  Non-field failures (403 / permission denials / anything without `fields[]`) take
+  exactly the path they took before.
+
+### Patch Changes
+
+- fc0272a: fix(actions): apply the ADR-0066 D4 capability gate on every action surface (framework#3923)
+
+  An action declaring `requiredPermissions` is supposed to be one declaration with
+  two enforcement surfaces: 403 on the server, hidden button in the UI. The UI half
+  only ever ran inside `ActionEngine.getActionsForLocation` — and the surfaces
+  `record_header`, `record_more`, `list_item` and `list_toolbar` actually render on
+  do not go through the engine. They filter their own action lists. So a button
+  declaring a capability nobody holds rendered, live and clickable, on the record
+  header, in every grid row menu, and on the list toolbar. For a `type: 'api'`
+  action pointed at a self-authored endpoint, nothing else was checking either: the
+  platform's action route (which is where the 403 comes from) never sees that
+  request.
+
+  `page:header`, `action:bar` (business _and_ `systemActions`) and the grid's
+  `RowActionMenu` now apply the same gate, via a shared `useCapabilityGate()` so
+  the surfaces cannot drift apart. The rule is the engine's, unchanged: hide unless
+  the caller holds **all** declared capabilities; an empty held set is "holds
+  nothing" and gates; **unknown** — no action runtime, no resolved capabilities —
+  fails OPEN, because the server is the authority and hiding a permitted user's
+  button on missing client data is the worse failure.
+
+  The record surface was also feeding the gate nothing to work with.
+  `RecordDetailView` mounts its own `<ActionProvider>`, which shadows the shell's
+  for every action on that page, and seeded it with identity only — no
+  `systemPermissions`. Since unknown fails open, that alone un-gated every
+  `record_header` / `record_more` / `record_section` action on the one page those
+  locations exist on. It now forwards the caller's resolved capabilities (and only
+  once they have actually resolved, so a standalone embed without a
+  `PermissionProvider` keeps failing open rather than hiding everything).
+
+  `useRecordEditable`'s record-level explain probe went out on a bare
+  `fetch(..., { credentials: 'include' })`. A bearer-token session carries its
+  credential in the `Authorization` header, not a cookie, so the probe came back
+  401 on a perfectly valid admin session and the verdict silently failed open —
+  the hook was inert in exactly the deployments it was written for. It now rides
+  the host's authenticated fetch (`SchemaRendererProvider`'s `apiFetch`), falling
+  back to the global one for standalone embeds.
+
+- 9eb932b: fix(console): three real-user console failures — 403 blamed on the network, ⌘K search capped at 8 objects, nav gating fields inert
+
+  1. **List error panel classifies the failure** (`plugin-list`, `i18n`): a 403/401 from the data source used to render the same "check your connection" copy as a genuine outage, sending users to debug their network while the server was correctly denying access. The panel now classifies by `httpStatus`/`status`/`statusCode`, the `PERMISSION_DENIED`/`UNAUTHORIZED` error codes, or an `HTTP <status>` message prefix, and renders dedicated permission-denied / sign-in-required copy (all nine locales).
+
+  2. **⌘K / full-page search scope is no longer truncated** (`react`): `maxObjectsQueried` caps the per-object fanout fallback, not the search scope — it used to slice the candidate pool itself, so the `objects` whitelist sent to the platform's `/api/v1/search` only ever named the first 8 nav objects. Which sidebar group came first decided which records were findable; everything later in the nav was unsearchable no matter what the user typed.
+
+  3. **Nav gating fields finally gate** (`app-shell`): `evaluateVisibility` only evaluated `${…}` template strings, so the `{ dialect: 'cel', source }` envelopes the spec normalizes every authored `visible` predicate into fell through to a blanket "visible" — a constant-false predicate still rendered for everyone. It now delegates to `ExpressionEvaluator.evaluateCondition`, which routes CEL envelopes to the canonical `@objectstack/formula` engine. And the sidebars' `requiredPermissions` check treats a bare name as an ADR-0066 system capability (union of the user's permission-set `systemPermissions` from `/me/permissions`) — the same subset rule the server applies to `AppSchema.requiredPermissions` — instead of misreading it as `can(<name>, 'read')`, which had degraded `requiredPermissions` into a hide-from-everyone switch (admins included). The `object:action` form and the legacy object-read fallback keep working.
+
+- 4952edf: fix(errors): error-code branches survive the framework's ADR-0112 rename — objectstack#3841
+
+  Framework ADR-0112 renamed the whole `error.code` vocabulary from lowercase
+  `snake_case` to `SCREAMING_SNAKE` (`destructive_change` → `DESTRUCTIVE_CHANGE`).
+  Eleven places compared `err.code` against the old spelling with `===`, so against
+  a swept server they simply stopped matching — and nothing threw. The affordance
+  each branch guards just vanished and the user got the generic error toast instead:
+
+  - the destructive-change confirm dialog (resource editor, permission matrix)
+  - the "create a writable package first" hint
+  - field-scoped validation issues on embedded item saves
+  - the all-or-nothing publish summary naming the causal item
+  - unknown-object tolerance in the app header and in record search
+  - the marketplace's local-install messages for conflict / auth / unavailable
+  - `isNotFoundError` in the data layer
+
+  `RECORD_NOT_FOUND` had already been renamed a release earlier, so that branch was
+  already dead before this fix.
+
+  New `errorCodeIs` / `errorCodeIsAnyOf` in `@object-ui/types` compare
+  case-insensitively, so the console keeps working against servers on either side
+  of the rename — the console ships separately from the server it talks to. Every
+  call site now passes the catalog (SCREAMING) spelling, and `error-code.ts` is the
+  single file to delete once no supported server emits the old vocabulary.
+
+- 2374a49: fix(sdui): a react page no longer loses its state to a memo that never held, and a source that exports nothing fails loudly
+
+  Writing the regression guard for objectui#2954's "latent hazard" found it was
+  already real.
+
+  **`evaluatedSchema` was memoised on values rebuilt every render.**
+  `SchemaRenderer` fell back to a fresh `{}` when no `SchemaRendererProvider` sat
+  above it, and `usePageVariables()` returned a brand-new object literal outside a
+  `PageVariablesProvider`. Both feed the `evaluatedSchema` memo's dependency list,
+  so for any tree without those providers the memo never hit: the schema was
+  re-cloned and the ExpressionEvaluator re-run on every render, and children got a
+  new schema identity every time. A `kind:'react'` page memoises its compiled
+  source on that identity, so the page was recompiled — a new page function, a new
+  element type — and React remounted it, silently discarding the user's `useState`.
+  Any registry notification (every lazy plugin's first load) triggered it. Both
+  fallbacks are now module constants.
+
+  **A source that exports nothing now throws instead of rendering blank.**
+  `generateElement` inserts the implicit `export default` only when the source
+  _starts with_ JSX, a `function` declaration, `()` or `class` — so the very
+  common `const Page = () => …` exported nothing, and the page rendered blank with
+  no error reported anywhere. It now throws with a message naming the fix, which
+  `ReactRunner`'s error panel surfaces. `export default null` still means "render
+  nothing"; a default export that is not a component throws too.
+
+  **`PageSchema['kind']` matches `@objectstack/spec`.** It declared
+  `'full' | 'slotted'` while the renderer had shipped `'react'` and
+  `'html'`/`'jsx'` since ADR-0080 and read the field through a cast. The union now
+  spells all five and the cast is gone.
+
+  Docs: new `content/docs/guide/react-pages.md` (choosing between the executed and
+  parsed tiers, the capability gate, the injected scope, flat props, `Block`,
+  `useAdapter`, source shapes, error handling) and a `@object-ui/react-runtime`
+  README — the package had neither, while being the tier AI-authored pages target.
+
+- Updated dependencies [62311b6]
+- Updated dependencies [9e7349e]
+- Updated dependencies [8864971]
+- Updated dependencies [9b773f9]
+- Updated dependencies [1cf0de7]
+- Updated dependencies [752e18f]
+- Updated dependencies [c785740]
+- Updated dependencies [b41f401]
+- Updated dependencies [19e9fa0]
+- Updated dependencies [d61efd1]
+- Updated dependencies [95b7214]
+- Updated dependencies [7d9734d]
+- Updated dependencies [6ae818e]
+- Updated dependencies [9eb932b]
+- Updated dependencies [746dd00]
+- Updated dependencies [aebfa4f]
+- Updated dependencies [38ca8be]
+- Updated dependencies [3cb9646]
+- Updated dependencies [4952edf]
+- Updated dependencies [7f0252e]
+- Updated dependencies [7d35010]
+- Updated dependencies [c4d7b20]
+- Updated dependencies [7639a61]
+- Updated dependencies [94e63ef]
+- Updated dependencies [02aef0c]
+- Updated dependencies [6f29aa5]
+- Updated dependencies [d21794c]
+- Updated dependencies [c4db402]
+- Updated dependencies [5319bf1]
+- Updated dependencies [49e5671]
+- Updated dependencies [b5b97e2]
+- Updated dependencies [f59f2c1]
+- Updated dependencies [4874117]
+- Updated dependencies [ad0183a]
+- Updated dependencies [ce08d55]
+- Updated dependencies [a17ef09]
+- Updated dependencies [aa1240a]
+- Updated dependencies [2374a49]
+- Updated dependencies [390c071]
+- Updated dependencies [d10f526]
+- Updated dependencies [2d5d594]
+- Updated dependencies [ea7f477]
+- Updated dependencies [7f23cd0]
+- Updated dependencies [0ded602]
+- Updated dependencies [24e0e0a]
+- Updated dependencies [f8a95e5]
+- Updated dependencies [3a6cf24]
+- Updated dependencies [aa35561]
+- Updated dependencies [03bd53b]
+- Updated dependencies [3c1f321]
+- Updated dependencies [a045a32]
+- Updated dependencies [912496d]
+- Updated dependencies [9867281]
+  - @object-ui/core@17.1.0
+  - @object-ui/types@17.1.0
+  - @object-ui/data-objectstack@17.1.0
+  - @object-ui/i18n@17.1.0
+
+## 17.0.0
+
+### Major Changes
+
+- c77108c: refactor(spec-bridge): remove the dead page/dashboard bridges (#1892)
+
+  `SpecBridge`'s `page` and `dashboard` bridges — `bridgePage`, `bridgeDashboard`,
+  and the `SpecBridge#transformPage` / `#transformDashboard` methods — had no
+  runtime consumer. Pages render through their own renderer and dashboards
+  through `DashboardView → DashboardRenderer → DatasetWidget` (ADR-0021); neither
+  path routes through `SpecBridge`. The dashboard bridge's input shape
+  (`object` / `categoryField` / `valueField` / `aggregate`) is the pre-ADR-0021
+  widget model, which the strict `DashboardWidgetSchema` now rejects — so the
+  bridge could not receive a spec-valid dashboard even in principle.
+
+  Flagged dead by the metadata-liveness audit (framework #1878 / #1892). The
+  `list` and `form` bridges are unaffected and remain the live authoring path.
+
+  BREAKING CHANGE: the public exports `bridgePage`, `bridgeDashboard`, and the
+  `SpecBridge#transformPage` / `#transformDashboard` methods are removed. There
+  is no replacement — render pages and dashboards through their renderers
+  (`DashboardRenderer` / the page renderer) directly.
+
+### Minor Changes
+
+- 952b978: fix(detail): the approval band honors the node's `lockRecord` instead of assuming every approval locks (#2902)
+
+  A record detail page treated "a pending approval request exists" as "this
+  record is locked". An approval node declares `lockRecord` (default `true`), and
+  on `lockRecord: false` the server keeps accepting writes for the whole time
+  that node waits — so the console was asserting a lock the backend did not
+  enforce.
+
+  The label was the smaller half of it. The same conflated signal fed `canEdit`,
+  so the record-level inline-edit session was suppressed too: no pencils,
+  `enter()` a no-op. On a single-approver step — a department head or plant
+  manager, exactly the case `lockRecord: false` exists for, where the approver is
+  meant to fill in the missing detail before deciding — the capability was
+  unreachable from the UI. And a flow chaining nodes with different policies drew
+  one identical band for "edit freely" and "the server will reject your save with
+  `RECORD_LOCKED`", so the two states were indistinguishable until Save failed.
+
+  Approval state is now two signals:
+
+  - **`approvalPending`** — an approval is running. Drives the band and the recall
+    button, both meaningful whether or not the record is editable.
+  - **`locked`** — that approval also forbids edits, from the pending node's
+    `lock_record` (framework#3814, read off the same `node_config_json` snapshot
+    the server's record-lock hook reads).
+
+  The band renders two states: amber lock + "Locked for approval", or sky clock +
+  "In approval · editable", each with its own tooltip. Recall moved out of the
+  locked branch — an editable pending approval is just as recallable. Inline
+  editing stays live in the editable state.
+
+  `InlineEditProvider` takes a new optional `approvalPending` prop, defaulting to
+  `locked`, so a host that threads only `locked` renders exactly as before. The
+  record's `approval_status` field remains the fallback for backends with no
+  approvals API; it carries no node granularity, so it still reads as locked — as
+  does a pending request from a backend too old to report the policy.
+
+  New `detail.approvalPendingEditable` / `detail.approvalPendingTooltip` keys are
+  translated in all ten locales.
+
+- 1767124: feat(grid): compute all eleven spec column summary aggregations (#2890)
+
+  `ColumnSummarySchema` accepts eleven aggregation names; `useColumnSummary` computed
+  five. The other six — `none`, `count_empty`, `count_filled`, `count_unique`,
+  `percent_empty`, `percent_filled` — passed validation at authoring time and then
+  rendered a blank footer cell, with no error raised on either side.
+
+  The computation now splits into two families. Count and percent read _raw_ cell
+  values, before the numeric parse, so they work on text, select and lookup columns and
+  a value that does not parse as a number still counts as a filled row; a cell is empty
+  when it is `null`, `undefined`, `""` or an empty array. `sum`/`avg`/`min`/`max` keep
+  the existing numeric parse and column formatting.
+
+  Two behavior changes follow from the enum carrying both `count` and `count_filled`,
+  which cannot mean the same thing:
+
+  - `count` is now every row; `count_filled` is the non-empty variant. Only a column
+    whose values are all empty renders differently than before.
+  - a zero count renders `Empty: 0` instead of collapsing to a blank cell.
+
+  Column currency/percent formatting is gated to the numeric family, so `count_unique`
+  on a currency column reads `Unique: 3` and not `$3.00`. `none` and unrecognized names
+  skip the entry entirely, so a view whose columns all opt out renders no footer row.
+
+  `ListColumnSchema`'s objectui-local `{ type, field }` arm now takes its vocabulary
+  from `SpecColumnSummarySchema` by reference — it was stuck at the same five names,
+  which left the per-column `field` override unavailable for the six new aggregations.
+
+  A parity test asserts the renderer's supported set equals the spec enum in both
+  directions: a spec name the renderer omits is the bug above, and a renderer name the
+  spec omits would be local dialect (Commandment #0).
+
+  **Removed:** `useColumnSummary` from `@object-ui/react`. It was a second, unrelated
+  hook of the same name with no callers — a different API, a comment claiming it
+  implemented spec v2.0.7, and a `distinct` aggregation that is not in the spec
+  vocabulary at all (the spec calls it `count_unique`). Use `useColumnSummary` from
+  `@object-ui/plugin-grid`, which implements the spec enum.
+
+- c6cfdf1: feat(react)!: trim the dead device/preference delegates from
+  `useClientNotifications` (objectstack#3612 companion)
+
+  `registerDevice`, `getPreferences`, and `updatePreferences` delegated to
+  `@objectstack/client` methods that were deleted in objectstack#3612 — the
+  `/notifications/devices` and `/notifications/preferences` server routes they
+  targeted were never built, so every call already surfaced an error at
+  runtime. The hook keeps `fetchNotifications` and `markAsRead` (both
+  dispatcher-served and route-ledgered). Breaking only for code destructuring
+  the removed functions from the hook result; nothing in this repo did.
+
+### Patch Changes
+
+- 8ecf5a6: Command palette (⌘K) now surfaces record search hits from the platform's global
+  search endpoint (`GET /api/v1/search`).
+
+  Previously the palette only ran a per-object `find({ $search })` fanout (the
+  metadata-driven ADR-0061 search), which misses records that only the global
+  search index knows about — so typing a well-known record name returned no
+  records even though `/api/v1/search` served them. `ObjectStackAdapter` now
+  exposes a `searchAll(query, { limit, objects })` method that calls the unified
+  endpoint, `useRecordSearch` prefers it when present (falling back to the fanout
+  otherwise), and the palette renders the resulting record hits grouped by object.
+
+- 7b35e4b: fix(dashboard,charts): resolve `{current_user_id}` in widget filters (framework #3574)
+
+  A dashboard widget filtered on `{current_user_id}` rendered `0`. The token
+  reached SQL as a literal, matched no row, and nothing was logged on the client
+  or the server — a silent zero that reads as "you have no work" rather than
+  "this filter did not resolve". The same token in a list-view filter resolved
+  correctly, so a user-scoped list and a user-scoped widget over the same data
+  disagreed.
+
+  There was no shared resolver. Three ad-hoc implementations had grown up
+  independently — `ObjectView` for list views, `ObjectDataPage` for URL filter
+  triples, `NavigationRenderer` for hrefs — and each understood only the filter
+  shape its own surface used. `ObjectView`'s opened with
+  `if (!Array.isArray(filter)) return filter`, so it could not have been reused
+  by dashboard widgets even in principle: widget filters are MongoDB-style
+  objects. Widgets therefore got no resolution at all — `DatasetWidget` called
+  `resolveDateMacros` and nothing else, which is why `{today}` worked in a widget
+  and `{current_user_id}` silently did not.
+
+  - **`@object-ui/core`** — new `utils/filter-tokens.ts` with
+    `resolveContextTokens` and `resolveFilterPlaceholders`. The latter expands
+    _every_ placeholder vocabulary in one call and is what surfaces should use;
+    resolving only some of them is the whole defect. The walk handles arrays and
+    plain objects uniformly, so one resolver covers both platform filter shapes.
+  - **`@object-ui/react`** — new `FilterScopeProvider` / `useFilterScope`. The
+    renderer packages deliberately do not depend on `@object-ui/auth`, so the
+    shell supplies the session values. This is a separate context from
+    `PredicateScopeContext`, which is the expression evaluation scope and carries
+    no organization.
+  - **`@object-ui/plugin-dashboard` / `@object-ui/plugin-charts`** — all six
+    widgets that previously resolved date macros only now resolve both
+    vocabularies: `DatasetWidget`, `ObjectMetricWidget`, `ObjectDataTable`,
+    `ObjectPivotTable`, and `ObjectChart` (dataset-bound and inline paths). The
+    chart's `compareTo` comparison filter gets the session pass too — otherwise
+    the overlay series silently ignored the owner clause the primary series
+    honoured.
+  - **`@object-ui/app-shell`** — `ObjectView`'s local `substituteFilterTokens`
+    and `ObjectDataPage`'s inline `=== '{current_user_id}'` ternary now delegate
+    to the shared resolver, so both also gain `{current_org_id}` and date macros.
+    Two of the three ad-hoc implementations are gone rather than joined by a
+    fourth.
+
+  An unresolvable token is left intact rather than dropped: leaving it yields an
+  empty result, whereas dropping the clause would _widen_ the result set and show
+  a signed-out viewer everyone's data. It is no longer silent — the resolver
+  warns, naming the token, and suggests the intended spelling for known
+  near-misses (`{current_user}`, `{user_id}`, `{organization_id}`). Authoring-time
+  enforcement lands separately as `filter-token-unknown` in `@objectstack/lint`.
+
+- Updated dependencies [0b3be01]
+- Updated dependencies [3c4d935]
+- Updated dependencies [4b60d2d]
+- Updated dependencies [952b978]
+- Updated dependencies [de5e40c]
+- Updated dependencies [1a03af6]
+- Updated dependencies [3e886eb]
+- Updated dependencies [cfc675e]
+- Updated dependencies [20df08c]
+- Updated dependencies [1767124]
+- Updated dependencies [8ecf5a6]
+- Updated dependencies [af705b9]
+- Updated dependencies [0502a7c]
+- Updated dependencies [7b35e4b]
+- Updated dependencies [e16ed2d]
+- Updated dependencies [c6fd752]
+- Updated dependencies [f9bbddb]
+- Updated dependencies [dfd3705]
+- Updated dependencies [2735de6]
+- Updated dependencies [6dee2cb]
+- Updated dependencies [e05f052]
+- Updated dependencies [0502a7c]
+- Updated dependencies [faad45e]
+- Updated dependencies [09c6a17]
+- Updated dependencies [c7cff19]
+- Updated dependencies [ba73a02]
+- Updated dependencies [cd09a7b]
+- Updated dependencies [f1abf0e]
+- Updated dependencies [f05b84e]
+- Updated dependencies [9b4b952]
+- Updated dependencies [7d46648]
+- Updated dependencies [6e8fd3c]
+- Updated dependencies [bb4aa25]
+- Updated dependencies [75f1cdf]
+- Updated dependencies [662bdf9]
+- Updated dependencies [059a052]
+- Updated dependencies [53642d4]
+- Updated dependencies [8aae006]
+- Updated dependencies [d62fb1f]
+- Updated dependencies [d147a13]
+- Updated dependencies [c6aaed8]
+- Updated dependencies [263f885]
+- Updated dependencies [dc334da]
+  - @object-ui/i18n@17.0.0
+  - @object-ui/types@17.0.0
+  - @object-ui/data-objectstack@17.0.0
+  - @object-ui/core@17.0.0
+
 ## 16.1.0
 
 ### Minor Changes
@@ -63,7 +701,7 @@
 
   Together with the `^15.1.1` alignment (#2662), a renderer CEL predicate now
   reaches the identical verdict as the server — including the framework's
-  `dateField == today()` equality fix (objectstack-ai/framework#3205) once it
+  `dateField == today()` equality fix (objectstack-ai/objectstack#3205) once it
   lands in a published 15.x. The broader home-grown-vs-canonical divergence
   motivation is #2661.