@object-ui/components 17.3.0 → 17.6.0

package/CHANGELOG.md

@@ -1,5 +1,2691 @@
 # @object-ui/components
 
+## 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.
+- 8b9dc62: `element:text.content` and `element:button.label` declare the inline translation
+  map they already accept
+  
+  Two more instances of the contradiction objectui#3832 fixed the mechanism for,
+  measured after that ruling had fixed its scope at five specimens and filed
+  separately as objectui#4970. Both inputs' own `description` tells the author to
+  write an inline translation map (`{ en, "zh-CN", … }`), both renderers resolve one
+  through `pickLocalized`, and both spec props schemas accept one — while the
+  declaration said `type: 'string'`, so the manifest gate reported
+  `type-mismatch` on the exact shape the block had recommended. Both blocks are in
+  `PUBLIC_BLOCKS`, so this reached authors through `sdui.manifest.json` and
+  `sdui-intrinsics.d.ts` as well as the save gate.
+  
+  Each declaration is now `type: ['string', 'object']`, the union form
+  objectui#3832 introduced, and the arms are the ones the contract accepts —
+  re-measured on the `@objectstack/spec` 17.0.0 GA pin rather than carried over
+  from the issue, which was written at the 17.0.0-rc.6 pin:
+  `ComponentPropsMap['element:text'].content` and
+  `ComponentPropsMap['element:button'].label` are both
+  `string | Record< string, string >`, and both refuse a number, a boolean and an
+  array. Those three refusals are the controls in the acceptance test, which is
+  what keeps a widening distinguishable from a silenced check.
+  
+  Nothing else about the two blocks moves. A plain-string `content` / `label`
+  validates exactly as before, values matching neither arm are still reported, and
+  no other manifest entry changes shape — the public manifest now carries seven
+  array-valued input types, the five from objectui#3832 plus these two, with the
+  remaining 57 public blocks serializing byte for byte as they did.
+  
+  `record:alert`'s renderer-local prop type is corrected in the same pass
+  (`plugin-detail`): its `title` / `body` were still typed `string` while the same
+  file resolves both through `pickLocalized` and the block's published `inputs`
+  have declared `['string', 'object']` since objectui#3832, so the two slots were
+  narrower than both the renderer and the block's own published surface. The type
+  is not exported, so no consumer was misled and no published surface changes. The
+  CTA's `action.label` one level down is left alone on purpose (objectui#4998):
+  `action` is published as a bare `object` whose member shape lives in prose, so
+  there are no declared arms for it to be aligned against yet.
+- a2a9747: `FieldValidationRules.pattern.value` narrows to `RegExp`, and the form renderer reports unrecognized validation rule names loudly (objectui#5099, maintainer ruling 2026-08-18).
+  
+  **BREAKING for hand-written form schemas — deliberately declared `minor`.** This
+  repo's version policy reserves `major` for tracking `@objectstack` majors and is
+  mechanically enforced (`scripts/check-changeset-no-major.mjs`); per that policy,
+  objectui's own breaking changes ship as `minor` with the breaking semantics
+  stated plainly here:
+  
+  - **What breaks:** `validation: { pattern: { value: '^…$', message } }` with a
+    **string** value no longer compiles. Write a `RegExp` literal instead:
+    `pattern: { value: /^…$/, message }`.
+  - **Why red is the fix, not the damage:** react-hook-form applies `pattern`
+    only when `value instanceof RegExp`, and the renderer's single read point
+    spreads `validation` verbatim — so every string pattern accepted by the old
+    type ran **zero** validations, silently. Callers turning red were not
+    validating anything yesterday; the error converts silent non-validation into
+    explicit failure at authoring time.
+  - **Unaffected:** the metadata route. `FieldSchema.pattern` (a string in field
+    metadata) is still compiled by `buildValidationRules` in `@object-ui/fields`
+    via `new RegExp(...)` before it reaches the renderer.
+  
+  Also, per the same ruling's second limb, the form renderer now reports rule
+  names react-hook-form does not run (`console.error`, message doubles as the fix
+  instruction): a misspelled `minlength`, an invented `email`, or numeric keys
+  left by spreading an array into `validation` shout instead of vanishing. The
+  recognized set is pinned against the installed react-hook-form bundle so a
+  future bump cannot silently rot the diagnostic. The ruling's rejected half is
+  equally binding and equally pinned by test: the read point does **not** compile
+  string patterns — that consumer-side tolerance would harden the ambiguous
+  declaration into contract (AGENTS.md #0.1).
+- 232f61a: Form-field type resolution no longer falls back to `ui`-namespace SDUI node renderers.
+  
+  A `FormSchema` field's `type` now resolves a `field:`-namespaced widget or takes
+  the builtin `default` input branch. It no longer falls back to
+  `ComponentRegistry.get(type)` — the bare name in whatever namespace happened to
+  hold it. (Maintainer ruling of 2026-08-19 on objectui#5254, option B.)
+  
+  **This is a behaviour change, and it is the point of the change, not a side
+  effect.** A spelling that resolved yesterday stops resolving: a form field whose
+  `type` names a non-field component renders the default input instead of that
+  component. Measured on the built-in (no-`registerAllFields()`) path, the removed
+  fallback answered **126** bare names — `div`, `h1`, `card`, `button`, `form`,
+  `alert`, `badge`, the display `text` widget — and 116 of them with the fields
+  package registered as well. Marked `minor` for that reason. It is released as a
+  behaviour change rather than a fix because callers cannot tell from their own
+  metadata which of the two rules answered them; anyone who deliberately pointed a
+  form field at an SDUI component was relying on a rule no contract stated, and
+  that reliance now needs a `field:`-namespaced widget instead.
+  
+  Nothing changes for the two paths that carry real traffic. With
+  `registerAllFields()` — the production configuration — every affected field type
+  already resolved its own `field:` widget (`email` to `field:email`, `password`
+  to `field:password`, `text` to `field:text`), and object-derived forms go
+  through `mapFieldTypeToFormType`, which has always emitted the `field:`-prefixed
+  id. Rendering one of these components as a top-level SDUI **node** is untouched:
+  this rule governs field resolution only.
+  
+  What the fallback was producing on the built-in path, for
+  `{ name: 'contact', type: 'email', max_length: 50 }`:
+  
+  ```
+  attrs=["class","id","max_length","field","aria-describedby",
+         "aria-invalid","type","value","name"]   maxlength=null
+  ```
+  
+  `email` and `password` are registered as `ui`-namespace node renderers for
+  top-level `{ type: 'email' }` nodes, so reached as a *field* they received the
+  field-widget prop bundle they do not implement and spread it onto the element:
+  the raw metadata object landed as `field="[object Object]"`, `max_length`
+  landed as an inert attribute with no cap in effect (`maxlength` null), and the
+  node renderer's own `<Label>` gave the control a second `<label>` on top of the
+  form's. All three are gone; the declared ceiling now actually caps
+  (`maxlength="50"`).
+  
+  `email` and `password` keep rendering the native input they always rendered.
+  The default branch derives `<input type>` from those two declared field types
+  (`EmailFieldMetadata` / `PasswordFieldMetadata`), because `inputType` there is
+  whatever the author wrote and a plain `{ name, type: 'password' }` authors none
+  — without it that field would have rendered `type="text"` and shown a secret in
+  clear text. An explicitly authored `inputType` still wins. Other declared types
+  with a native HTML equivalent (`url`, `phone`, `number`, `color`, `date`)
+  already took this branch as `type="text"` and are unchanged.
+- 5673576: fix(components): call `FormSchema.onChange` — the declared callback the form renderer never invoked (objectui#4259)
+  
+  `FormSchema` declares four lifecycle callbacks and the form renderer
+  destructures all four off `schema` in one block: `onSubmit`, `onChange`,
+  `onDirtyChange`, `onCancel`. Three were wired. `onChange` was destructured and
+  then never referenced again — the destructure was its only occurrence in the
+  whole file — so a consumer who authored it got a typed, exported, documented,
+  autocompleted callback that did nothing at all. No warning, no dev-mode notice,
+  no type error: the declaration said it was supported.
+  
+  It is now called with the live form values whenever a value changes, through the
+  same `form.watch` subscription plumbing the `onDirtyChange` and `onAction`
+  channels already use, so the value channel cannot drift into its own schedule.
+  
+  Two properties are deliberate and pinned by tests:
+  
+  - **The subscription is guarded.** A schema that authors no `onChange`
+    establishes no subscription at all, exactly like the existing `onAction`
+    channel and unlike the unconditional `onDirtyChange` one. Watching
+    unconditionally would have put a third `form.watch` on every form in the
+    product on behalf of callers who asked for nothing; honouring the declaration
+    is meant to be purely additive for everyone else.
+  - **It runs in the layout phase**, matching the `defaultValues` reset and the
+    two subscriptions beside it. React runs every layout destroy before any layout
+    create, so a caller passing a fresh inline arrow each render — the common
+    shape — has the subscription torn down before the reset and re-established
+    after. That is what keeps a record landing in edit mode from being reported to
+    the host as if the user had edited every field it filled. A passive effect
+    inverts that order.
+  
+  The callback receives the form values, per its declared
+  `(data) => void` signature — not a DOM event. A top-level `onChange` spread onto
+  the form node is still stripped before it can reach the `form` element, where it
+  would have fired with a SyntheticEvent instead; that block's behaviour is
+  unchanged, only its now-outdated comment was corrected.
+  
+  No change to `@object-ui/types` — the declaration was already there and already
+  correct. This is the renderer starting to honour it.
+- 911ceaa: The fullscreen long-text dialog announces the field's validation state and carries the field's name
+  
+  objectui#4824, objectui#4832.
+  
+  `mobile.fullscreenLongText` is a shipped opt-in, and with it on the phone user
+  edits long text in this dialog and nowhere else. Measured on all three surfaces
+  that render the dialog — `TextAreaField`, `RichTextField`, and the form
+  renderer's built-in `textarea` branch — with the field genuinely invalid at that
+  moment:
+  
+  ```
+  INLINE  richtext  aria-invalid= true
+  DIALOG  richtext  aria-invalid= false   aria-describedby= null
+  INLINE  textarea  aria-invalid= true
+  DIALOG  textarea  aria-invalid= null    aria-describedby= null
+  ```
+  
+  and the accessible name of every dialog control empty, against `F` on every
+  inline one. The rich-text row is the sharp half: the dialog was not silent about
+  the failure, it was announcing the OPPOSITE of the inline control for the same
+  field at the same moment, because `RichTextEditorSurface` computed
+  `aria-invalid={!!error}` from an `error` prop the dialog rendering never
+  received. 3 surfaces, 3 broken, one cause: the dialog's control is built from
+  scratch by the host, so none of the wiring the inline control gets from the form
+  renderer reaches it.
+  
+  **Answered once, in the primitive.** `FullscreenEditor` now takes the field's
+  `error` and owns what the dialog does with it: it renders the message in a
+  dialog-local node, and hands `children` a required fourth argument — a
+  spreadable set of DOM attributes — carrying `aria-labelledby` (the dialog
+  title's text, i.e. the field label #3393 already put there), `aria-invalid`, and
+  `aria-errormessage` naming that node. The host spreads it; the host never learns
+  an id, so it cannot name the wrong node, cannot compose the attributes subtly
+  wrong, and cannot compute its own `aria-invalid` from a prop it forgot to plumb.
+  Three hosts hand-answering this is the shape that produced three identical
+  holes.
+  
+  **On objectui#3222's "the text belongs to `FormMessage`".** The maintainer's
+  ruling of 2026-08-16 restates that rule as what it was always protecting —
+  only one copy of the error text is in the accessibility tree at any moment —
+  which the dialog-local node satisfies: it exists only while the dialog is open,
+  and for exactly that window Radix `aria-hidden`s everything outside the modal,
+  `FormMessage` included. The shortcut of pointing the dialog control's
+  `aria-describedby` / `aria-errormessage` at the host's `FormMessage` id is
+  forbidden rather than merely unused: it resolves to a node that is `aria-hidden`
+  for the whole time the reference is live (an ARIA MUST violation), and neither
+  happy-dom nor jsdom can see the difference — which is why every new pin asserts
+  that the named node is inside THIS dialog, not merely that it exists.
+  
+  `aria-errormessage` carries a single IDREF and is emitted only alongside
+  `aria-invalid="true"`. It is deliberately not folded into the host's
+  `aria-describedby` chain, which on the textarea surface already carries the
+  fullscreen character counter's sentence.
+  
+  **The name reuses the visible title rather than minting a second author for it**
+  (#3978): `aria-labelledby` points at a span inside `DialogTitle`, not at
+  `DialogTitle` itself — Radix renders the title as `h2` with the id its own
+  `DialogContent` `aria-labelledby` names, so putting an id on it would buy the
+  control a name at the cost of the dialog's.
+  
+  **Breaking (shipped as `minor`, see below), `@object-ui/components` only.**
+  `FullscreenEditorProps.error` is REQUIRED, not optional, and
+  `FullscreenEditorProps['children']` takes a fourth argument.
+  
+  FROM → TO for an out-of-repo host:
+  
+  ```
+  <FullscreenEditor value={v} onCommit={c} label={l} testIdPrefix="x">
+    {(draft, setDraft, disabled) => <textarea … />}
+  </FullscreenEditor>
+  
+  <FullscreenEditor value={v} onCommit={c} label={l} testIdPrefix="x" error={err}>
+    {(draft, setDraft, disabled, aria) => <textarea {...aria} … />}
+  </FullscreenEditor>
+  ```
+  
+  A render prop may still declare fewer parameters, so only `error` fails to
+  compile — which is the point of making it required. Every consumer already has
+  the value at hand (registered widgets take `error` off the widget props
+  contract, objectui#3222; the built-in branch reads `fieldState.error?.message`),
+  and an omitted `error` reproduces this defect exactly: a dialog announcing
+  `aria-invalid="false"` for a field its own form has already failed. An optional
+  key was forgotten by three surfaces in a row; a required one cannot be.
+  
+  `@object-ui/fields` is `patch`: `FullscreenFieldEditor` is internal to that
+  package (not re-exported from its entry), so nothing in its public surface
+  changes — only the behaviour of the two long-text widgets' dialogs.
+  
+  `minor` rather than `major` follows the repo's standing retirement precedent
+  (AGENTS.md §版本号策略, enforced by `scripts/check-changeset-no-major.mjs`): all
+  publishable packages sit in one `fixed` group, so a `major` here would carry the
+  whole family up against an `@objectstack` that has not moved.
+- 98eab36: Publish the five `@objectstack/spec` 17.0.0 keys the renderers already honoured, so
+  authors can discover them
+  
+  `page:header.maxVisible`, `page:header.mobileMaxVisible`, `page:tabs.alwaysShowStrip`,
+  `record:details.inlineEdit` and `record:details.showHeader` are declared by the spec and
+  read by the renderers today, and none of them was in its block's published `inputs`. That
+  is the direction nothing reports: `gen-manifest.ts` left all five out of
+  `sdui.manifest.json` and `sdui-intrinsics.d.ts`, so they were in no designer panel and no
+  generated type; `sdui-parser`'s prop walk reported `unknown-prop` on an author who wrote
+  one anyway; and the renderer honoured it regardless. Measured on the console's own
+  manifest before this change, all five drew
+  
+  ```
+  unknown-prop: page:header has no prop "maxVisible"
+  unknown-prop: page:header has no prop "mobileMaxVisible"
+  unknown-prop: page:tabs has no prop "alwaysShowStrip"
+  unknown-prop: record:details has no prop "inlineEdit"
+  unknown-prop: record:details has no prop "showHeader"
+  ```
+  
+  and now draw nothing. Same defect as `record:details.hideFields` in objectui#3808 and
+  `readonly` in objectui#3407; it could not land until the GA pin moved (objectui#4636),
+  because the pre-GA pin declared none of the five and publishing them would have failed the
+  repo-wide parity gate's forward direction.
+  
+  Each entry carries a description, because for these keys the discoverability IS the fix.
+  Two are worth reading before use:
+  
+  - `maxVisible` / `mobileMaxVisible` are positive integers — the contract rejects `0` and
+    fractional values — and they do not govern every action: an action declaring
+    `record_more` without `record_header`, and any action with `component: 'action:menu'`,
+    is routed to the overflow menu regardless of the budget.
+  - `inlineEdit` is an opt-OUT only. The value is combined with the object's own resolved
+    editability (ADR-0103) and with the server's effective API operation set, so `false`
+    always wins while `true` cannot open editing the platform refuses.
+  
+  **`page:tabs` also gains a read.** `alwaysShowStrip` was honoured only as
+  `schema.properties.alwaysShowStrip`, while `inputs` publishes TOP-LEVEL keys — the shape
+  the manifest whitelists, the generated types declare and the JSX-page compiler validates.
+  Measured on a one-tab schema: the wrapped form showed the strip, the flat form did not, so
+  publishing the key alone would have advertised a write the renderer throws away. The
+  canonical top-level arm is read first now, with the `properties` arm kept for paths that
+  reach the renderer without `SchemaRenderer`'s hoist — the same dual read `maxVisible` has
+  always had. This can only ever ADD a strip to a one-tab page; multi-tab pages are
+  unaffected, and `false` and non-boolean values both read as "not set".
+  
+  The five GA-pending entries that held this card's place in
+  `registry-inputs-spec-parity.test.ts` are deleted, which is what the gate's own
+  `carries no stale unpublished-key exemption` check demands once the keys are published.
+- 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.
+- f1d4748: Remove the retired `striped` / `bordered` / `virtualScroll` list-view surface
+  
+  objectstack#7176 retired `list.striped`, `list.bordered` and `list.virtualScroll`
+  from the spec after measuring every objectui reader as pass-through: each one
+  copied the key onward and no renderer ever applied it. objectui stops declaring,
+  typing and forwarding them.
+  
+  Off the chain: the `@objectstack/spec` list-view bridge in `@object-ui/react`,
+  `ListView`'s child-view props in `@object-ui/plugin-list`, both `ObjectView`
+  relays (`@object-ui/plugin-view` and `@object-ui/app-shell`), the `ObjectGridSchema`
+  and `NamedListView` declarations in `@object-ui/types` (interface and zod),
+  `ObjectGrid.component.yml` in `@object-ui/components`, and the page-block
+  inspector's `striped` / `bordered` toggles in the metadata-admin designer.
+  
+  Behaviour is unchanged: nothing read these keys, so nothing rendered differently
+  for them. Stored view metadata that still carries one keeps validating — the keys
+  are simply no longer relayed. `ListViewSchema` continues to take the spec's
+  list-view fields by reference, so the protocol's own retirement tombstones
+  arrive with the next `@objectstack/spec` bump and reject the keys at the
+  authoring boundary. Restoring any of the three as live surface requires an
+  implementation card filed first, per the ruling.
+- 58b8346: Settle the two declared-but-unread keys on `AccordionItem`: retire `icon`, wire
+  `disabled` (objectui#4652).
+  
+  The same defect as objectui#4632 (PR #4651), one interface up in the same file.
+  `AccordionItem` declared `disabled?: boolean` and `icon?: string` while the
+  `accordion` renderer read neither — it mapped items to `value`/`title`/`content`
+  and dropped the rest. Nothing went red: an author who declared either key got a
+  correctly rendered accordion with the key silently ignored.
+  
+  The two keys are settled in opposite directions, by measurement rather than by
+  symmetry. A full corpus sweep (schema catalog, docs, example apps, and this
+  repo's `objectstack` sibling checkout) found **zero** sites authoring either key
+  on an `AccordionItem`:
+  
+  - **`icon` is retired** from the TypeScript interface and from the
+    `AccordionItemSchema` Zod mirror. It had zero measured pull anywhere in the
+    corpus and no established convention to lean on, so under this platform's
+    declared=enforced doctrine it is removed rather than speculatively
+    implemented.
+  - **`disabled` is honored**, despite also having zero catalog pull today.
+    Item-level `disabled` is already established live convention in this
+    codebase — `tabs`, `select`, `dropdown-menu`, `menubar`, `context-menu` and
+    (objectui#4632) `toggle-group` all forward it, and `accordion` was the next
+    outlier. The underlying Radix accordion item supports `disabled` natively, so
+    the renderer forwarding one prop is the whole change; the synced
+    `ui/accordion.tsx` primitive is untouched. The schema catalog's
+    `basic-accordion` example now demonstrates a disabled item.
+  
+  **Breaking for TypeScript authors of `icon` only** (marked `minor` per this
+  repo's version-alignment rule, which reserves `major` for following
+  `@objectstack` across a major — see AGENTS.md's 版本号策略 and the identical
+  classification PR #4651 used for `ToggleGroupItem.icon`). Runtime behaviour of
+  an authored `icon` is unchanged — it rendered nothing before and renders
+  nothing now; what changes is that the contract no longer claims otherwise, so
+  the mistake surfaces at authoring time. Authored `disabled` changes from
+  silently ignored to actually disabling that one item (and blocking its
+  expand/collapse).
+- 93fe362: layout: `flex` and `container` now honour a declared scale value of `0`
+  
+  `FlexSchema.gap` and `ContainerSchema.padding` are declared `number`, and both
+  renderers already carried an explicit zero branch (`gap === 0 && 'gap-0'`,
+  `padding === 0 && 'p-0'`). Neither branch was reachable: the value was read with
+  `||`, so a declared `0` was folded into the default before the branch was tested.
+  A `flex` asking for no gap rendered `gap-1.5 sm:gap-2`, and a `container` asking
+  for no padding rendered `p-2 sm:p-3 md:p-4` — the JSON said one thing and the DOM
+  did another, with nothing reported.
+  
+  Both now read the value with `??`, matching how the sibling `stack` and `grid`
+  renderers already read theirs. Omitting the key still applies the same defaults
+  (`gap: 2`, `padding: 4`); only an explicitly declared `0` changes, and no node in
+  this repository declared either key as `0` before this change.
+- 99bd015: Settle the two declared-but-unread keys on `ToggleGroupItem`: retire `icon`, wire
+  `disabled` (objectui#4632).
+  
+  `ToggleGroupItem` declared `icon?: string` and `disabled?: boolean` while the
+  `toggle-group` renderer read neither — it mapped items to value + aria-label +
+  label and dropped the rest. Nothing went red, which is what made it durable: an
+  author who declared either key got a correctly rendered group with the key
+  silently ignored, and the schema catalog (the corpus AI authoring tools retrieve
+  from) was teaching `icon` on all three items of
+  `components-disclosure-toggle-group/with-labels`.
+  
+  The two keys are settled in opposite directions, by measurement rather than by
+  symmetry:
+  
+  - **`icon` is retired** from the TypeScript interface, from the `ToggleGroupItemSchema`
+    Zod mirror, from that catalog entry and from the component's docs page. It had zero
+    measured pull — across the repo the single catalog entry was the only site authoring
+    it, no application code or example app declared it, and no renderer resolved it.
+  - **`disabled` is honored.** Item-level `disabled` is already live convention here —
+    `tabs`, `select`, `dropdown-menu`, `menubar` and `context-menu` all forward it, and
+    `toggle-group` was the lone outlier. The underlying Radix item supports it natively,
+    so the renderer forwarding the prop is the whole change; the synced `ui/toggle-group.tsx`
+    primitive is untouched.
+  
+  **Breaking for TypeScript authors of `icon` only** (marked `minor` per this repo's
+  version-alignment rule, which reserves `major` for following `@objectstack` across a
+  major). Runtime behaviour of an authored `icon` is unchanged — it rendered nothing
+  before and renders nothing now; what changes is that the contract no longer claims
+  otherwise, so the mistake surfaces at authoring time. Authored `disabled` changes from
+  silently ignored to actually disabling that one item.
+
+### Patch Changes
+
+- 460c4d0: The built-in form `input` branch now honours a declared ceiling in both authored spellings.
+  
+  The branch spread its leftover field props straight onto the element and never
+  read the declared ceiling, so one declaration produced two different outcomes.
+  Measured on `origin/main`, rendering the built-in branch (no `registerAllFields()`)
+  and dumping the element's `getAttributeNames()` / `getAttribute('maxlength')`:
+  
+  | declaration | `maxlength` on the element | effect |
+  |---|---|---|
+  | `maxLength: 50` | `"50"` | capped — but only by the coincidence that `maxLength` names a real DOM attribute |
+  | `max_length: 50` | `null`, plus a stray `max_length="50"` | no cap at all, and invalid HTML |
+  
+  Two distinct defects: the missing cap, and an inert attribute on the DOM that
+  reads like a working cap to whoever greps the file next.
+  
+  `max_length` is a live authoring spelling, not a fossil. The registered
+  `field:*` widgets have dual-read `maxLength ?? max_length` since framework#1878
+  §3, all three producers of a form field normalize it (`ObjectForm`,
+  `sectionFields`, `EmbeddableForm.applyDefaultMaxLengths`) and `@object-ui/types`
+  declares it on several field types. Every reader in the repo honoured it except
+  this branch — which is precisely the one serving a hand-written `FormSchema` fed
+  straight to the renderer, where no producer sits in between to normalize it and
+  the author is the producer. This is the same mechanism objectui#3439 resolved
+  for the built-in `textarea` branch.
+  
+  The legacy key is destructured off locally rather than added to the shared
+  `stripRendererOnlyProps` list: that helper feeds every branch
+  (`checkbox`/`switch`/`select`/`default` all share `domFieldProps`), so extending
+  it would change what reaches the DOM for widgets this change neither fixes nor
+  tests. The neighbouring `textarea` branch strips it the same local way.
+  
+  Scope, stated because the sibling card resolved more than this one: the ceiling
+  only. Whether a single-line input should also carry the visible `{n}/{max}`
+  counter and the announced limit that the `textarea` branch grew in
+  objectui#3439 is an independent design trade-off that does not follow from that
+  card's conclusion, and is deliberately left undecided here.
+- 0ae27f7: The form renderer's built-in `textarea` branch now honours a declared character cap the same way the registered `field:textarea` widget does.
+  
+  One `maxLength` declaration produced two experiences. The registered path has
+  shipped four things since objectui#3406/#3408/#3417 — the native cap, visible
+  `{n}/{max}` digits, a description reached through `aria-describedby` so the
+  limit is announced on focus, and a threshold-gated debounced near-limit notice.
+  The built-in branch — the path standalone and embedded hosts take, the ones that
+  call no `registerAllFields()` — shipped a subset of one of them.
+  
+  The accessibility half is the half that mattered: a screen-reader user on this
+  path learned the field's limit only as a validation error AFTER submitting. All
+  four affordances now render on both of the branch's surfaces (the inline control
+  and the fullscreen dialog), from the SAME `CharacterCount` component the widget
+  renders rather than a second copy of it.
+  
+  Also fixed, and wider than the visible gap: the branch never READ the cap, it
+  only spread its leftover field props onto the element. A camelCase `maxLength`
+  therefore worked by coincidence — it names a real DOM attribute — while the
+  legacy `max_length` spelling, which the registered widget and all three
+  producers of a form field have dual-read since framework#1878 §3, landed as a
+  stray inert `max_length="…"` attribute and capped nothing at all. The branch now
+  resolves both spellings and keeps the non-attribute spelling off the DOM.
+  
+  `CharacterCount` moved from `@object-ui/fields` to `@object-ui/components`, the
+  package both render paths may import, in the direction and for the reason
+  objectui#3398 measured for `FullscreenEditor`. It was internal to `fields` (never
+  exported from that package's barrel), so no published export changed; it is a
+  new export of `@object-ui/components`. Its copy moved with it onto the same
+  `fields.textarea.*` keys with byte-identical English defaults, so the ten locale
+  packs need no edit and provider-less rendering is unchanged.
+- 78c0f9a: The form's cascade clear now recognises object-form fields, so a narrowed option list no longer submits a stale value.
+  
+  `field:select` and `select` name the SAME field kind: the object-form path
+  (`mapFieldTypeToFormType`) emits the prefixed widget id, hand-written SDUI
+  schemas the bare one. The form host's cascade-clear effect (objectui#2284)
+  compared the RAW type string against the bare-name set, so every option field
+  coming from an OBJECT schema fell out of the effect entirely. Its controlling
+  field could change, its option list narrow, and the no-longer-offered value was
+  never dropped — the form submitted exactly the stale "china + california" pair
+  the effect exists to prevent. Only genuinely cascading fields were affected
+  (those carrying a `dependsOn` or a per-option `visibleWhen`); a plain picklist
+  has nothing to recompute either way.
+  
+  The comparison now normalizes the type before the lookup, which is what the
+  render path a few hundred lines below has done for `isOptionField` since
+  objectui#3231 — the two readers of "is this an option field?" no longer
+  disagree about what a `select` is. This half was the one missed then.
+  
+  Stated because it is a behavior change and not an equivalent refactor: the
+  object-form path gains cascade clearing for the FIRST time. A form whose stored
+  value is genuinely excluded by its chosen parent will now clear that value where
+  it previously kept it. The narrowing is bounded by the rules already in place
+  for the bare-name path, both of which the object path now inherits unchanged: a
+  GATED list (a declared `dependsOn` parent still empty) is treated as unknown
+  rather than invalid and never deletes anything (objectui#4247), and a field with
+  no `dependsOn` and no per-option predicate is never recomputed at all.
+- 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.
+- 2e82ab2: The config panel footer translates: `ConfigPanelRenderer`'s Save / Discard labels come from the locale pack.
+  
+  `saveLabel` and `discardLabel` carried the English literals `'Save'` and
+  `'Discard'` as parameter defaults, and no caller in the repo passes either prop,
+  so the sticky footer that appears the moment a config draft is dirty stayed
+  English in every locale — inside panels whose every other string had already
+  been routed through `t()`. The fix is in the renderer rather than per-caller:
+  the footer is the renderer's own chrome, so a caller-side fix would translate
+  one panel's footer and leave the next host's English.
+  
+  Both labels now resolve through `createSafeTranslation` — the mechanism this
+  package already uses for its built-in copy in `form.tsx`,
+  `fullscreen-editor.tsx`, `data-table.tsx` and friends. An explicitly passed
+  `saveLabel` / `discardLabel` still wins, unchanged and untranslated.
+  
+  `common.save` is reused rather than twinned: it already ships `Save` in all ten
+  packs and is what the console's other save buttons read. `common.discard` is
+  new, because the packs carried no shared spelling of the word — the three that
+  existed are each scoped to one surface (`form.discard`,
+  `console.settingsView.discard`, `console.objectView.discard`) and the last of
+  them diverges from the other two in zh/ko/fr. Its ten values are the majority
+  spelling, byte-identical to `form.discard` and `console.settingsView.discard`.
+  
+  Both English defaults are byte-identical to the literals they replace, so a
+  host that mounts no `I18nProvider` renders exactly what it did before.
+- 40d3a33: `div` 的废弃提示按 provenance 收窄:只对 **JSON 作者面**的节点报,不再对 `kind:'html'` tier 自己解析出的节点开火。
+  
+  html tier 的页面是一段受限 JSX/Tailwind 文本,由引擎自己的解析器编译(只解析、不执行),标签名原样映射成节点 —— 作者在那一层写下的盒子标签,是该 tier 词表里的一等成员,**没有别的拼法可迁移**。提示照旧对他们开火,给的还是 JSON 作者面的替代建议:一条谁都无法执行的提示不是废弃,是噪声;它同时意味着这个类型永远退不掉,因为引擎自己的编译器一直在产出它。
+  
+  判据是**来源**,由生产者确立:解析器给它产出的每个节点打一个 symbol 标记(`Symbol.for` 注册键),渲染器读这个标记。symbol 对 `JSON.stringify` / `Object.keys` / DOM 全部不可见 —— 所以它既不会落进被持久化的文档,也就无法被一份(手写或 AI 生成的)JSON 元数据复制回来给自己买到豁免;通过花括号属性夹带进来的 JSON **不打标记**,那部分本来就是手写的,建议对它成立。
+  
+  迁移建议一字未改,JSON 作者面照旧每次模块加载报一次;提示文案现在写明它针对哪一个作者面。
+- a1609a6: Console list filters: a `between` range is submitted only when both bounds are filled, and six operator labels stop rendering as raw i18n keys.
+  
+  Two defects in the list-view filter panel (objectstack#8815), both in the Console
+  render layer, with no workaround available downstream.
+  
+  **A half-filled range no longer refuses the whole view.** Picking a date column
+  and 「介于」 draws two inputs — that part landed in objectui#3958 — but typing
+  only one bound produced `["2024-01-01", ""]`, and both write paths read "is this
+  row filled in?" with one shape-blind predicate (`null` / `''` / empty array).
+  An array of length 2 passed it, so the empty bound went to the server, which
+  refuses the query outright (`400 INVALID_FILTER`): the list showed
+  「该视图的查询被拒绝」 and the filters the user had already applied stopped
+  applying too. The saved-view fold persisted the same half-range, so the refusal
+  came back on every later read of that view, for every user of it.
+  
+  The spec cannot intercept this — `ViewFilterRuleSchema` accepts
+  `["2024-01-01", ""]` because it counts the two slots rather than what is in
+  them, while refusing a scalar or a one-element array. Authoring validation is
+  therefore green on exactly the shape that fails at query time, which makes not
+  emitting it the producer's job. `@object-ui/components` now exports
+  `isFilterValueComplete(operator, value)` — arity-aware, so a `pair` row needs
+  both bounds — and the two consumers that had each kept a copy of the old
+  predicate (`plugin-list`'s `convertFilterGroupToAST`, `app-shell`'s
+  `foldFilterGroupToSpecRules`) read it instead. A half-filled range is now
+  dropped exactly as a half-typed `equals` row already was: no filter, rather than
+  a filter the server will reject. Bounds of `0` and `false` stay real bounds.
+  
+  **Six operator labels are translated in all ten locale packs.**
+  `startsWith`, `endsWith`, `isNull`, `isNotNull`, `exists` and `notExists` were
+  missing from every pack, so i18next resolved them to the raw key and the dropdown
+  showed `filterBuilder.operators.isNull` beside translated entries. The
+  component's own defaults table could not cover it: that table serves only the
+  no-provider path, and the Console mounts a provider. The report named four —
+  a `date` column's bucket offers the four nullness operators; a `text` column
+  showed all six.
+  
+  Because the label key is built dynamically (`t(\`filterBuilder.operators.${op}\`)`),
+  no existing gate could see the gap: the call-site checker classifies a template
+  key as `missing-prefix` and only asks whether the prefix resolves, and
+  cross-pack parity is satisfied when all ten packs are missing a key together.
+  A new parity test pins the packs against `FILTER_BUILDER_OPERATORS` in both
+  directions, so an operator added to the dropdown now fails loudly until every
+  pack labels it.
+- 53f23bc: `FilterBuilder` shows the falsy values a row actually holds — a boolean `false` and a number `0` are values, not empty boxes.
+  
+  The value controls asked `!condition.value` and `String(condition.value || "")`,
+  which folds `false` and `0` in with the rows nobody has filled in yet. Both rows
+  saved, persisted and filtered by their value the whole time; only the control
+  said otherwise:
+  
+  - a boolean column filtered `equals false` snapped back to the **Select value**
+    placeholder the moment the user clicked **False**, while the row carried
+    `value: false`;
+  - a number column filtered `equals 0` showed an empty box — and typing `0` into
+    one looked like the keystroke had never landed, because the row took the value
+    and the very next render blanked the input;
+  - a single-select whose option id is `0` showed the placeholder too, even though
+    the same control's multi-select branch already drew that option as checked.
+  
+  "No value" is now one judgement (`undefined` / `null` / `''`), read by every
+  value control and by the two helpers that already spelled it out correctly, so
+  "not picked yet" and "picked False" stay two distinguishable states rather than
+  trading places.
+  
+  The three keyed numeric paths — the token input's commit, a range bound, and the
+  single value input — no longer read with `parseFloat(raw) || 0`, which takes half
+  of `"42abc"` and turns `"acme"` into `0`: a filter the user never wrote. All
+  three now use the same strict reading a field switch uses, so this component
+  holds one answer to "is this string a number" instead of a strict one and a
+  lenient one. An unreadable entry becomes an unfilled value, except in the token
+  input, which declines the commit and leaves the text in the draft box to be
+  fixed. No behaviour a user can reach today changes: those inputs are
+  `<input type="number">`, which never hands a non-numeric string to the component
+  in the first place — this closes the drift, before a text box, a formula or a
+  paste path opens it.
+- c4533dc: `FilterBuilder` settles a row's operator when its **field** changes, instead of leaving an operator the new field's dropdown does not list.
+  
+  The operator buckets are per field type and they do not nest: a `select` column
+  offers `in` / `notIn`, a `text` column offers none of them, and only a date
+  column offers `between`. Changing a row's field wrote `{ field }` alone, so the
+  operator survived into a bucket that no longer contained it. Radix's
+  `SelectValue` matches against the `SelectItem`s actually mounted, so the
+  operator trigger rendered **blank** — while the row went on filtering by an
+  operator the user could neither see nor reach, and could only clear by deleting
+  the row.
+  
+  Changing the field is now one edit with the operator and the value's shape, the
+  same way objectui#3958 / PR #4762 made changing the operator one edit with the
+  value's shape:
+  
+  - an operator the new field's bucket still offers is **kept** — switching
+    `contains` from one text column to another must not silently become `equals`,
+    and the value it carries is left alone;
+  - one the new bucket cannot offer is replaced by that bucket's **first** entry,
+    and the row's `value` is then re-shaped for the family it lands in — a list
+    under `in` collapses to its first entry under `equals`, a `between` range
+    keeps its lower bound, an untouched `[]` becomes `''`.
+  
+  Membership is decided through the spec's own `normalizeFilterOperator`, the fold
+  `filterValueArity` already uses, so a stored rule that reaches the builder
+  spelled `not_in` is recognised as the operator the dropdown lists as `notIn` and
+  is not reset out from under the author. The fold is injective over this
+  builder's whole operator vocabulary, which is what makes comparing through it
+  safe; a test pins that, and fails the day an added operator would break it.
+- be60815: `FilterBuilder` settles a row's **value** when its field changes, instead of leaving a value the new column's input cannot show.
+  
+  objectui#4768 / PR #4779 settled the row's operator on a field switch and
+  re-shaped the value only when the operator's family changed — scalar to scalar
+  has no shape question, so what the user typed was carried through on purpose.
+  But the field's **type** changed too, and the value input is redrawn from it: a
+  browser renders a non-numeric value in `<input type="number">` as **blank**. A
+  `text` row filtered `equals "acme"`, pointed at a number column, showed an empty
+  box while the row went on carrying `"acme"` — `foldFilterGroupToSpecRules`
+  persisted it and the live grid queried `amount equals "acme"`. The same
+  invisible-value shape as objectui#4768, one column over.
+  
+  Changing the field is now one edit with the operator, the value's shape **and**
+  the value's type. Convertible values are carried, the rest clear to the family's
+  empty shape (scalar `''`, list `[]`, range `[]`):
+  
+  - `"42"` on a number column becomes the number `42`; `"acme"`, `"42abc"` and
+    `"1,000"` clear. The reading is deliberately stricter than `parseFloat`, which
+    would turn `"acme"` into `0` — a filter the user never wrote;
+  - `"true"` / `"false"` convert on a boolean column, and a boolean becomes
+    `"true"` / `"false"` on a text column, so the round trip closes; `1` and
+    `"yes"` are conventions rather than readings, and clear;
+  - date-like columns take only what their own input can render, plus the one
+    truncation that loses nothing it could have shown (`"2024-03-05T14:30"` →
+    `"2024-03-05"` on a date column). A bare date does **not** gain a midnight to
+    fit a `datetime` column: `equals 2024-03-05T00:00` is a filter that looks
+    answered and matches almost nothing;
+  - a value the new column can already hold is left alone — switching between two
+    text columns, or two numeric ones, still keeps what the user typed, and an
+    unfilled row stays unfilled.
+  
+  The convertibility judgement is defined once, next to `reshapeFilterValue`,
+  and `getInputType` now reads the same family table it does — so the type a value
+  is converted **to** and the input it is edited **in** cannot drift apart.
+- 37f6844: FilterConditionField can author the spec's `$icontains` — case-insensitive contains is reachable from the filter UI.
+  
+  `@objectstack/spec`'s `FieldOperatorsSchema` gained `$icontains` between
+  `17.0.0-rc.2` and `rc.5`, and every driver and evaluation face the platform
+  ships now executes it. `FilterConditionField` had no builder operator that could
+  author it, so the capability was unreachable from the sharing-rule criteria
+  builder and sat in that widget's parity test as an explicit `KNOWN_UNREACHABLE`
+  entry.
+  
+  The FilterBuilder gains a `containsCaseInsensitive` operator ("Contains (ignore
+  case)", translated in all ten locale packs). `condToMongo` emits
+  `{ field: { $icontains: value } }` and `kvToCondition` reads it back, so a saved
+  criteria reopens in the visual builder instead of falling into the raw-JSON
+  editor. Today's `contains` is unchanged and still emits the case-SENSITIVE
+  `$contains`; whether it should have been case-insensitive all along is a product
+  question that stays open, and stored filter views keep meaning what they meant.
+  
+  The fold is ASCII-only by contract — `café` does not match `CAFÉ`.
+  
+  The new operator is **opt-in per consumer**: `FilterBuilder` takes an
+  `extraOperators` prop, and only `FilterConditionField` passes it. The one
+  dropdown feeds three at-rest dialects and only the MongoDB-style criteria this
+  widget writes can carry the operator — the spec's `VIEW_FILTER_OPERATORS` (saved
+  views) and `VALID_AST_OPERATORS` (the live grid's filter AST) have no
+  case-insensitive contains, so offering it there would author a filter those
+  paths cannot execute. Every other FilterBuilder is unchanged.
+- 93de4f6: fix(components): FilterBuilder 的 lookup 列不再因 `options: []` 被拒掉远程搜索 (objectui#5031)
+  
+  `renderValueInput` 里那条远程 picker 分支的条件写的是 `!field?.options`,而 `[]`
+  是真值 —— 于是一个带 `referenceTo`、`options` 为空数组的 lookup 列**进不到**
+  `LookupValuePicker`,落进按 options 画的分支:标量算子得到一个候选数为 0 的
+  Select(没有搜索框),`in` / `notIn` 得到一个空的勾选框列表。用户在这一列上挑不出
+  任何**新**值,而同一列若 `options` 键干脆缺席反而能拿到完整的远程搜索。可达性不需要
+  任何异常状态:`@object-ui/fields` 的 `deriveFilterFields` 与 `plugin-view` 的
+  `deriveFieldOptions` 都把 `options` 原样透传,对象元数据里 picklist 值尚未到位时
+  就是这个形状。
+  
+  objectui#4874(PR #5030)已经为「静态选项集是否真的在位」建了唯一判据
+  `hasStaticOptionDomain(field)`(= `options` 是**非空数组**),并按「`options: []`
+  属于远程/未到位」这一侧裁定了值域行为。这条分支条件把同一个问题又答了一遍,两个答案
+  对 `options: []` 相反:值域侧当它是远程列(保值),控件侧当它是静态列(画空 Select)。
+  
+  按 2026-08-17 维护者裁定,分支条件改读同一个判据:
+  
+  - `referenceTo`(或 `type` 为 `user` / `owner`)且 `options` 为 `[]` 的 lookup 列
+    → `LookupValuePicker`,与 `options` 键缺席时完全一致:有搜索框、有候选、能选出
+    新值;多值算子走 picker 的多选形态,仍然回吐列表(objectui#3958)。
+  - `options` **非空**的列不受影响 —— 选项集就是它的全部值域,静态 Select 依旧。
+  - 分支的其余条件未动:没有 `referenceTo` 又不是 `user` / `owner` 的列(无处可搜)、
+    以及 `select` 这类非 lookup 列,路由与此前逐字相同。
+  
+  「值必须可见」这一条不变,只是由 picker 而不是临时 `SelectItem` 兑现。
+- 2b50261: `FilterBuilder` gives the set and range operators an input that matches the value shape the spec accepts, and stops minting the shape it refuses.
+  
+  Three independent paths let one filter row end up with `operator: 'in'` and a
+  SCALAR `value` — the shape `ViewFilterRuleSchema` refuses at save time since
+  objectstack#6227, and the shape the query path answered `400 INVALID_FILTER` on
+  before that (objectstack#5869):
+  
+  - Changing the operator dropdown wrote `{ operator }` alone, so the seed `''`
+    (or whatever the previous family had produced) survived the switch into
+    `in` / `not_in` / `between`. The operator and the shape of its value are one
+    edit, so they are now made together: switching families re-shapes the value —
+    a typed scalar becomes a one-element list, an empty one becomes `[]`, a range
+    keeps its first bound and leaves the second open, and a list collapsing to a
+    scalar keeps its first entry.
+  - A plain text or number column has no static `options`, so `in` fell through to
+    the single-value input and the user could only ever type a scalar into it.
+    Those columns now get a token input (type, Enter or comma commits, `×` or
+    Backspace removes) that always emits an array; `between` gets its two bounds
+    instead of one box. The lookup picker's no-DataSource fallback, which also
+    handed back a scalar while `multiple`, emits a list too.
+  - The multi-value families were decided from a local `["in", "notIn"]` literal,
+    already one spelling adrift: `notIn` is an alias and the canonical member is
+    `not_in`, so a stored view read back in canonical form got the single-value
+    input for a set operator. The families are now read from `@objectstack/spec`'s
+    exported `VIEW_FILTER_LIST_VALUE_OPERATORS` / `VIEW_FILTER_PAIR_VALUE_OPERATORS`
+    and folded through `normalizeFilterOperator`, so both spellings of one operator
+    get one answer and a family the spec widens is picked up without an edit here.
+  
+  `foldFilterGroupToSpecRules` is unchanged and needed no change: it normalizes the
+  operator and carries `value` through verbatim, so the shape that reaches storage
+  is the producer's to get right. An untouched `in` row arrives as `[]`, which the
+  fold's existing incomplete-row rule already drops.
+  
+  Four locale keys are added to all ten packs for the new inputs
+  (`filterBuilder.addValue` / `.removeValue` / `.rangeStart` / `.rangeEnd`).
+- 384f30d: fix(components): FilterBuilder 的值不再落在列的选项集之外还看不见 (objectui#4874)
+  
+  带 `options` 的 select/lookup 列，其值控件是一个受控的 Radix Select，而
+  `SelectValue` 只认已挂载的 `SelectItem`。于是文本列的 `equals "acme"` 指到
+  picklist 列（选项 `won` / `lost`）之后，值控件显示空，行里仍是
+  `value: "acme"` —— `foldFilterGroupToSpecRules` 照样持久化、实时网格照样拿
+  `stage equals "acme"` 去查。这是 #4768（operator）、#4781（值的类型）之后
+  「看不见的值」的第三张脸，成因是**值域**而不是类型：`select` / `lookup` 属于
+  文本族，`"acme"` 在类型上装得下，只是不在该列的选项集里。
+  
+  按 2026-08-17 维护者裁定（A + C 组合）：
+  
+  - **静态选项列**（`options` 是非空数组，选项集就是该列的全部值域）：切换 field
+    时做成员判定，不在选项集里的值清到 #4781 的那套空形 —— 标量 `''`、列表逐项
+    过滤后 `[]`。列表是**逐项**判定，用户写对的那几项不会被一颗坏项连坐。
+  - **远程/异步列**（lookup 远程搜索、`options` 缺席，或 `options: []` 尚未到位）：
+    值**保留**并**可见** —— 绝不因一份从未声称完整的本地选项集去删一个合法的
+    lookup id。Select 把该值挂成一个临时项（标签用值本身，与
+    `LookupValuePicker` 对没有 label 的 id 的做法一致），多值列表把它渲染成一行
+    已勾选、可取消的条目。
+  - 可见性是**无条件**的：无论值是切列带来的、从已存视图读回来的，还是选项集晚到
+    才对不上，控件都显示行里真正带着的东西。「行带值、控件空白」这个形态不再存在，
+    也不会为了显示去悄悄改写传入的 `value`。
+- 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.
+- 97fba31: The built-in form's `default` fallback branch now enforces a declared `max_length` ceiling.
+  
+  The last arm of the field switch — the one serving a `type` that is neither a
+  built-in field type nor resolvable from the registry — spread its props straight
+  onto the rendered `Input` and never read the declared ceiling. One declaration
+  therefore split into two outcomes depending on how it was spelled. Measured on
+  `main` after objectui#5201 landed:
+  
+      max_length: 50 -> attrs=["class","max_length",...]  maxlength=null
+      maxLength: 50  -> attrs=["class","maxlength",...]   maxlength="50"
+  
+  The camelCase spelling capped by coincidence — it happens to name a real DOM
+  attribute. The legacy `max_length` capped nothing at all and landed as a stray,
+  inert `max_length="50"` attribute: invalid HTML that reads like a working cap to
+  the next reader. Two independent defects, both now fixed.
+  
+  `max_length` is a live authoring spelling, not a fossil: the registered `field:*`
+  widgets have dual-read `maxLength ?? max_length` since framework#1878 §3, all
+  three producers of a form field normalize it (`ObjectForm`, `sectionFields`,
+  `EmbeddableForm.applyDefaultMaxLengths`), and `@object-ui/types` declares it on
+  several field types. This branch serves a hand-authored `FormSchema` handed
+  straight to the renderer, where there is no normalizing producer in between and
+  the author is the producer — so it was the one reader in the repo that dropped
+  the declaration.
+  
+  Same defect and same fix shape as objectui#5201 (the `input` arm) and
+  objectui#3439 (the `textarea` arm): the ceiling is resolved locally inside the
+  branch, and the legacy key is destructured off locally. The shared
+  renderer-only strip table is deliberately unchanged — it feeds the `checkbox`,
+  `switch` and `select` arms too, and widening it would alter branches this change
+  does not test.
+  
+  A field that declares no ceiling in either spelling renders no `maxlength`
+  attribute, exactly as before.
+- 3fbbea1: `container`: honour a declared `maxWidth: false` as "no maximum width"
+  
+  `ContainerSchema` has always declared `maxWidth?: … | false`, but the renderer
+  read it as `schema.maxWidth || 'xl'`, so `false` folded into the default and a
+  container asking for **no** constraint rendered `max-w-xl` (`max-width: 36rem`)
+  — the opposite of what it declared. The `false` arm of the union had no
+  reachable path from the day it was declared.
+  
+  `maxWidth` is now read with `??` (the spelling `stack` / `grid` always used, and
+  the one objectui#4003 gave this file's `padding` and `flex`'s `gap`), and `false`
+  emits an explicit **`max-w-none`** rather than simply omitting a class. The two
+  are not the same fact: an omitted class leaves an inherited max-width standing —
+  `@tailwindcss/typography`'s `.prose` sets `max-width: 65ch` — while `max-w-none`
+  cancels it. The registry `inputs` enum for `maxWidth` gains `false` to match the
+  type it lagged, so the designer and `sdui-parser`'s manifest gate stop reporting
+  a legal value as `invalid-enum`.
+  
+  No authored node in the repo declared `maxWidth: false`, so nothing that renders
+  today changes.
+- 616a2a5: The list filter builder no longer offers `Is set` / `Is not set`, which its query dialects cannot express.
+  
+  **User-visible before/after.** The operator dropdown in the list toolbar's
+  filter popover — and in the Studio view/tab/page filter inspectors, the dataset
+  inspector and the generic `filter` config field — loses two rows: **"Is set"**
+  and **"Is not set"**. The sharing-rule criteria builder (`FilterConditionField`)
+  keeps both, unchanged. `Is null` / `Is not null` and `Is empty` / `Is not empty`
+  are untouched everywhere and remain the way to filter on a missing value from
+  the list.
+  
+  Nothing that worked stops working. Every save path behind those two rows was
+  already broken, in three different ways depending on the surface:
+  
+  - **Live grid** — `ListView.mapOperator` had no row for either id, so its
+    `default:` arm returned the id verbatim and the query went out as
+    `['name', 'exists', 'x']`. `exists` is not a member of the spec's
+    `VALID_AST_OPERATORS`, so `isFilterAST()` rejects the shape: an unfiltered
+    read or a 400, never the filter the user asked for.
+  - **Save as view** — `foldFilterGroupToSpecRules` normalizes through the spec's
+    `normalizeFilterOperator`, which does not know the pair, and
+    `ViewFilterRuleSchema`'s enum then refuses the rule.
+  - **Dataset inspector** — `groupToCondition` has no row either and drops the
+    condition silently, so the filter simply never applied.
+  
+  **Why withheld rather than mapped.** Measured on `@objectstack/spec`
+  17.0.0-rc.6: neither `VIEW_FILTER_OPERATORS` nor `VALID_AST_OPERATORS` contains
+  an existence operator, under any spelling — both sets have zero members matching
+  `/exist/`. Only the MongoDB-style `FieldOperatorsSchema` criteria carries
+  `$exists`, and that is precisely the dialect `FilterConditionField` writes, so
+  the pair moves behind the existing `OPT_IN_OPERATORS` gate and that widget opts
+  in. Collapsing them onto `isNotNull` / `isNull` was rejected: the builder
+  already draws those as their own rows, the round trip is lossy (a saved
+  `exists` reads back as `isNotNull`), and the spec's own note records `$exists` =
+  has-value as still unsettled across drivers — `driver-memory`'s live mingo path
+  and `driver-mongodb` read key-presence.
+  
+  **The class is now closed by an assertion, not by discipline.** objectui's three
+  existing operator-parity guards all sweep spec vocabulary → objectui; none asked
+  whether an id the dropdown draws is an id the consumer can persist, which is the
+  direction that broke. `plugin-list`'s new
+  `list-offered-operator-expressible-parity.test.ts` forces the set the list
+  toolbar offers to **equal** the set its two dialects can express, in both
+  directions — so an unexpressible operator cannot be offered, and an operator
+  that becomes expressible upstream cannot stay needlessly withheld.
+- 4a0bd17: `page:accordion` now renders an item's `icon` in its panel trigger.
+  
+  `PageAccordionItem` (`packages/components/src/renderers/layout/containers.tsx`)
+  has always declared `icon?: string`, but `PageAccordionRenderer` never read it
+  — an authored icon reached the trigger and was silently dropped. The
+  `objectstack` spec's `PageAccordionProps.items[].icon` already treats this as
+  legitimate, undeprecated authorable surface (unlike the neighboring `value`
+  key, which the same schema explicitly flags as dead), so the renderer was the
+  side out of sync. It now renders the Lucide icon before the panel label,
+  following the same convention `page:tabs` items already use in this file.
+- b8b9af4: `page:header`'s `maxVisible` / `mobileMaxVisible` now honour the contract's value domain instead of a laxer renderer tolerance.
+  
+  Three authorities gave two answers for the same value (objectui#5006). Measured on
+  `ComponentPropsMap['page:header']` at `@objectstack/spec@17.0.0` — the member lives
+  on the `@objectstack/spec/ui` subpath, not the package root — both keys are a
+  POSITIVE SAFE INTEGER (`{format:'safeint'}` plus
+  `{check:'greater_than',value:0,inclusive:false}`). Spec rejects `0`, `-1`, `1.5`
+  and anything past `Number.MAX_SAFE_INTEGER`. objectui's manifest gate and
+  `sdui-parser`'s `checkType` said nothing about any of them, and the renderer's
+  `readMax` was looser still: it accepted `0` and floored fractions. So the loosest
+  of the three layers decided what shipped on screen, while `os validate` / `os build`
+  rejected the very same metadata outright.
+  
+  `readMax` now accepts only what the contract accepts. `Number.isSafeInteger(v) && v > 0`
+  is the exact translation of `safeint`, not an approximation — plain `Number.isInteger`
+  would admit `2**53 + 2` and `1e21`, which spec rejects.
+  
+  Behaviour change, stated because this NARROWS the renderer's accept set rather than
+  only fixing a fault: a contract-rejected value no longer takes effect and falls back
+  to the documented default (3 desktop / 1 mobile). Concretely, `maxVisible: 0` used to
+  render zero inline buttons and sweep every action into the overflow menu, and
+  `maxVisible: 1.5` used to be floored to `1`; both now render the default 3-inline
+  split. This is a narrowing *toward* an already-published contract — no in-tree
+  producer writes a rejected value, so nothing in the repo changes behaviour. Both
+  schema-level and `properties.*` spellings go through the one reader. `action:bar`'s
+  `maxVisible` is an unrelated reader with no `ComponentPropsMap` entry and is
+  deliberately untouched.
+  
+  `ComponentInput.type`'s doc comment now records the trade the ruling fixed in place
+  (maintainer, 2026-08-17): the coarse `number` arm plus `description` is the
+  publication face's expression ceiling today, and spec is the sole judge of values.
+  Giving `ComponentInput` real constraint slots, and binding `checkType` to spec, were
+  both deferred with a named reopen condition — a measured case of an author shipping
+  a spec-rejected value that objectui's silence let through.
+- aff10e2: A `field:`-prefixed `password` no longer renders as clear text when its widget is not registered
+  
+  On the built-in path (`@object-ui/fields` not registered) a form field spelled with the
+  `field:`-prefixed widget id resolved nothing and took the form renderer's `default` input
+  branch. That branch's native-input table was keyed on the raw `type`, so the prefixed
+  spelling missed it and rendered `type="text"` — and `mapFieldTypeToFormType` emits the
+  prefixed id for **every** object-derived form, so this was the normal path, not an edge
+  case. An object-derived `password` field therefore put the secret on screen in clear text,
+  and an object-derived `email` field lost its native keyboard and validation.
+  
+  The two spellings now get the answer each deserves:
+  
+  - **`field:password` refuses.** Reaching the unregistered default with a registry key
+    proves the app shipped without the widget it declares, so the value is not rendered at
+    all — no input, nothing carrying the secret in the DOM. In its place is an inline
+    `role="alert"` refusal naming the missing widget, plus a `console.error` that doubles as
+    the fix instruction. Masking alone would still invite a user to type a secret into a form
+    whose password widget is absent.
+  - **`field:email` renders the native email input**, because the native-input table is now
+    keyed on the declared type with the `field:` prefix stripped.
+  - **The bare `password` / `email` spellings are unchanged.** They claim no registered
+    widget, the default branch is their intended home, and their native input stays exactly
+    as it was.
+  
+  Deliberately narrow: only `password` refuses, and only under the `field:` namespace. Every
+  other unregistered `field:*` id renders the same text box it rendered before, and a
+  registered `field:password` widget still wins.
+- 7458a41: A readonly field's replacement display is now named by the field's label and described by its help text.
+  
+  A registered field widget's readonly branch renders a replacement display — a
+  `mailto:` anchor, a formatted span, a chip row, a preview table — and returns
+  before its DOM pass-through, so nothing the form renderer handed down reached an
+  element. Measured on a real form, one field per row, with `description` set: the
+  host control id (`…-form-item`) was on NO element in the document, so the visible
+  label's `for` pointed at nothing and the readonly surface had NO accessible name
+  at all, while the rendered help text had zero consumers. All 34 registered
+  non-group-labelled widget types read identically, including the four display-only
+  ones (`formula` / `summary` / `auto_number` / `vector`) whose whole widget is a
+  replacement display.
+  
+  The form renderer now wraps a readonly registered field widget's output in a
+  container carrying the host id, `role="group"`, `aria-labelledby` and
+  `aria-describedby`, and the label publishes an `id` in place of its `for` — the
+  same WAI-ARIA group pattern objectui#3961 / #3990 / #4005 established for the
+  seven composite widgets, applied at the host instead of in each widget. Not one
+  widget file changed: the mechanism lands once, so the current widgets and any
+  future third-party one are correct by construction, with no "remember to spread
+  the host props" step left to miss.
+  
+  The name is composite — the label's id AND the container's own — so the VALUE
+  stays in the accessible name (`Email user@example.com`, not just `Email`);
+  `group` is not a name-from-content role, and the value is usually the only thing
+  on screen. `aria-invalid` is deliberately dropped at this boundary: it is
+  control-channel state reporting what a user's own editing may do wrong, and a
+  readonly display cannot be edited (objectui#3291 / #3318 / #4005).
+  
+  Two consequences worth stating. Readonly registered fields gain one DOM layer,
+  which end-to-end selectors written against the widget root as a direct child of
+  the form item will see; the layer carries `data-slot="readonly-field-group"` as a
+  stable locator. And because that layer is a block box where several readonly
+  faces were inline, those rows now take the form's standard label-to-value
+  spacing, matching the editable state. Builtin types (`input` / `textarea` /
+  `checkbox` / `switch` / `select`), editable fields, group-labelled widgets and
+  fields rendered without a label are untouched, byte for byte.
+- 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.
+- 75444e3: The dependency-gate hint now enumerates its controlling fields with the locale's
+  own list separator, and reads identically whichever caller produced it.
+  
+  `lookup.selectFirst` and `fields.options.selectFirst` are deliberately one
+  wording, so a field gated on two or more parents says the same thing whether the
+  lookup widget or the form renderer rendered it. The sentence was shared but its
+  `{{fields}}` slot was not: each call site joined the controlling-field names
+  with its own hardcoded separator, and not even the same one — `', '` in
+  `LookupField`, `' / '` in the form renderer's `gatedHint` and in
+  `OptionsEmptyState`. A field gated on Account and Lead Source read
+  `Select Account, Lead Source first` from one side and
+  `Select Account / Lead Source first` from the other.
+  
+  A list separator is a property of the locale rather than of the code, so both
+  spellings were also wrong for the script under zh/ja (which enumerate with
+  U+3001) and under ar (U+060C). All three call sites now read
+  `validation.formInvalidJoiner` — the key already shipped in all ten packs for
+  the invalid-submit toast's field list, which is the same class of truncated-name
+  list. One key, every caller: a second, gate-specific key would have recreated
+  the divergence the shared sentence exists to prevent.
+  
+  No locale pack changes, and no change to what a provider-less render produces in
+  English: the `@object-ui/fields` defaults table declares the joiner as `', '`,
+  the `en` pack's value and the literal `LookupField` previously hardcoded.
+- 2d0bd16: Remove two unreachable renderer registrations, and fail the build on any new same-namespace duplicate.
+  
+  The component registry silently keeps the LAST registration for a given
+  `namespace:type` key. Two renderers on `main` were therefore dead code — they
+  compiled, type-checked, and never ran:
+  
+  - `renderers/data-display/table.tsx` (`SimpleTableRenderer`) lost `ui:table` to
+    `renderers/complex/table.tsx`, because `renderers/index.ts` imports
+    `./data-display` before `./complex`. It was the only table renderer that read
+    `bind`, which is why a `table` node with a two-row `bind` rendered a header and
+    zero rows (objectui#5125).
+  - The `kbd` entry in `renderers/basic/html-elements.tsx`'s `TAGS` loop lost
+    `ui:kbd` to `renderers/data-display/kbd.tsx` — despite that list's own comment
+    stating it excludes anything already registered.
+  
+  In both cases the renderer that serves the key today is the one kept, so no
+  reachable behaviour changes: `table` still renders inline `data` against
+  `columns` and still ignores `bind`, and `kbd` still renders one `<kbd>` per entry
+  in `keys`. Both readings are now pinned by tests.
+  
+  Whether `table` *should* read `bind` is deliberately left open — that would widen
+  the authorable key surface and is a product decision, not a consequence of
+  deleting dead code.
+  
+  The new gate (`renderers/__tests__/registration-uniqueness.test.tsx`) counts every
+  registration the production barrel makes and fails on any key registered twice
+  under one namespace, so a re-introduced duplicate is caught at CI rather than by
+  an accidental probe. It is a test rather than a runtime warning because
+  re-registering a key is a supported pattern for test stubs, and a warning there
+  would fire mostly on legitimate overrides.
+- dad51e5: fix(fields): deliver the host's a11y channels to `slider` and name `signature`
+  
+  `SliderField` and `SignatureField` forwarded nothing a form host handed them —
+  neither spread `toDomProps(props)` at all — so `<FormControl>`'s whole payload
+  landed on nothing. Measured on a real form, one required field per row, freshly
+  failed validation:
+  
+  ```
+  slider     ariaInvalidTrue=[]  labelFor=…-form-item -> DANGLING  descConsumers=0  ids=[]
+  signature  ariaInvalidTrue=[]  labelFor=…-form-item -> DANGLING  descConsumers=0  ids=[]
+  text       ariaInvalidTrue=[input]  labelFor -> input            descConsumers=1
+  ```
+  
+  `ids=[]` is the tell: no element in either row carried an id at all, so the
+  visible label pointed `for` at nothing, the rendered help text had zero
+  consumers, and a failed slider announced no error state.
+  
+  **`slider`** now delivers all three. Its focusable control is Radix's
+  `span[role="slider"]` thumb, which the synced `ui/slider.tsx` renders internally
+  and does not export, so the primitive grew a declared `thumbProps` — routed
+  through a new `lib/slider-thumb` and applied to the no-touch file as a declared
+  sync patch, so it survives regeneration. The split of which keys stay on Root
+  (`name`, `disabled`) is the one the `select` fix already settled.
+  
+  **`signature`** gets the name and the description on a `role="group"` container.
+  Its control state deliberately does not follow: the drawing surface is a
+  `<canvas>` with no keyboard path, and its only other element is disabled while
+  the pad is empty, so there is no element a control state could be read from.
+  
+  Both are now declared `labelling: 'group'` — a `<span>` and a `<canvas>` are not
+  labelable elements, so a host `for` could only dangle at them.
+- 1c9c342: The `span` deprecation notice is now reported once per page load, and only to the authoring surface it applies to.
+  
+  `SpanRenderer` was two rulings behind `div`. It still `console.warn`ed on **every
+  render**, and it still fired at nodes the `kind:'html'` tier's own parser had
+  emitted — the two defects that were ruled on for `div` in objectui#3965 (PR
+  #3998, which explicitly named `span` as the follow-up) and objectui#4000 (PR
+  #4916, which built the provenance mechanism). This is that follow-up
+  (objectui#4917); it copies the shape now in `basic/div.tsx` rather than inventing
+  a second one.
+  
+  - **Once per module load.** The notice is a property of the deprecated TYPE, not
+    of each node, so repeating it per render only buries the page's real console
+    errors. The deprecation still fires in dev builds, exactly once.
+  - **JSON-authored nodes only.** An author writing the plain inline tag in a
+    `kind:'html'` page gets a node this deprecated renderer serves — and was told
+    to migrate to `badge` / `text`, neither of which exists in that tier's
+    vocabulary, with nothing they could write to make it stop. Provenance is
+    established by the producer (the parser stamps what it emits, via
+    `isHtmlTierNode`), not guessed from the node's shape here.
+  - **The notice now names its surface**, so whoever reads the console can tell
+    which of their pages it is about. The migration guidance itself is unchanged:
+    this narrows WHO is told, it does not water down WHAT they are told.
+  
+  Order is load-bearing and pinned by tests: the html-tier exemption is checked
+  BEFORE the warn-once set is marked, so an html-tier node rendering first cannot
+  swallow the notice a JSON-authored node earns later on the same page.
+- 787c738: `span` renders the `value` its type and its published doc both declare, with child content winning when both are present.
+  
+  Two declared authoring surfaces named `value` the text content of a span and the
+  renderer read neither: `TextSpanSchema` declares `value?: string` commented
+  `Text content` (`packages/types/src/layout.ts`), and the published doc's Schema
+  block lists the same key with the same comment. Before objectui#5027 the
+  renderer read `body`, which no producer emits; #5027 moved it to the canonical
+  `children`. Neither version ever read `value`. So an author writing
+  `{ "type": "span", "value": "hello" }` — exactly what the type and the docs
+  instruct — got an empty element, with no warning and no diagnostic. Same failure
+  shape as #5027 (content silently dropped), one key over, and not catchable on
+  the type surface: `BaseSchema` carries an index signature, so no spelling on
+  this node is ever a TS error.
+  
+  Precedence, ruled 2026-08-17: `children` wins, `value` is the fallback. This is
+  the shape the sibling type in the same family already sets — `basic/text.tsx`
+  renders `schema.content || schema.value` — so `span` stops being the odd one out
+  rather than growing a rule of its own. "No child content" means an absent, empty
+  or empty-array `children`; that is exactly when `value` renders.
+  
+  Both declared faces stay as written. The fix makes them true instead of
+  retracting a key that has been published as authorable. `body` remains refused
+  (objectui#5027): it is declared nowhere for this type, whereas `value` is
+  declared twice — the question is whether a key was published as authorable, not
+  whether a tolerant read would be convenient.
+- 8396656: The `span` renderer renders its content again — it reads `children`, the key its own type declares and its producers emit.
+  
+  The renderer read `schema.body` and nothing else, and no producer on either of
+  its authoring surfaces emits that key. In a `kind:'html'` page the parser
+  assigns compiled child nodes to `children`
+  (`@object-ui/sdui-parser`'s `parse.ts`), so an author writing the plain inline
+  tag with text inside it got an EMPTY element back — the text was dropped with no
+  warning and no diagnostic, because the parser's tree validation does not inspect
+  child keys. A sibling paragraph on the same page rendered normally, which is what
+  made this read as anything but a compile failure. On the JSON surface the same
+  thing happened to anyone following the declaration: `TextSpanSchema` declares
+  `value` and `children`, so `children` is what an author writes, and `children` is
+  what rendered nothing.
+  
+  The canonical child key is `children` — what the type declares, what the parser
+  emits, and what the sibling `div` renderer already reads. `body` is deliberately
+  NOT accepted as a second spelling: a tolerant read would fossilize a second
+  de-facto contract for the one type whose declaration never named it
+  (Commandment #0.1), and a repo sweep found no page, example, catalog entry or
+  metadata document authoring it on this tag. A pin test states both halves — the
+  content renders, and a `body` alias renders nothing — so re-adding the lenient
+  read turns a test red rather than passing review.
+  
+  Reachability, stated plainly: the `span` type is deprecated for JSON-authored
+  pages, but it is permanent first-class vocabulary of the `kind:'html'` tier,
+  where the tag is compiled straight through and no other spelling exists. So the
+  authors who could do nothing about the deprecation were exactly the ones losing
+  their text.
+  
+  Not changed here, and named because the declaration still promises it: `value`
+  on this tag is declared by `TextSpanSchema` and read by nobody, as it was before
+  this fix. Making it render needs a ruling on precedence against `children`,
+  which belongs with the wider child-key drift (objectui#4631) rather than in a
+  rendering-path fix.
+- 138ab04: Fix a list filter that silently applied nothing when the first thing you picked was **Is null** or **Is not null**.
+  
+  Adding a filter seeds the row with no value, and changing the operator keeps it that way — which is correct for an operator that takes no value, since the panel draws no input for one. The live grid read that row as unfinished and dropped it: the filter appeared in the panel, the query went out without it, and every record came back with no error to explain it. Only `Is empty` / `Is not empty` were exempt; the builder renders six operators value-less.
+  
+  Which operators are complete without a value now has a single owner — `VALUELESS_FILTER_BUILDER_OPERATORS`, exported from `@object-ui/components` beside the code that decides it. The live grid and the saved-view fold both read it instead of keeping their own lists, so the two halves of one interaction can no longer disagree about whether a row is finished.
+- Updated dependencies [88085e3]
+- Updated dependencies [69251bf]
+- Updated dependencies [57e668f]
+- Updated dependencies [516663d]
+- Updated dependencies [41ac1b7]
+- Updated dependencies [1eaf0a1]
+- Updated dependencies [2533ec5]
+- Updated dependencies [bbe8b86]
+- Updated dependencies [8477be5]
+- Updated dependencies [279fb13]
+- Updated dependencies [2e82ab2]
+- Updated dependencies [ad07b65]
+- Updated dependencies [41f498b]
+- Updated dependencies [ef0d150]
+- Updated dependencies [f34226e]
+- Updated dependencies [564b605]
+- Updated dependencies [e1d4251]
+- Updated dependencies [40d3a33]
+- Updated dependencies [1184192]
+- Updated dependencies [a2a9747]
+- Updated dependencies [a1609a6]
+- Updated dependencies [37f6844]
+- Updated dependencies [2b50261]
+- Updated dependencies [ac600e5]
+- Updated dependencies [d374caf]
+- Updated dependencies [c1ef923]
+- Updated dependencies [af5e292]
+- Updated dependencies [7f96b10]
+- Updated dependencies [167ec42]
+- Updated dependencies [0046d8f]
+- Updated dependencies [f1d4748]
+- Updated dependencies [bea374e]
+- Updated dependencies [b1119ec]
+- Updated dependencies [9f23d2b]
+- Updated dependencies [578e025]
+- Updated dependencies [af025ee]
+- Updated dependencies [d109a4d]
+- Updated dependencies [598c89a]
+- Updated dependencies [b8b9af4]
+- Updated dependencies [31676be]
+- Updated dependencies [8c0d52e]
+- Updated dependencies [70a774b]
+- Updated dependencies [9ce096f]
+- Updated dependencies [e05db88]
+- Updated dependencies [ad13d63]
+- Updated dependencies [5ffcc14]
+- Updated dependencies [d971e51]
+- Updated dependencies [97abb24]
+- Updated dependencies [deb157a]
+- Updated dependencies [9c60144]
+- Updated dependencies [d2ce342]
+- Updated dependencies [9695da7]
+- Updated dependencies [58b8346]
+- Updated dependencies [a9e17b4]
+- Updated dependencies [b8ce7dc]
+- Updated dependencies [dbbd38a]
+- Updated dependencies [8871c14]
+- Updated dependencies [dfc6975]
+- Updated dependencies [3cf4de0]
+- Updated dependencies [c9dc811]
+- Updated dependencies [144ef9b]
+- Updated dependencies [a0b9e91]
+- Updated dependencies [99bd015]
+- Updated dependencies [21e4585]
+  - @object-ui/types@17.6.0
+  - @object-ui/i18n@17.6.0
+  - @object-ui/react@17.6.0
+  - @object-ui/core@17.6.0
+  - @object-ui/sdui-parser@17.6.0
+  - @object-ui/react-runtime@17.6.0
+
+## 17.5.0
+
+### Minor Changes
+
+- dc2aa3e: The action renderers publish the modern `UIActionSchema`, and every `forwardRef` renderer's props parameter is annotated so its declared types survive
+
+  **Breaking semantics (declared `minor` per the repo's version-alignment rule — objectui#4403 precedent — never `major`).** Six exported declarations in `@object-ui/components` change the action type they name, from the `@deprecated` legacy `ActionSchema` (`crud.ts`) to `UIActionSchema` (`ui-action.ts`):
+
+  - `ActionBarSchema.actions`, `ActionBarSchema.systemActions`
+  - `ActionMenuSchema.actions`
+  - `ActionGroupSchema.actions`
+  - `ActionButtonProps.schema`, `ActionIconProps.schema`
+
+  The two types are not interchangeable in either direction. `UIActionSchema` requires `name`, which legacy inherits as optional from `BaseSchema`; legacy pins `type: 'action'` where these renderers serve `'script' | 'url' | 'modal' | 'flow' | 'api'`; and only the modern type declares `locations`, `target`, `endpoint`, `bodyExtra`, `bodyShape` and a `variant` union containing `'primary'` — all of which the implementations already read. objectui#4417 measured four compiler errors proving the VALUES were modern while the DECLARATIONS said legacy; this moves the declarations to match, so the contract and the implementation finally agree.
+
+  No runtime behaviour changes, and no published surface is involved: none of the six declarations is re-exported from the package index, and the sweep found zero type-checked consumers outside each declaration's own file. Metadata that renders today renders identically — the renderers read the same keys through the same paths.
+
+  Separately, all fifteen `schema`-reading `forwardRef` renderers in the package now annotate their render function's first parameter directly, and carry the pass-through index signature on that annotation rather than on the `forwardRef` type argument. `forwardRef` routes its type argument through `PropsWithoutRef`, whose `Omit` collapses a props type carrying `[key: string]: any` down to the bare index signature — every declared property erased, silently, with `noImplicitAny` reporting clean because the `any` is supplied explicitly by the index signature. That is what hid the declaration/implementation drift above for as long as it lasted. Thirteen renderers recover a real declared type for `schema` (the two raw-tag factories keep `any`, which is what they genuinely declare), and a new structural guard, `forwardref-props-annotation.guard.test.ts`, fails on any future `forwardRef` that reintroduces either half of the trap.
+
+- cb13400: One fullscreen long-text editor, hoisted to the package both render paths may import
+
+  The "expand to a full-height dialog" interaction had two independent implementations. `FullscreenTextarea` lived inside the form renderer's built-in (unregistered) `textarea` branch in `@object-ui/components`; `FullscreenFieldEditor` lived in `@object-ui/fields` and served the registered `TextAreaField` / `RichTextField` widgets. They exist because ONE form-level promise — `ObjectFormSchema.mobile.fullscreenLongText`, projected onto every long-text field as `mobile_fullscreen` — is honoured on two render paths, and each path grew its own answer.
+
+  Two copies of a state machine drift, and these did, in both directions: objectui#3400 measured a read-only long-text field that was fully editable through the built-in branch's dialog (and "Done" wrote the edit into form state), objectui#3402 measured the same write-back hole for `disabled` on the registered path, and objectui#3393 (the dialog title needs the field label) and objectui#3272 (the copy needs i18n) each landed on one side before the other. Every repair was correct and none of them scaled.
+
+  `@object-ui/components` now exports `FullscreenEditor`, a single primitive owning the affordance, the dialog, the draft/commit state machine and the copy. The direction follows the measured import graph rather than fighting it: `@object-ui/fields` depends on `@object-ui/components`, and `components` declares no dependency on `fields` in either `dependencies` or `peerDependencies`, so the shared code can only live in `components`. `FullscreenFieldEditor` becomes a thin wrapper over it and keeps its name, its props and its test-id namespaces, so both hosts and their pins are unchanged.
+
+  The load-bearing part of the merge is that the primitive DEFINES `readOnly` and `disabled` instead of inheriting them by accident. Neither copy defined both: the built-in one grew them under objectui#3400, while the fields one declared only `disabled` and was shielded from `readonly` by its hosts' early return — a single implementation cannot be shielded by one caller's control flow. So both are answered once, and both call paths inherit the same answers: `readOnly` renders no affordance at all (it means "shown plainly", so advertising an expand button the user cannot use is worse than showing none), `disabled` leaves an inert one (it means "not interactive, muted"). Neither relies on the toggle alone, because `disabled` also carries the form's `isSubmitting` and can flip to true while the dialog is already open — so opening refuses independently of the attribute, the injected editor is told, "Done" is disabled, and `onCommit` is gated as the single point where a value leaves for host state.
+
+  No copy changed and no locale pack needed an edit: the primitive consumes the same `form.fullscreen.*` / `common.cancel` keys both copies already read, through `createSafeTranslation` with English defaults byte-identical to the literals, so provider-less hosts render exactly what they did. The now-unread `form.fullscreen.*` defaults are dropped from `useFieldTranslation`, where they would have re-created in the defaults map precisely the duplication this change removes from the components.
+
+  `toggleClassName` is not carried into the new primitive. It was declared on `FullscreenFieldEditorProps` and written by nobody — zero producers repo-wide — and `FullscreenFieldEditor` is not exported from the `@object-ui/fields` barrel, so no consumer outside the package could ever have set it. Minting it as part of a NEW public export in `@object-ui/components` would have published a prop with no producer, the shape objectui#3232/#3233 keeps deleting.
+
+- 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.
+
+- 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.
+
+- bb68488: `element:record_picker` publishes `sort`, `limit` and `emptyText` as authoring
+  inputs (objectui#4167).
+
+  All three were already READ by the renderer and declared by the contract — the
+  renderer has passed `sort` into `$orderby` and `limit` into `$top` since the
+  block existed, and `emptyText` decides the no-rows message — but none of them
+  appeared in `inputs`, so every layer that reads a manifest said they did not
+  exist. `packages/components/src/renderers/layout/page.tsx` builds the JSX-page
+  compiler's prop whitelist from `getKnownTypes()` plus these `inputs`, so writing
+  any of the three on a JSX page drew an `unknown-prop` warning from
+  `sdui-parser/src/validate.ts` on a key the renderer then went on to honour.
+
+  That is objectui#3407's shape — honoured, undiscoverable — and this is the same
+  repair objectui#3808 made for `record:details.hideFields` and objectui#3830 made
+  for `element:record_picker.filter`. `@objectstack/spec` 17.0.0-rc.6 is what made
+  it actionable: objectstack#5775 declared the three upstream, and the reverse
+  direction of the console's registry parity gate went red demanding them the
+  moment the pin moved — a red the previous exemption had predicted in writing and
+  called "correct and wanted".
+
+  Each description documents the renderer's real behaviour rather than restating
+  the schema, because that is the half an author cannot read off the contract:
+
+  - **`sort`** and **`limit`** are both overridden OUTRIGHT by a node-level
+    `dataSource` binding (`dataSource.sort ?? sort`), not merged with it — so a
+    node that carries a `dataSource` silently ignores them.
+  - **`limit`** defaults to 50 in the renderer, not in the schema, and a record
+    outside the limit cannot be picked at all with nothing in the control to say
+    more exist.
+  - **`emptyText`** is published as `string` against a contract of
+    `string | Record< string, string >`: rc.6 widened it to `I18nLabel`, and this
+    renderer passes the value straight into a text node with no locale resolution,
+    so only the plain-string form renders today. The description says so rather
+    than advertising a shape the renderer drops — the narrowed-type treatment
+    objectui#3832 describes, with the render-site gap tracked in objectui#4163.
+
+  The console's `registry-inputs-spec-parity` suite also drops all twelve of its
+  off-spec exemptions, which rc.6 obsoleted at once (objectstack#6776 declared
+  `page:header.recordChrome` / `showStar` / `showCopyId`, `page:accordion.variant`
+  and `page:tabs.tabStyle`; objectstack#5775 declared the `element:record_picker`
+  trio and `children` on the four page containers). The forward direction of that
+  gate now runs with no cover of any kind.
+
+- 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
+
+- ceccdcf: Action confirm dialogs and success toasts now honour the bundle's translated
+  `confirmText` / `successMessage`, not just `label` (objectui#4265).
+
+  A TranslationBundle entry for an action carries three keys under one
+  `_actions.<name>` node — `label`, `confirmText`, `successMessage` — and
+  `useObjectLabel()` has always exposed a resolver for each. What had drifted was
+  the call sites: `page:header` (authored record pages), `record:quick_actions`
+  and the related-list row menu resolved the button `label` only and dispatched
+  the authored `confirmText` / `successMessage` untouched. One bundle entry met
+  two fates: the button rendered the translation, the confirm dialog rendered the
+  authored English.
+
+  All action-rendering surfaces now go through one resolver,
+  `useActionTextLocalizer()` (new, exported from `@object-ui/react`), which
+  applies the existing `actionLabel` / `actionConfirm` / `actionSuccess`
+  resolvers over the three keys together. Fallback is unchanged: with no bundle
+  entry — or an entry lacking a key — the authored text renders. A bundle cannot
+  introduce a `confirmText` or `successMessage` the metadata never declared.
+
+- d6e5124: An action rendered in the overflow menu, as an icon or inside a group now reaches the runner carrying the same authored keys as the same action rendered inline — `action:menu`, `action:icon` and `action:group` forward `label` and `description`, and the two group/icon surfaces also forward `resultDialog`.
+
+  Every action renderer hands the `ActionRunner` an explicit key WHITELIST rather than the action itself. That is deliberate — a key no renderer honours must not look wired — but the whitelists had drifted, and which renderer a given action gets is decided by `action:bar`'s `maxVisible` split (3 on desktop, 1 on mobile) and by `systemActions`, which are always in the overflow menu. So the same declared action behaved differently depending on the viewport.
+
+  `label` and `description` are what the console's param-collection handler titles its dialog from (`title: action?.label || action?.title`, `description: actionDescription(…, action?.description)`). Dropped, an action with declared `params` opened a dialog titled "Action parameters" while the SAME declaration rendered inline named itself "Create Environment". `resultDialog` is the one-shot reveal spec (a fresh 2FA code, a newly minted OAuth secret): dropped, the runner falls back to the success toast and the value the user was meant to copy is gone — the objectui#3646 defect, still live on two of the four declared surfaces.
+
+  `undoable` and `recordIdField` are deliberately NOT added. Both are read only under a `rowRecord` guard, and `rowRecord` is `params._rowRecord`, written exclusively by the spread-based hosts (`DeclaredActionsBar`, `RelatedRecordActionsBridge`, `ObjectGrid`, `page:header`), none of which dispatch through these renderers. They are unreachable on this path rather than dropped — `action:button` forwards them here inertly — so forwarding them would have added a second inert copy instead of restoring an affordance.
+
+  A new repo gate, `pnpm check:action-forward-parity`, now derives each surface's owed key set (`authorable ∩ runtime-read − retired`) from the spec's own schemas and the consumers' ASTs and fails when a renderer drops one, so the seventh instance of this class fails on the pull request that introduces it rather than shipping green.
+
+- debad27: An `autoTrigger` action that spills past `action:bar`'s `maxVisible` now still runs — `action:menu` consumes the flag instead of dropping it.
+
+  `autoTrigger` is the client-composed "run this action as soon as a renderer receives it" flag behind deep links like the welcome page's "Create your environment" CTA (#844). It was consumed only by `action:button`. `action:bar` splits its post-gate list at `maxVisible` (3 on desktop, 1 on mobile) and hands the tail to `action:menu`, which had no `autoTrigger` handling at all — so an auto-triggered action that happened to sort past that threshold was rendered as an ordinary "More" menu entry and never ran, while the caller had already spent the one-shot signal it stood for. The `?runAction=create_environment` deep link is consumed by stripping it from the URL, so the measured end state was `urlParam=null execute=0`: no dialog, and no URL left to retry from. Which actions lost their auto-trigger was partly a function of viewport width, since `maxVisible` drops to 1 on mobile, and `systemActions` — always in the overflow menu, whatever the viewport — could never fire one at all.
+
+  The flag's contract is now stated and enforced as "execute once on mount by whichever renderer receives the action". `action:menu` consumes it by EXECUTING, through the same path a click on that item takes; it does not open the dropdown, so a transport flag never moves what the user sees. Consumption happens where the action provably arrives — the menu renderer receiving it — not in the menu items, which Radix mounts only once the dropdown opens and which would therefore have waited on the very click the flag exists to avoid.
+
+  Once-ness has one implementation (`renderers/action/auto-trigger.ts`), now shared by both renderers rather than written twice: a guard ref per rendered action, so re-renders never re-fire it and a flag that flips true later still fires exactly once. Container visibility still governs mounting — a hidden `action:bar` or `action:menu` renders no children and auto-triggers nothing — while the action's own `visible` gate does not suppress the trigger, matching `action:button`'s long-standing behaviour so that a deep link cannot depend on where the bar happened to put the action.
+
+  The `action:bar` split, the inline `action:button` path and #4166's arming pins are unchanged.
+
+- f650253: `BaseSchema.ariaLabel` declares the keyed i18n vocabulary the renderer actually
+  resolves, `.disabled` accepts the predicate string it actually evaluates, and the
+  keyed shape finally has a name (objectui#4581)
+
+  Three slots on one base type had drifted from what the renderer does with them.
+  PR #4593 fixed `visible` and measured the rest; these are the rest.
+
+  `ariaLabel` was `string`, but `SchemaRenderer.tsx:111` resolves it with
+  `resolveKeyedI18nLabel`, whose input is the KEYED form
+  `{ key, defaultValue?, params? }` — a reference into a translation bundle. It is
+  now `string | KeyedI18nLabel`, and `KeyedI18nLabel` is a new exported type in
+  `@object-ui/types` rather than a fourth inline copy of one object literal: the
+  three that existed (`@object-ui/react`'s resolver, `@object-ui/layout`'s
+  `resolveLabel`, `@object-ui/app-shell`'s `t`-taking twin) were verified identical
+  in their object half first, and two of them now import the name.
+
+  The vocabulary matters more than the widening. `#4581` originally asked for
+  `string | I18nLabel`, and that spelling was withdrawn as measured-wrong: the
+  spec's `I18nLabel` is the INLINE LOCALE MAP (`string | Record<string, string>`),
+  a different vocabulary resolved against a BCP-47 locale by a different function
+  of a confusingly similar name. Under it the shipped keyed fixture type-checked
+  only vacuously — as a locale map whose "locales" are named `key` and
+  `defaultValue` — the same label carrying `params` was rejected outright, and a
+  genuine `{ en: 'Owner' }` compiled while rendering an EMPTY `aria-label`. Naming
+  the keyed shape is the declaration half of the fix objectui#4167 started on the
+  naming side; `@object-ui/app-shell`'s copy keeps its inline spelling for now
+  because an open PR has a pending change to that file, and the comment there says
+  so.
+
+  `disabled` was `boolean` on a key the renderer never reads as one:
+  `SchemaRenderer.tsx:466` evaluates it through the same `evaluateCondition` as
+  `visible`, and a `disabledOn?: string` sibling exists for the same reason. It is
+  now `boolean | string`. The asymmetry with `visible` was accidental rather than
+  deliberate.
+
+  Both are widenings on authored-input-dominant properties: authors gain a
+  spelling, nothing that type-checked before stops doing so, and readers already
+  coped with `any` through `BaseSchema`'s index signature. Three test fixtures that
+  had been casting past these declarations with `as unknown as BaseSchema` state
+  their values directly now, and the declared unions are pinned invariantly so
+  neither a missing widening nor an overshoot to `any` can pass unnoticed.
+
+  Declaring the vocabulary honestly also surfaced a real one: the `toggle`
+  renderer writes `aria-label` itself instead of going through SchemaRenderer's
+  resolver, and it forwarded the raw value. Invoked directly it emitted
+  `aria-label="[object Object]"` for a keyed label — announced verbatim by a
+  screen reader. It resolves now. Through `SchemaRenderer` the bug was invisible,
+  because SchemaRenderer injects its own resolved `aria-label` afterwards; a
+  downstream type-check sweep found it, not a test.
+
+  `BaseSchema.label` and `.description` are deliberately unchanged and pinned that
+  way. They receive the spec's inline `I18nLabel` from the view bridges, which is a
+  real defect, but resolving it belongs at the spec-to-schema boundary rather than
+  in this declaration — and that work is still blocked on a design question about
+  where the display locale enters, so it is not in this release.
+
+- d0c3b26: Every plain `<button>` now declares its `type`. HTML defaults an untyped button to
+  `type="submit"`, so any of these buttons would submit the form it was composed into
+  instead of running its own handler — a real risk for renderers (`drawer`, `tree-view`,
+  `navigation-overlay`) whose placement inside a form is a JSON metadata decision. 114
+  sites were converted to `type="button"`; no site was a genuine submit button, and the
+  DOM is otherwise unchanged.
+
+  The defect class is now closed mechanically by a new `object-ui/button-has-type` ESLint
+  rule (error), so the next untyped button fails CI at write time rather than being found
+  by a fourth audit round (objectui#4045, closing the objectui#3344 family).
+
+- 4dadf0d: `@object-ui/components` compiles under `noImplicitAny` — the workspace's last strict-relaxing package
+
+  `packages/components/tsconfig.json` carried `"noImplicitAny": false`, the only place in the workspace that relaxed a `strict` sub-flag, under a comment that explained the neighbouring `rootDir` removal rather than the flag itself. `tsconfig.test.json` mirrored the one flag deliberately, so that a test project could not become the compiler of record for a source strictness decision the build config owns. Both now simply inherit `strict: true` from the root config, and the mirror's reasoning is rewritten to record why the mirror is gone rather than deleted silently.
+
+  Turning the flag on reported 26 implicitly-`any` sites in five renderer source files and 2 in the package's own tests, all of which now have real types. Nothing about the runtime changed; every one of the package's 1077 tests passes untouched.
+
+  Two of those signatures were typed by measurement rather than by preference, and both are worth recording:
+
+  The ten `sidebar.tsx` entry points follow the convention the package's other registered renderers already use — an inline `{ schema: <X>Schema; [key: string]: any }` annotation naming the registered component's own schema type (21 occurrences across the renderer tree, against zero uses of `ComponentRendererProps`). Only `'sidebar'` itself has a schema type in the registry map; the other ten registrations are sidebar _parts_ with none of their own, so they take `BaseSchema`, the type every registered node satisfies. Annotating them `SidebarSchema` would have asserted `type: 'sidebar'` on a node whose type is `'sidebar-header'`.
+
+  The action renderers' callbacks are typed from `UIActionSchema`, not the legacy `ActionSchema` those three files import for their declarations. The legacy interface (`crud.ts`, already `@deprecated`) has no `locations`, so the shared `actionRendersAt` placement predicate rejects it outright; its `variant` union has no `'primary'`, the value the objectui#2339 ordering tie-break compares against; and its `type` is the literal `'action'`, while the actions actually flowing through these renderers carry `'form' | 'script' | 'url' | 'flow' | 'api' | 'modal'`. `action:bar`'s own documented example is a `UIActionSchema`. None of this was checkable before, because the props type never reached the callbacks at all: `forwardRef` routes props through `PropsWithoutRef`, whose `Omit` collapses a props type carrying `[key: string]: any` down to the bare index signature, so `schema` arrived as `any` and every callback under it inferred `any` too. The fix annotates each action list once where it enters and lets the `filter`/`some`/`map` chains below infer.
+
+  Graded `patch`: no declaration this package publishes changes shape. The three action schema interfaces and the leaf components whose props moved to `UIActionSchema` are internal — none is re-exported from `src/index.ts`. The `actions?: ActionSchema[]` keys those interfaces still declare remain on the legacy type; reconciling that declaration with the type the implementation actually receives reaches roughly 46 sites across 12 files and is filed separately.
+
+- ae10a01: Console chrome reaches the bundle — the list switcher, the aggregate footer, the dialog a11y fallbacks and the whole Settings namespace screen stop being English on non-English consoles
+
+  Six strings on the two screens a user looks at most were hardcoded English literals rather than bundle lookups, so they stayed English on every non-English console with nothing an app could author to change them. They are not object, field, view or action labels — no key in `TranslationData` reaches them — while the console's own bundle already ships zh-CN, ja-JP, es-ES, de, fr, pt, ru, ko and ar and translates hundreds of neighbouring strings. Omissions from an otherwise complete bundle, not a missing capability.
+
+  **Two of the six needed no new keys at all, which is the more interesting half.** The list-view mode switcher named its nine visualizations from a private `VIEW_LABELS` table while `console.objectView.viewType*` — the same nine words — had been resolved through the bundle by the create-view picker for months; the switcher now reads those keys, so the picker's 「画廊」 and the switcher's 「画廊」 cannot drift apart in nine languages. The create/edit dialog's close button is the remainder of a fix that already landed: objectstack#5505 routed the `sr-only` close label through `common.close` for the two Shadcn-synced primitives, but `MobileDialogContent` is a hand-written wrapper outside that regeneration zone with its own close button, and it is exactly what `ModalForm` renders — so the dialog the report measured was the one place still announcing "Close" in English.
+
+  The aggregate footer is the one the original report singled out: the **number** was already locale-formatted and the **prefix** was a hardcoded `Avg: ` / `Sum: `. All eleven aggregation kinds now take their prefix from `grid.summary.*`, and the label/value join is its own key rather than a `': '` baked into the renderer — the separator is translatable content, so zh sets a fullwidth colon and fr the French space-before-colon. The numbers are untouched. The form dialog's `sr-only` description fallback joins the packs too; it is clipped, not visible, so the only way an app could displace it was to author a `description` and thereby put a visible subtitle on every dialog.
+
+  **The Settings namespace screen converts as one unit.** `SettingsView` routed zero framing copy through i18n — save/failure toasts, the env-lock and crypto refusals, the load-error card, the empty-route state, the navigation buttons, the unsaved-changes save bar — while its immediate sibling `SettingsHub`, in the same directory, resolved everything through `t('console.settingsHub.*')`. A zh-CN admin read correctly translated field labels sitting inside an English save bar, because `useSettingsLabel` translates a namespace's authored content but reaches none of the chrome around it. All of it now resolves through a `console.settingsView.*` namespace placed beside the hub's, including the crypto-refusal strings that objectui#4579 deliberately left in English rather than leave one translated string among a dozen literals.
+
+  The save-bar counter was an English plural rule executing in every locale (`change` plus an `s` when the count exceeds one). It is now a real i18next plural family — base key plus `_one` and `_other` in all ten packs — not the `(s)` spelling translated nine ways. The base key is the load-bearing part: i18next asks `Intl.PluralRules` for the one suffix a language needs and, finding no such slot, falls back to English, so without it Russian would read English at counts 2-20 and Arabic at 2-99. Russian and Arabic take the "noun: {count}" form their packs already use for this exact reason, and the counter is verified rendering in-language at 1, 2 and 5.
+
+  The Beta badge reuses the hub's existing key rather than minting a twin, and the refusal messages interpolate their subject through the bundle instead of concatenating a translated word onto an English prefix.
+
+- 4b70d28: data-table row menu — the built-in Edit/Delete predicate parameters are derived from the authoring type, not hand-restated
+
+  One authoring shape (`DataTableSchema.rowEditPredicates` / `rowDeletePredicates`, objectui#2614) had grown four separate declarations in `renderers/complex/data-table.tsx`: the shared `isBuiltinRowActionVisible` gate and `planDataTableRowMenu` each hand-wrote `{ visibleWhen?: unknown }`, and the row-menu ITEM component hand-wrote the full `{ visibleWhen?: unknown; disabledWhen?: unknown }` pair. Nothing tied any of them to the type whose values they receive, so a rename in `@object-ui/types` would have left all four compiling against a shape that no longer existed — the objectui#3009 hand-copy family, in miniature.
+
+  Each one now derives. The planner keeps its deliberate visibility-only subset, `Pick`ed from the very key its caller passes (`Pick<NonNullable<DataTableSchema['rowEditPredicates']>, 'visibleWhen'>` and the delete twin), so the signature still tells the truth about what the function reads while becoming structurally unable to drift from what it subsets. The two consumers that serve both built-ins share one derived alias taken from the union of the twins, so they may only read keys both schema keys declare. Measured: with `visibleWhen` renamed in `@object-ui/types`, the previous hand-written declarations still type-check clean, the derived ones fail to compile.
+
+  No behavior change — no runtime code was touched, and the package's suite passes unchanged. Alongside it, the "a disabled item still counts toward the menu" rule gains the pin it never had where a user meets it: a row whose only action is `disabledWhen`-gated keeps its "⋮" trigger, and that trigger opens the item, present and `aria-disabled`. The two halves of that rule live in different functions, and each half's own test stayed green while the other regressed.
+
+- b4d3c22: `element:button`'s action forward is excess-property checked again — a misspelled key on that payload is now a compile error, not silence
+
+  The payload `element:button` hands to `execute(…)` closed with `as any`. An assertion asks only for comparability, so it switched TypeScript's excess-property (freshness) check off for the whole literal: all sixteen keys the renderer forwards rode unchecked, and `ActionDef` being a closed type (objectui#4046) bought this surface nothing. A typo added to that list — `refreshAftr`, `confirmTxt` — would have compiled, published, and reached a runner that silently does nothing, which is the objectstack#2169 "Mark Done does nothing" shape the closed type exists to prevent.
+
+  The exemption that recorded this assumed the cast was load-bearing, on the reasoning that `element:button` receives a bare `action?: Record< string, any >` prop rather than a typed action, so removing the cast would be a contract change. Measured on TypeScript 6.0.3, that was wrong on the point that mattered: dropping the cast type-checks clean as-is, because every key the literal writes is already declared on `ActionDef`. The prop's type is a separate question and is deliberately untouched here — the forward literal never needed the cast to compile.
+
+  Two literals needed it, not one. The `execute(…)` argument is contextually typed by `execute(action: ActionDef)`, so dropping the cast is enough for the explicit keys. The `paramsPayload` binding spread into it is the second, easily-missed half: a spread source's own keys are not checked _through_ the spread, so `{ actionParams }` / `{ params }` could still invent a key while the payload around them was checked. That binding is now annotated `ActionDef` too.
+
+  Runtime behaviour is unchanged — the object reaching `execute` is identical, key order included, and the emitted `.d.ts` does not move. What changes is that the compiler now rejects an invented key here, verified in both directions: the same probe key produces `TS2353` after this change and no diagnostic at all before it.
+
+  With this surface fixed, `check:action-forward-parity` has no payloads exempt from its freshness rule: all five action-forwarding renderers write into a literal the compiler checks, and the gate's ratchet removed the exemption entry itself as designed.
+
+- bc64bfe: A dependency-gated option list no longer deletes the field's stored value on mount
+
+  The four fixed-option widgets (`SelectField`, `MultiSelectField`, `CheckboxesField`, `RadioField`) end their cascade resolution with a "drop what is no longer offered" effect, and the form renderer runs an equivalent clear of its own over every option field. Both read `resolveCascadingOptions`, which returns an **empty** offered set whenever the list is _gated_ — a declared `dependsOn` parent is still empty. Nothing the field held could be "still offered" against an empty set, so both paths wrote the field empty **on mount, with no interaction**, while the control rendered "Select Country first" beside it: it told the user it could not offer anything, and deleted what they had.
+
+  Gated means **unknown**, not invalid. The cascade clear exists (ADR-0058) so a user-driven parent change prunes a now-invalid child; a withheld list on mount is missing information — the record simply arrived with its controlling field empty (a later-cleared parent, an import, a partially-migrated row) — and that is not a reason to destroy stored data. Both clears now skip while gated, reading the resolver's own `gated` flag rather than re-deriving it from an empty offered set, which would collide with the distinct never-configured case guarded separately in objectui#4220.
+
+  Convergence stays exactly where it belongs: once the parent **is** chosen and the resolved set genuinely excludes the stored value, the prune applies unchanged — including at the moment the gate lifts, so picking a parent whose list does not contain the old value still clears it on that transition. The three states are pinned apart (never-configured / gated / resolved-and-excludes) across all four widgets and the form host, so a future edit cannot collapse them back into one empty-set test.
+
+  Reachable on every host that mounts these widgets with a live record: the form renderer, the grid's inline cell editor, and the detail page's inline editor — where each `onChange` went straight into the record draft the save bar commits.
+
+- 3e19fe7: i18n copy: one ellipsis glyph across the ten packs, `usted` in the es draft-preview empty state, and a pt sentence that stops contracting `de` onto its own hole
+
+  Three locale-copy defects that no gate could see, because all three are _value_ defects on keys whose names, placeholders and key sets were already correct.
+
+  **One ellipsis (objectui#3878).** `en` ended 33 values with three ASCII full stops (`Loading...`, `Ask anything...`) and 110 with the typographic ellipsis `…`, and the nine translation packs had copied `en` value by value — so a user could read both glyphs on one screen: `common.loading` beside `dashboard.loading`, `console.ai.askAnything` beside its own panel's siblings. All ten packs now spell it `…` (U+2026), per the maintainer-authorized consistency pass registered on objectstack#6015. 312 pack values changed: 34 in `en` (the 33 trailing plus the one mid-sentence `collaboration.commentPlaceholder`) and 278 across the nine. Eleven inline `defaultValue` call sites were re-synchronised with the new `en` text, which `scripts/check-i18n-call-site-keys.mjs` requires byte-for-byte.
+
+  The convention is now pinned so the split cannot regrow: `packages/i18n/src/__tests__/ellipsis-glyph-3878.test.ts` fails, by key name, on any value in any of the ten packs that holds three ASCII full stops. It is deliberately wider than "a trailing `...` in `en`", because the census showed the narrow rule would have shipped with two holes in it — `collaboration.commentPlaceholder` puts the ellipsis mid-sentence, and `list.loading` had the packs wrong while `en` was already right, which no `en`-only rule can see.
+
+  Fifteen module-local **no-provider fallback** entries were moved with the packs, across `useCollaborationTranslation`, `useFieldTranslation`, `useDetailTranslation`, `ObjectGrid`, `KanbanImpl`, `data-table` and `ConnectionStatus`. Those maps exist to render when no `LocalizationProvider` is mounted, and each one's own docblock requires it to stay byte-identical to the `en` pack — a requirement objectui#3440 already enforces mechanically for the collaboration map. Leaving them behind would have made the provider-less path disagree with the provider path on ten keys.
+
+  **es `usted` (objectui#3875).** `preview.empty.notReadyDescription` said `Revisa la conversación` — the tú imperative — in a namespace that is otherwise 23:1 usted, and it renders _underneath the usted draft-preview banner at the same moment_, not before or after it. `Revisa` → `Revise`; nothing else in the sentence carries a register. The neighbouring `approvalsInbox` namespace is legitimately tú and was left alone.
+
+  **pt contraction (objectui#3877).** `ConcurrentUpdateDialog` splits `detail.concurrentUpdateDescription` on `{{field}}` and renders a bolded label in the gap, and pt left a bare `de` in front of that gap. When the multi-field conflict branch passes the record label (`este registro`), Portuguese users read `de este registro` — a contraction error every native speaker sees, and one that no spelling of the leaf value could fix (`deste registro` renders `de deste registro`). The pt sentence is rewritten so the hole is preceded by the verb `afeta` instead of any preposition, which closes the whole class rather than trading `de` for an `em` or `a` that contract just as hard. pt only; `en` is unchanged.
+
+  No behavior, no keys added or removed, no placeholder changed.
+
+- 45e1949: Numbers render in the user's locale, and a `Field.number` year is no longer `2,026`
+
+  Every numeric field the console rendered went through an `Intl.NumberFormat` built with the locale hardcoded to `en-US` and `useGrouping` never set. Two defects rode in that one construction: a `zh-CN` or `de-DE` console still grouped and pointed decimals the US way, and a four-digit **year** stored as `Field.number({ scale: 0 })` rendered as `2,026` — in every locale, with no field property able to turn it off. Apps had been converting year columns to `Field.text` to escape it, permanently trading numeric comparison, range filters and dataset dimension types for a display detail.
+
+  The construction had been copied into five places — the number cell renderer, the currency cell renderer, the `CurrencyField` widget, the compact `formatNumber` helper, and the dashboard `MetricWidget` — so fixing any one surface never changed the answer. They now share one formatter, `formatDisplayNumber` in `@object-ui/i18n`, which owns the locale and the grouping policy together, plus one locale resolver, `useDisplayLocale`.
+
+  `useDisplayLocale` composes the two locale channels this repo already had rather than adding a third: the tenant's regional default (`useLocalization().locale`, ADR-0053) when an org has configured one, otherwise the active UI language (`useObjectTranslation().language`) so grouping and decimal marks follow a language switch. That second step is what covers the case the report was measured in — a fresh database, where the tenant localization endpoint has no locale to give.
+
+  Grouping is now suppressed when a field declares `scale: 0` and carries no currency, which is what makes years, fiscal periods and other ordinals render plainly. This is an **interim default** with an accepted cost: a large scale-0 _count_ loses its separators too. It holds only until the spec gains an authorable presentation hint, which is being specified separately, contract-first; when that lands it overrides this heuristic.
+
+  Three surfaces deliberately keep their separators, because a zero-decimal display there does not come from a field declaration: the dashboard `MetricWidget` (its decimals are parsed from a numeral.js format pattern, and its own contract calls the separators load-bearing — "`1,930,000` not `1930000`"), the `element:number` aggregate renderer, and every currency path including amounts whose currency code could not be resolved. An **undeclared** `scale` also keeps grouping — absent means "decimals unknown", not "integer".
+
+  `formatCurrency`, `formatCompactCurrency` and `formatNumber` each take a new optional trailing `locale` argument. Existing calls are unaffected; omitting it now follows the runtime default rather than forcing US conventions.
+
+- a3ae404: fix(components,plugin-dashboard): a static-data `table` widget renders instead of crashing
+
+  A dashboard widget authored as `{ type: 'table', options: { data: [ … ] } }` fell into the
+  error boundary with "Maximum update depth exceeded" the moment its tile re-rendered, while
+  every chart family on the identical static surface rendered clean.
+
+  - `data-table` no longer re-renders itself to death. Its `columns` / `data` fallbacks are
+    module-scope empties instead of per-render array literals, and the prop→state column sync
+    re-seeds on a value change rather than on a new identity — so a consumer that derives its
+    columns each render (which both dashboard surfaces do) costs the table nothing.
+  - Both dashboard surfaces now give the static table the `columns` key `DataTableSchema`
+    requires, derived from the rows when the author declared none — the same derivation the
+    `provider: 'object'` half of the widget family already performed. Previously such a table
+    drew one empty row per record: no headers, no cells.
+  - `DashboardGridLayout` reads an authored `options.data` ARRAY for its static table, which
+    its `widgetData?.items` expression resolved to `[]`. `DashboardRenderer` had the arm all
+    along.
+
+- bfdf3d4: `element:record_picker.filter` is now discoverable from the published `inputs`
+
+  The fourth A-class gap of objectui#3808's own list, and the one its three-way
+  triage dropped: `filter` appears in that issue's raw key dump for this block and
+  then in none of its A / B / C lists, so the change that added the repo-wide
+  parity gate exempted it by name instead of declaring it. It is the same shape as
+  the four #3808 fixed — `@objectstack/spec` declares
+  `ElementRecordPickerProps.filter`, the renderer has read it all along
+  (`composed?.filter ?? props.filter`, straight into the picker query's `$filter`),
+  and the registry `inputs` never mentioned it.
+
+  `element:record_picker` is not in the public tier ("record picking is a field
+  widget, not a page block"), so the gap was not in `sdui.manifest.json` — it was
+  in the JSX-page compiler's prop whitelist, which `renderers/layout/page.tsx`
+  builds from `getKnownTypes()` plus these same `inputs`. A JSX page writing
+  `filter` therefore got an `unknown-prop` warning from `sdui-parser`'s prop walk
+  on the very key that decided which records the picker offered, and the designer
+  panel gave an author no way to discover the key existed at all.
+
+  The description is derived from what the renderer does, not from restating the
+  spec's one-liner, because the one thing an author cannot read off the spec is
+  which of the two places they may write a filter wins: a node-level `dataSource`
+  filter (itself AND-combined with any saved `view` it names) is taken and this
+  top-level `filter` is DROPPED, not merged — so this key applies only when the
+  node carries no `dataSource` filter.
+
+  `type` is `'object'`, taken from the spec's actual shape on the resolved pin
+  rather than the `'array'` the issue's landing sketch guessed:
+  `FilterConditionSchema` is `z.record(z.string(), z.unknown())` intersected with
+  the `$and` / `$or` / `$not` group, so a rule array is rejected. This is the one
+  key in the family where `ComponentInput`'s coarse typing costs nothing —
+  `sdui-parser`'s `checkType` accepts exactly the values the spec accepts here, so
+  unlike `element:text_input.defaultValue` there is no narrowing to disclose.
+
+  The parity gate's explicit exemption for this key is deleted in the same change
+  (its own `carries no stale unpublished-key exemption` assertion demands it), and
+  the key joins #3808's four in the by-name "declared, not merely not-failing" pin.
+
+- b1e42d0: Conditional required (`requiredWhen`) now decides at SUBMIT time too — the star and the validator can no longer disagree
+
+  A `requiredWhen` predicate that flipped to FALSE after the dialog mounted updated only half the form. The display layer re-evaluated correctly — the asterisk and `aria-required` both disappeared — while submit stayed refused with "<field> is required" and no write was ever issued. The user saw an optional field and a form that would not save, with nothing on screen naming the field it was still waiting on (objectui#4161).
+
+  The cause is not a mount-time snapshot, which is what the symptom looks like. The renderer hands react-hook-form its per-field rules as a `<Controller rules>` prop, and RHF _merges_ that object into the field descriptor it already holds — `_f: { ...previous._f, ...options }`. A rule key that stops being spelled is therefore never removed. Rules could be ADDED live (a predicate flipping TRUE after mount did start enforcing, correctly) but never withdrawn: the `validate.required` entry installed the first time the predicate evaluated TRUE outlived every later FALSE verdict. The validation layer was append-only, latched on the first TRUE the field ever produced.
+
+  The `validate.required` entry is now registered unconditionally and decides required-ness when it _runs_, reading the live verdict the renderer publishes on every render — the same single `resolveFieldRuleState` result that draws the asterisk, not a second evaluation of the predicate with its own copy of the record assembly. Both directions are pinned: a predicate flipping FALSE re-opens submit, a predicate flipping TRUE starts enforcing, and statically required fields are unaffected.
+
+- 3f5f87c: `SchemaRenderer` states its real contract — a typed, required `schema` and a deliberate forwarding surface
+
+  `SchemaRenderer` is the renderer loop: every registered SDUI component is rendered through it. It handed `forwardRef` a props type of `{ schema: SchemaNode } & Record<string, any>`, which puts `string` into `keyof Props`, so `'ref' extends keyof Props` was always true, React's `PropsWithoutRef` took its `Omit` branch, and `Omit` over a type carrying a string index signature keeps only the index signature. Every declared prop was erased. Measured on the pre-fix source: `keyof ComponentProps<typeof SchemaRenderer>` was `string` and `ComponentProps<typeof SchemaRenderer>['schema']` was `any`, while the type argument went on declaring `SchemaNode`. The other half is the same defect seen from the call site — `<SchemaRenderer />` with no schema at all, `<SchemaRenderer schema={12345} />`, and an arbitrary misspelled prop each type-checked in silence. This is objectui#4422 / PR #4438's trap in the most central component in the repo, spelled `Record<string, any>` rather than `[key: string]: any`, which is why every previous sweep's grep and both shipped guards' detector reported the site as clean.
+
+  Graded **minor, not major**, on objectui#4528's reasoning: the type argument has always DECLARED `schema`; the index signature erased it from the resolved type, and restoring what the declaration documents is a fix to the published contract rather than a contract break.
+
+  **The forwarding surface is kept, deliberately.** This component forwards every prop it does not read to the component the schema names, resolved at runtime from a plugin-extensible registry — `packages/react/README.md` documents exactly that, and `@object-ui/components`' form renderer consumes the `onSubmit` it shows being forwarded. Closing that surface would state a false contract and would force every leaf plugin's props into this package. So the two halves are separated: the `forwardRef` type argument is the honest `SchemaRendererProps`, with no index signature for `PropsWithoutRef` to collapse, and the open surface is stated once in an explicit export annotation, which nothing routes through `Omit`. The published `.d.ts` shows the erasure disappearing: `ForwardRefExoticComponent<Omit<{ schema: SchemaNode } & Record<string, any>, "ref"> & RefAttributes<any>>` becomes `ForwardRefExoticComponent<SchemaRendererProps & Record<string, any> & RefAttributes<any>>`.
+
+  `SchemaRendererProps.schema` is declared as `BaseSchema | string | null | undefined` — what this component actually handles. It previously declared `@object-ui/core`'s `SchemaNode` interface, which requires `type: string` and so contradicted the component's own early returns for strings and nullish, while every caller held `@object-ui/types`' wider union. The erasure hid that mismatch completely.
+
+  **One declared behaviour change.** A non-object, non-string primitive schema now renders as its own text. It previously fell through to the shallow copy `{ ...schema }`, which spreads a primitive to an empty object, lost the `type` the renderer then looked up, and surfaced the red "Unknown component type: undefined" box — an accident of the spread rather than a decision. The declared props type excludes `number` / `boolean` so no author is invited to pass them; the runtime handling is defence-in-depth for untyped callers and stored metadata. Strings, `null`, `undefined`, `0` and `false` render exactly as before, and an object naming an unregistered type still gets the error box; all four are pinned.
+
+  Latent defects the erasure had been hiding, each surfaced by the repo-wide type-check and fixed at its call site: `DashboardRenderer` cast its widget schema to `Record<string, any>`, dropping the `type` every branch of `getComponentSchema` sets; `DashboardGridLayout`'s equivalent now states its return type instead of inferring a union that admitted a shape with no `type`; and `ReportViewer` handed a section's `content` array to the renderer whole, so a multi-node section rendered the unknown-component box instead of its content — arrays are mapped rather than widened into the renderer's declared input.
+
+  A repo-wide structural guard replaces the two per-package siblings' blocked direction: it judges every `forwardRef` in `packages/*/src` (219 sites) and its detector resolves `Record<string, …>` and `string`-keyed mapped types in addition to literal index signatures — the spelling the previous detector went blind on. It judges the type argument only, where an index signature is an accidental eraser, and never an export annotation, where one is a stated contract.
+
+- f5e1143: A collapsed sidebar now survives a reload — `SidebarProvider` reads the `sidebar_state` cookie it has always written
+
+  The cookie half of this feature only ever ran in one direction. `setOpen` wrote `sidebar_state` on every toggle with a 7-day max-age, and nothing ever read it back: `SidebarProvider` seeded its state from `defaultOpen` (default `true`), so a sidebar you collapsed came back expanded on the next load with the correct cookie sitting right there, unread. QA measured it at 255px and `data-state=expanded` at +2s, +4s and +8s after load, reproduced three times.
+
+  Upstream Shadcn closes this loop in a **server component** — it reads the cookie there and passes the value down as `defaultOpen`. A pure SPA like the console has no such step, which is why nothing downstream could paper over it: passing a cookie-derived `defaultOpen` from one shell would have fixed that shell and left every other consumer of the primitive broken. The read therefore happens client-side, in the provider, as a lazy `useState` initialiser rather than a mount effect — the state has to be right on the first render, since a post-mount correction would still flash an expanded sidebar at the user.
+
+  Precedence is now pinned, in this order: a controlled `open` prop, then the cookie, then `defaultOpen`, then `true`. The cookie overrides the _default_, never a controlled usage. With no cookie present the behaviour is exactly what it was before, which is what keeps explicit `defaultOpen={false}` call sites — the marketing demos in `apps/site` — rendering unchanged; those cases are controls in the new test file and are green on both sides of the change.
+
+  Only the two values the writer produces are honoured (`"true"` / `"false"`), matched on an exact cookie name; anything else, including an absent or malformed value, falls through to `defaultOpen` rather than inventing a preference the user never expressed. The reader is SSR-safe, which `apps/site` needs: those primitives are `"use client"`, and Next still renders them on the server for the initial HTML, where there is no `document`.
+
+  Because `packages/components/src/ui/**` is regenerated from the Shadcn registry, the primitive itself only gains two anchored one-liners. All of the parsing lives in `packages/components/src/lib/sidebar-cookie.ts`, which the sync never touches, and the two edits are declared in `scripts/shadcn-local-patches.mjs` so `pnpm shadcn:update` re-applies them instead of silently reverting the fix — the same mechanism already used for the translated `Sheet`/`Dialog` close labels.
+
+- 5bf09fd: `ActionParamDialog`'s `select` branch no longer renders a hardcoded English `Select...` placeholder. The fallback used when an action param declares no `placeholder` of its own now reads the existing `common.select` pack key, so it is translated in all ten locales and carries the typographic ellipsis (U+2026) that #3878 converged the packs on. Authored `placeholder` metadata keeps priority, and no locale pack changed — the key was reused from `LookupField`'s identical select-trigger use.
+- Updated dependencies [0e67b53]
+- Updated dependencies [ceccdcf]
+- Updated dependencies [ee66e2e]
+- Updated dependencies [ee26e65]
+- Updated dependencies [5900ac5]
+- Updated dependencies [932cbcd]
+- Updated dependencies [734d186]
+- Updated dependencies [f650253]
+- Updated dependencies [3d9769a]
+- Updated dependencies [8f85f8b]
+- Updated dependencies [d0c3b26]
+- Updated dependencies [3fc2971]
+- Updated dependencies [aca27fa]
+- Updated dependencies [dde7283]
+- Updated dependencies [f7c6430]
+- Updated dependencies [ae10a01]
+- Updated dependencies [92876f0]
+- Updated dependencies [f279deb]
+- Updated dependencies [eb7f586]
+- Updated dependencies [e901131]
+- Updated dependencies [d9d3463]
+- Updated dependencies [2a40f69]
+- Updated dependencies [bec3e14]
+- Updated dependencies [613b167]
+- Updated dependencies [1f9b905]
+- Updated dependencies [828549a]
+- Updated dependencies [e1ade8f]
+- Updated dependencies [abb0f81]
+- Updated dependencies [38ab505]
+- Updated dependencies [3e19fe7]
+- Updated dependencies [bb58d1d]
+- Updated dependencies [5cc847c]
+- Updated dependencies [fa21254]
+- Updated dependencies [33c32bf]
+- Updated dependencies [66fb4fa]
+- Updated dependencies [b953a97]
+- Updated dependencies [d7f3e30]
+- Updated dependencies [6d641c9]
+- Updated dependencies [7e4f0e5]
+- Updated dependencies [a84385b]
+- Updated dependencies [45e1949]
+- Updated dependencies [92250d6]
+- Updated dependencies [c1d939f]
+- Updated dependencies [58bebf6]
+- Updated dependencies [405e808]
+- Updated dependencies [49ae9f4]
+- Updated dependencies [c0f9a4b]
+- Updated dependencies [2459a3e]
+- Updated dependencies [ac853ce]
+- Updated dependencies [fa51109]
+- Updated dependencies [d6aa172]
+- Updated dependencies [fe52a04]
+- Updated dependencies [d46f9b8]
+- Updated dependencies [3f5f87c]
+- Updated dependencies [2fea4d2]
+- Updated dependencies [7f1cb33]
+- Updated dependencies [f148a64]
+- Updated dependencies [bb68488]
+- Updated dependencies [2e3b0c0]
+- Updated dependencies [9461dd3]
+- Updated dependencies [78fa331]
+- Updated dependencies [47f551b]
+- Updated dependencies [31ab1ac]
+- Updated dependencies [0082db8]
+- Updated dependencies [ab04728]
+- Updated dependencies [06915b0]
+- Updated dependencies [ff84b05]
+  - @object-ui/i18n@17.5.0
+  - @object-ui/react@17.5.0
+  - @object-ui/core@17.5.0
+  - @object-ui/types@17.5.0
+  - @object-ui/sdui-parser@17.5.0
+  - @object-ui/react-runtime@17.5.0
+
+## 17.4.0
+
+### Minor Changes
+
+- ecae400: Retire the `capability-multiselect` field widget name, which existed only on the docs-site registration path and which nothing ever stamped (objectui#3308, ADR-0049 enforce-or-remove)
+
+  `field:capability-multiselect` was registered by `registerFields()` and only there. That function's sole caller is the docs site, so the key never existed on the live path (`registerAllFields()`, run at module import, iterates `fieldWidgetMap` — which never listed it). A field authored with `widget: 'capability-multiselect'` therefore resolved to nothing in every real application, while the comment above the registration described it as usable from a record form: a code comment promising a capability that does not exist, which is the worst direction for a metadata renderer AI-authored apps read as authority.
+
+  Nothing stamped the hint either. ADR-0056 P1 stamps `permission-facet-link` on all six `sys_permission_set` facets — `system_permissions` included — through the single `ObjectStackAdapter.getObjectSchema` choke point, and P2 put the capability editor in Studio. The widget name was a leftover from an intermediate iteration of that rollout.
+
+  Removed, with a tombstone at each site:
+
+  - `@object-ui/fields` — the `field:capability-multiselect` registration and the comment that advertised it. **Breaking in name only**: the key was unreachable outside the docs site, so no application could have resolved it. A field still carrying the hint now degrades to its declared `type` renderer, the defined behavior for an unregistered widget.
+  - `@object-ui/plugin-detail` — `InlineFieldInput`'s `widget === 'capability-multiselect'` branch, the hint's last honoring surface. Leaving one consumer for a name no producer emits and no form resolves is the same declared-vs-enforced split, inverted. The sibling `permission-facet-link` branch is untouched and pinned.
+  - `@object-ui/components` — the dead `capability-multiselect` entry in the form renderer's `DATA_SOURCE_FIELD_TYPES` set, which could never match a resolvable widget.
+  - `@object-ui/plugin-form` — a comment naming `capability-multiselect` as the widget stamped onto `sys_permission_set.system_permissions`; it names `permission-facet-link` now, which is what is actually stamped.
+
+  `CapabilityMultiSelectField` itself is **unchanged and still exported**: Studio's `PermissionMatrixEditor` imports and renders it directly, which is ADR-0056 P2's design. Only the widget name is retired — the component is not a registry field widget and its doc comment now says so.
+
+  `registerFields()` is also **kept**, with its `@deprecated Use registerAllFields() instead` note corrected. The two are not interchangeable: it registers `createFieldRenderer(widget)`, which synthesizes the label, description and the local `value`/`onChange` state that lets a bare field node (`{ type: 'currency', label: 'Amount' }`) render standalone in the docs demos. Retiring it needs a decision about where that demo chrome goes; the note now records that instead of implying a drop-in replacement.
+
+### Patch Changes
+
+- 794c497: `action:bar` member actions declaring `visible: false` are now hidden instead of rendered
+
+  `action:button` and `action:icon` carried the same truthiness gate objectui#3812
+  removed from the member-action leaves — `if (schema.visible && !isVisible)
+return null` — so `visible: false`, the most explicit way an author can say
+  "never show this", fell into the "no gate declared" branch and the action
+  rendered anyway.
+
+  objectui#3812's triage judged the five component-level `schema.visible` gates a
+  dormant defensive layer, because `packages/react`'s `SchemaRenderer` evaluates
+  `newSchema.visible !== undefined` and hides the node before the component ever
+  mounts. Two of the five are not dormant, and this is the difference:
+
+  `action:bar` does not route through `SchemaRenderer`. It resolves each member's
+  renderer from the `ComponentRegistry` itself and spreads the whole member action
+  onto that renderer's schema, so an author's `visible` on a member arrives as the
+  child's own `schema.visible` and lands on the child's gate. `action:bar` is also
+  the only gate on that path by design — its `filteredActions` deliberately
+  filters on `requiredPermissions` and `actionRendersAt` only, leaving `visible` to
+  the member renderer. The path is reachable end-to-end and is now pinned that way
+  (registry-mounted `action:bar`, member declaring `visible: false`), so the
+  reachability does not have to be argued again.
+
+  Both gates now read the same named definition as the rest of the family,
+  `hasDeclaredVisibilityGate` (`!= null && !== ''`) — the invariant objectui#3492
+  established for the selection bar and objectui#3758 applied to the row-action
+  surfaces. The evaluation entry is untouched and already short-circuits a boolean
+  rather than handing it to the CEL engine, which `actionPredicate.parity` pins for
+  both the engine and the renderer path.
+
+  Behaviour change surface, deliberately narrow: only an `action:button` /
+  `action:icon` whose `visible` is the literal boolean `false` (or another falsy
+  non-empty value) changes — from rendered to hidden, which is what the
+  declaration asked for. `visible: true` still renders, `''` and an absent
+  `visible` are still no gate at all, and no expression-valued `visible` changes
+  verdict. `ActionSchema.visible` is `ExpressionInputSchema` with no boolean
+  member, so `objectstack build` cannot emit this shape; hand-written view JSON and
+  in-process callers constructing action defs can.
+
+  The remaining three component-level gates (`action:group`, `action:menu`,
+  `action:bar`'s own) stay as they are — they only ever mount through
+  `SchemaRenderer`, which resolves `visible` first, and the overflow `action:menu`
+  that `action:bar` synthesizes carries no `visible` at all.
+
+- 993336f: An action declaring `disabled: ''` is no longer greyed out forever (objectui#3842)
+
+  The "is a `disabled` gate declared?" test stopped at `!= null`, missing the
+  `!== ''` half of the invariant the `visible` family converged on
+  (`hasDeclaredVisibilityGate`, objectui#3492 / #3758 / #3812 / #3823 / #3835). So
+  `disabled: ''` counted as a declared gate, and the verdict went to the evaluation
+  entry — which reads an empty predicate as "no condition → `true`"
+  (`toPredicateInput('')` is `undefined`, `evaluateCondition(undefined)` is `true`).
+
+  The direction is why this half is a defect and the `visible` half was not. On
+  `visible`, that `true` means SHOW, so an over-broad "declared" test and a
+  permissive empty predicate cancel out and `visible: ''` renders either way. On
+  `disabled`, the same `true` means DISABLE — the two mistakes compound, and an
+  empty predicate stopped meaning "no gate" and started meaning "permanently
+  greyed out". One empty predicate, opposite treatment under two keys.
+
+  Two gates now ask the shared definition instead:
+
+  - `@object-ui/app-shell`'s `DeclaredActionsBar` — the hot one. Its actions are
+    SERVER-declared (`objectDef.actions[]`) and its hosts are the approvals inbox's
+    record sections, so a `disabled: ''` arriving from metadata (an authoring form
+    left empty, a template that rendered to an empty string) produced an Approve /
+    Reject button nobody could click, indistinguishable from deliberate metadata.
+    objectui#3835 was this same surface failing the other way.
+  - `@object-ui/components`' `action:button` — verified to be the same shape before
+    it was changed (the issue inferred it from the identical spelling but did not
+    probe it): with `disabled: ''` the rendered button carried `disabled=""`.
+
+  **Behaviour change surface, deliberately narrow.** Only `disabled: ''` changes —
+  from disabled to clickable, which is what "no predicate" asked for. `disabled:
+true` still disables, `disabled: false` and an absent `disabled` still do not, and
+  no expression-valued `disabled` changes verdict. One consequence worth naming: on
+  `action:button`, an empty `disabled` now falls THROUGH to the legacy non-spec
+  `enabled` fallback instead of short-circuiting on the empty predicate, so an
+  action spelling both (`disabled: ''` + `enabled: true`) becomes clickable.
+
+  The legacy `enabled` leg of `action:button` was routed through the same
+  definition for consistency, and that part is behaviour-preserving by derivation
+  rather than a fix: the leg is negated (`disabled = !isEnabled`), so an empty
+  predicate's `true` already arrived as "not disabled" — the same verdict "no gate"
+  produces. All four shapes are identical under either test; the derivation table
+  and the reason no test can distinguish them are written down next to the pins.
+
+  `hasDeclaredVisibilityGate` keeps its historic name at both call sites (the
+  objectui#3842 dispatch ruling): the predicate is key-neutral, and one
+  implementation behind two names is how a repo grows dialects. Each call site says
+  so in a comment.
+
+- f0a625a: `disabled: ''` no longer greys out the remaining five action surfaces (objectui#3849)
+
+  objectui#3842 / PR #3851 fixed the "is a `disabled` gate DECLARED?" test on
+  `action:button` and app-shell's `DeclaredActionsBar`. Five same-shaped sites were
+  outside that PR's scope and stayed on `!= null`, so within one component the
+  `visible` gate asked `hasDeclaredVisibilityGate` while the `disabled` gate on the
+  next line asked `!= null` — two spellings of one question:
+
+  - `@object-ui/components` — `action:icon`, `action:group`'s inline button
+    (`InlineActionButton`) and dropdown item (`DropdownActionItem`), and
+    `action:menu`'s item (`ActionMenuItem`).
+  - `@object-ui/plugin-detail` — `record:quick_actions`' `QuickActionButton`.
+
+  Why the missing `!== ''` half is a defect on this key and not on `visible`:
+  `toPredicateInput('')` is `undefined` and `evaluateCondition(undefined)` is
+  `true`. On `visible` that `true` means SHOW, so an over-broad "declared" test and
+  a permissive empty predicate cancel out. On `disabled` it means DISABLE, so they
+  compound — `disabled: ''` (an empty predicate: nothing declared) rendered a
+  permanently greyed-out control, with nothing the author could write to un-grey
+  it. Unlike #3842's approvals inbox, these five are the general action face
+  (toolbars, dropdowns, record quick actions), so the reach is wider even though no
+  single high-value host owns them.
+
+  **Behaviour change surface, deliberately narrow.** Only `disabled: ''` changes —
+  from disabled to clickable, which is what "no predicate" asked for. `disabled:
+true` still disables, `disabled: false` and an absent `disabled` still do not, and
+  no expression-valued `disabled` changes verdict. On the four sites that also carry
+  the legacy non-spec `enabled` fallback, one consequence follows: an empty
+  `disabled` now falls THROUGH to that leg instead of short-circuiting on the empty
+  predicate, so an action spelling both (`disabled: ''` + `enabled: true`) becomes
+  clickable. `record:quick_actions` has no `enabled` leg, so its chain is the single
+  gate.
+
+  Routing those legacy `enabled` legs through the same definition is
+  behaviour-preserving by derivation rather than a fix: the leg is negated
+  (`disabled = !isEnabled`), so an empty predicate's `true` already arrived as "not
+  disabled" — the verdict "no gate declared" produces. #3842's four-shape derivation
+  table is reproduced next to the new pins, together with the statement that no
+  `enabled` case can go red by reverting that leg.
+
+  `hasDeclaredVisibilityGate` keeps its historic name (the objectui#3842 ruling): the
+  predicate is key-neutral, and one implementation behind two names is how a repo
+  grows dialects. The three `@object-ui/components` sites import it relatively;
+  `record:quick_actions` takes it from the package barrel, the cross-package route
+  objectui#3835 opened. Every call site says so in a comment.
+
+- b5980f4: Action-face member actions declaring `visible: false` are now hidden instead of rendered
+
+  The three member-action gates on the action face asked truthiness —
+  `if (action.visible && !isVisible) return null` — so `visible: false`, the most
+  explicit way an author can say "never show this", fell into the "no gate
+  declared" branch and the action rendered anyway:
+
+  - `action:group` in `display: 'inline'` mode (`InlineActionButton`);
+  - `action:group` in `display: 'dropdown'` mode (`DropdownActionItem`);
+  - `action:menu`'s items (`ActionMenuItem`).
+
+  These leaves `.map()` the component's own `actions` array, so neither
+  `SchemaRenderer`'s node-level `visible` handling nor
+  `ActionEngine.getActionsForLocation` (whose boolean `visible` was always
+  correct) is in the path — the truthy gate was the only gate.
+
+  All three now read one named definition, `hasDeclaredVisibilityGate`
+  (`!= null && !== ''`), and let the declaration itself decide. This is not a new
+  decision: objectui#3492 established the invariant for the selection bar, whose
+  `hasVisibilityGate` spells out why truthiness cannot answer the question, and
+  objectui#3758 applied it to both row-action surfaces. The evaluation entry is
+  untouched and already short-circuits a boolean rather than handing it to the CEL
+  engine, which `actionPredicate.parity` pins for both the engine and the renderer
+  path.
+
+  Behaviour change surface, deliberately narrow: only a member action whose
+  `visible` is the literal boolean `false` (or another falsy non-empty value)
+  changes — from rendered to hidden, which is what the declaration asked for.
+  `visible: true` still renders, `''` and an absent `visible` are still no gate at
+  all, and no expression-valued `visible` changes verdict.
+  `ActionSchema.visible` is `ExpressionInputSchema` with no boolean member, so
+  `objectstack build` cannot emit this shape; hand-written view JSON and
+  in-process callers constructing action defs can.
+
+- 8aad9fd: Action-face predicates written against the canonical `record.` root now evaluate
+
+  `action:button`, `action:icon`, `action:menu` and `action:group` gated their
+  actions on `useCondition(pred, context)`, which evaluates on
+  `new ExpressionEvaluator({ ...scope, ...context })` — and the context each of
+  them passed was the row spread flat, or nothing at all. Only the shorthand
+  spelling resolved:
+
+  | predicate                    | verdict, before                  |
+  | ---------------------------- | -------------------------------- |
+  | `status == "pending"`        | evaluates (`action:button` only) |
+  | `record.status == "pending"` | throws `record is not defined`   |
+  | `data.status == "pending"`   | throws `data is not defined`     |
+
+  `record.` is not a mistaken spelling — it is the canonical one. It is what
+  `ExpressionEvaluator`'s CEL path binds (`bag.record` as the record namespace),
+  what `evalRowPredicate` binds on the record header, list rows, the row kebab
+  and conditional formatting (`record.status` / bare `status` / `data.status`),
+  and what the server enforces with. A `visible` that fails CLOSED turns the throw
+  into "hidden", so a correctly-authored predicate deleted its own button —
+  indistinguishable from the gate having said no. On the fail-soft legs the same
+  throw lands the other way: `disabled` greyed a control out for everyone.
+
+  Live rather than theoretical: every declared action on framework's
+  `sys_approval_request` gates on `record.viewer.*`, so the whole server-declared
+  approval decision set was invisible wherever the declared-action bar rendered
+  until objectui#4077 fixed that bar. These four generic renderers carried the
+  same binding.
+
+  What changed:
+
+  - all four bind the row the three canonical ways, through one named helper
+    (`usePredicateRecordContext`, exported from `@object-ui/react` beside
+    `useCondition`), so the action face and the row surfaces answer an author's
+    `visible:` the same way;
+  - `action:icon` reads the row at all. It evaluated against an empty bag, so not
+    even the bare-field shorthand resolved — and its `data` prop was landing in
+    the props spread onto the DOM button;
+  - `action:menu`'s items and `action:group`'s two leaves receive the row from
+    their host, which they previously never got;
+  - `action:bar` forwards the row into the overflow menu it builds, not just to
+    its inline members. An action's predicate had been answering a different
+    question purely because it spilled past `maxVisible` — which on mobile
+    defaults to 1, making the verdict a function of the viewport.
+
+  Deliberately unchanged: the evaluation entry and each site's error policy. A
+  predicate that genuinely faults still fails closed on `action:button` /
+  `action:menu` `visible` and still fails soft on the other legs, exactly as
+  before; `toPredicateInput`, `hasDeclaredVisibilityGate` and the empty-predicate
+  rules keep their pinned semantics. Binding the row is a separate question from
+  what to do when the predicate faults.
+
+  A surface with no row of its own binds nothing rather than an empty record, so
+  a host that supplies the row through the ambient predicate scope is not blanked
+  out; a row passed explicitly still wins over the scope.
+
+- 0cbdca8: Built-in `select` fields: the form's label, validation message and required state now reach the control
+
+  A hand-written form field `{ name: 'status', label: 'Status', type: 'select', options: [...] }`
+  rendered a visible "Status" label that pointed at nothing. Measured before the fix:
+  `<label for="…-form-item">` resolved to no element at all, `getByLabelText(/status/i)`
+  found zero matches, and the trigger button carried no `id`, no `aria-describedby`, no
+  `aria-invalid` and no `aria-required`. Clicking the label did nothing and a screen reader
+  announced an anonymous combobox with no field name, no error link and no required state.
+
+  Cause: the built-in `select` branch spread its whole DOM pass-through onto Radix's
+  `Select.Root`. Root renders no DOM element of its own, so everything it does not
+  recognise is silently dropped — and that is exactly where `<FormControl>`'s Slot puts the
+  field's `id` / `aria-describedby` / `aria-invalid` and the renderer puts `aria-required`.
+  The pass-through now lands on `SelectTrigger`, the focusable `button[role=combobox]` the
+  user and their assistive tech actually operate, with the same two keys deliberately kept
+  on Root as in the widget-side fix: `name` (the one key Root consumes — it forwards it to
+  the hidden native `select` that takes part in form submission) and `disabled` (Root
+  disables trigger, items and hidden select together, so the raw prop must not gain a second
+  author). `ref` rides the pass-through too, so react-hook-form can finally focus a built-in
+  select.
+
+  This is the built-in half of the same mechanism objectui#3306 fixed on the widget side.
+  The two halves diverged because `'select'` is a `BUILTIN_FIELD_TYPES` member: an
+  object-driven `field:select` resolves to the registered `SelectField` (fixed since #3306),
+  while a hand-written bare `type: 'select'` never consults the registry and kept the
+  defect. Both paths are now pinned side by side — the registered path as a positive control
+  — so they cannot drift apart again. Which component renders a bare `select` is unchanged;
+  only where its host props land.
+
+  Authored `className` on a built-in `select` now reaches the trigger (it previously reached
+  no element), composed with the branch's touch-target height rather than replacing it.
+
+- d3e738a: Export `hasDeclaredVisibilityGate` from the package barrel (objectui#3835)
+
+  `hasDeclaredVisibilityGate(visible)` — "did this action DECLARE a visibility gate
+  at all?", i.e. `!= null && !== ''`, with the verdict left to the evaluation entry
+  — is the single definition objectui#3492 established and PR #3816 / #3825 / #3836
+  applied to every member-action gate in this package and in `@object-ui/plugin-grid`.
+  It lived module-private in `src/renderers/action/visibility-gate.ts`.
+
+  The family turned out to have a member outside these packages:
+  `@object-ui/app-shell`'s `DeclaredActionsBar` gates server-declared actions with
+  the same question and had the same truthiness bug (objectui#3835). Exporting the
+  one definition is what keeps that fix from becoming a fifth hand-spelled copy of
+  it — the drift shape objectui#3142 already had to unpick for `locations` in these
+  same files.
+
+  Additive only: one `export` line, no behaviour change in this package. The
+  function is pure and dependency-free.
+
+- 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.
+
+- 7ed3360: fix(data-table): don't render a row overflow ("⋮") trigger that opens an empty menu
+
+  The row overflow trigger was gated on whether row-action **handlers** were
+  supplied (`onRowEdit` / `onRowDelete` / `rowActionDefs`), while the menu's items
+  were filtered a second time — per item, per record — against
+  `rowEditPredicates` / `rowDeletePredicates` and a custom action's `visible`. On a
+  row where every item was predicate-suppressed the trigger still rendered and
+  opened an empty box, which reads as a broken page.
+
+  The trigger is now decided by the items that will actually render for that row,
+  resolved through the same visibility rule the items gate themselves on, so the
+  two cannot disagree. The decision is per row: within one table a row that keeps
+  an action keeps its trigger while a row with nothing left renders none. The
+  actions cell itself is unchanged, so the column stays aligned with its header.
+
+- 0fa5e4d: The `div` deprecation notice is now reported once per module load, not once per render (objectui#3965)
+
+  `DivRenderer` called `console.warn` on every render. That is invisible on a page
+  with one `div` and destructive on a page with many: the docs schema-catalog index
+  renders 400+ example thumbnails and emitted ~190 byte-identical notices, burying
+  the page's real console errors underneath — the two nested-button errors fixed in
+  objectui#3903 / PR #3964 had to be fished out of that flood, and it cost a
+  browser-verification run its signal twice.
+
+  The deprecation itself is unchanged: dev builds still report it, the message and
+  its migration guidance are byte-identical, and production builds are still
+  silent. Only the repetition is gone. The guard is a module-level `Set` keyed by
+  type, and the production early-return happens _before_ the set is marked, so a
+  production render cannot suppress a later dev-build notice.
+
+- 5bfaabd: `PageComponentSchema.dataSource` now reaches every object-bound block, not just
+  `list-view` — and `element:record_picker` stops discarding `view`
+  (objectstack#6953).
+
+  objectstack#5576 wired the spec's per-element data binding
+  (`dataSource: { object, view?, filter?, sort?, limit? }`) to `list-view` and left
+  the same declaration inert on every other page component. Two gaps remained, and
+  both were silent:
+
+  - **`element:record_picker` read four of the five keys and dropped `view`.** So
+    `dataSource: { object: 'account', view: 'hot' }` — the spec's own example —
+    built a picker over EVERY account instead of the rows the saved view selects.
+    Nothing threw and nothing rendered an error; the option list was simply wider
+    than what was authored, which also means a user could select a record the page
+    said was out of scope.
+  - **`object-grid` / `object-form` / `object-kanban` / `object-calendar` /
+    `object-chart` / `object-metric` / `record:related_list` read none of it.**
+    Each gates its fetch on its own `objectName`, and nothing mapped
+    `dataSource.object` onto it, so a page written the way the spec documents
+    rendered an empty grid / a field-less form / a board with no cards / an empty
+    month / an empty chart / a static metric number — with no request and no
+    diagnostic anywhere. Spec-valid metadata rendering nothing is the
+    objectstack#4413 shape.
+
+  Composition follows objectstack#5576's landed semantics unchanged on every block:
+  a named saved view supplies the baseline, a key written on the component itself
+  overrides it, an explicit binding key overrides both, `filter` AND-combines
+  ("additional filter criteria" — a binding can narrow a view, never widen it), and
+  a `view` name that does not resolve renders a configuration error instead of
+  degrading to the object's full scope.
+
+  - `@object-ui/react` — new `useElementDataSourceSchema(schema, mapping, dataSource?)`
+    and `ElementDataSourceGate` apply a resolved binding to the schema keys a given
+    block reads, plus `ElementDataSourceErrorPanel` / `ElementDataSourceLoadingPanel`
+    for the two non-final states. One precedence table for all blocks rather than
+    one copy per block — that copy is how "additional filter criteria" would have
+    become two dialects.
+  - A mapping names **only** keys its block genuinely reads. A composed value
+    written onto a key the block ignores would be accepted and dropped, which is
+    the defect being removed, one layer deeper — so a kanban's swimlane `columns`
+    never receive a view's field list, and a block with no row cap leaves `limit`
+    unmapped. The per-block coverage table, including two residual gaps that are
+    named rather than papered over, is in `content/docs/guide/data-source.md`.
+
+  No behaviour changes for a block that carries no `dataSource`: the binding-free
+  path returns the schema by reference, so nothing remounts and nothing refetches.
+
+- 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.
+
+- e24d767: Record page header action predicates now speak CEL, like every other action surface
+
+  `visible` / `hidden` / `disabled` on a `page:header` action were handed to
+  ObjectUI's legacy JS evaluator, while the row kebab, the selection bar and
+  conditional formatting have evaluated the identical metadata on the canonical
+  CEL engine since objectui#1584 / ADR-0058. Every construct that exists only in
+  CEL therefore worked in a list row and threw on the record page — where the
+  throw fail-closed hid the button, leaving nothing on screen to notice:
+
+  - method calls — `record.f_tags.size() > 0`, `record.f_textarea.contains("x")`
+  - the `in` operator — `'"red" in record.f_multiselect'` (a parse error)
+  - stdlib functions — `record.f_date < today()` (`today is not a function`)
+
+  Both header evaluation sites now go through `evalRowPredicate`: the same entry,
+  the same bindings (`record.*` + bare field names + `data.*` + the host scope,
+  with relations bound as the stored foreign key), and the same fail-closed +
+  warn-once semantics as the row surfaces. One predicate on one record now reaches
+  the same show/hide verdict in the row menu, the selection bar and the record
+  header.
+
+  Legacy-dialect strings are unaffected: `${…}`, `===`/`!==`, `?.`, `??` and
+  JS-only methods such as `.includes()` still route to the legacy evaluator (with
+  its existing one-time deprecation warning), so authored pages keep working. A
+  `${…}` template predicate, which the header previously could not evaluate at
+  all, now resolves through that fallback instead of hiding the button. A
+  predicate that genuinely cannot be evaluated still hides its action, and now
+  reports itself once in the same words the other surfaces use, naming the
+  surface, the action and the predicate.
+
+- aca561a: Four spec keys the renderers already honoured are now discoverable from the published `inputs`
+
+  `record:details.hideFields`, `record:related_list.relationshipValueField`,
+  `record:related_list.add` and `element:text_input.defaultValue` were declared by
+  `@objectstack/spec` and read by their renderers, while the registry `inputs` —
+  the surface `gen-manifest.ts` serializes into `sdui.manifest.json` and
+  `sdui-intrinsics.d.ts` — never mentioned them. Nothing anywhere reported the
+  mismatch, and every layer that reads a manifest said the opposite of the
+  runtime: the keys were in no designer panel and no generated `.d.ts`,
+  `sdui-parser`'s prop walk returned `unknown-prop` for an author who wrote one,
+  and the renderer honoured it regardless. That is objectui#3407's original
+  complaint (`readonly` was enforced and honoured, the description just never said
+  so) on four more keys.
+
+  Each description is derived from what the renderer actually does, not from
+  restating the spec's one-liner, because the two can differ and the published
+  text is what an AI author reads:
+
+  - `hideFields` documents bare field names only — the renderer tolerates
+    `{name}` / `{field}` entries but the spec is `z.array(z.string())` and rejects
+    them, so teaching that spelling would publish a dialect the contract refuses;
+  - `relationshipValueField` publishes the renderer's `'id'` default and says that
+    the resolved value drives the list filter, the Add-picker link value and the
+    pre-filled create form together;
+  - `add` publishes its member shape in prose (`ComponentInput` is flat and has no
+    member-shape slot) with each default taken from the renderer — including
+    `picker.labelField`, where the renderer defaults to `name` while the spec's
+    own wording says "the object title field". It also names `picker.filter` as a
+    KNOWN GAP rather than documenting it as a restriction: the spec declares it
+    and nothing reads it, so an author would otherwise believe their picker is
+    scoped when it offers every record (objectui#3831);
+  - `defaultValue` distinguishes the two behaviours an author can get — seeding a
+    bound page variable once while it is still empty, versus the native
+    uncontrolled initial value with no variable bound.
+
+  `element:text_input` is not in the public tier, so its gap was not in
+  `sdui.manifest.json` at all — it was in the JSX-page compiler's prop whitelist,
+  which `renderers/layout/page.tsx` builds from `getKnownTypes()` plus these same
+  `inputs`, making the undeclared `defaultValue` a live `unknown-prop` warning.
+
+  The repo-wide parity gate now runs in both directions over one covered set and
+  one exemption discipline, so neither direction can be forgotten again the way
+  the reverse half was after PR #3806. Nine spec keys stay deliberately
+  unpublished, each with a written reason and a tracking issue: two the renderers
+  do not read at all (objectui#3829), three retired upstream by ADR-0087
+  tombstones, `page:tabs.type` (a carrier collision, objectstack#6776), two
+  `targetVariable` declarative hints (objectui#3834), and
+  `element:record_picker.filter` (objectui#3830).
+
+- 0ef9dfd: `page:card` publishes `children` instead of the retired `body`, and `page:section` / `page:footer` / `page:sidebar` publish the `children` slot they render
+
+  `inputs` is the published authoring surface, not documentation: the Studio block
+  designer builds its panel from it, `sdui-parser`'s `gen-manifest.ts` serializes
+  it into `sdui.manifest.json` and `sdui-intrinsics.d.ts`, and the JSX-page
+  compiler builds its prop whitelist from it. Two of the `page:*` containers had
+  drifted from the contract in opposite directions.
+
+  `page:card` published `{ name: 'body', type: 'slot' }`. `@objectstack/spec`
+  retired `PageCardProps.body` in objectstack#5775 (PR objectstack#6281, merged
+  2026-08-07, ADR-0087 D2) and declared `children` in its place — one composition
+  slot with one spelling, the same one `grid`, `flex`, `page:section` and
+  `page:tabs` items already use. The designer was teaching a key the contract now
+  rejects by name.
+
+  `page:section`, `page:footer` and `page:sidebar` declared no `inputs` at all, so
+  the designer could not authorize the child list those three components exist to
+  render. The same upstream PR replaced their `EmptyProps` declaration with the
+  shared `PageContainerProps`, whose single key is `children`; all three now
+  publish that one slot from one shared literal, mirroring the spec's own single
+  definition.
+
+  Rendering is unchanged in both directions. `PageCardRenderer` still READS `body`
+  first (`schema?.body ?? schema?.children`) and the three thin containers still
+  read `schema?.children || schema?.body`, so documents stored under the old
+  contract keep rendering until the ADR-0087 D2 conversion rewrites the key at
+  load time — a back-compat read is not a second authorable spelling, the same
+  split the `page-header-subtitle-alias` sequencing established. No validation
+  verdict moves either: `children` is already in `sdui-parser`'s `BASE_PROPS` (so
+  it was never an `unknown-prop`), `isContainer: true` was already set on all
+  four, and `codegen.ts` filters `slot` inputs out of the generated `.d.ts` where
+  `SduiBaseProps.children` types it.
+
+  What changes for an author is the designer surface: `body` is no longer offered
+  on `page:card`, `children` is, and the three thin containers gained an
+  authorable content slot.
+
+- 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`.
+
+- 54233b1: Record detail pages: a header ⟳ that refreshes the record, its related lists and its tab counts in place — no browser reload
+
+  Concurrent-editing scenario from the shop floor (MES work orders): operator A sits on a record's detail page while operator B starts or reports the same order. A had no way to see the new state except F5, which throws away the open tab, the scroll position and any in-progress inline edit along with the stale data.
+
+  The pipeline for this already existed — the objectui#2269 invalidation bus refetches every mounted reader in place, and `RecordContext.refresh` had been declared for it — but nothing produced that field and no UI reached for it. Three changes give it a trigger:
+
+  - **`RecordDetailView` produces `RecordContext.refresh`**, publishing `notifyDataChanged({ objectName: '*' })`. The wildcard is deliberate: a user reaches for refresh because of a write made by SOMEONE ELSE, which this client never saw and therefore cannot attribute to particular objects. `'*'` marks everything mounted as stale, so the main record, every related child list and the tab-count badges all refetch — no remount, so tab / scroll / draft state survive. First phase covers the standalone record route; embedded hosts (list drawer, split-pane preview) keep their existing chrome unchanged.
+  - **`page:header` renders the ⟳** at the far end of the header row when — and only when — the host provides `refresh`. It is page chrome rather than a header action, so its position is the same on every record page regardless of which business actions the object declares, and it can never be collapsed into the `⋯` overflow. Styled as that `⋯` trigger's twin so the row reads as one button family. Its accessible name and tooltip come from the existing `common.refresh` key, so the icon-only button is not English-only in the other nine locales. The icon spins for a short floor after a click, because the bus is fire-and-forget and a warm backend would otherwise finish before the click looked like it landed.
+  - **`RelatedList` accepts the `'*'` wildcard** on the legacy `objectui:related-changed` event, matching what `dataChangeMatches` already does for the bus's own readers. This listener compared the payload's object name to its own, so a wildcard invalidation reached everything on the page except the related lists — a concrete foreign object name is still ignored.
+
+  Hosts that provide no `refresh` render exactly as before.
+
+- 97b63d7: Row actions declaring `visible: false` are now hidden instead of rendered
+
+  A custom row action's visibility **gate** was detected by truthiness, so
+  `visible: false` — the most explicit way an author can say "never show this" —
+  fell into the "no gate declared" branch and the action rendered for every row.
+  Both surfaces of the ObjectGrid row cell (the "⋮" overflow item and the inline
+  `variant:'primary'` button) and the data-table's row overflow menu read the same
+  gate, so all three rendered it; the `#3562` emptiness guard counts with that same
+  gate, so a row whose only action was `visible: false` also grew a "⋮" it could
+  not fill.
+
+  The gate now detects a **declared** gate by `!= null && !== ''` and lets the
+  declaration itself decide — a boolean short-circuits to its own verdict rather
+  than being handed to the CEL engine. This is the invariant objectui#3492 already
+  established for the selection bar, whose `hasVisibilityGate` spells out why
+  truthiness cannot answer the question, and the same `!= null` posture the
+  built-in `visibleWhen` gate has always had. `visible: true` still renders,
+  `''` and an absent `visible` are still no gate at all, and no expression-valued
+  `visible` changes verdict.
+
+  Behaviour change surface, deliberately narrow: only an action whose `visible` is
+  the literal boolean `false` (or another falsy non-empty value) changes — it goes
+  from rendered to hidden, which is what the declaration asked for.
+  `ActionSchema.visible` is `ExpressionInputSchema` with no boolean member, so
+  `objectstack build` cannot emit this shape; hand-written view JSON and
+  in-process callers constructing defs can, and did. The three row surfaces now
+  reach the same verdict as the selection bar and the record page header for every
+  non-expression shape, which `predicate-surface-parity` pins.
+
+- Updated dependencies [8aad9fd]
+- Updated dependencies [6719877]
+- Updated dependencies [56ff091]
+- Updated dependencies [7864f03]
+- Updated dependencies [d229dfa]
+- Updated dependencies [4bc6c23]
+- Updated dependencies [c3b01a7]
+- Updated dependencies [f5f8744]
+- Updated dependencies [69becd2]
+- Updated dependencies [5e52495]
+- Updated dependencies [b750823]
+- Updated dependencies [5bfaabd]
+- Updated dependencies [e06810e]
+- Updated dependencies [ab3ad4f]
+- Updated dependencies [c2fd122]
+- Updated dependencies [ac2139c]
+- Updated dependencies [b14ab3a]
+- Updated dependencies [8c60819]
+- Updated dependencies [e64a52e]
+- Updated dependencies [844d17f]
+- Updated dependencies [48132f7]
+- Updated dependencies [4dcd52a]
+- Updated dependencies [42ae5c6]
+- Updated dependencies [1d723e3]
+- Updated dependencies [0109f54]
+- Updated dependencies [7e5bb5d]
+- Updated dependencies [fbc23e0]
+- Updated dependencies [6d762da]
+- Updated dependencies [d11996e]
+- Updated dependencies [e6fdbdc]
+- Updated dependencies [f9faa7d]
+- Updated dependencies [6bb454a]
+- Updated dependencies [523be48]
+- Updated dependencies [7e2b7e9]
+- Updated dependencies [33526fd]
+- Updated dependencies [32413ec]
+- Updated dependencies [c1e1e6b]
+  - @object-ui/react@17.4.0
+  - @object-ui/core@17.4.0
+  - @object-ui/i18n@17.4.0
+  - @object-ui/types@17.4.0
+  - @object-ui/react-runtime@17.4.0
+  - @object-ui/sdui-parser@17.4.0
+
 ## 17.3.0
 
 ### Minor Changes
@@ -159,6 +2845,7 @@ props}` _alongside_ `field`. The predictable result was ~30 widgets resolving
   compile time rather than work under one host and not another.
 
   ## What did NOT change
+
   - **Host metadata (SDUI JSON) is untouched.** No authored schema changes; this is
     a change to how widgets are _written_, not to what apps declare.
   - **`schema` is still the universal SDUI prop** every registered component
@@ -210,6 +2897,7 @@ props}` _alongside_ `field`. The predictable result was ~30 widgets resolving
     the flip where a name cannot.
 
   ## What changed
+
   - Every field control — built-in (`input` / `textarea` / `checkbox` / `switch` /
     `select`) and registered widget alike — now receives `aria-required="true"`
     when the field resolves required, and **no attribute at all** when it does
@@ -253,7 +2941,7 @@ AriaAttributes`) and every widget forwards its leftover props to the control it
   half-translated in a way a user could see inside one widget: the dependency-gate
   sentence next to it already went through `t()`
   (`fields.options.selectFirst`), so under a `zh` session a gated select read
-  "请先选择Country" and the same select — one keystroke later, when the parent
+  "请先选择 Country" and the same select — one keystroke later, when the parent
   value matched no option — flipped to English.
 
   `fields.options.empty` is added to `useSafeFormTranslation`'s defaults map, the
@@ -357,6 +3045,7 @@ AriaAttributes`) and every widget forwards its leftover props to the control it
   - 展开按钮的无障碍名永远插值通用名词，一张有三个长文本字段的表单上三个按钮读屏完全一样。读屏用户无法判断自己要展开的是哪个字段，这是可达性缺陷而不是观感问题。
 
   ## 改了什么
+
   - 调用点显式转发 `label`（与 `placeholder` / `emptyHint` 同法），这是唯一的行为改动。
   - `label` 属于 renderer-only：`stripRendererOnlyProps` 与 `stripRegisteredFieldProps` 各加一条丢弃项，所以它既不会变成 DOM 上的 `label="备注"` 杂属性（每个内置分支都会把剩余 props 直接摊到 DOM 节点上），也不会成为注册型 widget 新收到的 prop——自 v17 起 `field` 是它们唯一的元数据载体（objectui#3233），label 一直在那里读。
   - 内置 `textarea` 分支里那句 `const { label: _label, ...rest }` 随之删除。它本想拦住 label 落到 DOM，但既然从来没有 label 送进来，它拦的是不存在的东西（ESLint 一直报着 `'_label' is assigned a value but never used`），而且只护住了这一个分支。现在这件事由 strip 统一负责，所有分支同等受护。
@@ -2659,6 +5348,7 @@ overflow-auto` region (bottom on-screen, within the viewport) and the table can
   objects+fields were editable in Studio; this reworks both surfaces.
 
   **Setup (assign + read-only):**
+
   - The six facets (`object_permissions`, `field_permissions`, `system_permissions`,
     `row_level_security`, `tab_permissions`, `admin_scope`) now render read-only on
     the `sys_permission_set` record page as a compact summary (counts, or capability
@@ -2673,6 +5363,7 @@ overflow-auto` region (bottom on-screen, within the viewport) and the table can
 
   **Studio (design every facet):** the permission matrix editor gains structured
   editors for the facets that were JSON-only —
+
   - **System Capabilities**: a multi-select over the live `sys_capability` registry
     (scope-grouped, labelled chips).
   - **Row-Level Security**: per-policy rows (object · operation · enabled) with CEL
@@ -3409,6 +6100,7 @@ overflow-auto` region (bottom on-screen, within the viewport) and the table can
   platform primitive for "no records / no data" states. Two new props
   keep it flexible enough to absorb the hand-rolled variants that lived
   in `plugin-list`, `plugin-kanban`, and `plugin-dashboard`:
+
   - `showIcon?: boolean` — drops the icon container entirely. Used by the
     kanban board-level empty banner, which is a status banner rather than
     a true empty-state.
@@ -3417,6 +6109,7 @@ overflow-auto` region (bottom on-screen, within the viewport) and the table can
     empty state, which uses a large standalone glyph).
 
   Adopters:
+
   - `plugin-list` (`ListView` grid empty-state) — preserves the existing
     large icon, title, message, add-record button and `data-testid`s,
     but delegates the structural markup to `DataEmptyState`.
@@ -3479,6 +6172,7 @@ overflow-auto` region (bottom on-screen, within the viewport) and the table can
   The renderer now passes `schema.action` through `SchemaRenderer` to turn it
   into a real React element, and explicitly strips `action`/`icon` from the
   spread so schema-shaped objects don't reach DOM attributes.
+
   - @object-ui/types@5.1.1
   - @object-ui/core@5.1.1
   - @object-ui/i18n@5.1.1
@@ -3501,17 +6195,20 @@ overflow-auto` region (bottom on-screen, within the viewport) and the table can
 - bd8447d: Three platform-wide detail polish items.
 
   **Tighter page rhythm**
+
   - Outer `PageRenderer` padding `p-4 md:p-6 lg:p-8` → `p-3 md:p-4 lg:p-6`
     and outer body wrap `space-y-8` → `space-y-6` so list / detail / home
     pages share the same edge rhythm. Cuts ~16px of edge slack on lg.
 
   **Highlights KPI treatment**
+
   - `HeaderHighlight` now renders numeric / currency / percent / decimal
     values as KPI numbers (`text-xl md:text-2xl font-semibold tabular-nums`)
     instead of the uniform `text-sm font-semibold`, so amount / probability
     / count fields read as headline stats — Salesforce-style key facts.
 
   **Discussion footer upgrade**
+
   - `RecordActivityTimeline` now uses `RichTextCommentInput` (bold / italic /
     list / code, `@`-mention autocomplete, preview toggle, Send) instead of
     a bare `<textarea>`.
@@ -3526,6 +6223,7 @@ overflow-auto` region (bottom on-screen, within the viewport) and the table can
   accordion in flush mode dropped all per-item borders so the collapsed
   "Quotes / Products / Open Tasks" triggers stacked with zero visual
   separation.
+
   - `@object-ui/plugin-detail` `DetailSection`: override the `CardTitle`
     className to `text-base font-semibold tracking-tight`, slim down
     `CardHeader` padding (`py-3 px-4 sm:py-4 sm:px-6`) and `CardContent`
@@ -3540,6 +6238,7 @@ hover:no-underline` (Shadcn's hover-underline default looks busy on
     CRM-style related-list lists).
 
 - d51a577: feat(platform): Discussion attachments + @mention directory + Reference Rail aside
+
   - **Discussion attachments** — `RichTextCommentInput` now accepts an `extraSlot`
     and a `canSubmitEmpty` flag so hosts can mount the existing
     `CommentAttachment` composer beneath the editor without forking the toolbar.
@@ -3559,6 +6258,7 @@ hover:no-underline` (Shadcn's hover-underline default looks busy on
 - d1ec6a2: Fold inline-edit into the page-header overflow menu (HubSpot/Lightning
   pattern) and remove the orphan "Edit fields" toolbar row that previously
   floated between the tab strip and the first detail section.
+
   - `@object-ui/app-shell` `RecordDetailView`: injects a new `sys_inline_edit`
     system action that appears in the ⋯ overflow menu and dispatches a
     `objectui:record:inline-edit-toggle` window CustomEvent (filtered by
@@ -3575,6 +6275,7 @@ hover:no-underline` (Shadcn's hover-underline default looks busy on
     in `page:accordion` / `page:tabs` items.
 
 - d548d6b: Unify empty-state visuals across timeline + registered `empty` renderer.
+
   - `RecordActivityTimeline` and `ActivityTimeline` now use `DataEmptyState`
     instead of a bare `<p>` so empty timelines match list/related-list visuals
     (muted icon badge + centered copy).
@@ -3625,6 +6326,7 @@ hover:no-underline` (Shadcn's hover-underline default looks busy on
   not only contacts of that account).
 
   Two coupled fixes:
+
   1. `RelatedList` now requires `parentId` + `referenceField` to auto-
      fetch. When both are present it calls `dataSource.find(api,
 { $filter: { [referenceField]: parentId } })`. When either is
@@ -3653,6 +6355,7 @@ hover:no-underline` (Shadcn's hover-underline default looks busy on
   default detail view. They were missing cross-cutting affordances and
   shipped with English-only tab labels and heavy bordered section cards
   even when the host locale was Chinese. Track 1 closes the visible gap:
+
   - **app-shell `RecordDetailView`**: the `assignedPage` branch now wears
     the same chrome as the default branch — lifecycle managed-by badge
     and presence avatars in the top-right, `MetadataPanel` debug panel,
@@ -3681,6 +6384,7 @@ hover:no-underline` (Shadcn's hover-underline default looks busy on
   record detail page (lead, opportunity, future account/contact/case).
   Before this change it had two problems that bled into every custom
   page across the product:
+
   1. **Quadruple registration**: `@object-ui/layout` registered both
      `page-header` and `page:header`, and `@object-ui/components`
      independently registered `page:header` (and `page:section`).
@@ -3691,6 +6395,7 @@ hover:no-underline` (Shadcn's hover-underline default looks busy on
      than the default detail view it was meant to supersede.
 
   This commit:
+
   - Removes the `@object-ui/layout` `page:header` registration. The
     layout package keeps the legacy kebab-cased `page-header` alias only.
     The canonical renderer now lives in `@object-ui/components` and is
@@ -3716,6 +6421,7 @@ hover:no-underline` (Shadcn's hover-underline default looks busy on
   opportunity highlights strip looks coherent with the chip above it.
 
 - ddb08a7: feat(page:header,page:tabs): title fallback + single-tab strip auto-hide (Phase G slice 3 polish)
+
   - `page:header.resolvedTitle` now honors `objectSchema.titleFormat`
     (e.g. `{first_name} {last_name}`) and falls back through `name →
 full_name → title → subject → display_name → label` before degrading
@@ -3762,6 +6468,7 @@ full_name → title → subject → display_name → label` before degrading
   muted badge on every empty Activity/History tab).
 
 - b14fe09: Phase P.0 + P.5: tighten record-detail header chrome.
+
   - `RecordTitleChip` collapses the title row to a single baseline-aligned line — H1, eyebrow object label, copy-id, favorite star — instead of the previous two-row title + subtitle layout.
   - `record:details` extends the highlight-field dedup set to also exclude the title field resolved from `objectSchema.primaryField` (or the standard `name`/`full_name`/`title`/`subject`/`display_name`/`label` fallbacks). Removes the duplicate row that previously echoed the H1 (e.g. "客户名称: Acme Corporation") inside the field grid.
 
@@ -3778,6 +6485,7 @@ full_name → title → subject → display_name → label` before degrading
   underline when active. 'card' and 'pill' variants are unchanged.
 
 - 74962b0: feat(detail): record:discussion schema component + flush accordion variant
+
   - New `record:discussion` schema type lets authors place the record
     chatter feed anywhere in a custom Page schema. Wired through a
     shared `DiscussionContext` provider on the `assignedPage` branch
@@ -3804,6 +6512,7 @@ full_name → title → subject → display_name → label` before degrading
   accordion, discussion slot) that custom Lightning pages already enjoy.
 
   Changes:
+
   - `buildDefaultPageSchema` now emits `page:tabs.items` (correct shape
     for the renderer) rather than `tabs`.
   - `PageHeaderRenderer.resolvedTitle` honors `objectSchema.primaryField`
@@ -3917,6 +6626,7 @@ full_name → title → subject → display_name → label` before degrading
   For every tab item whose `count` is not set explicitly, the renderer walks the tab's children (depth-first) to find the first `record:related_list` schema node and issues a `limit:1` find through the active `dataSource` to read the matching `total`. The badge appears in the tab strip without spec authors having to wire counts manually.
 
   Behavior:
+
   - Explicit `count` in the spec always wins.
   - Probe is filtered by the parent record id via `relationshipField` when present (skipped until the parent record is loaded).
   - Best-effort: a failed probe just omits the badge — no error surface.
@@ -3957,6 +6667,7 @@ full_name → title → subject → display_name → label` before degrading
 ### Patch Changes
 
 - 6b683c8: fix(detail): clean up record page rendering
+
   - Drop `ai:chat_window` from the protocol-component placeholder list. The
     floating chat overlay (plugin-chatbot) is the canonical AI entry point;
     inline page schemas that still reference `ai:chat_window` now surface
@@ -3984,6 +6695,7 @@ full_name → title → subject → display_name → label` before degrading
   The report configuration panel is now safe to open on any spec-shape `Report` and only exposes fields that are actually persisted by `@objectstack/spec`.
 
   `@object-ui/plugin-report`:
+
   - Add a bidirectional `SpecFilterAdapter` so `ReportConfigPanel` can edit
     spec `FilterCondition` filters (`{field: value}`, `{field: {$op: value}}`,
     top-level `$and`/`$or`). Complex / nested filters fall back to a
@@ -4005,15 +6717,18 @@ full_name → title → subject → display_name → label` before degrading
   - 18 new unit tests cover the filter adapter round-trip.
 
   `@object-ui/components`:
+
   - `FilterBuilder` now guards against malformed external `value` props.
     Previously a spec-shape filter (`{is_active: true}`) would crash the
     component on first render; the builder now falls back to an empty
     AND group whenever `value` is not a valid `FilterGroup`.
 
   `@object-ui/i18n`:
+
   - Add `report.editor.*` strings to `en` and `zh`.
 
 - 8442c05: Improve report editor panel usability based on real-user browser testing:
+
   - **Wider config panel** — the report editor now defaults to a `--config-panel-width`
     of 440px (up from 280px), driven by a new optional `style` prop on
     `ConfigPanelRenderer`. Long field labels, report titles, type labels, and filter
@@ -4136,6 +6851,7 @@ full_name → title → subject → display_name → label` before degrading
   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
@@ -4218,6 +6934,7 @@ full_name → title → subject → display_name → label` before degrading
   plugin-designer, plugin-detail, plugin-editor, plugin-form, plugin-gantt,
   plugin-grid, plugin-kanban, plugin-list, plugin-map, plugin-markdown,
   plugin-report, plugin-timeline, plugin-view, plugin-workflow.
+
   - @object-ui/types@4.0.5
   - @object-ui/core@4.0.5
   - @object-ui/i18n@4.0.5
@@ -4232,6 +6949,7 @@ full_name → title → subject → display_name → label` before degrading
   Library builds (vite lib mode) now externalize every non-relative import instead of bundling third-party CJS dependencies into the published dist. This avoids inlined `require("react")` / `require("react-dom")` calls that cause `Calling \`require\` for "react" in an environment that doesn't expose the \`require\` function` runtime errors when consumer apps re-bundle the published dist.
 
   Specifically fixes:
+
   - `@object-ui/plugin-dashboard` no longer inlines `react-grid-layout` (and its transitive `react-draggable` / `react-resizable` CJS bundles). `react-grid-layout` is now declared as a peer dependency so consumers install a single ESM-friendly copy.
   - `@object-ui/components`, `@object-ui/plugin-calendar`, `@object-ui/plugin-charts`, `@object-ui/plugin-designer` no longer inline `react-i18next` / `i18next` / `use-sync-external-store` CJS shims.
   - All plugin packages now use a unified `external: (id) => !/^[./]/.test(id) && !id.startsWith(__dirname)` rule, ensuring future additions of CJS deps are automatically externalized.
@@ -4288,6 +7006,7 @@ full_name → title → subject → display_name → label` before degrading
   contract through the renderer end-to-end:
 
   **`@object-ui/types`** — `DataSource` gains four optional methods:
+
   - `createExportJob(resource, request)` → `{ jobId, status, estimatedRecords, createdAt }`
   - `getExportJobProgress(jobId)` → `{ status, processedRecords, totalRecords, percentComplete, downloadUrl, … }`
   - `cancelExportJob(jobId)` (optional)
@@ -4297,6 +7016,7 @@ full_name → title → subject → display_name → label` before degrading
   remain dependency-free.
 
   **`@object-ui/components`** — new public API:
+
   - `useExportJob({ dataSource, pollIntervalMs, onComplete, onError })` — owns the
     full polling loop, terminal-state handling, cancel, and download.
   - `<ExportProgressDialog open onOpenChange job filename closeAfterDownloadMs />` —
@@ -4315,24 +7035,29 @@ full_name → title → subject → display_name → label` before degrading
 - a2d7023: End-user feature batch — forms, designer history, import/export, and PWA offline sync.
 
   **Forms (`@object-ui/fields`, `@object-ui/providers`)**
+
   - `FileField`: native `<input capture="environment">` camera capture for mobile devices, plus a uploading-progress indicator driven by `UploadProvider`.
   - `ImageField`: per-image inline crop/rotate via the lazy-loaded `ImageCropperDialog` (canvas-based, zero new deps).
   - New `UploadProvider` in `@object-ui/providers` with pluggable adapters for S3 and Azure Blob (plus the default object-URL adapter for local previews). XHR-based with progress, abort, and retry.
   - `LookupField`: `lookup.dependsOn: string | string[]` to chain dependent lookups (e.g. State depends on Country); the trigger is gated until parent values are present and the OData `$filter` is built automatically.
 
   **Container-aware widget widths (`@object-ui/components`)**
+
   - New `useResizeObserver(ref)` hook exposing `{ width, height }` of any element. SSR-safe; reads the initial size via `getBoundingClientRect`.
   - `plugin-gantt` and `plugin-kanban` now react to their container size instead of `window.innerWidth`, so they behave correctly inside split panels and dashboards.
 
   **Designer history (`@object-ui/plugin-designer`)**
+
   - `useUndoRedo` (and therefore `useDesignerHistory`) gains `persistKey` + `storage` options to round-trip the undo/redo stack through `sessionStorage`, plus a `clearPersisted()` cleanup helper. Drafts now survive accidental tab refreshes.
   - New `<HistoryPanel>` component renders the timeline visually with one-click jump-to-checkpoint via the new `jumpTo(index)` API.
 
   **Import wizard (`@object-ui/plugin-grid`)**
+
   - Saved column-mapping templates: name, save, re-apply, and delete via a new template bar in the mapping step. Persisted under `objectui:import-templates:${objectName}` (override via `templateStorageKey` / `templateStorage`).
   - Inline validation correction: cells with errors in the preview step are now editable; corrections feed straight into the import without requiring a re-upload, with green-bar status indicators for fixed rows.
 
   **PWA offline sync (`@object-ui/mobile`)**
+
   - New `MemoryOfflineQueue` / `IndexedDbOfflineQueue` (`createOfflineQueue()` picks the best backend) backed by IndexedDB.
   - `createOfflineDataSource(inner, { queue })` wraps any DataSource so mutations issued while offline (or that fail with a network-style error) are queued and replayed in order on reconnect. Includes `replay()`, `drop()`, `clear()`, `pending()`, an `onChange` notifier, and an opt-in `resolveConflict` hook for stale-write conflicts.
   - New `useOfflineSync(source)` hook exposes `{ isOnline, pending, isReplaying, replay, drop, clear }` and auto-replays on the browser's `online` event.
@@ -4360,11 +7085,13 @@ full_name → title → subject → display_name → label` before degrading
   `FormSchema.mobileStickyActions` (new) is the lower-level escape hatch — applied automatically when `mobile.stickyActions` is set on `ObjectFormSchema`.
 
   **`@object-ui/plugin-form`** — `ObjectForm` now:
+
   - propagates `mobile.fullscreenLongText` to every textarea/markdown/html field as `mobile_fullscreen: true`,
   - sets `mobileStickyActions` on the inner form schema and adds `pb-20` padding so content isn't covered by the fixed bar,
   - when `mobile.stepper === true` (or `'auto'` + `useIsMobile()` + > `stepperMinFields` fields), routes the flat field list through the existing `WizardForm` with synthetic single-field "steps" — keeping per-step validation and the existing `Next`/`Back`/`Submit` flow.
 
   **`@object-ui/components`** — the registered `form` renderer adds:
+
   - a `mobileStickyActions` opt-in that turns the action row into a `position: sticky; bottom: 0` bar on small viewports, and
   - an inline `FullscreenTextarea` wrapper used when no field-package widget is registered, providing the same expand-button + edit-dialog UX so the feature works even in lighter setups.
 
@@ -4403,6 +7130,7 @@ full_name → title → subject → display_name → label` before degrading
   `@object-ui/app-shell` and `@object-ui/components` have been updated to
   point at the new paths; no runtime behaviour changed. A new
   `examples/README.md` provides a "which example should I use?" selector.
+
   - @object-ui/types@3.3.1
   - @object-ui/core@3.3.1
   - @object-ui/i18n@3.3.1
@@ -4547,6 +7275,7 @@ full_name → title → subject → display_name → label` before degrading
 - 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
@@ -4555,6 +7284,7 @@ full_name → title → subject → display_name → label` before degrading
   - 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
 
@@ -4570,6 +7300,7 @@ full_name → title → subject → display_name → label` before degrading
 - 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