@object-ui/core 17.3.0 → 17.6.0

package/CHANGELOG.md

@@ -1,5 +1,2013 @@
 # @object-ui/core
 
+## 17.6.0
+
+### Minor Changes
+
+- 279fb13: `ComponentInput.type` can declare a UNION, so a block stops warning about legal
+  writes its own description recommends
+  
+  A registration's `type` was one coarse control kind, while a good number of spec
+  keys accept more than one shape. A declaration therefore had to pick an arm, and
+  the repo's own manifest gate then reported `type-mismatch` on the other arm's
+  legal values. Four of the five measured cases were the loud shape: the input's
+  `description` teaches the author to write an inline translation map
+  (`{ en, "zh-CN", … }`) while the same input's `type: 'string'` made
+  `sdui-parser`'s `checkType` warn about exactly that map — one platform authority
+  contradicting itself on the write it had just recommended. Because these land at
+  warning severity the page still compiled and rendered; the cost is that noise on
+  correct authoring trains authors, AI authors included, to dismiss the
+  `unknown-prop` and `type-mismatch` reports that are real.
+  
+  `type` now accepts an ARRAY of coarse kinds as well as a single one (maintainer
+  ruling on objectui#3832, direction (a)), and a value passes the coarse check when
+  ANY declared arm accepts it. Both declaration sites in `@object-ui/types` move
+  together with the registry's own copy in `@object-ui/core`, and
+  `ComponentInputSchema` enforces the same widening — a non-empty array of
+  DISTINCT kinds, so an empty arm list or a repeated arm is refused at authoring
+  time rather than normalized behind the author's back.
+  
+  Five declarations now spell their real contract, and the `type-mismatch` warning
+  on each of these legal writes is gone:
+  
+  - `page:header.title`, `page:header.subtitle`, `page:card.title` —
+    string **or** inline translation map (the spec's union, measured against
+    `ComponentPropsMap` at the pinned rc.6; the renderers resolve both through
+    `pickLocalized`);
+  - `record:alert.title`, `record:alert.body` — the same two shapes, justified
+    against the RENDERER since the pinned spec carries no `record:alert` props
+    schema;
+  - `element:text_input.defaultValue` — `string | number`, the spec's union,
+    which had been narrowed to `'string'` with the number arm named only in prose.
+  
+  **Backward compatible, and measured as such.** The single-kind form stays valid
+  and is still the canonical spelling for a one-arm key: it validates identically
+  (the diagnostics for one arm, `invalid-enum` and its `error` severity included,
+  are byte-identical), and `manifestFromConfigs` collapses a one-element array back
+  to the bare string, so every entry already in a published `sdui.manifest.json`
+  serializes unchanged and arrays appear only where a union was really declared.
+  The JSX authoring surface follows in the same step — `generateDts` emits a
+  TypeScript union for a union input, so the `.d.ts` an author type-checks against
+  accepts exactly what the gate accepts.
+  
+  A union widens what is legal; it does not switch the check off. A value matching
+  NO declared arm is still reported, a multi-arm mismatch reports at its strictest
+  arm's severity (`error` when an `enum` arm is present, so an enum's closed list
+  does not become dismissible by having a second arm added next to it), and arms
+  are meant to match the contract rather than relax the gate:
+  `element:text_input.defaultValue` deliberately gains no `object` arm because the
+  spec rejects a map there, and `element:record_picker.emptyText` keeps its single
+  `'string'` arm because that renderer drops the map form (objectui#4163) — an arm
+  the renderer never honours would advertise a shape that cannot reach the screen.
+- e1d4251: Action param `visible`: one dialect answer, and a fault that is fail-open and LOUD
+  
+  `ActionParamDialog`'s `filterVisibleParams` was the last predicate face never
+  converted to the canonical entry. It evaluated each param's `visible` on a bare
+  `ExpressionEvaluator` inside `try { … } catch { return true }`, and that produced
+  two defects at once (objectui#4640, measured on `main`):
+  
+  - **Silence.** Three of the four fault shapes emitted nothing at all — an
+    unparseable source, an unbound identifier and a faulting legacy predicate all
+    resolved without a word, so a broken `visible` was indistinguishable from an
+    absent one. The standing 2026-08-06 ruling on objectui#4051 /
+    objectstack#5149 names silence as the one option that is not available.
+  - **The fail DIRECTION was decided by the predicate's dialect, not by the
+    surface.** A bare string ran the legacy JS evaluator (lenient → falsy → param
+    silently DROPPED); a `{ dialect, source }` envelope ran CEL (fault → param
+    silently KEPT). One `visible` key, two opposite outcomes, chosen by whether
+    the authored text happened to contain `${…}` / `===` — the objectui#3314
+    shape. Both halves hurt: a dropped param means the dialog never collects a
+    value the server requires and the action fails at submit with nothing pointing
+    at the predicate; a kept one offers a field the backend rejects.
+  
+  `filterVisibleParams` now routes through `evalRowPredicate`. A param whose
+  `visible` cannot be evaluated is **shown**, and reported once, with the action
+  and the param named and the predicate quoted. Fail-open is the ruled direction
+  for this surface: an extra offered field is rejected by the server with a
+  message, while a silently hidden required param is undiagnosable. (Row surfaces
+  keep failing closed — there the harm runs the other way.) Boolean and blank
+  predicates are answered before the evaluator, so `visible: false` hides the
+  param and an empty predicate is not reported as broken.
+  
+  **Behaviour change worth knowing before you upgrade.** On the canonical CEL
+  engine an ABSENT key is a runtime fault, not a falsy read. A param gated on
+  `features.phoneNumber == true` in a deployment whose scope carries no
+  `phoneNumber` key at all now takes the fail-open branch: the param is SHOWN,
+  with a warning naming it, where it used to be hidden. The conservative outcome
+  is still available, in the spelling that is portable to the server's own engine:
+  
+  ```
+  has(features.phoneNumber) && features.phoneNumber == true
+  ```
+  
+  Deployments that DECLARE the flag (`features: { phoneNumber: false }`) are
+  unaffected — that is a genuine verdict on both engines, and it did not move.
+  
+  `@object-ui/core` gains the two evaluator changes this needed:
+  
+  - `evalRowPredicate` accepts **`rowless`** — "this surface has no row of its
+    own", so nothing is bound over the host scope and a `record` / `data` the
+    scope carries survives instead of being shadowed by an empty row. Row surfaces
+    are untouched: without the option the row is still the subject (objectui#3796).
+  - A faulting **`{ dialect, source }` envelope now reports its own source**.
+    It used to print the literal `"(expression)"`, and because the warn-once key
+    is (label, predicate), the first faulting envelope under a label silenced
+    every other one. The envelope is what `@objectstack/spec` normalizes every
+    authored predicate into, so this was the likeliest shape in served metadata
+    and the least diagnosable one.
+- 167ec42: `ComponentMeta.labelling` grows a third value: `'control' | 'group' | 'display'`
+  (objectui#4857, ruled jointly with objectui#4871 as the single repo-wide vocabulary for
+  "how does a host learn what a widget will render"). `'display'` declares a widget whose
+  whole surface is a pure display in EVERY state — no focusable control, nothing a
+  `<label for>` could ever reach.
+  
+  The form renderer answers the declaration with the objectui#4788 host container (field
+  id + `aria-labelledby` + `aria-describedby` + `role="group"`) in the editable state too;
+  the `readonly === true` arm keeps its exact #4788 semantics for undeclared widgets. The
+  display-only four (`formula` / `summary` / `auto_number` / `vector`) declare `'display'`
+  — on the real object-form path they arrive `disabled`, never `readonly` (a deliberate
+  distinction this change does not touch), so their visible labels pointed `for` at an id
+  no element carried and their help text had zero consumers in every editable form.
+  
+  `grid` was re-measured before being classified: its only bare-config focusable is the
+  auxiliary "Add line" button (routing `for` there would have label clicks insert rows),
+  and every realistic config is a table of per-cell inputs — a composite. It declares
+  `labelling: 'group'` and its root container now consumes the host id, name and
+  description, exactly like `address` / `checkboxes`.
+  
+  Companion registry gate: `FIELD_WIDGET_LABELLING` (exported) is a `Record` keyed by the
+  field-widget map's own literal key union, so registering a widget without deciding its
+  labelling is a compile error rather than a silent fall-through to the dangling-`for`
+  path, and the declaration test asserts the registered meta agrees with it key by key.
+- b1119ec: Project every declared `recordIdField`, and refuse an action that names no record
+  
+  objectstack#8018. An `api` action declaring `recordIdParam` identifies the record
+  it acts on by a row field — `recordIdField`, default `id`. The grid built
+  `$select` from the listView columns, `id` and the predicate refs only, so an
+  action keyed on any other field asked the server for everything except the key
+  naming its own record. The row arrived without it, and the injection was skipped
+  silently: the request went out anyway, minus the parameter. A backend reading a
+  missing selector as "match nothing" then answers success for having changed
+  nothing, so a record-scoped mutation reports success and does nothing.
+  
+  Two independent repairs, both in this change:
+  
+  - **Projection.** `listViewPredicates` (`@object-ui/core`) now also harvests
+    `recordIdField` from `rowActionDefs`, `bulkActionDefs` and the object's
+    `actions`, spelled as a synthetic `record.<name>` so the one existing harvester
+    handles it. Both projection builders — `ObjectGrid` and `ListView` — read that
+    function, so both gain the key with no call-site change. The existing guards
+    still apply: a name the object does not declare, or one that is not a bare
+    identifier, is dropped rather than put in `$select`, because an unknown key
+    there is not ignored by every backend.
+  - **Loud failure.** New `resolveRecordIdParamSeed` (`@object-ui/core`) is the one
+    definition of "can this row identify the record?". `useConsoleActionRuntime`'s
+    api handler now refuses the dispatch — `{ success: false, error }`, before the
+    request — when the row lacks the key, or holds `null` for it. The two refusals
+    are worded differently because they point at different repairs: an absent key
+    is a projection or read-visibility problem, a null value is a data one. Falsy
+    real values (`0`, `''`, `false`) are values and still dispatch.
+  
+  The second half is what closes the class rather than the common case: a row can
+  lack the key for reasons projection cannot fix — a server-side read mask that
+  strips the field regardless of `$select`, a partial payload, a field the
+  principal cannot read.
+  
+  Behaviour change worth noting: an action that previously dispatched an
+  under-specified request now fails visibly instead. That is the point — the old
+  path could not report the failure it was causing.
+- af025ee: Draw a null second-dimension group instead of carrying its measure invisibly
+  
+  objectui#4673. `buildChartSeries`' pivot branch kept the pre-objectui#4466
+  answer on the SECOND dimension: it bucketed groups by `String(row[groupKey] ??
+  '')` behind a `gId !== ''` gate, so a group whose second dimension is `null`,
+  `undefined` or `''` never joined the series list — while the line below the
+  gate still wrote its measure into the emitted row under the `''` key. The
+  number was in the data and bound to no mark, which is #4466's harm verbatim one
+  dimension over: the chart understated its own data without saying so.
+  
+  Measured on the card's repro — `GROUP BY status, priority` over a Backlog with
+  5 hours at High priority and 40 hours at no priority — the transform emitted
+  `{status: 'Backlog', High: 5, '': 40}` with a single `High` series, and the
+  renderer drew exactly ONE bar. The 40 hours were present in the row, scaled for
+  on the y-axis, and painted on nothing.
+  
+  Two such groups were worse than unbound: `null` and `''` both key `''`, so the
+  later group silently overwrote the earlier one's measure and one of the two
+  numbers did not survive the transform at all.
+  
+  **A known-empty group now draws; an unprojected key still refuses.** That split
+  is the doctrine the first dimension already used (objectui#4466 versus
+  `hasNoCategoryKey`, framework#4033), and it now answers the same way on both
+  dimensions. Concretely, a row that does not carry the group key at all gets no
+  bucket and contributes no column, where it previously wrote its measure under
+  `''`.
+  
+  `null` and `''` are two different groups with two series, following
+  objectui#4508's ruling on the first dimension.
+  
+  **The series key is collision-safe, not merely unlikely to collide.** Unlike an
+  axis bucket's private map key, a series key is a column of the emitted row and
+  the `dataKey` a renderer binds to, so it has to be unique within that row. A
+  group keys its column by its own display label — leaving an ordinary pivot's
+  rows, series, legend, tooltip and drill title exactly as they were — unless
+  that label cannot name it: shared with another group (a stored value spelling
+  the null bucket's label), reserved by the row itself (the x-axis column, the
+  identity carrier), or equal to some group's identity. Those key by identity
+  instead, which no other group has. Because no surviving label is any group's
+  identity, the two key spaces cannot meet.
+  
+  Drill-through follows the same assignment: a clicked series key resolves back
+  to the group IDENTITY it names, and rows are matched on that. The previous
+  `String(r[gDim] ?? '')` comparison was the display-string matching
+  objectui#4508 removed on the x-axis — it spelled a null group and an
+  empty-string group alike, so the empty-string group's segment resolved to the
+  null group's records rather than its own.
+  
+  No renderer change was needed: the null group's series carries the same
+  `nullCategoryLabel` the renderers already pass for the first dimension.
+- 9ce096f: Give a chart bucket an identity distinct from its display label
+  
+  objectui#4508. `buildChartSeries` used the bucket's DISPLAY string as the
+  bucket's own key, so two pairs of genuinely different groups were conflated —
+  and the segment click that drills a bar back to its records inherited both
+  conflations. The maintainer ruling (2026-08-14) approved the sentinel-identity
+  direction, aligning the chart branch with the distinct-bucket-id form the pivot
+  TABLE (`buildPivot`) already uses over the same dataset rows.
+  
+  Two collisions, one cause:
+  
+  - **A null group and an empty-string group drew ONE bar.** The pivot branch
+    keyed buckets by `String(xRaw ?? '')`, which spells `null` and `''`
+    identically. The bar took its label from whichever row created the bucket, and
+    the other group's segment then resolved to no row at all — a visible bar whose
+    click did nothing.
+  - **A record whose stored value spells the bucket label stole the null bucket's
+    drill.** A row storing the literal text `(None)` (or any localized
+    `chart.nullCategory` — `(未指定)` and the other nine packs) kept its own
+    bucket, so two bars carried the same axis text and BOTH resolved to the first.
+    That one is a wrong drill, not a dead one: clicking the null bucket's bar
+    opened the drawer on another group's records.
+  
+  What changed:
+  
+  - **`chartBucketId`** (`@object-ui/core`) is the bucket identity — the SAME
+    encoder `buildPivot` keys its buckets with (`pivotBucketId` over
+    `pivotDimensionValue`), so the two surfaces stop answering one question two
+    ways. The pivot branch now buckets by it, which is what makes null and `''`
+    two groups again.
+  - **`CHART_BUCKET_ID_KEY`** carries that identity on an emitted row, written
+    exactly where two DISTINCT buckets paint the same axis text — the complete set
+    of cases where the display string cannot name what was clicked. An ordinary
+    chart's rows are returned untouched (by identity), so no renderer-internal key
+    reaches an authoring surface.
+  - **`findChartSeriesRow`** takes that identity back as `options.bucketId` and
+    treats it as authoritative. The renderers forward it: the drill event gains
+    `categoryId` (`ChartSegmentClickEvent`, now declared once in
+    `@object-ui/core` instead of inline in three packages), `AdvancedChartImpl`
+    reads it off the clicked row on the cartesian, pie and funnel paths, and
+    `DatasetWidget.handleChartDrill` hands it to the lookup.
+  
+  Behaviour change worth noting: an empty-string category no longer resolves to a
+  null-valued row. That tolerance was justified as the drill layer's own spelling
+  of "no group value", but no producer of this lookup's `category` writes it,
+  while `''` IS the axis text a genuine empty-string group paints — so the
+  tolerance was giving that group's bar a different group's records. A host that
+  forwards no `categoryId` keeps its existing drill unchanged.
+- e05db88: A clicked cartesian mark names its own series, and the drill title reads its label
+  
+  objectui#4672, objectui#4682.
+  
+  **The dead pivoted drill.** objectui#4680 fixed what a cartesian click could
+  read out of recharts 3's `MouseHandlerDataParam`, and measured the wall it could
+  not get past: a chart-level click is an AXIS interaction, and recharts
+  dispatches those with `activeDataKey` hard-coded `undefined`, because the shared
+  cursor spans every series at that tick. A pivoted dataset chart — 2 dimensions,
+  1 measure, the shape ADR-0021 introduced — needs the series to resolve its drill
+  row, so every segment of every such dashboard chart stayed a dead click. The
+  series was left unresolved rather than guessed, and the card carried the rest.
+  
+  The answer is the mark itself. This renderer draws the `Bar` / `Line` / `Area`,
+  so an item-level `onClick` closes over the very `dataKey` it was rendered with —
+  the series is statically known, not inferred from tooltip state.
+  
+  Both handlers fire for one gesture (measured: item first, chart second, sharing
+  one `nativeEvent` object), so the item handler does not emit. It RECORDS its
+  series, stamped with that gesture, and the chart-level handler composes the one
+  event. That is the double-fire answer and the additive property together:
+  
+  - **one click, one drill event**, because there is one emit site — not a second
+    event suppressed after the fact;
+  - **a click that lands on no mark is untouched**: it records nothing and falls
+    through to the objectui#4680 axis answer exactly as shipped — category, bucket
+    identity, and the series only where one series is plotted. Empty plot area
+    stays category-only, and "drill the whole category" was rejected as a
+    different product question. Nothing that resolved before stops resolving; a
+    line's `dot={false}` stroke simply GAINS the exact series where it is hit;
+  - pairing on the shared DOM event rather than on a flag means a record left by
+    one gesture can never be adopted by a later click.
+  
+  The clicked key is forwarded exactly as rendered, `''` included: the
+  empty-string second-dimension group draws its own bar since objectui#4673, and
+  `''` is falsy, so a truthiness test on the way out would send no series at all
+  and leave that bar's drill standing on the reader's coercion instead of on what
+  was clicked.
+  
+  **The opaque drill title.** `ChartSegmentClickEvent` gains `seriesLabel`, and
+  `DatasetWidget`'s drill drawer titles itself from `seriesLabel ?? series`.
+  `ev.series` stays the LOOKUP key — `findChartSeriesRow` resolves it through the
+  same assignment `buildChartSeries` made — and only the title reads the label.
+  
+  The two strings are equal for every ordinary group, which is why reading the key
+  as a title went unnoticed. They part company when a group's label cannot name
+  it: the null bucket beside a record whose stored value literally spells
+  `(None)`, which is objectui#4508's collision on the series axis, reachable since
+  objectui#4673. Both groups then key by `chartBucketId`, and the drawer opened on
+  the right records under the title `Backlog / [null]`. An internal id where a
+  label belongs reads as broken DATA rather than as a broken title.
+  
+  Neither string can do the other's job, which is why this is a second field
+  rather than a change to the first: the label is not resolvable (it is exactly
+  what the colliding groups share) and the key is not showable. `seriesLabel` is
+  optional and absent wherever a renderer resolved no label, so every other
+  chart's title is byte-identical.
+- d2ce342: Retire the structured `confirm` object on actions (objectui#4314, maintainer ruling
+  2026-08-17, ADR-0049 enforce-or-remove). `confirmText` is now the one confirm
+  spelling — the only one the translation bundle can address
+  (`{ns}.objects.{obj}._actions.{name}.confirmText`), matching `@objectstack/spec`'s
+  action surface.
+  
+  Breaking semantics (flagged `minor` per this repo's version-alignment policy):
+  
+  - `@object-ui/types`: `ActionSchema.confirm` is a `?: never` tombstone — authoring
+    it is now a tsc error, and the Zod twin rejects any authored value at parse time
+    (it previously accepted the object). The backwards `@deprecated` note that
+    steered authors from `confirmText` INTO the structured arm is gone.
+  - `@object-ui/core`: `ActionRunner` no longer reads `confirm.message` (which used
+    to outrank `confirmText`, untranslated). `ActionDef.confirm` carries the same
+    `never` tombstone. The `ConfirmationHandler` signature is unchanged, but the
+    runner now invokes it without the `options` argument.
+  - `@object-ui/plugin-grid`: `resolveBulkActions` no longer falls back to
+    `confirm.message` when promoting an object action — spec metadata can never
+    deliver that key.
+  
+  Nothing in the repo, the example apps, or the schema catalog authored the
+  structured form (verified on the issue); a dialog authored that way silently lost
+  localization. Reopen condition recorded on objectui#4314: real demand returns the
+  arm WITH bundle keys designed in.
+
+### Patch Changes
+
+- 2533ec5: The bulk-action dialog's "this widget needs a DataSource" rule now derives from the shared reference-field family instead of a fourth private copy.
+  
+  `packages/plugin-grid/src/components/bulkParamToField.ts` held its own
+  `DATA_SOURCE_WIDGET_TYPES` — the fourth hand-maintained answer to one question
+  ("which widget has to query records, so it must be handed a DataSource and a
+  `reference_to`"), and the only one whose member set matched none of the other
+  three: `lookup` / `master_detail` / `user`, against `@object-ui/core`'s
+  `EXPANDABLE_FIELD_TYPES` (which also holds `tree`) and the object form's rule
+  (which adds three widget-hint pickers). Nothing anywhere could detect the drift;
+  the same shape objectui#4770 and objectui#4790 each closed on another surface.
+  
+  It now reads core's set through one predicate, so all three consumers of the rule
+  — the label prefetch / option source (`isLookupishParam`), the `dataSource` prop
+  the dialog threads into the widget (`fieldNeedsDataSource`), and the
+  `reference_to` / `display_field` branch of `bulkParamToField` — cannot drift apart
+  from each other or from the form again.
+  
+  No behaviour change on any reachable path, which is why this is a patch. The one
+  member the two tables differed on, `tree`, can never be a widget key on this
+  surface: it is absent from the fields widget map and `mapFieldTypeToFormType`
+  sends it to `field:lookup`, so a `tree` param arrives at the rule as `lookup`
+  (pinned). The divergence in the other direction is deliberately preserved: the
+  form additionally wires `object-ref` / `filter-condition` / `recipient-picker`,
+  widget hints no object schema can declare and no bulk param produces — absorbing
+  them would change which widgets receive a DataSource here, which is a behaviour
+  change and not a convergence.
+  
+  The pin is an identity pin, not a membership one: it spies on the `has` of the
+  Set object core exports, so a member-identical private copy fails it. A
+  value-equality assertion would have passed against exactly the defect this
+  change removes.
+- bbe8b86: The allow-list of option widgets that are fed the live record is now one exported constant, `CASCADE_OPTION_WIDGET_TYPES`, instead of three private copies.
+  
+  `select` / `multiselect` / `radio` / `checkboxes` are the widgets whose OFFERED
+  option set is re-resolved against a record (per-option `visibleWhen`, plus the
+  `dependsOn` gate), so they are the widgets a surface must thread its live record
+  to. Three surfaces feed that one evaluator — the object form, the single-record
+  action dialog and the bulk action dialog — and until now each carried its own
+  private `new Set([...])` of the same four keys, with a comment in each asking the
+  next person to change all three together. Nothing could have reported them
+  drifting: every copy passed its own behavioural tests, and a divergence would
+  have shown up only as one surface silently disagreeing with another about what
+  "the record" is.
+  
+  The set now lives in `@object-ui/core`, next to `resolveCascadingOptions` — the
+  evaluator that reads that record — because core is the one package all three
+  surfaces already depend on, and it is re-exported from `@object-ui/fields` next
+  to `resolveFormWidgetType`, whose output is the vocabulary the keys are written
+  in. Both are the same object, pinned by test; each consumer keeps its own
+  normalization (`normalizeFieldType` in the form, `resolveFormWidgetType` in the
+  dialogs), which agree on these four members.
+  
+  No behaviour changes: the members are identical on all three surfaces, and the
+  existing pins for each surface still assert the same records reaching the same
+  widgets. The rationale that was repeated in the three copies — including the
+  note that the widget-hint picker family (`filter-condition`, `recipient-picker`,
+  the lookup family) reads a different sibling key off the same channel and is
+  deliberately NOT in this set — is now stated once, in the constant's own
+  documentation. Whether the action and bulk dialogs should ever feed those
+  pickers stays an open question (objectui#4771), unchanged by this convergence.
+- 8477be5: `cloneAsOverride()` now returns `DeepMutable<T>`, so a Tenant/User override draft type-checks as the mutable value it has always been.
+  
+  `cloneAsOverride<T>(view: T): T` handed the input type straight back. Cloning a
+  `SystemView<S>` — which is `DeepReadonly<S>` plus the marker symbol — therefore
+  returned something still typed deep-readonly, even though the implementation has
+  always produced a plain mutable object (`structuredClone`, or a JSON round-trip
+  fallback) and deliberately drops the marker. The declaration was simply wrong
+  about its own value, and the documented override flow was the thing that broke:
+  
+  ```ts
+  const draft = cloneAsOverride(userListView)
+  draft.columns.push({ name: 'name' })   // TS2339 before this change
+  ```
+  
+  That is `packages/core/README.md`'s override example, and it failed to compile
+  against the built types — measured by the doc-snippet compile gate, which reads
+  `dist/*.d.ts` rather than source. The neighbouring line one block up,
+  `userListView.columns.push(...) // ❌ TypeError (strict mode)`, is the opposite
+  demonstration and correctly still fails; only the draft line changes colour.
+  
+  The fix adds `DeepMutable<T>`, the inverse of the `DeepReadonly<T>` that
+  `SystemView` is built from, and returns it. Per the maintainer's 2026-08-19
+  ruling (option A on objectui#5257), the alternatives were rejected by name:
+  teaching a cast in the README is the lenient-consumer pattern the contract rules
+  out, and declaring the block a documentation fragment hides a real signature
+  defect behind the fragment marker.
+  
+  Why this is a patch and not a break: the return type relaxes TOWARD what the
+  runtime already does, never away from it. A caller gains permission to mutate;
+  nobody loses one. `DeepMutable<S>` stays assignable everywhere `DeepReadonly<S>`
+  or `SystemView<S>` was expected, so a caller who fed a draft back into a
+  deep-readonly position still compiles — both directions are pinned as type-level
+  cases in `freeze-schema.types.test.ts`. A repo-wide sweep found no call site at
+  all outside the README, so nothing in this workspace needed changing.
+  
+  Two limits of `DeepMutable`, stated rather than discovered later. It is
+  symmetric with `DeepReadonly` arm for arm, which means it inherits the same
+  tuple behaviour: a tuple widens to an array, exactly as `DeepReadonly` widens it
+  in the other direction. And it does not remove the `SYSTEM_VIEW_MARKER` key —
+  the clone never carries the symbol at runtime, but the key is declared optional,
+  so keeping it states "may be absent", which is true. Excluding it would require
+  a non-homomorphic mapped type that drops the `?` modifier from every other
+  property and turns optional keys required — a strictly worse type traded for
+  removing a key that already reads as optional.
+- ad07b65: Four packages stop publishing tooling material in their `dist/`
+  
+  Each of these packages spelled its build exclusions as `*.test.*`, while this repo's tooling convention is a directory one — `__tests__` / `__mocks__` / `__benchmarks__`, exactly as `TOOLING_FILE` in `scripts/check-phantom-dependencies.mjs` spells it. Any tooling file whose *name* is not `*.test.*` therefore stayed in the emit program and shipped in the tarball. This is the same shape and the same cause as objectui#4006, which fixed `@object-ui/fields` and `@object-ui/plugin-editor` by the filename criterion and so did not reach these four.
+  
+  Measured by building each package from a cleared `dist/` on both sides of the change. Nine files disappear, none appears, and every surviving file is untouched — the totals move by exactly the count removed:
+  
+  | package | `dist/` files | removed |
+  | --- | --- | --- |
+  | `@object-ui/core` | 176 to 174 | `dist/__benchmarks__/core.bench.js`, `core.bench.d.ts` |
+  | `@object-ui/plugin-designer` | 70 to 66 | `dist/__tests__/__mocks__/plugin-form.d.ts`, `plugin-grid.d.ts`, and both `.d.ts.map` |
+  | `@object-ui/plugin-grid` | 62 to 60 | `dist/__tests__/explainDouble.d.ts` and its `.d.ts.map` |
+  | `@object-ui/plugin-view` | 13 to 12 | `dist/__tests__/explainDouble.d.ts` |
+  
+  Only `@object-ui/core`'s had runtime weight. The other eight are declarations nothing resolves, but `core.bench.js` is a real emitted module whose first import is `import { bench, describe } from 'vitest'` — a runtime import of a package a consumer never installs, since `vitest` is a devDependency of `@object-ui/core` and devDependencies are not installed transitively. Nothing resolves it today either (it is not in the `exports` map), so no consumer breaks in either direction; this is the tarball shedding files nothing reached.
+  
+  No type coverage leaves with the emit. The three plugins' helper and mock files are already program inputs of the `tsconfig.test.json` that each package's `type-check` chains, reached through the imports in the suites beside them — `tsc --listFiles` names all four files on both sides of the change. `core.bench.ts` had no such edge, since nothing imports a benchmark, so it is now named explicitly in `packages/core/tsconfig.test.json`. That move was deliberate rather than forced: `scripts/check-type-check-coverage.mjs` enumerates `*.test.ts(x)` only, so a benchmark that no program reads is invisible to it, and dropping the coverage silently would have been the "coverage that was right by accident" objectui#4006 recorded. Verified by appending a provably-false annotation to the benchmark, which turns `tsc -p packages/core/tsconfig.test.json` red at exit 2.
+- 41f498b: Fix `packages/core/README.md`'s Component Registry example, which taught
+  `new ComponentRegistry()` against an exported singleton **instance**, not a
+  class — the built `packages/core/dist/registry/Registry.d.ts` declares
+  `export declare const ComponentRegistry: Registry<any>`, so the snippet did
+  not compile (`TS2351: This expression is not constructable`, measured by the
+  objectui#5138 doc-snippet type gate). A reader who copied it got a compile
+  error; if `new ComponentRegistry()` had compiled it would have produced a
+  second, empty registry nothing renders from, the more expensive half of the
+  mistake.
+  
+  The snippet now calls `ComponentRegistry.register(...)` /
+  `ComponentRegistry.get(...)` directly on the singleton, with one line stating
+  it is the process-level shared instance `SchemaRenderer` resolves every
+  `type` against — the same wording `packages/components/README.md` was given
+  in objectui#5160, kept consistent across both READMEs. Readers who want their
+  own isolated registry still have `Registry` itself, separately exported as a
+  real class.
+  
+  `scripts/check-doc-snippet-types.mjs`'s `UNGATED_DOCS` entry for
+  `packages/core/README.md` is updated to match: `TS2351x1` is dropped from its
+  reason text now that the diagnostic is gone. The entry is not deleted — the
+  document's remaining `TS2339x2` pair (a different, pre-existing defect) is
+  out of scope for this change; it's tracked as objectui#5257.
+- ac600e5: A `user` field in a form now receives `dataSource` / `dependentValues` / `dependsOnLabels`, like every other reference field.
+  
+  The form renderer decided which registered widget gets those three props from a
+  module-private `DATA_SOURCE_FIELD_TYPES` set, while `@object-ui/core` kept
+  `EXPANDABLE_FIELD_TYPES` for the same underlying fact — a field whose stored
+  value is a foreign key into another object. The core side's TSDoc claimed to
+  mirror the form's set, and it did for 15 days: the form's copy then gained
+  `capability-multiselect` (objectui#2403) and the three widget-hint pickers
+  `object-ref` / `filter-condition` / `recipient-picker` (objectui#2421) on the
+  same day, after which the two sets were not in a subset relation in either
+  direction — `user` only in core, the picker names only in the form — with
+  nothing able to report it.
+  
+  The form now derives its rule instead of restating it: the reference half is
+  core's set, the form-specific half is the three picker names, which are widget
+  hints and can never be a declarable field `type`. Adding a member to
+  `EXPANDABLE_FIELD_TYPES` therefore also grants it the form's data-source wiring;
+  that coupling is intended and is now written down on both sides.
+  
+  The user-visible half is `user`. It previously received none of the three props.
+  `dataSource` and `dependentValues` each have a `SchemaRendererContext` fallback
+  inside the widget, so the person picker limped along wherever a provider
+  happened to supply one; `dependsOnLabels` has no fallback, so a
+  dependency-gated user picker interpolated the raw API name into its
+  "select ... first" hint in every locale — the leak objectstack#5407 closed for
+  lookups and left open here. The widget contract's own `dataSource` doc has
+  always named `user` among the types the form renderer injects for.
+  
+  No change to what is expanded, projected or rendered anywhere else: the core
+  set's members are untouched.
+- c1ef923: Grid and related-list column headers no longer offer a sort on a `formula` column.
+  
+  A `formula` value is computed on read: no driver materialises a column for it, so
+  a server `$orderby` naming one has nothing to order by. That sort never worked.
+  Until objectstack#6994 the platform did not say so — the response carried the very
+  values it had been asked to order by, out of order, under a `200`, with ascending
+  and descending byte-identical on a real SQL driver — and it now answers
+  `400 INVALID_SORT`. So the header was wrong before the platform's refusal and is
+  wrong after it, for the same reason: it offers a sort that cannot be performed.
+  
+  `ObjectGrid` withheld the affordance only from reference-bearing columns
+  (objectui#3096). Unmaterialized types are a SECOND reason a server sort is
+  impossible, not a different mechanism, so it now reads both — and so do the two
+  sort entry points of a related list (the embedded table's headers and the
+  sort-button row a `data-list` card keeps), which each derived that rule
+  separately.
+  
+  Client-side sorting is deliberately unchanged. There the rows are all in the
+  browser and the formula value is the one the server hydrated on read, so ordering
+  by what the cell shows is honest — the same split the relational carve-out makes.
+  A sort DECLARED in view metadata is also unchanged: it still goes out and is still
+  refused by name, because silently dropping an author's declaration would hide the
+  authoring error instead of surfacing it (the toolbar's sort picker keeps such a
+  field listed for exactly that reason — it is the only way to remove it).
+  
+  The membership — `formula` alone — moved out of a private set in `ListView` into
+  `@object-ui/core` (`UNMATERIALIZED_FIELD_TYPES` / `isUnmaterializedFieldType`),
+  bound to `@objectstack/spec`'s own storage predicate so the renderer cannot drift
+  from what the drivers actually store. It is deliberately narrower than the spec's
+  write contract `COMPUTED_VALUE_TYPES`: a `summary` and an `autonumber` each get a
+  real maintained column and sort correctly, and withholding their headers would
+  have broken two affordances that work.
+- af5e292: Emit explicit file extensions on relative import specifiers, so the published
+  entries can be imported by Node's own ESM resolver.
+  
+  `@object-ui/react`'s built entry re-exported through extensionless relative
+  specifiers (`export * from './SchemaRenderer'`). Node does not extension-search
+  relative specifiers, so `import('@object-ui/react')` under plain Node — an SSR
+  host, or any consumer without a bundler — failed with `ERR_MODULE_NOT_FOUND`.
+  Bundled consumers were never affected and are unchanged by this.
+  
+  `@object-ui/types`, `@object-ui/core` and `@object-ui/i18n` carried the same
+  emission; `@object-ui/react`'s entry stayed unloadable until they were fixed
+  too, because evaluation crosses into them. No exported API changed.
+- 9f23d2b: The object list's Import button now honours `userActions.import`'s CEL predicates.
+  
+  `@objectstack/spec@17.0.0` widened BOTH toolbar-scope keys, not just `create`:
+  `userActions.create` and `userActions.import` are typed identically
+  (`z.union([z.boolean(), RowCrudActionOverrideSchema])`) and
+  `resolveCrudAffordances` emits a predicate envelope for each, with the docblock
+  binding them in one breath ("`importPredicates` — same binding as
+  `createPredicates`"). objectui#4646 gave the `create` half a consumer and left
+  the `import` half declared-and-inert: `importPredicates` had zero readers in
+  objectui. An author could write `userActions.import.visibleWhen`, have the spec
+  accept it and the resolver parse it, and watch the object-list toolbar offer the
+  CSV import wizard unconditionally.
+  
+  The toolbar now evaluates them, mirroring the related list's create half:
+  `visibleWhen` fails CLOSED (an unevaluable predicate hides the entry and warns
+  once), `disabledWhen` fails SOFT (an unevaluable one leaves the button enabled),
+  and the declared-ness rules are the family's — `?? true` for `visibleWhen` so
+  `visibleWhen: false` hides rather than reading as "ungated", `!= null` for
+  `disabledWhen` so an empty predicate reads as "no condition". The layer sits on
+  TOP of the object-level verdict: a predicate can narrow what the `managedBy`
+  bucket, the server's effective API operations and the principal's grant already
+  allow, never re-open what they closed.
+  
+  Per the spec's binding, a toolbar predicate evaluates once per toolbar against
+  the record of the scope the toolbar sits in — and a standalone object list has
+  no record in scope. Predicates over the host scope (`os.user.*`, `features.*`)
+  are the meaningful shape there; one reading `record.*` has nothing to bind and
+  hides the entry, which is the fail-closed rule the spec spells out for exactly
+  this surface.
+  
+  `UserActionsOverride.import` widens from `boolean` to the same union as
+  `create`, deliberately in this same change: objectui#4646 kept it narrow on
+  purpose because widening a type ahead of its consumer re-declares the
+  inert-metadata defect one key over. Type and consumer travel together.
+- 31676be: `buildChartSeries`' pivot branch preserves key ABSENCE, so a never-projected first dimension still reaches the framework#4033 placeholder.
+  
+  `hasNoCategoryKey` (plugin-charts' `AdvancedChartImpl`) exists to catch one
+  shape: a dimension a dataset query GROUPED BY but never PROJECTED, so no row
+  carries the category key. Rather than draw an axis with no marks, the renderer
+  names the missing key. Its whole signal is `key in row`, asked of the rows it is
+  handed — which for a dataset-bound chart are `buildChartSeries`' output.
+  
+  The pivot branch wrote `[xKey]` onto every bucket it created, so `key in row`
+  was unconditionally true downstream and the guard could not fire for a
+  2-dimension/1-measure chart no matter what the query returned. Every row
+  collapsed into one unnamed bucket drawing a blank tick — the exact silent shape
+  the placeholder was introduced to eliminate. The defence was dead precisely
+  where the defect it guards against lands. The single-dimension branch was never
+  affected: it passes rows through, so key-absent rows stay key-absent.
+  
+  An emitted bucket now carries the axis key exactly when some row of it did.
+  That is `hasNoCategoryKey`'s own `rows.some(key in row)` lifted through the
+  pivot's aggregation, so the guard reads the same fact before and after.
+  
+  The route rests on a measurement of how a dataset query actually reports an
+  unprojected dimension in a 2-dimension grouping: it OMITS the key. The ObjectQL
+  strategy writes a dimension key only when the engine returned that column, the
+  native-SQL strategy returns driver rows carrying only the selected columns, JSON
+  cannot transport `undefined`, and `ObjectStackAdapter.queryDataset` passes rows
+  through by reference. An explicit `null` means the opposite — the column WAS
+  projected and its value is null — and that case is untouched: it still renders
+  under the `(None)` bucket label (objectui#4466 / objectui#4497). Where one
+  bucket collects both (an absent value and a stored `null` share the `[null]`
+  identity), the bucket keeps its label and draws, because refusing there would
+  tell an author their query never projected a dimension that it did.
+  
+  No change to any chart whose first dimension projected: ordinary, null-valued
+  and empty-string categories all emit byte-identical rows, key order included.
+- 5ffcc14: fix(plugin-report): forward the chart chrome and series presentation `ReportChartSchema` declares (objectui#4877)
+  
+  A report's embedded chart forwarded exactly six keys to the registered chart
+  component — `chartType`, `data`, `height`, `isAnimationActive`, `series`,
+  `xAxisKey`. Everything else `ReportChartSchema` declares as authorable never
+  left the report renderer, so it was inert metadata: the author writes it, the
+  schema accepts it, nothing reads it.
+  
+  `showLegend` was the sharpest case because dropping it does not merely ignore
+  the author, it INVERTS them: `AdvancedChartImpl` computes
+  `legendVisible = showLegend !== false`, so an absent value means the legend is
+  on and an explicit `showLegend: false` still drew one.
+  
+  Now lowered, under objectui#4229's ruled data/presentation split:
+  
+  - chrome — `showLegend`, `showDataLabels`, `colors` (both the positional-palette
+    array and the per-category record), `subtitle`, `description`, `annotations`,
+    `interaction`, `height`;
+  - per-series presentation — `color`, `stack`, `type`, `yAxis`, `dashArray`,
+    `opacity`, `variant`, matched by `series[].name` so series MEMBERSHIP stays
+    with the dataset.
+  
+  `title` is deliberately not forwarded: the report renderer paints it as its own
+  heading above the plot, and forwarding it would draw a second one inside the
+  chart's frame. `aria` is not lowered either — nothing on this path reads it
+  (`AdvancedChartImpl` has no `aria` prop, and this renderer hands the component a
+  schema directly rather than through `SchemaRenderer`'s flat ARIA injection), so
+  forwarding it would move declared-but-unread one layer down.
+  
+  The two helpers (`chartConfigPresentation`, `mergeAuthoredPresentation`) moved
+  from `plugin-dashboard`'s `DatasetWidget` to `@object-ui/core` beside
+  `buildChartSeries`, the derivation they merge onto, so both surfaces lower one
+  vocabulary once instead of keeping a second copy (the duplication objectui#4389
+  filed as a defect). `@object-ui/core` additionally exports `mergeAuthoredSeries`
+  — the series merge alone — for a surface whose axes are bare dimension/measure
+  NAME strings rather than spec `ChartAxis` objects, which is what a report chart
+  declares. `DatasetWidget` re-exports both names, so its public surface and its
+  rendering are unchanged.
+- d971e51: A create form no longer deadlocks on a `requiredWhen` field that also declares a runtime `defaultValue`.
+  
+  `#4069` ruled that in **create** mode a field whose `defaultValue` is a runtime
+  instruction the server resolves per insert (`NOW()` / `current_user`, or a CEL
+  Expression envelope) is producer-owned: the control is deliberately left empty
+  and the key is omitted from the payload, because `ObjectQL.applyFieldDefaults`
+  resolves the declaration only for a field that arrives absent or null. That was
+  implemented on the STATIC `required` flag.
+  
+  The conditional spelling was not covered. `requiredWhen` is resolved one layer
+  downstream, in the form renderer, against the live record — so a predicate
+  resolving TRUE on a create form put the requirement straight back: the control
+  was still empty by design, the submit was refused, and the user had nothing
+  sensible to type.
+  
+  Both spellings now behave identically on a producer-owned field. A
+  `requiredWhen` predicate is a claim about the value at rest in a given state,
+  and `NOW()` / `current_user` resolve at insert regardless of state, so the
+  producer's guarantee covers the conditional claim by the same argument that
+  covers the unconditional one. An author who really means "the user must supply
+  this in this state" has a natural spelling for it: do not declare the default.
+  
+  The suppression lands in the single evaluator both layers read,
+  `resolveFieldRuleState` — the same verdict that draws the required marker and
+  the one the submit-time check consults — so a field can never lose its asterisk
+  while still refusing the write. The classifier that answers "is this value the
+  producer's to supply" moved down to `@object-ui/core`
+  (`isRuntimeDefault` / `isServerOwnedValue`, re-exported from
+  `@object-ui/plugin-form`) so the renderer, the wizard's cross-step gate and the
+  create-form field builders all read one implementation rather than three.
+  
+  **Edit mode is unchanged.** Defaults do not re-apply to an existing record, so
+  on a persisted row the token was already resolved at insert and blanking the
+  column is a real removal: `requiredWhen` enforces there exactly as authored.
+  Fields with no declared default, and fields whose default is a static literal
+  (which IS seeded into the control), are also unaffected in both modes.
+- dfc6975: Related-list "+ New" now honours `userActions.create` predicates, and the grid
+  toolbar's inline-edit affordance is gated on `update` permission (objectui#4646,
+  objectui#4647).
+  
+  Two declared-but-unenforced gaps on the same toolbar surface.
+  
+  **#4646 — `createPredicates` had a producer and no consumer.**
+  `@objectstack/spec@17.0.0` widened `userActions.create` to
+  `z.union([z.boolean(), RowCrudActionOverrideSchema])`, so `resolveCrudAffordances`
+  emits `createPredicates` — and nothing in objectui read them, against roughly
+  fifteen consumption sites apiece for `editPredicates` / `deletePredicates`. The
+  symptom: a parent record entering a frozen state correctly greyed its children's
+  row Edit/Delete while the related list's "+ New" stayed fully live, so the user
+  filled in the whole child form to earn a server 409. The related-list toolbar now
+  evaluates `visibleWhen` / `disabledWhen` **once against the host parent record**,
+  per the spec docblock's binding for this key, on top of the existing
+  `o.create ∧ can(child, 'create')` check. `visibleWhen` hides "+ New" and fails
+  CLOSED; `disabledWhen` greys it and fails SOFT — the same evaluator, fail
+  directions and hidden-vs-disabled split the record header already uses for
+  edit/delete (objectui#4419 / PR #4515). A bare-boolean `userActions.create` is
+  untouched: with no predicates there is nothing to evaluate.
+  
+  **#4647 — the inline-edit toggle was the one ungated affordance on its toolbar.**
+  It rendered on "grid view ∧ the host wired `onInlineEditChange` ∧ not the compact
+  toolbar", and every host wires that callback unconditionally. New and Import are
+  hidden for an account without the grant and the bulk-delete entry on the same
+  toolbar ANDs `can(obj, 'delete')`, but a read-only principal could flip inline
+  edit, modify cells and press "Save all" to earn a server 403. It is now gated on
+  the object's resolved edit affordance ∧ `can(object, 'update')`, mirroring that
+  bulk-delete gate. The gate is applied at all three sites that carry this
+  affordance — the wide toolbar's toggle, the compact toolbar's settings-popover
+  entry (which previously had no gate at all, not even the callback), and the
+  `editable` mode handed to the grid, so a stored view carrying `inlineEdit: true`
+  can no longer drop a read-only principal into editable cells with no toggle to
+  press.
+  
+  `ListViewSchema.userActions.editInline` is also consumed now: an explicit `false`
+  withholds the affordance wholesale, which authors previously could not do.
+  
+  **Behaviour change for read-only users, stated plainly.** Where the UI used to
+  offer inline editing and let the server refuse it, it now declines to offer the
+  entry point at all. No data access changes — the server gate was and remains the
+  enforcement boundary; this only stops the UI walking users into round-trips
+  guaranteed to fail. Accounts *with* the grant see no change, and hosts with no
+  `PermissionProvider` mounted (standalone embeds, the Studio designer) keep
+  today's behaviour, since `can()` answers `true` there by design.
+  
+  One deliberate non-change: the absent case of `userActions.editInline` defers to
+  the host's existing `inlineEdit` channel rather than enforcing the spec's
+  `.default(false)`. Enforcing that default would remove the toggle from every
+  stored console list view in one release, since nothing folds a legacy key into
+  `editInline` and no existing view declares it. This follows the rule the
+  surrounding toolbar-flag block already states for itself — defaults chosen to
+  match what the flags have always done. `InterfaceListPage`, the key's other
+  consumer, reads the absent case as OFF, because the ADR-0047 interface page has
+  no such host channel to defer to.
+- Updated dependencies [88085e3]
+- Updated dependencies [279fb13]
+- Updated dependencies [1184192]
+- Updated dependencies [a2a9747]
+- Updated dependencies [af5e292]
+- Updated dependencies [7f96b10]
+- Updated dependencies [f1d4748]
+- Updated dependencies [578e025]
+- Updated dependencies [598c89a]
+- Updated dependencies [b8b9af4]
+- Updated dependencies [97abb24]
+- Updated dependencies [deb157a]
+- Updated dependencies [d2ce342]
+- Updated dependencies [9695da7]
+- Updated dependencies [58b8346]
+- Updated dependencies [3cf4de0]
+- Updated dependencies [c9dc811]
+- Updated dependencies [a0b9e91]
+- Updated dependencies [99bd015]
+  - @object-ui/types@17.6.0
+
+## 17.5.0
+
+### Minor Changes
+
+- ee66e2e: Close `ActionDef` — delete the `[key: string]: any` index signature and converge `visible` / `disabled` on the spec's unified shape.
+
+  `ActionDef` accepted any key of any type, so a typo (`targt`) and a retired spec
+  key (`execute`) both type-checked and the runner then silently bound no handler
+  — the objectstack#2169 "Mark Done does nothing" shape. Step 1
+  (objectstack#4075) made that audible with a dev-mode warning; step 2 promoted
+  the 18 spec-owned keys to real fields. This is **step 3**, executing the
+  maintainer's 2026-08-06 ruling now that its upstream half shipped in
+  `@objectstack/spec` 17.0.0-rc.6 (objectstack#5970).
+
+  - **`visible` and `disabled` now have ONE shape, derived from the spec** —
+    `boolean | string(CEL) | { dialect, source }`. The ruling was "统一形状,spec
+    采纳": boolean is the degenerate literal verdict, the string is CEL shorthand,
+    the envelope is the full form. `visible` loses its hand-written `| boolean`
+    (the spec adopted that arm, so restating it locally would be a second
+    contract), and `disabled` gains the envelope arm it never had — it was
+    `string | boolean`, which is why the envelope the spec emits could only be
+    read through a cast.
+  - **The index signature is gone.** `tsc` now rejects an unknown or retired key
+    at any site that authors an action literal in code.
+  - **Five keys the deletion surfaced, promoted to real fields.** `to`,
+    `external`, `newTab`, `replace` — the `navigation` alias's own spelling, ruled
+    legitimate by step 1 and listed in `NAVIGATION_ALIAS_KEYS` ever since, but
+    declared only as data; and `description`, which every action renderer forwards
+    (`check:action-forward-parity` requires it) and the param-collection dialog
+    reads for its subtitle (objectui#4192). These were the only two `TS2353`s the
+    deletion produced across the whole workspace.
+  - **`ActionContext` keeps its index signature**, deliberately. It is a runtime
+    data bag whose keys are genuinely open; `ActionDef` is a declared metadata
+    contract. That asymmetry is the point, and it is now pinned in both
+    directions.
+
+  **Breaking edge, deliberate — same class as step 2's, one step further.** An
+  `ActionDef` literal carrying a key this interface does not declare is now a
+  compile error where it previously compiled and did nothing at runtime. That
+  includes the retired `execute` (rename it to `target`; `os migrate meta --from
+16` rewrites it) and plain typos. Values that were only ever absorbed silently
+  are the ones that stop compiling, so the failure moves to where it can be fixed
+  rather than appearing as a button that does nothing.
+
+  **What did NOT retire with the index signature**, contrary to step 1's
+  expectation: the dev-mode `warnOnUnknownActionKeys` shim and `executeScript`'s
+  `execute` rename prescription both stay. `tsc` only ever sees actions authored
+  as TypeScript, while stored `sys_metadata` rows are rehydrated UNPARSED
+  (objectstack#3903) — which is the population `execute: 'markDone'` actually
+  lives in. The two mechanisms cover disjoint populations; retiring the runtime
+  half would have re-opened the gap it was written for.
+
+- 3fc2971: A null-keyed group renders as an explicit bucket instead of silently vanishing from a chart (objectui#4466)
+
+  `buildChartSeries`' single-dimension branch passed rows through verbatim, so a row whose category VALUE is `null` reached recharts with a null category and drew no mark. The visible outcome was not an empty chart but a quietly wrong one: rows `[{user_id: null, event_count: 51}, {user_id: 'Dev Admin', event_count: 2}]` drew exactly ONE bar — the dominant group, 51 of 53 events, dropped while the y-axis scale still accommodated it, so the chart understated its own data and the axis proved the data had been there. With every group null it drew axes, gridlines and an axis title with zero marks and no empty state, which is the shipped first-boot state of the built-in System Overview board's "Events by User" (every seeded `sys_audit_log` row is written with `user_id = NULL`).
+
+  The mapping lives in the shared series layer, so dashboard widgets and standalone `ObjectChart` get one answer rather than a per-chart patch in the recharts wrapper. It resolves the two-answers disagreement the card names as well: an empty result set keeps the designed empty state, a non-empty result always draws bars — the null bucket included.
+
+  `@object-ui/core` gains `NULL_CATEGORY_LABEL` and `ChartSeriesOptions`; `buildChartSeries` and `findChartSeriesRow` each take an optional trailing `options`. Both additive — every existing call site compiles and behaves identically, and a result with no null category is still returned by array identity. The two helpers are a pair on purpose: the caller matches a clicked segment against rows that still carry the raw `null`, so `findChartSeriesRow` reads the bucket label back to that row and the newly-visible bar keeps its drill-through instead of resolving to `-1`.
+
+  The label goes through the i18n channel (`chart.nullCategory`, en `(None)` / zh `(未指定)`, all ten packs), passed down by the renderer: `@object-ui/core` is React-free and cannot read the locale bundle, so it takes the resolved string the same way `dimensionOptionTranslator` takes a resolver. Its English constant is the floor for a provider-less host, not the mechanism.
+
+  `hasNoCategoryKey` (framework#4033) is untouched and now documented against this: a row that does not carry the category key AT ALL is a different defect — a dimension grouped by but never projected — and keeps its explanatory placeholder. The bucket deliberately never ADDS the key to such a row, which is what keeps that guard's signal alive. Key absent → the placeholder; key present with a null value → the bucket.
+
+- dde7283: `chatbot` and `chatbot-enhanced` now pass only whitelisted DOM props to their host element (objectui#4431)
+
+  Both registrations destructured `schema` and `className` and forwarded everything else. `SchemaRenderer` hands a registered component the authored node's own keys, the contents of its `props` container, the ARIA it resolved and the host's trailing props — so all of it became attributes on the chat root `div`, because React passes unknown lowercase attributes through in silence and stringifies object values. Measured through the real SDUI path with a data-source adapter attached: **14 non-DOM attributes on each widget**, including `datasource="[object Object]"` (the injected adapter, which only appears on a deployment that really loads data) and a camelCase `arialabel` sitting next to the resolved `aria-label`, so the element carried each ARIA value twice under two spellings — one of them meaningless to assistive technology.
+
+  Both are now consume-or-whitelist: configuration is read off `schema` as before, the evaluated `disabled` verdict is consumed by name, and only `toDomProps`' output reaches the element. The resolved `aria-label` / `aria-describedby`, `role`, `id`, `tabIndex` and the `data-*` family still arrive — dropping them would have been an accessibility regression dressed as a leak fix, so the pin asserts the delivered set exactly, not just the absent one. `chatbot-floating` is untouched: its content mounts through a portal and its root never spread.
+
+  `@object-ui/core` gains the shared executor this migration needs (`utils/dom-props.ts`): `toDomProps` for the SDUI widget contract, plus `pickDomProps` — the mechanism — for a package whose own contract declares a different key set. That is the objectui#4409 dependency direction: plugin packages declare `@object-ui/core` and must not grow a dependency on `@object-ui/fields` to reach a whitelist.
+
+  `@object-ui/fields` keeps its own key list and its compile-time bindings, and now executes them through core's mechanism. Its behaviour is unchanged and its exported `DomProps<P>` is the same structural type. The two lists differ for measured reasons and no longer can drift silently: `name` and `disabled` are legal only on form controls, which is what every field widget renders and what `FieldWidgetComponentProps` declares, while `role` is resolved by `SchemaRenderer` for every SDUI node and is not part of the field contract. A new assertion binds every shared key in both directions, with `role` named as the single deliberate exception.
+
+- f279deb: fix(core): bare-string filter options — docs/examples stop teaching it, the runtime lift warns (objectui#4356)
+
+  `globalFilters[].options` had two de-facto contracts. `@objectstack/spec`'s `GlobalFilterSchema` accepts only `{ value, label }` pairs, while `normalizeFilterOptions` also lifted a bare-string shorthand (`options: ['EMEA', 'APAC']`) — so a dashboard authored that way rendered correctly in objectui and was refused the moment it reached the platform's validation. That is the "one strict contract beats N dialects" divergence AGENTS.md #0.1 names, with the renderer's tolerance hiding the producer's bug instead of surfacing it.
+
+  Maintainer ruling of 2026-08-12 on objectstack#7917, verbatim 「7917 ②」: **the spec stays strict; the runtime lift retires behind a deprecation window sized by a stored-dashboard survey.** This is Phases 0 and 1 of that window, shipped together. Phase 2 (removing the lift) is scheduled on objectstack#7917 and is deliberately not here.
+
+  **Phase 1 — the lift now says so out loud.** `normalizeFilterOptions` still lifts a bare string, unchanged and mechanically lossless (`'EMEA'` becomes `{ value: 'EMEA', label: 'EMEA' }`), because stored dashboards carry the shorthand and dropping it silently would turn a rendering filter into an empty one. It now also logs a deprecation warning naming the offending filter, quoting the offending values, and printing the canonical replacement. The warning fires **once per offending filter per session** — `resolveDashboardFilterDefs` runs on every dashboard render, and a warning that floods the console is a warning that gets muted — and it is dev-mode only, matching the `warnOnDeprecatedObjectParams` convention in `actions/actionKeys.ts`. It does not fire for canonical object options, and a mixed array names only its bare members, since partial migrations happen. A silent lift can never be retired, because nothing would ever show that the last shorthand document is gone (ADR-0078).
+
+  **Phase 0 — objectui stopped teaching the form.** The stored-dashboard survey on objectstack#7917 found the shorthand's source: objectui's own docs and its schema-catalog corpus — which the catalog's `package.json` declares an AI RAG/few-shot retrieval source — still authored it, so the stored population was still growing. All seven non-test occurrences are corrected to the pair form: `content/docs/guide/dashboard-filters.md` (a code block **and** a prose passage that presented the shorthand as an equal alternative), `content/docs/plugins/plugin-dashboard.mdx`, `packages/plugin-dashboard/README.md`, and the three `examples/schema-catalog` `filtered-dashboard*.json` entries. Warning authors while the docs still taught the form would have been a contradiction users report as a bug.
+
+  **Guardrail.** The schema catalog previously asserted only that its entries were structurally well-formed and rendered without throwing — which is exactly how a spec-invalid example got in. Every `globalFilters[]` entry in every `plugin-dashboard` catalog example is now parsed with the real `@objectstack/spec` `GlobalFilterSchema`, with a non-vacuity control so a broken sweep cannot read as green.
+
+  New export: `resetDashboardFilterWarnings()`, the warn-once memo reset, matching `resetActionKeyWarnings`. Graded `minor` for that additive export — measured, the emitted `.d.ts` gains exactly one declaration and narrows nothing.
+
+- eb7f586: Dashboard dataset measures follow the display locale (objectui#4566).
+
+  `formatMeasure` and `formatDimensionValue` in `@object-ui/core` formatted every
+  value with a bare `undefined` locale tag at all three of their `Intl` sites.
+  `undefined` is not "the user's locale", it is the MACHINE's — neither of the
+  repo's two locale channels. A German session read a dashboard KPI as `1,234.5`
+  next to a grid cell rendering the same number as `1.234,5`, and inverted
+  separators read as a different number, not as an unstyled one.
+
+  Both functions take the display locale as a new OPTIONAL LAST parameter, and
+  `DatasetWidget` threads `useDisplayLocale()` into every site it formats through:
+  the KPI, the grouped table's measure and dimension cells, and the cross-tab's
+  header labels and cells.
+
+  **English output does not move**, and that is the discriminator against the
+  sibling fix. These sites already went through `Intl` with default grouping, so
+  the only thing that changes is WHOSE locale is used:
+
+  |                   | before      | after                 |
+  | ----------------- | ----------- | --------------------- |
+  | en, 1234.5 `0.0`  | `1,234.5`   | `1,234.5` (unchanged) |
+  | de, 1234.5 `0.0`  | `1,234.5`   | `1.234,5`             |
+  | de, 1234.5 EUR    | `€1,234.50` | `1.234,50 €`          |
+  | de, 0.6083 `0.0%` | `60.8%`     | `60,8%`               |
+
+  Contrast objectui#4553, where `formatPercent` had never grouped at all and
+  moving en `1235%` → `1,235%` WAS the fix.
+
+  Omitting the new argument reproduces the previous output byte for byte, so
+  callers that do not thread a locale yet are unaffected.
+
+  Two behaviours are deliberately preserved rather than "improved" alongside the
+  locale fix, both measured:
+
+  - **Integers stay verbatim.** The integer branch renders no separator and no
+    decimal mark, so a locale has nothing to change there — and routing it through
+    `Intl` WOULD change it (a locale with its own numbering system re-digits it,
+    and `1e21` expands to 22 digits).
+  - **The percent sign stays a literal suffix.** `Intl`'s `style: 'percent'`
+    re-scales by 100, and that round trip loses precision at the top of the range
+    (en `100,000,000,000,000,000,000,000%` becomes
+    `99,999,999,999,999,990,000,000%`). The consequence — a German list cell
+    writing `1.234,5 %` with a no-break space where a dashboard measure writes
+    `1.234,5%` — is filed separately rather than smuggled in behind a locale fix.
+
+  `@object-ui/core` is `minor` because two of its ENTRY exports gained an optional
+  parameter (measured in the built `.d.ts`). `@object-ui/plugin-dashboard` is
+  `patch`: its published declarations are unchanged — `buildPivot`'s new optional
+  parameter is internal, as that function is not on the package's `exports`
+  surface.
+
+- e901131: `DatasetResultField` is now `@objectstack/spec`'s `AnalyticsResult.fields[]` element itself, not a hand-written restatement of it
+
+  `packages/core/src/utils/dataset-format.ts` declared its own six-key interface for the analytics result column, under a doc comment describing the server's contract. The key set happened to match the spec today, so nothing was broken — but it was the last surviving member of the derive-don't-restate family (#3613 / #3753 on the parameter side, #3752 on the adapter return side), and it was the member with no compile-time tripwire: three surfaces (`plugin-dashboard`'s `DatasetWidget`, `plugin-report`'s `DatasetReportRenderer`, app-shell's `DatasetPreview`) consume this name AS the real column type, so the next spec column key would simply never appear here and no build would complain. It is now `AnalyticsResult['fields'][number]`, so it cannot lag the contract again.
+
+  **Consumer-visible type tightening (the reason this is a minor, not a patch).** The restatement had relaxed `type` to optional; the contract requires it. Anything that assigned a column literal without `type` — or a bare `{ name, label?, format? }` — to `DatasetResultField` will now fail to compile, and the fix is to supply the `type` the server always sends. Nothing in this repo needed changing: every value of this type originates in `ObjectStackAdapter.queryDataset`, which already declares the spec element, and no consumer reads `.type` at all, so the widening had bought no caller anything while advertising a `string | undefined` the wire never produces. Marked `minor` per the repo's bump policy, which reserves `major` for following `@objectstack/spec` across a major.
+
+  The exported name is unchanged and the `PercentScale` re-export from this module is untouched, so existing import paths keep working. `packages/core/tsconfig.typetests.json` (chained off the package's `type-check`) compiles the new parity test, so the pins are checked by CI rather than merely written down — including a negative pin that goes red if the hand-written interface is ever restored, and the `ChartResultField` superset relationship the module's comment claims.
+
+- d9d3463: Retire four zero-consumer declared surfaces (dead-surface sweep batch 3, #4328). Each was
+  measured as declared-but-never-read at the branch point, and each is removed rather than
+  left as an authoring surface whose values nothing acts on.
+
+  Breaking for anyone who typed against the removed declarations, marked `minor` per this
+  repository's version-alignment convention (the major tracks `@objectstack`, never an
+  API-break count):
+
+  - `@object-ui/core` no longer exports `mergeViewsIntoObjects`. It was a second copy left
+    behind by the move of that step to the provider layer, and it had drifted: it ignored a
+    view container's default `list` and keyed views by the authored bare key instead of the
+    composer's `<object>.<key>` identity. The live implementation — `MetadataProvider`'s, in
+    `@object-ui/app-shell` — is unchanged and remains the only one. (#3775)
+  - `@object-ui/types`' `RoleDefinition` no longer declares `permissions`. A role's grants
+    live in `ObjectPermissionConfig.roles`, keyed by object; that is the only home any
+    consumer reads (`resolveRoles` walks `inherits` and matches on `name`). The removed
+    field was _required_, so five fixtures across three packages had been declaring an empty
+    array for a value nothing would ever look at. Role-attached grants are now a compile
+    error rather than silently ignored data. (#4288)
+  - `@object-ui/react`'s `RecordContextValue` no longer declares `loading` / `error`. Both
+    had zero producers and zero consumers — no host passed them, no `record:*` renderer read
+    them — and only the provider's memo dependency list still named them. Record-level
+    loading and error state stays where it is actually expressed: each renderer's own data
+    source. (#3773)
+
+  No behaviour change, no request-count change:
+
+  - `@object-ui/data-objectstack` drops five `metadataCache.invalidate('views:<object>')`
+    calls across `updateViewConfig` / `createView` / `updateView` / `deleteView`. No read
+    path has ever populated that key — `listViews` fetches directly, uncached — so all five
+    were permanent no-ops. The invalidations of the keys that do have readers
+    (`view:<object>:<viewId>` for `getView`, `view-overrides:<object>` for
+    `listViewOverrides`) are untouched and now pinned. (#3778)
+
+- 38ab505: Retire the `global_nav` Studio designer surfaces, and track the `@objectstack` family at `17.0.0-rc.6` (objectstack#7100 / objectstack#6888).
+
+  ## The retirement
+
+  `global_nav` was an `ACTION_LOCATIONS` member no running-app surface ever rendered. The console's ⌘K palette (`app-shell/src/chrome/CommandPalette.tsx`) builds its groups from nav items, objects, dashboards, pages, reports, recent items, record search and theme; it holds no reference to `global_nav`, to `actionRendersAt`, or to any action-metadata source. An action declaring `locations: ['global_nav']` therefore never reached a user.
+
+  The Studio designer previewed it anyway — a mock frame reading `⌘K · Command palette` with the author's button inside it. That is the sharp edge the maintainer's 2026-08-09 ruling on objectstack#6888 named: an authoring tool promising a surface the product does not have teaches authors, and every AI copying this corpus, to declare dead metadata. `@objectstack/spec` `17.0.0-rc.6` retired the member (7 members → 6) with a named rejection message; this release removes the designer surfaces that outlived it.
+
+  - `metadata-admin/previews/ActionPreview.tsx` — the mock command-palette placement frame is gone. The metadata strip above it still ECHOES whatever `locations` the draft declares, deliberately: reporting what a (possibly stale) draft says is honest, whereas the frame CLAIMED the platform renders it.
+  - `metadata-admin/inspectors/ActionDefaultInspector.tsx` — the `global_nav` entry is gone from `LOCATION_LABELS`. That map is typed `Record< ActionLocation, string >`, so the retirement reached it as a compile error rather than as a silently stale dropdown — the mechanism objectui#3017 installed, firing as designed.
+  - `metadata-admin/previews/block-config.ts` — the `record:quick_actions` location dropdown no longer offers it, and both locale tables drop the now-orphaned `…option.location.global_nav` key.
+  - `@object-ui/components`' `action:bar` doc comment is aligned. The component's published enum is `[...ACTION_LOCATIONS]`, so it followed the retirement on its own; only the prose was stale.
+
+  `@object-ui/core`'s `ActionEngine.getActionsForLocation` is **unchanged and still answers a literal string match**. Narrowing it to the six live members would put a second rejection point beside the schema's — the tolerant-consumer shape the strict-contract rule forbids, inverted. Enforcement stays where it belongs: the parameter type is now six-membered so no type-correct caller can spell the retired value, and `ActionLocationSchema` rejects it by name at authoring and publish time.
+
+  ## The dependency move
+
+  All 37 `@objectstack/*` declarations across 30 `package.json` files move from `^17.0.0-rc.5` to `^17.0.0-rc.6`, and `pnpm-lock.yaml` resolves one copy of each family package at rc.6. The siblings move with `spec` because `client` / `formula` / `lint` pin it **exactly** — leaving them behind would keep two copies of the spec in the tree, the split brain objectui#3560 called out.
+
+  Bumping the pin and repairing the fallout cannot be split: at rc.5 the `Record< ActionLocation, string >` above is missing a key, at rc.6 it has an excess one.
+
+  ## Breaking, in FROM → TO form
+
+  - **`@object-ui/types`' `Theme` now binds the spec's `Theme`, not `ThemeInput`.** rc.6 retired every `…Input` alias and moved the bare name onto the `z.input` side (`X` = `z.input`, `XParsed` = `z.infer`). The runtime shape and this package's exported name are unchanged — `Theme` was, and still is, the AUTHORING shape where `mode` is optional. Re-pointing at `ThemeParsed` would have been the silent swap.
+  - **`SpecReport` / `SpecReportChart` re-point to `ReportParsed` / `ReportChartParsed`, and `SpecReportInput` / `SpecReportChartInput` to `Report` / `ReportChart`.** Same rename, same rule: each local alias keeps the SIDE it had at rc.5.
+  - **`@object-ui/types` no longer re-exports `I18nObject`, `LocaleConfig`, `PluralRule`, `DateFormat` or `NumberFormat`** — all five were retired by rc.6. They were dead re-exports here: nothing in this repo imported them from `@object-ui/types` (`@object-ui/i18n`'s formatter vocabulary in `utils/spec-formatters.ts` is locally declared and never bound the spec symbols). `I18nLabel` survives and is unchanged as a name.
+  - **`I18nLabel` itself widened from `string` to `string | Record< string, string >`** — rc.6 folded the retired `I18nObject`'s per-locale map into it and ships `resolveI18nLabel(label, locale)` as the shared resolver. Every read in this repo that lands in a text slot now goes through that resolver, so an inline map renders its locale instead of `[object Object]`. Reads the compiler cannot see are audited separately in objectui#4163.
+  - **`@object-ui/types`' `GlobalFilterSchema` derives via `.safeExtend`, not `.extend`.** rc.6's `GlobalFilterSchema` carries a refinement and zod 4 refuses `.extend()` on a refined object outright, which threw at module load. `.safeExtend` is zod's prescribed replacement and KEEPS the refinement, so the spec's cross-field rule now also runs on this package's dialect — which is the intended behaviour, since the pinned divergences widen individual fields and were never meant to switch off a whole-object rule.
+
+- 92250d6: One home for the number-display policy — and a percent stops meaning two different things between a list cell and a dashboard measure
+
+  `formatDisplayNumber`, `shouldGroupDisplayNumber` and `DisplayNumberFormatOptions` move from `@object-ui/i18n` into `@object-ui/core`. `@object-ui/i18n` re-exports all three under the same names, so every existing import path keeps working unchanged and both spellings resolve to the same function object; nothing published was removed.
+
+  The move is what fixes the bug. `@object-ui/core`'s `formatMeasure` needed exactly this policy and could not import it — `core` is the React-free engine and is a runtime dependency of React-free consumers (the `object-ui` VS Code extension, `@object-ui/data-objectstack`), while `i18n` depends on `i18next`/`react-i18next` and peer-depends on React. So `formatMeasure` carried a parallel `Intl` implementation, recorded at both ends as deliberate duplication, and the two drifted in the one place a hand-built string and `Intl` disagree. A German session read `1.234,5 %` from a list cell and `1.234,5%` from a dashboard measure showing the same number. The function is pure, so the boundary was never a property of the code — only of where the code sat; moving it down removes the obstacle instead of working around it. `core` imports nothing from `i18n`, so the new edge adds no cycle.
+
+  **Behaviour change — a measure's percent sign now follows the locale.** `formatMeasure` appended a literal `%` in every locale; it now renders the locale's own percent convention, the same one the list-cell `formatPercent` has used since the fix to its own machine-locale defect. Measured to change output in de, fr, es, ru, sv, cs, fi (a no-break space appears before the sign), tr (the sign moves to the FRONT: `%1.234,5`) and ar (its own percent sign plus U+061C). English, Japanese and Chinese are byte-identical — their convention is a bare trailing sign — which is why this was invisible in an English session.
+
+  **No numeral moves, in any locale, at any magnitude.** The obvious route to the locale's convention is `Intl`'s `style: 'percent'`, but that style expects a fraction, so a value already in percentage points would have to be divided by 100 for `Intl` to multiply it straight back — and that round trip is lossy. Measured, it moves 27,581 of 1,200,013 ordinary-magnitude en-US forms at rounding ties (`0.175` at two decimals becomes `0.17%` instead of `0.18%`), plus `MAX_SAFE_INTEGER` and everything from 1e23 up, where `100,000,000,000,000,000,000,000%` becomes `99,999,999,999,999,990,000,000%`. The percentage points are formatted directly instead, through a new `style: 'percentPoints'` on `DisplayNumberFormatOptions`; that route was measured to produce a byte-identical percent affix to `style: 'percent'` across all 171 locale tags tested while moving none of those 1,200,013 forms. Callers holding a fraction keep using `style: 'percent'`, whose behaviour is unchanged — naming the two cases apart is what stops the next caller from reaching for the lossy one.
+
+  `@object-ui/i18n`'s entry declaration is byte-identical, but the declaration it points at now lives in `@object-ui/core` and the package gains that dependency, so it takes the same minor bump rather than a patch.
+
+- c1d939f: One `SchemaNode`, and one label vocabulary — the union wins, and labels resolve where the locale lives
+
+  Two packages published a type called `SchemaNode` and they were not the same type. `@object-ui/core` hand-declared `interface SchemaNode { type: string; … [key: string]: any }`; `@object-ui/types` exported `type SchemaNode = BaseSchema | string | number | boolean | null | undefined`, whose own doc comment names `'Plain string'` a valid node. Both were exported under one name from packages the same consumers import together, so which declaration a call site got depended on which package it happened to import from — #4548's canary measured 19 of 35 errors as exactly that collision. Core's declaration is now a re-export of types', so there is one declaration left to disagree with. Core's entry surface is unchanged: `dist/index.d.ts` is byte-identical across the change.
+
+  Reconciling it exposed a real defect rather than a mechanical narrowing, which is why the first attempt was withdrawn instead of forced. The spec bridges write `spec.label` — the spec's `I18nLabel`, an INLINE locale map like `{ en: 'Owner', 'zh-CN': '负责人' }` — into `node.label`, and `BaseSchema.label` declared `string`. Under core's old index signature that assignment was invisibly `any`; under one honest `SchemaNode` it is a type error. `BaseSchema.label` and `.description` therefore now accept `string | I18nLabel`, and the two bridge assignments compile with their expressions untouched.
+
+  Resolution happens at READ time, in the renderer, against the display locale — not at the bridge. Resolving at the bridge was measured unimplementable: it is a plain class method that cannot call a hook, `BridgeContext` declares no locale, and `updateContext()` has zero callers, so a bridge-resolved label would freeze one audience's language into the node tree with no re-translation channel. React's own invalidation re-translates for free at the read site.
+
+  The widening turned every blind `schema.label`-as-string read into a named compiler error, and that inventory is the audit: it named four sites repo-wide, all one class — the label reaching a React child position, where a map does not render as `[object Object]` but THROWS `Objects are not valid as a React child`, failing the whole subtree. Three are `@object-ui/components` renderers (`filter-builder`, `sidebar-group`, `dropdown-menu`), which now resolve with the spec's own `resolveI18nLabel` against `useDisplayLocale()`. The fourth is `plugin-dashboard`'s `DashboardGridLayout` heading, which resolves with `pickLocalized` against the active UI language — matching the widget-title resolution already in that same component rather than putting two resolvers and two disagreeing locale channels in one render; the two resolvers are limb-for-limb twins with a parity test pinning them.
+
+  One interface now carries both label vocabularies two properties apart — `label`/`description` are the spec's INLINE map, `ariaLabel` is the KEYED bundle reference — and each accepts the other's shape vacuously. That confusability is objectui#4167's known hazard, inherent to the spec's `I18nLabel` design; both shapes are named with cross-referenced doc comments stating which resolver owns which slot, and a pin asserts the two unions do not collapse into each other.
+
+  Finally, the spec bridges declare their return type as `BaseSchema` instead of the union. Both bridges end in a single `return node` on an object literal, so the union described nothing real while forcing a narrowing at every read — 272 mechanical errors across five suites in the first round. That change is a type annotation only; the emitted JavaScript is byte-identical.
+
+- 2459a3e: Retire `ActionEngine`'s event-mapping API (objectui#3368). `ActionEngine.addMapping()`,
+  `ActionEngine.dispatch()`, the private `mappings` registry behind them, and the exported
+  `ActionMapping` interface are removed under enforce-or-remove: all four were public surface
+  of `@object-ui/core` with zero production callers. Nothing in the repo ever registered a
+  mapping, so `dispatch()` had no reachable caller either, and every call site was in the
+  engine's own test file.
+
+  Breaking for anyone who typed against or called the removed declarations, marked `minor`
+  per this repository's version-alignment convention (the major tracks `@objectstack`, never
+  an API-break count). Actions are still entered by name (`executeAction`), by location
+  (`getActionsForLocation`), by shortcut (`handleShortcut`) and in bulk (`executeBulk`) —
+  only the event-keyed entry point is gone, and no runtime behaviour changes because no
+  runtime path reached it.
+
+  The three ways the retired condition gate had drifted from the `visible` contract that
+  `getActionsForLocation` implements die with the path rather than being fixed on it: it
+  entered on a raw truthy check (`condition: false` dispatched anyway), typed `condition` as
+  `string` only (a `{ dialect: 'cel', source }` envelope could not reach the canonical
+  `@objectstack/formula` engine), and evaluated without `throwOnError` (a throwing predicate
+  failed OPEN, the opposite of `visible`'s fail-closed posture). Aligning the contract of an
+  API nobody calls would only have widened behaviour nobody uses.
+
+- fe52a04: `rowHeightToDensityMode` answers only for the five spec row heights — the coerce-to-`comfortable` fallback is gone
+
+  Two surfaces narrow a list view's `rowHeight` onto the renderer's three-step
+  density vocabulary, and since objectui#4352 they answered differently for the
+  same off-spec input: `@object-ui/react`'s spec bridge declined to answer, while
+  `@object-ui/core`'s `rowHeightToDensityMode` rehabilitated anything unknown into
+  `comfortable`. One metadata-driven system, two answers for one input
+  (objectui#4440).
+
+  The strict answer wins, per AGENTS.md #0.1: a renderer-side rehabilitation of
+  off-spec metadata is a second de-facto contract, and one strict contract beats N
+  dialects — a bad `rowHeight` gets fixed at the producer, where the schema already
+  rejects it. The five mappings themselves are untouched (`compact`/`short` →
+  `compact`, `medium` → `comfortable`, `tall`/`extra_tall` → `spacious`), and the
+  table keeps its `Record< RowHeight, … >` typing, so a row height added upstream
+  still fails the build here.
+
+  **Breaking semantics, deliberately graded `minor`** (this repo never publishes
+  `major` — its major tracks `@objectstack`). Two things change:
+
+  - **Published type.** `rowHeightToDensityMode` is exported from
+    `@object-ui/core`, and its return widens from `DensityMode` to
+    `DensityMode | undefined`. A host assigning the result straight into a
+    `DensityMode` now has to say what an off-spec row height should mean to it.
+  - **Rendered output, for input the spec already rejects.** `ListView` — the one
+    in-repo caller — used to render an off-spec `rowHeight` one step looser than an
+    ABSENT one (`comfortable`, 40px rows, vs `compact`, 32px). It now renders it
+    exactly like an absent one, `compact`, which is also `ObjectGrid`'s own default.
+    A sweep of this repo, the `objectstack` example apps and one downstream app
+    found zero authored off-spec values, and the legacy `densityMode` alias cannot
+    produce one (`DENSITY_MODE_TO_ROW_HEIGHT` is typed
+    `Record< DensityMode, RowHeight >`).
+
+  Also closed while retiring the branch: the lookup guarded membership with `in`,
+  which walks the prototype chain, so `rowHeight: 'toString'` returned
+  `Object.prototype.toString` — a function — from something typed `DensityMode`. It
+  is an own-property check now.
+
+- bb68488: Stop declaring 14 symbols under names `@objectstack/spec` owns at `17.0.0-rc.6`
+  (objectui#4167, objectstack#4115).
+
+  The rc.6 bump published nine names this repo already declared locally, on top of
+  four that predate it — `check:spec-symbols` reported all thirteen at once, and a
+  fourteenth (`GlobalFilterSchema`) appeared during the bump itself. Each was
+  triaged on its own rather than blanket-renamed, because the right answer differs
+  per symbol: five bind to the spec, three are renamed because the spec's
+  same-named export means something else, five arrive by derivation, and one is a
+  declared dialect with a written reason.
+
+  **Breaking for importers of `@object-ui/react`, `@object-ui/app-shell` and
+  `@object-ui/types`** — three exported names changed, because the spec exports the
+  same name for a _different_ thing:
+
+  | package               | was                | now                            | what the spec's same-named export actually is                                                                                                          |
+  | :-------------------- | :----------------- | :----------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------- |
+  | `react` / `app-shell` | `MetadataState`    | `MetadataCacheState`           | a metadata item's LIFECYCLE state — `'draft' \| 'active' \| 'deprecated' \| 'archived'` (`MetadataStateSchema`, `@objectstack/spec/system`)            |
+  | `react` / `app-shell` | `resolveI18nLabel` | `resolveKeyedI18nLabel`        | a resolver for the INLINE per-locale map (`{ en: 'Owner', 'zh-CN': '负责人' }`) against a BCP-47 locale                                                |
+  | `types`               | `DateRangePreset`  | `FilterBuilderDateRangePreset` | the thirteen HISTORICAL dashboard filter-bar presets; this one is the filter-builder set, which adds eight FUTURE windows the dashboard schema rejects |
+
+  `resolveI18nLabel` is the one where the collision had already started costing
+  something. rc.6 widened `I18nLabel` from `string` to
+  `string | Record< string, string >`, so the same authored value now reaches
+  either resolver — and each answers wrongly, silently, for the other's input: the
+  keyed one returns `undefined` for `{ en: 'Owner' }` (no `key`, no
+  `defaultValue`), and the spec's reads `key` / `defaultValue` / `params` as locale
+  tags. The rc.6 bump PR met this and aliased the spec's import as
+  `resolveInlineI18nLabel` in five files, with hand-written comments at two of
+  them. That is a review convention, which is what objectstack#4115 exists to
+  replace with a rule — so `Keyed` is now the counterpart of that `Inline`, and the
+  name says which vocabulary it resolves at every call site.
+
+  **Eleven keep their names and are now imported or derived from the spec** instead
+  of re-declared: `DATE_RANGE_PRESETS`, `NavigationMode`, `AddressValue`,
+  `BreakpointColumnMap`, `BreakpointOrderMap`, `KanbanConfig`, `CalendarConfig`,
+  `GanttConfig`, plus the three renamed above at their new names.
+
+  **Four of the copies were losing information, not just duplicating it.**
+
+  - **`GanttConfig` declared six keys and called itself canonical; rc.6's
+    `GanttConfigSchema` declares seventeen.** The eleven it never mentioned —
+    `parentField`, `typeField`, `baselineStartField`, `baselineEndField`,
+    `groupByField`, `resourceView`, `assigneeField`, `effortField`, `capacity`,
+    `quickFilters`, `autoZoomToFilter` — are all read by
+    `plugin-gantt/src/ObjectGantt.tsx`, through a local `GanttConfigEx`
+    intersection that existed only because this type did not carry them. It now
+    derives from the spec, with `timeSegments` (shift segmentation) as the one
+    genuinely local extension; the schema is `$loose` upstream, so that key is
+    legal metadata rather than a second dialect.
+  - **`GanttConfig.tooltipFields` carried the comment "not part of the upstream
+    GanttConfigSchema".** It is, as of rc.6, so the key now arrives from the spec.
+  - **`AddressValue` declared five of the spec's seven parts** — `countryCode` and
+    `formatted` were missing, under a comment already claiming to be "the part
+    names of `AddressSchema`". The widget still renders five inputs; binding the
+    type stops it from asserting the platform cannot store the other two, and makes
+    the `{ ...address }` write-through say so.
+  - **`DATE_RANGE_PRESETS` was `Object.keys(PRESET_RANGES)`,** a third copy of a
+    vocabulary the spec extracted in objectstack#4614 precisely to collapse — its
+    own doc comment names this module as one of the three. It is now the spec's
+    array by reference, and the local date-macro bounds table is pinned complete
+    against it with `satisfies`, so a preset the schema gains without bounds here
+    is a compile error rather than a filter that validates clean and then selects
+    nothing.
+
+  `NavigationMode` was one hop from the spec already (`NavigationConfig['mode']`);
+  it is bound directly, with a both-directions type pin that it stays the same type
+  as the config's own `mode`. `KanbanConfig` / `CalendarConfig` /
+  `BreakpointColumnMap` / `BreakpointOrderMap` were exact hand copies of `$strict`
+  schemas and are now re-exports — "still exact" is the argument for binding them,
+  since a copy with nothing to protect can only drift.
+
+  `GlobalFilterSchema` is the one ALLOW entry. It is the same spread-composition
+  dialect as `SelectOptionSchema` next to it, and it collided only because rc.6's
+  new refinement forced `.extend()` to be respelled as a `.shape` spread — which
+  moved a derivation the guard could see into an object literal it deliberately
+  does not descend into. The dialect is unchanged and its three divergences are
+  pinned; which side moves on the refinement itself is objectui#4165.
+
+  `@objectstack/spec` moves from `devDependencies` to `dependencies` in
+  `@object-ui/layout`: its public type surface now references the spec.
+
+### Patch Changes
+
+- ee26e65: Analytics: the dimension label net's fetch-and-memo glue is written once, not once per surface
+
+  PR #4388 (objectui#4330) put the same React glue on two surfaces — the dashboard's `DatasetWidget` and plugin-report's dataset block. The resolution RULES were never duplicated (both call the same `@object-ui/core` helpers), but the wiring around them was: read the object schema through the host's authenticated `apiFetch`, keep the fetched metadata locale-free in state, derive the label maps in a render memo. Two copies meant two statements of the same two bug fixes, which is a drift surface rather than a defect — nothing a user could hit today, filed as objectui#4389 so it was retired deliberately.
+
+  It is now split along the layer that can actually hold each half. `@object-ui/core` gains the React-free parts — `loadDimensionFieldMeta` (the base-object read composed with the dimension walk), `deriveDimensionLabelMaps` (the locale-applying derivation) and `dimensionOptionTranslator` (binding the bundle resolver to the object that OWNS a terminal field, which for a dotted path is the relationship target). `@object-ui/react` gains `useDatasetDimensionLabels` / `useDatasetDimensionMeta`, the React wiring that cannot live in core, beside the `useViewData` / `useElementDataSource` / `useDiscovery` hooks that already read `SchemaRendererContext` the same way. Both plugins consume it; the dashboard keeps its chart-only per-category colour and category-order derivation layered locally, since a table renders no palette.
+
+  The card originally proposed `@object-ui/core` as the whole glue's home. That home was disproven by measurement and retired in the card's PM RULING #2: `SchemaRendererContext` is defined in `@object-ui/react`, which depends on core, so core importing it back is a cycle — and core is React-free by declaration, by content, and by the topology in AGENTS.md. objectui#3367 had already ruled this direction for the same family (core-canonical logic, react re-exports).
+
+  Behaviour is unchanged by construction: same read count, same best-effort fallback, same memoization boundary. The two bug fixes are now stated once and pinned at the shared hook — the read rides the host's authenticated `apiFetch` (objectui#4121, pinned by asserting that a new channel re-issues the read, i.e. that it really is in the effect's deps), and the fetched metadata stays locale-free (objectui#4030 / PR #4324, pinned by switching language at runtime and asserting the labels flip with no second metadata read). All 39 assertions PR #4388 landed across both surfaces pass unchanged, and their files are byte-identical to before.
+
+- 5900ac5: Analytics surfaces now run resolved select-option labels through the locale bundle — the chart legend and the related list on one page stop disagreeing
+
+  A dashboard widget grouped by a `select` field rendered the option's authored English label while the related list beside it rendered the translation. The decisive evidence in objectui#4030 is the stored value `orion`: the chart read `Orion Engineered Carbons`, a string with no resemblance to the value and matching the object's `label` byte for byte. So the analytics path had already RESOLVED the option label — it simply never ran the result through the i18n bundle before display. (`domestic → Domestic` differs from its value by case alone, which is why the first diagnosis, "the report groups by stored value", was wrong.)
+
+  There is exactly one resolution channel and this change reuses it rather than adding a chart-side dialect: `fieldOptionLabel` from `useObjectLabel`, i.e. `{ns}.fieldOptions.<object>.<field>.<value>` — the convention `@objectstack/spec` names objectui as the reader of, and the one list, form, kanban and record-picker surfaces already translate select options through. The bundle is applied ONCE, at the output of the label net that landed in objectui#4053/#4263, on the shared option list every consumer reads: chart axis and legend, the table/pivot cells of a dotted dimension, that table's CSV export, per-category colours and the declared category order. `@object-ui/core` gains `localizeFieldOptions` (the pure mirror of `translateOptions`), an optional translator on `buildDimensionLabelMap`, and `resolveDimensionFieldMeta` — the same single relationship walk `resolveDimensionFieldOptions` performs, now keeping the object that OWNS the terminal field, because for `crm_account.industry` the bundle key is `crm_account`, not the dataset's base object.
+
+  Two properties the fix is shaped around. The rows reach this net keyed either way — by stored value when the server did not resolve the dimension, by the English label when it did (ADR-0021) — and the reported screen is the second case, so the map answers to both keys and lands on the same translated display. And identity is untouched: `relabelDimensions` still rewrites display only, so a drilled chart segment clicked as `欧励隆` filters by `orion`, bucket ids and pivot totals keep their raw keys, and an option with no bundle entry (or an `en` console) renders exactly the authored label it renders today.
+
+  The per-locale work moved from the metadata fetch into the render, so switching language now re-labels in place instead of waiting for a refetch.
+
+  Not covered, and unchanged here: a LOCAL select dimension on a table/pivot, whose label the server resolves and whose client-side net is deliberately off (objectui#4263), and a dashboard global filter's own field label, which has no object name in its metadata to key a bundle lookup with — tracked on objectui#4030.
+
+- aca27fa: The multi-dimension pivot branch buckets a null first-dimension value instead of dropping its bar (objectui#4497)
+
+  `buildChartSeries`' pivot branch (2+ dimensions, single measure) bucketed rows by `String(xRaw ?? '')` but wrote the RAW value into the emitted row, so a null first-dimension value produced `{status: null, Low: 3}` and reached recharts with a null category — which draws no mark. Measured at the DOM: a two-group pivot drew ONE bar, and an all-null pivot drew axes and gridlines with zero bar rectangles and no empty state. That is the same mechanism objectui#4466 fixed one branch below, on the branch that card deliberately left pinned as-is until the pivot's own bucketing had been measured.
+
+  The pivot now maps a null/undefined first-dimension VALUE to the same bucket label the single-dimension branch uses — `ChartSeriesOptions.nullCategoryLabel`, defaulting to `NULL_CATEGORY_LABEL`. One doctrine, one predicate, two call sites; no new export, and every existing call site compiles and behaves identically.
+
+  The bucket KEY is untouched, which is what keeps this a display fix: `String(xRaw ?? '')` still decides which rows share a bar, so every existing grouping is byte-identical and only the label the bucket carries changes. Rows that lack the category key entirely are still not bucketed — that shape is a dimension grouped by but never projected (framework#4033), a different defect with a different answer.
+
+  Drill-through needed no change, which was measured rather than assumed: the pivot's emitted rows are AGGREGATED, so they are not index-aligned with `drillRawRows` and the one production caller (`DatasetWidget.handleChartDrill`) already drills by SEARCHING the raw rows through `findChartSeriesRow`. Those raw rows still carry their null, and objectui#4466's label-matching covers the multi-dimension arm as well as the single-dimension one, so the newly-visible bar resolves to the right record. Pinned at both levels so a regression in either half surfaces as the dead click it would be.
+
+- 613b167: A dataset dimension on a dotted relationship path now renders its option labels instead of the raw stored enum
+
+  A `DatasetDimension` whose `field` is a relationship path (`crm_account.industry`) got no select-option resolution at all: the chart plotted `education`, `finance`, `manufacturing` — the database column, unresolved — while the **same underlying field** reached as a **local** dimension rendered `Education`, `Finance`, `Manufacturing` beside it on the same dashboard. Nothing errored, so the widget just quietly showed database enum values to end users; on a non-English deployment those are words that appear nowhere else in the UI, since every form and list shows the translated label.
+
+  The label lookup read options as `baseObject.fields[<path>]`, which only ever matches the local spelling. For a dotted path the options live on the **related** object, so the lookup missed and the renderer fell through to the stored value.
+
+  The object-resolution step of that one lookup now walks the path: each segment before the last must be a declared relationship (`lookup` / `master_detail`, target read from `reference` / `reference_to` / `referenceTo` / `reference_to_object`), and the terminal field's options are read off the object that actually owns it. This is the same lookup for both spellings rather than a dotted-path variant beside it — a single-segment path never enters the walk and resolves exactly as before, so the local and joined paths cannot drift apart. Multi-hop paths (`crm_account.owner.department`) resolve too, which is the shape the dataset designer already emits.
+
+  Hops ride the caller's existing `GET /meta/object/:name` channel — the same authenticated read that fetched the base object — so no new fetch layer is introduced, and objects are fetched once per resolution even when several dimensions share a prefix. Every failure stays best-effort: a segment that is not a relationship, a target that cannot be loaded, or a terminal field with no options yields no mapping and the raw value survives, exactly as it does today.
+
+  Applies to both surfaces that carried this lookup: dashboard dataset widgets (`DatasetWidget`) and the chart view's dataset path (`ObjectChart`).
+
+  Scope: this ends at "the label is in hand". Whether that label then passes through the i18n bundle is a separate gap tracked upstream as objectstack#5076.
+
+- abb0f81: A dashboard date filter's default has one spelling again — the bare preset name — and the `{ preset }` object becomes a documented legacy alias with a retirement window
+
+  `@objectstack/spec` 17.0.0-rc.6 added a cross-field refinement to `GlobalFilterSchema` holding a `type: 'date'` filter's `defaultValue` to three spellings: a preset NAME (`last_7_days`), an ISO date (`2026-01-15`), or a date-macro token (`{today}`). objectui's derived schema had widened `defaultValue` to `z.any()` and did not carry the refinement, so it accepted `{ preset: 'last_7_days' }` — metadata the platform refuses. That is the tolerant-consumer shape where the designer goes green and the save fails server-side, and it is now closed: the refinement is adopted, the widening is retired, and the object form is refused with the spec's own message.
+
+  Per the maintainer ruling on objectui#4165, the spec stays strict and the bare preset name is the single canonical spelling. `{ preset }` is handled as an ADR-0089 legacy alias rather than by a permanently tolerant schema: `liftLegacyGlobalFilterDefault` / `liftLegacyDashboardFilterDefaults` (new exports on `@object-ui/types`) convert it to the bare name, `@object-ui/core`'s `resolveDashboardFilterDefs` applies the lift when it reads a stored dashboard, and the console's dashboard designer applies it as the document enters the editable draft so the next save persists the canonical spelling. The retirement window is recorded at the read site: the alias may be removed in `@object-ui/types` 18.0.0, and every lift warns on the console so a surviving legacy document is visible rather than silently tolerated.
+
+  No stored dashboard has to change for this release. The lift means a document carrying the object form keeps loading and rendering exactly as before — measured, not assumed: a legacy declaration already resolved correctly, because `{ preset }` also happens to be the runtime value shape objectui's own date filters use, and that coincidence is why the object form went unnoticed for so long. What changes is that the declaration is now canonicalized on read and rewritten on save, so the two spellings converge instead of accreting.
+
+  The other two divergences in this schema — the bare-string `options` shorthand and the optional `optionsFrom.labelField` — are unaffected. Carrying the spec's refinement while keeping them needed a new composition: a refined object schema in zod 4 rejects `.extend()` and `.omit()` outright and types every `.safeExtend()` override as `never`, so objectui's schema now spreads the spec's shape and re-attaches the spec's object-level rules by delegating to the spec schema itself. Nothing restates the spec's grammar, and a refinement the spec adds later flows in with no change here.
+
+- 7e4f0e5: fix(dashboard,i18n): KPI cards and dashboard filters resolve authored labels instead of dropping them (#4032)
+
+  A `type: 'metric'` dashboard widget rendered raw English while every other widget
+  type on the same dashboard rendered the translation, and dashboard filter chips
+  rendered `[object Object]` or the raw stored value. Both come from the same
+  cause: authored labels reaching a render site that could not read the
+  vocabulary `@objectstack/spec` actually admits.
+
+  - **KPI cards rejoin the widget translation channel.** The self-contained
+    `metric` branch built its own label from the raw `widget.title`, so the
+    `{ns}.dashboards.{dash}.widgets.{id}.title` value the renderer had already
+    resolved was computed and thrown away. It now reads that channel like every
+    other widget header.
+  - **The three private `resolveLabel` copies** (`DashboardRenderer`,
+    `MetricWidget`, `MetricCard`) are gone. Each read the retired
+    `{ key, defaultValue }` key-reference form and ended `defaultValue || key`, so
+    handed the inline per-locale map the spec admits today they returned nothing —
+    a KPI card with a map title rendered the literal string `metric`. All three
+    now use `pickLocalized`, the resolver already used for this vocabulary
+    elsewhere in the package.
+  - **Dashboard filter labels and static option labels resolve per locale.**
+    `DashboardFilterDef.label` widens to `string | I18nLabel`, the filter bar
+    resolves before rendering (fixing `[object Object]: All` in the trigger, and
+    in `aria-label` / `placeholder`), and the `def.label || def.name` gate now
+    tests the RESOLVED string — an object is always truthy, so it never reached
+    the fallback before.
+  - **Option labels are no longer discarded.** `normalizeFilterOptions` coerced a
+    map label to the raw stored value in every locale, English included, so
+    `{ value: 'domestic', label: { en: 'Domestic', … } }` displayed as `domestic`.
+    The pair shape is still normalized; the label vocabulary is preserved for the
+    render side to resolve.
+  - **`DashboardComponentSchema.globalFilters` is bound to the spec's
+    `GlobalFilter`** instead of restated by hand. The restatement was both too
+    narrow (`label?: string`, which is what made these read sites invisible to
+    `tsc`) and too wide (it declared a bare-string option shorthand the spec
+    rejects at publish).
+
+  Plain-string labels are unaffected and render byte-identically.
+
+- 49ae9f4: Pivot buckets encode an empty dimension value as JSON `null`, so it no longer collides with a row whose value is literally the placeholder character
+
+  objectstack#5473 / objectstack#5665 replaced the pivot's delimiter-joined ids
+  with `JSON.stringify`, because every delimiter that had been tried — an empty
+  string, a plain space, a control character — assumed the data would not contain
+  it, and each assumption failed on ordinary data. This closes the last place the
+  same assumption survived: the ids were JSON, but the VALUES fed into them were
+  spelled `String(row[d] ?? '∅')`, so an absent dimension value became the
+  ordinary string `"∅"` and shared a bucket with a row whose value literally is
+  that character (U+2205). One bucket, later row overwriting the earlier one — the
+  cell showed a different row's measure, the overwritten row was unreachable, and
+  drill-through followed the same wrong index into the wrong records, all without
+  an error. The trigger requires that character to appear as a dimension value, so
+  this is the assumption being removed rather than a defect users hit today.
+
+  An empty value now encodes as JSON `null`, which `JSON.stringify` renders as a
+  bare `null` that no string can spell. The normalization lives in
+  `@object-ui/core` as `pivotDimensionValue` (absent ⇒ `null`, everything else ⇒
+  its string form) rather than at each call site, because a placeholder spelled by
+  a caller is a placeholder that can collide again — which is exactly how this one
+  survived the previous fix. `pivotBucketId` accepts `Array<string | null>`
+  accordingly; that is a widening, so existing callers passing `string[]` are
+  unaffected.
+
+  Both renderers' bucket keys move together, which the fix requires: a bucket id
+  and the subtotal map keyed by it are built from the same expression, so changing
+  one alone would split the headers while the subtotal map still merged, landing
+  every column subtotal under the wrong header. In `plugin-dashboard`'s
+  `DatasetWidget` that is the row bucket id, the column bucket id, the cell key,
+  and both the `rowTotalById` and `colTotalById` lookups; in `plugin-report`'s
+  `DatasetReportRenderer` the single `bucketId` helper already feeds all five.
+
+  The dashboard's column bucket id also stops being a bare string and becomes a
+  one-element tuple through the same shared encoder. It was the one id in the
+  family still built by hand, on the reasoning that a single value needs no
+  boundary — true of the boundary, false of everything else the encoder does, and
+  it is why the across axis kept carrying this collision after the row ids were
+  fixed.
+
+  No display change: these placeholders only ever entered ids, never labels. An
+  unset dimension still renders through `formatDimensionValue` exactly as before,
+  and data containing neither an absent value nor that character buckets
+  identically — the ids are opaque lookup keys, never parsed back into a value,
+  never shown, never persisted.
+
+- d6aa172: Retire `params.newTab` on a url action — `openIn: 'new-tab'` is the sanctioned spelling
+
+  `ActionRunner`'s navigator read a legacy `params.newTab` escape hatch below `openIn` and above the external-URL heuristic. That read is removed, executing the objectstack#6828 maintainer ruling of 2026-08-10, whose contract half shipped in objectstack PR #7375: the url-side readings of an object-form `params` are retired, not renamed.
+
+  Nothing that ever validated can regress. `params` is declared as `z.array(ActionParamSchema)`, so an object-form `params` has always failed the props parse — the fallback could only fire on a stack the spec refuses. The removal also closes a collision hazard: a params dialog declaring a field named `newTab` had the user's own collected input silently steering navigation.
+
+  `openIn: 'self' | 'new-tab'`, the legacy `navigate.newTab` modifier on the `navigation` shape, and the external/relative default are all unchanged.
+
+- 9461dd3: Form actions no longer carry a record id across an object boundary (#4292).
+
+  `ActionRunner.executeForm` forwarded `/forms/:name?recordId=<id>` unconditionally,
+  and that URL says nothing about which object the id belongs to — so the form route
+  resolved it against the FormView's own target object. When an action fired from a
+  record of a DIFFERENT object and ids collide across objects (per-table integer
+  keys), the form silently prefilled and, since the route learned to honour the param,
+  `PATCH`ed a same-id record of the wrong object.
+
+  - **Producer**: the id is forwarded only when the firing context record's object
+    (`context.objectName`) matches the target view's object; on a mismatch no id is
+    forwarded, preserving create semantics. When it IS forwarded, the object travels
+    with it as `?recordObject=`.
+  - **Consumer**: `/forms/:name` refuses — no record read, no write — when
+    `recordObject` disagrees with the FormView's object. A URL without the param
+    behaves exactly as before, so existing deep links are unaffected.
+
+- Updated dependencies [f650253]
+- Updated dependencies [3d9769a]
+- Updated dependencies [92876f0]
+- Updated dependencies [d9d3463]
+- Updated dependencies [2a40f69]
+- Updated dependencies [bec3e14]
+- Updated dependencies [1f9b905]
+- Updated dependencies [abb0f81]
+- Updated dependencies [38ab505]
+- Updated dependencies [7e4f0e5]
+- Updated dependencies [c1d939f]
+- Updated dependencies [bb68488]
+- Updated dependencies [ab04728]
+  - @object-ui/types@17.5.0
+
+## 17.4.0
+
+### Minor Changes
+
+- c3b01a7: Give composite and grouped field widgets a real accessible name: the form renderer now associates its label by IDREF for widgets that declare `labelling: 'group'`, instead of emitting a `<label for>` that nothing labelable answers (objectui#3961).
+
+  Six widgets rendered a visible group label that named **nothing** in the accessibility tree. Measured in a real form, one field per row, reading each label's `for` against the DOM:
+
+  ```
+  address      for=…-form-item -> MISSING            byLabelText=0   role+name=0
+  geolocation  for=…-form-item -> MISSING            byLabelText=0   role+name=0
+  checkboxes   for=…-form-item -> div                byLabelText=0   role+name=0
+  radio        for=…-form-item -> div[radiogroup]    byLabelText=0   role+name=0
+  rating       for=…-form-item -> div                byLabelText=0   role+name=0
+  file         for=…-form-item -> div[role=button]   byLabelText=0   role+name=0
+  ```
+
+  Two shapes, one outcome. `address` / `geolocation` spread the host's id onto their first sub-input and then replaced it with that input's own unique id (objectui#3343, correct in itself), so the `for` named an id no element carried — clicking "Shipping Address" did nothing and the group label was absent from the accessibility tree entirely. `checkboxes` / `radio` / `rating` / `file` kept the id, but on a `div`: a `<label for>` on a non-labelable element is inert HTML — `HTMLLabelElement.control` is `null`, so it activates nothing and contributes no name. A screen reader heard "Street Address", "City", "Alpha", "Beta" — never which group they belonged to.
+
+  The fix is the WAI-ARIA group pattern, driven by a DECLARATION rather than by the host guessing at widget DOM:
+
+  - `@object-ui/core` — `ComponentMeta` gains `labelling?: 'control' | 'group'`. Additive and optional; absent means `'control'`, which is every existing component's behaviour.
+  - `@object-ui/components` — the form renderer reads it. For a `'group'` field the `<FormLabel>` publishes an `id` and drops its `for`, and the widget receives `aria-labelledby`. The single-control path is unchanged down to the attribute: no id on the label, no `aria-labelledby` key on the widget, so no field acquires a second naming channel. `ui/form.tsx` is untouched (Shadcn no-touch) — both halves travel as ordinary props, since `<FormLabel>` spreads props after its own `htmlFor`.
+  - `@object-ui/fields` — the six audited widgets declare `labelling: 'group'`. `address` / `geolocation` move the host id (and only the id) from their first sub-input to the group container; `checkboxes` / `rating` answer a host-supplied `aria-labelledby` with `role="group"`; `radio` keeps Radix's more specific `radiogroup`; `file` takes the name on its dropzone with no invented group layer, because it has exactly one control that merely happens not to be labelable.
+
+  No new key in the widget props contract: `aria-*` is already declared on it and forwarded by `toDomProps`, the same channel `aria-required` (objectui#3290) travels.
+
+  Deliberately unchanged: sub-labels keep naming their own inputs (`aria-labelledby` overrides `<label for>`, so putting the group name on the first sub-input would have replaced "Street Address" with the field name — the concatenated-name outcome this issue rejected), `aria-describedby` stays on the first focusable sub-input where focus can reach it (objectui#3318), the sub-input ids of objectui#3343 do not move, and standalone rendering — the inline grid editor, a bare SDUI node, where nobody hands down an id and there is no host label to point at — emits no role and no IDREF at all.
+
+  A widget that does not declare itself keeps the old `for`, which the label-association tests report as an association resolving to a non-labelable element. Silence was the failure mode being fixed; the default path stays loud.
+
+- 48132f7: Track the `@objectstack` family at `17.0.0-rc.5` (objectui#3560).
+
+  The pin moves from `^17.0.0-rc.2` to `^17.0.0-rc.5` across all 37 declarations in
+  30 `package.json` files, and the sibling `@objectstack/*` packages (`client` /
+  `formula` / `lint`) move with it — they pin `@objectstack/spec` **exactly**, so
+  leaving them behind would keep a second copy of the spec in the tree and have
+  `@objectstack/lint` validating against schemas that still accept the keys rc.3–rc.5
+  retire. `pnpm-lock.yaml` now resolves one copy of each of the six family packages
+  (`spec` / `client` / `core` / `formula` / `lint` / `sdui-parser`), all at rc.5.
+
+  Bumping the pin and repairing the fallout cannot be split: the pin alone reddens
+  CI, and the code alone targets a shape that is not in effect yet.
+
+  ## A live bug this upgrade fixes
+
+  **`ObjectStackDataSource.delete()` never emitted its mutation event, and resolved
+  `undefined` instead of a boolean.** `@objectstack/client`'s `DeleteDataResult`
+  declared a key called `deleted` — a key no schema has ever declared and no server
+  path has ever returned on `DELETE /data/:object/:id`. So `result.deleted`
+  compiled and read `undefined` at runtime: the guard never fired, a successful
+  delete notified no subscriber, and every consumer's cache stayed stale.
+  objectstack#5638 corrected the interface to the schema's `success`; following the
+  rename is what restores both behaviours. Nothing in this repo had to change shape
+  for it — the code was already asking the right question of the wrong key.
+
+  ## Breaking, in FROM → TO form
+
+  - **The five `@objectstack/spec/ui` interaction-config modules are gone** —
+    touch / dnd / keyboard / animation / offline, 32 defs and 64 exports
+    (objectstack#4988, PR objectstack#5321). None of them had an authoring door: no
+    metadata document could ever carry one of these blocks, so a stack that parsed
+    before the retirement parses byte-for-byte the same after it. `@object-ui/types`
+    drops the 32 `export type` re-exports. The vocabulary each one's only real
+    consumer needs is now declared by that consumer, which is the remedy the spec's
+    own retirement ledger prescribes ("declare that union locally — it is your
+    client's policy, not the platform's"):
+
+    - `@object-ui/react`'s `useOffline` owns `OfflineStrategy`, `ConflictResolution`,
+      `PersistStorageType`, `EvictionPolicyType`, `OfflineConfig`,
+      `OfflineCacheConfig`, `OfflineSyncConfig`;
+    - `@object-ui/core`'s `DndProtocol` / `KeyboardProtocol` own `DndConfig`,
+      `DragItem`, `DropZone`, `DragConstraint`, `DragHandle`, `DropEffect`,
+      `KeyboardNavigationConfig`, `KeyboardShortcut`, `FocusManagement`,
+      `FocusTrapConfig`;
+    - `@object-ui/types`' `mobile` module owns `SpecGestureConfig`,
+      `SwipeGestureConfig`, `PinchGestureConfig`, `LongPressGestureConfig`,
+      `TouchTargetConfig`, `TouchInteraction` (plus a new `SPEC_GESTURE_TYPES`
+      runtime tuple), so `@object-ui/mobile`'s import paths are unchanged.
+
+    Every shape is moved verbatim — same keys, same members, same optionality — so
+    no hook or bridge changes behaviour. Consumers importing these names from
+    `@object-ui/types` must import them from the owning package instead. Note the
+    spec's _surviving_ `ConnectorConflictResolution` (`/integration`, connector sync)
+    and `ConflictResolutionStrategy` (`/api`, route merge policy) are **different
+    concepts** — do not re-point at them.
+
+  - **`@object-ui/types` no longer re-exports `NotificationAction` or `EmbedConfig`**
+    (objectstack#5015, PR objectstack#5300). Both were published `ui` vocabulary with
+    no authoring door; no notification action was ever parsed from metadata and no
+    iframe route ever read an embed config. The presentation enums
+    (`NotificationType` / `NotificationSeverity` / `NotificationPosition`) and
+    `SharingConfig` **survive** and are untouched — public form sharing still gates
+    the anonymous endpoints on `allowAnonymous` + `publicLink`.
+    `@object-ui/core`'s `SharingProtocol` keeps `resolveEmbedConfig` /
+    `generateEmbedCode` against a locally declared `EmbedConfig`, so its surface is
+    unchanged.
+  - **`ThemeEngine` stops emitting nine retired CSS variable groups**
+    (objectstack#5021 option 2, PR objectstack#5289). `theme.animation`,
+    `theme.zIndex` and five typography groups (`fontSize` / `fontWeight` /
+    `lineHeight` / `letterSpacing`, plus `fontFamily.heading` / `fontFamily.mono`)
+    are tombstones the schema now rejects by name, so `--duration-*`, `--timing-*`,
+    `--z-*`, `--font-size-*`, `--font-weight-*`, `--line-height-*`,
+    `--letter-spacing-*`, `--font-heading` and `--font-mono` had become structurally
+    dead code — no author could produce the input that reached them.
+    `generateAnimationVars` and `generateZIndexVars` are removed from
+    `@object-ui/core`, and `@object-ui/types` drops `Animation` / `ZIndex` /
+    `AnimationSchema` / `ZIndexSchema`. **`theme.customVars` is the declared — and
+    since #5021 the only — door**: each entry is emitted verbatim as
+    `--<key>: <value>`, so a `--z-modal` or a `--duration-fast` goes there now.
+    LIVE emission is untouched byte for byte: `colors`, `borderRadius`, `shadows`,
+    `typography.fontFamily.base` (→ `--font-sans`) and `customVars`.
+  - **`@object-ui/types`' `HttpMethodSchema` now binds the spec's
+    `HttpMethodSubsetSchema`, and `HttpMethod` binds `HttpMethodSubset`**
+    (objectstack#5832, PR objectstack#5976 — objectui#3499). The spec renamed its
+    5-value UI subset because `schemaNameFromExportKey` strips the `Schema` suffix,
+    so the 5-value and 7-value enums both published as `shared/HttpMethod` and the
+    later write won — the emitted JSON Schema and reference page described only one
+    of them. **The runtime domain is unchanged and this repo's exported names are
+    unchanged**; this follows the rename without touching cross-package semantics.
+    Deliberately NOT re-pointed at the spec's bare `HttpMethod`: that is the 7-value
+    enum, and widening to it would let `method: 'HEAD'` compile and then throw in
+    `HttpRequestSchema.parse()`.
+  - **`dashboard.widgets[].actionUrl` / `actionType` / `actionIcon` / `aria` are
+    refused, not stripped** (objectstack#5010, ADR-0049 enforce-or-remove). A
+    dashboard widget has no action button and never had one — every action the
+    dashboard dispatches comes from `header.actions[]` — and no renderer ever applied
+    the widget `aria`, so it promised accessibility compliance it did not deliver.
+    A stale dashboard now gets a named error telling it where the affordance moved,
+    instead of silently losing it. Run `os migrate meta --from 16` to rewrite.
+
+### Patch Changes
+
+- 6719877: `condition: false` now actually prevents the action from executing (objectui#3872)
+
+  `ActionRunner.execute` — the engine's public execution entry, shared by every
+  action surface — gated conditional execution on `if (action.condition)`, i.e. on
+  the raw value's TRUTHINESS. Truthiness cannot answer the question the gate needs
+  answered ("did the author declare a condition?"), and on this key it answered in
+  the over-permissive direction: `condition: false` fell on `if (false)`, so the
+  whole block was skipped, `evaluateCondition` was never consulted, and the action
+  executed. Measured with a call-counting handler:
+
+  - `condition: false` — handler ran: **true**, result `{ success: true }`
+  - `condition: { dialect: 'cel', source: 'false' }` — handler ran: false, result `{ success: false, error: 'Action condition not met' }`
+
+  Two spellings of the same statement, opposite outcomes. `false` is the most
+  explicit "never execute this" metadata can carry — and what a template that
+  switches an action off emits — so the direction matters: the action really ran,
+  possibly writing. This is the over-permission half of the objectui#3492 family
+  (the `disabled` gate one line below is objectui#3848, whose defect pointed the
+  other way).
+
+  The gate now asks whether a `condition` gate is DECLARED before evaluating.
+  "Nothing to evaluate" is read from core's single predicate normalizer
+  (`toPredicateInput`, which maps `''`, `null`, an empty-`source` envelope and
+  non-predicate values to `undefined`), plus the whitespace-only string, which the
+  normalizer wraps rather than collapses — objectui#3850's ruling on the scope of
+  "empty predicate", the same one the `disabled` gate already applies. Once the
+  door asks the right question the verdict needs no boolean branch of its own:
+  `evaluateCondition` returns a boolean argument verbatim.
+
+  **Behaviour change surface, deliberately one-directional and one row wide.**
+  Exactly one shape changes verdict — a declared boolean `false`, from executing to
+  refused (`{ success: false, error: 'Action condition not met' }`, the message the
+  key already used). Everything else is byte-identical: `condition: true`, an
+  absent `condition`, and truthy expressions/envelopes still execute; falsy
+  expressions, falsy CEL envelopes and falsy `${…}` templates are still refused,
+  as before; the three empty predicates (`''`, whitespace-only, an empty-`source`
+  envelope) still execute, now because nothing was declared rather than because
+  `if ('')` happened to be falsy; and non-predicate junk (`0`, `{}`) still
+  executes — a value that is not a predicate must not decide an action's fate,
+  which is the fail-open posture this module already committed to for `disabled`.
+  So this change can only start refusing execution, never start allowing it — the
+  mirror image of objectui#3848's fix.
+
+  `ActionDef.condition` is widened to `string | boolean` to match what the gate now
+  honours (and the `disabled` key beside it). This is not a lenient consumer
+  alias: the boolean was always accepted at runtime through the interface's index
+  signature, it was simply ignored.
+
+  The value handed to the evaluator is deliberately left RAW rather than normalized
+  first, for the same reason as objectui#3848 with the sign flipped:
+  `toPredicateInput` wraps unconditionally, so an already-templated `'${x}'`
+  becomes `'${${x}}'`, fails to parse, returns verbatim and coerces to a constant
+  `true` — on `disabled` that blocks everything, on `condition` it would EXECUTE
+  everything. That normalizer defect is objectui#3871; a tripwire next to the new
+  pins goes red the day it is fixed.
+
+- 56ff091: An empty `disabled` predicate no longer refuses to run the action (objectui#3848)
+
+  `ActionRunner.execute` — the engine's public execution entry, shared by every
+  action surface — gated on `action.disabled != null && action.disabled !== false`
+  and handed the value straight to `evaluateCondition`. That function documents one
+  default for "there is no condition here": return `true`, meaning
+  _visible/enabled_. On `disabled`, `true` means BLOCKED. So every empty predicate
+  was read as "disabled": the handler was never invoked and the caller got
+  `{ success: false, error: 'Action is disabled' }` — a state the metadata never
+  declared. Measured with a call-counting handler:
+
+  - `disabled: ''` — handler ran: false
+  - `disabled: '   '` (whitespace only) — handler ran: false
+  - `disabled: { dialect: 'cel', source: '' }` (the empty envelope `objectstack build` can emit) — handler ran: false
+
+  After objectui#3842 / objectui#3849 fixed the renderer halves, this was live
+  user-visible behaviour: the button became clickable and clicking it returned
+  `Action is disabled` — the renderer and the execution entry disagreeing about one
+  predicate value, the shape objectui#3314 already paid for once.
+
+  The gate now asks whether a `disabled` gate is DECLARED — whether there is a
+  condition to reach a verdict on — before evaluating. "Nothing to evaluate" is
+  read from core's single predicate normalizer (`toPredicateInput`, which maps
+  `''`, `null`, an empty-`source` envelope and non-predicate values to
+  `undefined`), plus the whitespace-only string, which the normalizer wraps rather
+  than collapses and which `evaluateCondition` itself calls "no condition"
+  (`evalRowPredicate` applies the same blank-source rule).
+
+  **Behaviour change surface, deliberately one-directional.** Only values with
+  nothing to evaluate change, and only from blocked to allowed: `''`,
+  whitespace-only, an empty-`source` envelope, and non-predicate junk (`0`, `{}`,
+  which previously coerced to "disabled"). `disabled: true`, a truthy expression
+  and a truthy CEL envelope still block; `disabled: false` and an absent `disabled`
+  still run; no expression- or envelope-valued predicate changes verdict. The
+  existing `catch { isDisabled = false }` fail-open posture is untouched, and this
+  change can only stop blocking things, never start.
+
+  The value handed to the evaluator is deliberately left RAW rather than normalized
+  first. `evaluateCondition(toPredicateInput(x))` is not interchangeable with
+  `evaluateCondition(x)` for a string that is already a `${…}` template:
+  `toPredicateInput` assumes a bare expression and wraps unconditionally, so
+  `'${x}'` becomes `'${${x}}'`, fails to parse, returns verbatim, and coerces to a
+  constant `true` — a template-spelled predicate evaluated that way is ALWAYS
+  "disabled", whatever it says. That normalizer defect is filed as objectui#3871
+  (it is live at the action renderers and `ActionEngine`, while `SchemaRenderer` and
+  `page:header` evaluate the raw value and pin the correct verdict); a tripwire next
+  to the new pins goes red the day it is fixed. Two rows therefore still differ
+  between the execution and renderer paths, each recorded with its owning issue:
+  the empty envelope (objectui#3850 owns the renderer half's scope ruling) and the
+  `${…}` spelling (objectui#3871).
+
+- 4bc6c23: Converge dashboard widget `compareTo` on the executor's `{ kind, dimension? }` contract, and make the dataset path actually render a comparison
+
+  `CompareToConfig` was a three-branch union (`'previousPeriod' | 'previousYear' | { offset }`). `@objectstack/spec` collapsed it to the shape the analytics executor already implements — `DatasetCompareTo`, a plain strict object `{ kind: 'previousPeriod' | 'previousYear'; dimension?: string }` (objectstack#5011) — so this renderer now reads that one shape:
+
+  - `shiftFilterByCompareTo` / `compareToTrendLabelKey` dispatch on `compareTo.kind`. The `{ offset }` duration shift is gone: `{ offset: '1y' }` is `kind: 'previousYear'`, while `'7d'` / `'1M'` have no faithful target and are restated by the author on the widget's own `filter` plus `kind: 'previousPeriod'`. No trend label key is retired — the offset arm resolved to `vsPreviousPeriod`, which survives as the `previousPeriod` fallback.
+  - `DatasetWidget` no longer discards part of `compareTo`. It used to forward only the object form because the two string forms had no meaning downstream; with one shape there is nothing to discard, and a stale string is now invalid metadata rejected where it is authored rather than silently reinterpreted here.
+  - **The comparison now actually runs on the dataset path.** A widget states its window in its own `filter` (a date macro, or the dashboard date-range filter merged in), but the executor shifts a `timeDimensions` entry carrying a `dateRange` — so a dataset widget asking for a comparison got "compareTo needs a dated window to shift" and rendered none. When (and only when) a comparison is requested, the resolved filter's bounded date windows are lowered into `selection.timeDimensions[].dateRange` and moved out of `runtimeFilter` (a copy left behind would intersect the shifted window with the current one and empty every comparison column). Which dimension gets shifted stays the executor's decision: every window found is lowered under the name the author wrote, and zero or two candidates surfaces the executor's own error, listing them.
+  - The `<measure>__compare` columns that come back are now shown: a delta + window label on KPI widgets, a comparison column on tables, and a `variant: 'comparison'` overlay series on charts — the same treatment and the same `dashboard.trend.*` labels the inline object-provider widgets already use.
+
+- e06810e: `PageComponentSchema.dataSource` is now consumed instead of discarded — a
+  `list-view` page component can reference a **saved view by name** for the first
+  time, and writing the binding no longer breaks the component
+  (objectstack#5576).
+
+  The spec declares a per-element data binding on every page component —
+  `dataSource: { object, view?, filter?, sort?, limit? }` — and objectui read none
+  of it. `ViewDataProvider.resolveElementDataSource` forwarded
+  `filter`/`sort`/`limit` and dropped `view` entirely, and had no caller outside its
+  own test; nothing mapped `object` onto the `objectName` a list actually reads. So
+  "reference a saved view by name" was published, validated and inert, and every
+  page that wanted a saved view's columns/filter/sort had to inline a second copy of
+  them — the drift the binding exists to remove.
+
+  Writing the binding also **broke** the block, for a reason unrelated to `view`:
+  `SchemaRenderer` spread the schema's `dataSource` metadata onto the component as a
+  React prop, and that is the prop name the host uses to inject the data-source
+  ADAPTER. The plain `{ object, view }` object shadowed the adapter, so the first
+  `dataSource.find(…)` threw `dataSource.find is not a function` and `list-view`
+  rendered "Couldn't load records" — a spec-compliant component failing next to
+  identical ones that omitted the binding.
+
+  - `@object-ui/react` — `SchemaRenderer` no longer spreads `schema.dataSource` as a
+    prop (it is metadata, like `visibleWhen`); renderers read it off `schema`. An
+    explicit React `dataSource` prop is unaffected. New
+    `useElementDataSource(schema, dataSource?)` hook resolves a binding, fetching
+    the named saved view from the object definition's `listViews` and the metadata
+    overlay's `listViews()`.
+  - `@object-ui/core` — new `isElementDataSourceConfig` / `collectSavedViews` /
+    `resolveSavedView` / `composeElementDataSource`, and `resolveElementDataSource`
+    now honours `view` through an optional `DataFetcher.fetchViews`, reporting an
+    unresolvable view as an error instead of silently returning every record.
+    `resolveViewId` moved here from `@object-ui/app-shell` (re-exported there) so
+    one matcher serves both the object page and a page component.
+  - `@object-ui/plugin-list` — `list-view` maps the binding onto the props
+    `ListView` reads. `dataSource.*` keys are authoritative, view-supplied values
+    are a baseline the component's own keys override, and `filter` AND-combines at
+    every level (the spec calls the binding's filter "additional criteria"), so a
+    binding can narrow a saved view but never widen it. A `view` name that does not
+    resolve renders a configuration error naming the object's actual views and
+    issues no query — it never falls back to the object's default view, because that
+    turns a typo into a silently wider answer.
+
+- ab3ad4f: An empty predicate is no longer a declared gate anywhere (objectui#3850, objectui#3862)
+
+  "Is a gate DECLARED on this key — is there a condition to reach a verdict on?" was
+  answered three times in this repo, with three different scopes, and the widest
+  answers sat on `disabled`, where the mistake is not benign:
+
+  - `hasDeclaredVisibilityGate` (the action face) asked `!= null && !== ''`, so every
+    OBJECT counted — including `{ dialect: 'cel', source: '' }`. That envelope is not
+    a hand-written curiosity: `@objectstack/spec`'s `ExpressionInputSchema` normalizes
+    every authored predicate into one, so "the author left the predicate empty"
+    compiles to exactly it. The verdict path normalized the same value back to
+    `undefined`, and `evaluateCondition(undefined)` answers `true` — "no condition, so
+    visible/enabled". On `visible` that `true` means SHOW, so the two mistakes
+    cancelled; on `disabled` it means GREY, so they compounded: a button disabled
+    forever that no author asked to disable (objectui#3850, the residue objectui#3842
+    left behind).
+  - `SchemaRenderer` asked `disabled !== undefined` inline, one notch wider again, so
+    `disabled: null` greyed out too — on the GENERIC rendering path, since that block
+    runs for every node type, and not as an internal flag either: `_disabled` is
+    forwarded to the component as a real `disabled` prop (objectui#3862).
+  - `ActionRunner`'s execution gates asked "does this normalize to something
+    evaluable?" — the scope that turned out to be right (objectui#3848 / objectui#3872).
+
+  There is now ONE definition, `hasDeclaredPredicate`, exported from
+  `@object-ui/core` (`evaluator/declaredPredicate.ts`, beside the `toPredicateInput`
+  normalizer it is derived from): a gate is declared when normalization still leaves a
+  condition to evaluate. `''`, a whitespace-only string, an empty-`source` envelope
+  and any non-predicate value (`0`, `{}`) are NOT declared; `false` IS (a verdict is
+  not a missing gate — objectui#3812). `hasDeclaredVisibilityGate` keeps its name as a
+  re-export of it, so the five member-action renderer call sites, `DeclaredActionsBar`
+  and `record-quick-actions` are unchanged and inherit the scope;
+  `SchemaRenderer`'s `disabled` / `disabledOn` chain and `ActionRunner`'s two gates
+  read the same function. No consumer got a local "and also check for empty" test —
+  that fourth dialect is what objectui#3842 / objectui#3849 spent two PRs merging away.
+
+  Measured behaviour change, `action:button` and the generic path, before → after:
+
+  | value                                                     | `visible`      | `disabled` | `enabled` | `SchemaRenderer` `disabled` prop |
+  | --------------------------------------------------------- | -------------- | ---------- | --------- | -------------------------------- |
+  | `''`                                                      | shown → shown  | on → on    | on → on   | forwarded → absent               |
+  | `null`                                                    | shown → shown  | on → on    | on → on   | forwarded → absent               |
+  | `{ dialect: 'cel', source: '' }`                          | shown → shown  | GREY → on  | on → on   | forwarded → absent               |
+  | `{ source: '' }`                                          | shown → shown  | GREY → on  | on → on   | forwarded → absent               |
+  | `'   '` (whitespace)                                      | HIDDEN → shown | on → on    | GREY → on | forwarded → absent               |
+  | `0` / `{}` (not predicates)                               | shown → shown  | GREY → on  | on → on   | forwarded → absent               |
+  | `true` / `false` / bare CEL / `${…}` / non-empty envelope | unchanged      | unchanged  | unchanged | unchanged                        |
+
+  Every row moves toward "there is no gate here", never away from it, and no value
+  that HAS a verdict changes it — the verdict is still read from the raw value, only
+  the gate in front of it narrowed. Two rows are behaviour changes rather than the
+  equivalence the ruling expected, and are pinned as such: the whitespace string moves
+  on `visible` / `enabled` (it used to normalize to `'${   }'`, which evaluates falsy,
+  so a predicate that says nothing HID the action from everyone), and non-predicate
+  junk stops greying controls out (fail-open, the posture `ActionRunner` already
+  committed to).
+
+  One blank spelling is knowingly still outside the scope: an envelope whose `source`
+  is blank but not EMPTY (`{ dialect: 'cel', source: '   ' }`) — the normalizer folds a
+  `source` of `''` and does not trim, so the string spelling of a blank predicate is
+  trimmed and the envelope spelling is not, and `disabled` still greys out for that one
+  value. The ruling enumerated three empty spellings; this is a fourth, measured and
+  filed as objectui#3960 rather than widened in here.
+
+  One chain is deliberately untouched: `SchemaRenderer`'s `visible` / `visibleWhen` /
+  `visibleOn` / `visibility` / `hidden` / `hiddenOn` legs keep `!== undefined`, because
+  narrowing them would change ALIAS PRECEDENCE, not just emptiness. The `hidden` legs
+  are not negated and therefore carry this same defect with the polarity that makes the
+  node vanish — measured, out of this ruling's scope, filed as objectui#3955.
+
+- c2fd122: fix(actions): forward `bodyShape` end-to-end so a declared body wrap is honoured
+
+  Sibling of the `bodyExtra` fix, same failure shape one key over. `bodyShape` is
+  the spec's body-WRAPPING declaration for a `type: 'api'` action — `'flat'` (the
+  default) or `{ wrap: key }` to nest the collected params under `key`, the shape
+  better-auth's `organization/update` needs. The console `apiHandler` read it
+  unconditionally while **no** action renderer forwarded it, so an author who
+  declared `bodyShape: { wrap: 'data' }` on an `action:button` / `:group` / `:icon`
+  / `:menu` action got a FLAT body on the wire: the endpoint received the params at
+  the top level, and the declaration read as honoured because it parsed and
+  published.
+
+  The four declared-action renderers now forward the key, and `ActionSchema`
+  declares it (typed by derivation from the spec, so the union cannot drift).
+  `ActionRunner.executeAPI` — the fallback path taken when no host registered an
+  `api` handler — now reads it too, closing a second asymmetry in which the same
+  action changed body shape depending on which host executed it. The wrap covers
+  the collected params only; `bodyExtra` and other top-level keys stay flat, which
+  is the spec's own wording for the key and what both console read-sites already
+  did.
+
+  `element:button` deliberately does **not** forward it: its whitelist mirrors
+  spec's `InlineActionSchema` pick list field for field, and that pick list does
+  not include `bodyShape` — it is not inline vocabulary.
+
+- 1d723e3: fix(core): stop re-wrapping an already-`${…}` predicate, so action-face `visible` / `disabled` finally honour it (objectui#3871)
+
+  `toPredicateInput` — the one normalizer every action surface and the action
+  engine share — wrapped **every** string as `${string}`, assuming a bare
+  expression. But `${…}` is a spelling this repo documents for a predicate
+  (AGENTS.md §4) and one the normalizer's own output type lists as valid, so an
+  already-normalized value was wrapped a second time: `'${x}'` became `'${${x}}'`,
+  which cannot match the evaluator's single-template fast path and does not parse.
+  The author's expression then decided nothing, and which constant came back
+  depended on the caller's error policy:
+
+  - **fail-soft** legs (every `disabled` / `enabled` leg; `visible` on
+    `action:icon`, `action:group` and the related-list toolbar) got the unparsed
+    string back, so `Boolean(…)` was a constant `true`: `disabled: '${…}'` greyed
+    the action out permanently, `visible: '${…}'` showed one the author had gated
+    away, and `enabled: '${…}'` never disabled anything.
+  - **fail-closed** legs (`throwOnError: true` — `visible` on `action:button`,
+    `action:bar`, `action:menu`, `DeclaredActionsBar`, and
+    `ActionEngine.getActionsForLocation`) got a **throw**, which each site turns
+    into "hidden": an action gated with a template predicate was invisible even
+    while its gate held, and the fail-closed warning blamed the author's
+    expression.
+
+  A string that already carries `${` is now returned untouched (the same guard
+  covers the envelope branch, where an unwrapped `source` reaches the identical
+  wrap), which makes the normalizer idempotent. Every affected surface goes from a
+  constant verdict to the predicate's real one — converging the action face with
+  `SchemaRenderer` and `page:header`, which read the raw value and have always
+  been right about this spelling (objectui#3314's shape). Bare expressions and
+  `{ dialect: 'cel' }` envelopes are untouched.
+
+  `ActionRunner`'s two execution gates already read the raw value and are
+  unchanged; the objectui#3871 tripwires they carried have been replaced by pins
+  of the now-converged behaviour.
+
+  Whether `${…}` should be _authorable_ on an action predicate at all is a
+  separate, spec-side question (`@objectstack/spec`'s `PredicateInput` models a
+  bare string and a dialect envelope): if it is to be rejected, that belongs in
+  publish-time validation, not in a consumer that silently invents a verdict.
+
+- 0109f54: Blank predicates and non-predicate values are no longer gates, at the last three entries that still judged them (objectui#3955, objectui#3957, objectui#3960)
+
+  objectui#3850 sank "is a predicate gate DECLARED here?" into one definition,
+  `@object-ui/core`'s `hasDeclaredPredicate`. Three places were left out of that
+  ruling's placement clause, each with the same shape of defect: the evaluator's
+  single default for "there is nothing here to evaluate" is `true`, meaning
+  _visible/enabled_, and wherever a too-wide "declared" test hands it an empty
+  predicate on an INVERTED key, that `true` turns a control off for a value the
+  metadata never used to say anything.
+
+  **`SchemaRenderer`'s `hidden` / `hiddenOn` legs (objectui#3955)** asked
+  `!== undefined` and did NOT negate the verdict, so an empty predicate meant HIDE
+  and the node disappeared — on the generic rendering path, since that block runs
+  for every schema type. Harder to diagnose than the `disabled` twin objectui#3862
+  fixed: a greyed-out control is still on screen, while a node that never rendered
+  is indistinguishable from metadata that meant to hide it. Both legs now read the
+  shared definition.
+
+  **The "blank" criterion now covers the envelope spelling (objectui#3960).** The
+  definition trimmed a whitespace-only STRING and not an envelope's whitespace-only
+  `source`, because `toPredicateInput` folds a `source` of `''` and does not trim.
+  So `{ dialect: 'cel', source: '   ' }` was a declared gate whose verdict came from
+  core's own CEL entry calling that exact value "no predicate" (`if (!source.trim())
+return true`) — `disabled` greyed out forever and `ActionRunner.execute` answered
+  `{ success: false, error: 'Action is disabled' }` with the handler never invoked.
+  Blankness is now decided once for both spellings, at the definition. The
+  NORMALIZER's contract is deliberately unchanged: "what shape does the evaluator
+  accept" is not the same question as "is there a condition", and moving the trim
+  there would have flipped verdicts for every
+  `useCondition(toPredicateInput(…))` call site, including container-level `visible`
+  reads that never asked this question at all.
+
+  **`ActionEngine.getActionsForLocation`'s `visible` filter (objectui#3957)** was the
+  last consumer answering the question with a range of its own — three empty
+  spellings folded by hand, everything else coerced with `Boolean(raw)`. It now reads
+  the shared definition and the coercion branch is gone, so one value no longer gets
+  two answers depending on whether an action was surfaced by the engine or rendered
+  standalone (the invariant objectui#3314 established). Its fail-CLOSED posture on a
+  predicate that THROWS is untouched (`throwOnError: true` + `warnHiddenPredicate`):
+  "the predicate faulted" and "there is no predicate" are different facts.
+
+  Behaviour changes, before → after. Observation-class: each needs an author to write
+  an empty/blank predicate or a non-predicate value, and there is no known user path
+  today.
+
+  | value                                                       | `ActionEngine` `visible` | `SchemaRenderer` `hidden` | `disabled` (action face + generic path) | `ActionRunner.execute` `disabled` |
+  | ----------------------------------------------------------- | ------------------------ | ------------------------- | --------------------------------------- | --------------------------------- |
+  | `''` / `null`                                               | shown → shown            | HIDDEN → rendered         | unchanged                               | unchanged                         |
+  | `'   '` (blank text)                                        | HIDDEN → shown           | HIDDEN → rendered         | unchanged                               | unchanged                         |
+  | `0` / `NaN`                                                 | HIDDEN → shown           | HIDDEN → rendered         | unchanged                               | unchanged                         |
+  | `{}` / `[]`                                                 | shown → shown            | HIDDEN → rendered         | unchanged                               | unchanged                         |
+  | `{ dialect: 'cel', source: '' }`                            | shown → shown            | HIDDEN → rendered         | unchanged                               | unchanged                         |
+  | `{ dialect: 'cel', source: '   ' }`                         | shown → shown            | HIDDEN → rendered         | GREY → on                               | refused → runs                    |
+  | `{ source: '   ' }` (no dialect)                            | HIDDEN → shown           | HIDDEN → rendered         | GREY → on                               | refused → runs                    |
+  | `true` / `false` / bare CEL / `${…}` / a non-blank envelope | unchanged                | unchanged                 | unchanged                               | unchanged                         |
+
+  Every row moves toward "there is no gate here", never away from it, and no value
+  that HAS a verdict changes it — a declared `false` is still a verdict, not a
+  missing gate (objectui#3812), and blankness is `trim()`, not "short": `{ dialect:
+'cel', source: ' x ' }` is a predicate. One alias precedence changes with the
+  `hidden` legs and is pinned rather than claimed as an equivalence: an undeclared
+  `hidden` no longer short-circuits the chain, so a declared `hiddenOn` is finally
+  consulted.
+
+  `SchemaRenderer`'s four `visible*` legs keep `!== undefined` deliberately, as
+  objectui#3850 ruled: their `true` is negated, so an empty predicate already lands
+  on "shown", and narrowing them would change alias precedence rather than fix
+  anything.
+
+- 7e5bb5d: fix(actions): forward `bodyExtra` end-to-end through the action chain
+
+  An action's static request body (`bodyExtra`) was dropped one hop before the
+  `ActionRunner`: every action renderer forwards an explicit whitelist of keys, and
+  none of them listed `bodyExtra`. Since `@objectstack/spec` 17 made it the only way
+  a `type: 'api'` action can carry a payload (`params` keeps its single meaning as
+  the parameter definition array), and the ADR-0087
+  `inline-action-api-params-to-body-extra` conversion rewrites older object-form
+  `params` pages onto it at load, a previously-working published page validated,
+  published and then POSTed an empty body.
+
+  `element:button`, `action:button`, `action:group`, `action:icon` and `action:menu`
+  now forward the key; `ActionRunner.executeAPI` merges it into the request body
+  **last** (so a constant always overrides a same-named user param, matching the
+  console `apiHandler`); `ActionSchema` declares it; and a non-array `params` on a
+  `type: 'api'` action keeps working for one version window with a dev-mode
+  deprecation warning naming `bodyExtra`.
+
+- fbc23e0: Action params that inherit a field's options now keep the keys that field declared
+
+  A field-backed action param (`{ field: 'tier' }`) had its inherited option list
+  rebuilt entry by entry as `{ label, value }`, which silently dropped every other
+  key the field's options declared — most consequentially the per-option
+  `visibleWhen` predicate (ADR-0058). A select field whose options narrow by
+  predicate in an object form therefore offered the FULL list in an action dialog,
+  including the entries the predicate exists to hide, with no diagnostic on either
+  side; `color` / `icon` / `disabled` were lost the same way. Options authored
+  inline on the param were never affected — they always passed through verbatim,
+  which is the asymmetry this restores.
+
+  The resolver now preserves each inherited entry and only does its two real jobs:
+  expanding bare strings into label/value pairs and translating the label through
+  `fieldOptionLabel`. The option widgets already filter on `visibleWhen`, so a
+  role-gated option (`'admin' in current_user.positions`) inherited by a dialog
+  param now narrows the offered set and clears a seeded value the predicate hides.
+
+  `ActionParamDef.options` (`@object-ui/core`) and the resolver's `RawActionParam`
+  are widened to match: `ActionParamOption` names the two keys the param layer
+  reads and carries the rest of a field's option vocabulary through.
+
+- 6bb454a: `evalRowPredicate`: the fail-closed report now names the engine's failure reason, and the ROW always wins over host scope (objectui#3792, objectui#3796)
+
+  Two defects in one function, `packages/core/src/evaluator/listConditional.ts`,
+  shared by every surface that gates on a row predicate: the row kebab, the bulk
+  selection bar, kanban conditional formatting, and — since objectui#3521 — the
+  record page header.
+
+  **The safest path said the least (objectui#3792).** `evalRowPredicate` has two
+  diagnostic routes, and their information content was inverted. The single-eval
+  fast route lets the canonical helper warn, so it prints the engine's own reason
+  (`Reason: [runtime] No such key: owner_id`). The `warnOnError: true` route — the
+  fail-CLOSED one, taken by every caller that makes a button disappear — runs
+  `evalFieldPredicate` twice with `{ warn: false }` to tell a fault from a genuine
+  `false`, and that silence discarded the reason along with the duplicate warning.
+  So the more decisively a surface hid a control, the less it said about why: the
+  console line named the predicate but not the defect, and `No such key: owner_id`
+  or `no such overload: string == null` is usually the whole answer.
+
+  `FieldPredicateDiagnostic` gains an optional `onFault(reason)` passback:
+  `evalFieldPredicate` hands out the engine's verbatim text (kind tag, message and
+  source excerpt — the exact string it prints after `Reason:`) even when its own
+  warning is suppressed. It fires per fault, deliberately independent of the
+  once-per-predicate warning dedupe, so a caller doing its own warn-once
+  bookkeeping keeps control of it; the verdict is unaffected, and callers that pass
+  nothing are unchanged. `evalRowPredicate` threads that reason into its labelled
+  warning, and the legacy-dialect route does the same with the message its engine
+  throws (`Reason: [legacy] …`), so both dialect paths report a fault the same way.
+  Warn-once semantics are unchanged — the reason is deliberately not part of the
+  dedupe key.
+
+  **Wording: not a list function, and not for a long time.** The same message
+  called every caller a "**list** conditional predicate". A hidden button on a
+  record page header reporting "a list conditional predicate" sends its author to
+  the list view to look for a control that was never there. Both messages this
+  module emits (evaluation failure and the legacy-dialect deprecation) now read
+  "conditional predicate".
+
+  **The row is the subject — on both dialect paths (objectui#3796).** The scope
+  merge pinned `data` after the host-scope spread but not `record`, leaving
+  `record` to each engine's own binding — and the two engines disagreed. The legacy
+  evaluator re-pinned `record` to the row (row won); the CEL engine takes its
+  `extra` bag over its `record` binding, so a host scope carrying a `record` key
+  won there instead. One function, one predicate text, two subjects — selected by
+  whether the string happens to contain `===` or `${…}`, the dialect-routing
+  markers, which no author picks deliberately. `record` is now pinned after the
+  spread exactly as `data` is, which fixes both paths at the merge site rather than
+  relying on either engine's precedence.
+
+  No host injects a `record` key today — `ExpressionProvider` binds
+  `current_user` / `user` / `ctx` / `os` / `app` / `data` / `features` — so nothing
+  observable changes for existing apps; this closes the edge before a host adds one
+  (`ctx.record` already exists, which is exactly how it would arrive). A row FIELD
+  named `record` is likewise no longer able to become the row root; it stays
+  addressable as `data.record`.
+
+  Shipped as a patch: no new exported symbol, one optional field added to an
+  already-exported options interface, and no existing call signature changed.
+
+- 523be48: `object-timeline` and `record:line_items` now apply the filter / sort / row cap they are given, so a named `dataSource.view` narrows them instead of contributing nothing
+
+  These were the two residual gaps in objectstack#7121's per-block coverage table
+  (objectstack#7137). Both blocks are object-bound lists, both accepted the spec's
+  per-element `dataSource` binding, and neither had a read site for `filter` or
+  `sort` anywhere in its fetch:
+
+  - `object-timeline`'s entire query was
+    `find(objectName, { options: { $top: 100 } })`.
+  - `record:line_items`' was the parent FK plus a fixed `$top: 500`.
+
+  So `dataSource: { object, view: 'hot' }` resolved the view — a typo still reported
+  a configuration error, it never degraded into an unfiltered query — and then
+  dropped everything the view said. The rendered rows could be **wider than the view
+  they named**, silently, which is exactly the class of mistake AI-authored metadata
+  hides best: the page looks like it works. objectstack#7121 deliberately left the
+  keys unmapped and recorded the gap rather than writing composed values onto schema
+  keys nobody read; this closes it at the fetch instead.
+
+  What each block now reads:
+
+  - **`object-timeline`** — `$filter: schema.filter`,
+    `$orderby: convertSortToQueryParams(schema.sort)`, and
+    `$top: schema.limit ?? 100`, matching the form `object-gantt` / `object-map` /
+    `object-calendar` already use. Its registry mapping gains
+    `filter` / `sort` / `limit`; `columns` stays unmapped, because a timeline
+    projects the fields its `timeline` config names.
+  - **`record:line_items`** — the composed filter is **AND-combined** with the parent
+    relationship condition through `mergeFilterNodes`, never substituted for it, the
+    same way `record:related_list` composes its own since objectstack#7118: a
+    line-items panel is always scoped to the record it sits on, so an _additional_
+    criterion can only narrow this parent's children and can never surface another
+    parent's rows. `sort` becomes the load order and `limit` the row cap (default
+    500). `columns` stays unmapped — here they are `GridColumn[]` driving an editable
+    grid, not a field-name projection, so a view's column list would be the wrong
+    _shape_ rather than merely a wider answer.
+
+  **Behaviour change worth knowing about:** the timeline's default window is now a
+  real cap. `{ options: { $top: 100 } }` nested the limit under a key that is not a
+  `QueryParams` field and that no adapter in this repo reads (`convertQueryParams`
+  maps `params.$top`), so the intended window never reached the wire and a timeline
+  over a large object fetched whatever the server chose to return. It is now sent as
+  `$top`, and authorable via `limit` or a view's `pagination.pageSize`.
+
+  `@object-ui/core` gains `convertSortToQueryParams`, the sort→`$orderby` lowering
+  the three sibling blocks each inline privately. It is shared rather than copied
+  twice more, and is slightly more faithful to the declared contract than those
+  copies: a sort entry that omits `order` means ascending instead of being dropped
+  (the string spelling `"amount"` already meant ascending in the same copies), and
+  nothing orderable yields `undefined` rather than a truthy empty `{}`. Migrating
+  the three existing copies onto it is objectstack#7148 and is not done here.
+
+- Updated dependencies [d229dfa]
+- Updated dependencies [c2fd122]
+- Updated dependencies [48132f7]
+- Updated dependencies [7e5bb5d]
+- Updated dependencies [e6fdbdc]
+- Updated dependencies [7e2b7e9]
+- Updated dependencies [c1e1e6b]
+  - @object-ui/types@17.4.0
+
 ## 17.3.0
 
 ### Minor Changes
@@ -2641,6 +4649,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
   project `health`) painted its categories from the generic `--chart-1..5`
   palette — the same gap the chart view (`object-chart`) had before #1932. It now
   resolves the dimension field's option colors (using the dataset's base `object`
+
   - dimension→field map the query already returns) and threads them to the
     renderer as a per-category `categoryColors` map, so health green/red/yellow
     paints semantically.
@@ -2883,6 +4892,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
 - 991b62d: Add `compareTo` field to dashboard widgets for period-over-period
   comparison. Supports `'previousPeriod'`, `'previousYear'`, and
   `{ offset: '7d' | '4w' | '1M' | '1y' }`.
+
   - **Metric / gauge widgets** now compute a delta percentage when `compareTo`
     is set and surface it as a derived `trend` (auto-labelled via
     `dashboard.trend.vsLast*` i18n keys sniffed from the filter macros).
@@ -2985,6 +4995,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
 
   Extract the bulk-vs-per-row decision into a reusable
   `executeBulkBatch(input, ops)` helper in `@object-ui/core`:
+
   - Single decision tree shared by both update and delete fast paths.
   - Bulk success → no per-row pass.
   - Bulk partial-count → aggregate batch error.
@@ -3029,6 +5040,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
   multi-user editing scenarios.
 
   **`@object-ui/data-objectstack`**
+
   - Exports `ConcurrentUpdateError` (carries `currentVersion` and
     `currentRecord`) and `isConcurrentUpdateError()` type guard.
   - `update()` / `delete()` accept `opts.ifMatch` and forward it via the
@@ -3041,6 +5053,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
     from conflicts without parsing the wire format.
 
   **`@object-ui/core`**
+
   - `ApiDataSource.update()` and `.delete()` accept `opts.ifMatch` and emit
     the `If-Match` HTTP header.
 
@@ -3176,6 +5189,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
   detail view (`TypeError: titleFormat.replace is not a function`) and printed
   `Failed to evaluate expression: ${[object Object]}` for every action visibility
   predicate.
+
   - `@object-ui/core`: `ExpressionEvaluator.evaluate` / `evaluateCondition` now
     unwrap Expression envelopes transparently.
   - `@object-ui/react`: new `toPredicateInput()` helper to safely normalize
@@ -3190,6 +5204,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
     the new `{ source }` envelope.
 
   All changes are backward-compatible — legacy bare strings continue to work.
+
   - @object-ui/types@4.0.7
 
 ## 4.0.6
@@ -3368,6 +5383,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
 - New plugin-object and ObjectQL SDK updates
 
   **Added:**
+
   - New Plugin: @object-ui/plugin-object - ObjectQL plugin for automatic table and form generation
     - ObjectTable: Auto-generates tables from ObjectQL object schemas
     - ObjectForm: Auto-generates forms from ObjectQL object schemas with create/edit/view modes
@@ -3376,6 +5392,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
   - ObjectQL Integration: Enhanced ObjectQLDataSource with getObjectSchema() method using MetadataApiClient
 
   **Changed:**
+
   - Updated @objectql/sdk from ^1.8.3 to ^1.9.1
   - Updated @objectql/types from ^1.8.3 to ^1.9.1
 
@@ -3389,6 +5406,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
 - Patch release: Add automated changeset workflow and CI/CD improvements
 
   This release includes infrastructure improvements:
+
   - Added changeset-based version management
   - Enhanced CI/CD workflows with GitHub Actions
   - Improved documentation for contributing and releasing