@object-ui/plugin-form 17.3.0 → 17.6.0

package/CHANGELOG.md

@@ -1,5 +1,1158 @@
 # @object-ui/plugin-form
 
+## 17.6.0
+
+### Minor Changes
+
+- 8c0d52e: A form's ruled `submitBehavior.url` redirect can now be performed by the HOST, so a destination stays inside a console mounted at a sub-path (objectui#4989 defect 4).
+  
+  `ObjectForm` and `WizardForm` accept a relative in-app path and used to travel to it with `window.location.assign`. A rooted path resolves against the ORIGIN there, so under a mounted host — `<BrowserRouter basename="/_console">`, which the framework CLI configures for every embedded deployment — an authored `/thanks` left the application. The destination was correct and the navigation was wrong, and a published renderer cannot fix that alone: only the host knows its mount.
+  
+  **New: `HostNavigationContext` (`@object-ui/react`).** A host offers its own navigate; a renderer uses it when it is there:
+  
+  ```tsx
+  import { HostNavigationProvider } from '@object-ui/react';
+  import { useNavigate } from 'react-router-dom';
+  
+  function Bridge({ children }) {
+    const navigate = useNavigate();
+    return (
+      <HostNavigationProvider value={{ navigate: (to, o) => navigate(to, { replace: o?.replace ?? false }) }}>
+        {children}
+      </HostNavigationProvider>
+    );
+  }
+  ```
+  
+  `@object-ui/app-shell`'s `ConsoleShell` now mounts that bridge above every console route, so the console's own routes, and its basename, are what a post-submit redirect resolves against — and the redirect becomes an SPA transition instead of a full page load.
+  
+  **Nothing changes for a host that wires nothing.** With no provider the behaviour is byte-for-byte what it was: one `window.location.assign` of the resolved path after the declared `delayMs`. A host with no router has no basename, so origin-rooted resolution is already right there — the seam changes what a MOUNTED host gets and nothing else. `useHostNavigation()` outside a provider answers `{ navigate: undefined }` and never throws.
+  
+  Two mechanisms were weighed and rejected by the ruling, recorded so they are not re-proposed. **Reading React Router's context when a router happens to be present** is implicit, and unavailable anyway: a React context is a module-instance object, so reading the host's means importing `react-router` into the renderer — which `@object-ui/plugin-form` declares in none of its dependency fields, whose published build externalises every bare specifier, and which two real consumers (`apps/site`, `packages/plugin-view`) do not install. **Requiring `react-router` as a peer** is the honest version of the same thing and costs the package its property of dropping into any React application.
+  
+  What the host takes on by supplying a navigate: the destination becomes a client-side transition, so an in-app path with no matching route renders the host's not-found instead of a full page load. That is the host's routing table to answer for, which is why the choice is the host's. The contract verdict is unchanged either way — a destination `@objectstack/spec` refuses is refused identically with or without a seam, so an injected navigate can never launder a value the authoring door rejects.
+  
+  `navigateOnSuccess` is a different declared key with its own open contract question (objectui#5034) and is deliberately untouched here.
+
+### Patch Changes
+
+- 9b20dea: Fix: a `drawer` form with no `sections` now renders the object's declared
+  `fieldGroups` as sections, matching `ObjectForm` and `ModalForm`.
+  
+  `deriveFieldGroupSections` had exactly two call sites in the repo —
+  `ObjectForm` and `ModalForm` — so the same object, with the same metadata,
+  rendered one section per declared group in the modal create dialog and one
+  ungrouped flat list in the drawer. The author who laid the groups out in the
+  object designer saw them honoured on two surfaces out of three.
+  
+  `DrawerForm` now runs the same fallback the modal does: gated on "no explicit
+  `sections`, no `customFields`", over the same auto-layout-filtered field list
+  (system fields dropped, auto-generated fields dropped in create mode), with the
+  flat path's inferred column count carried onto the grouped layout. A curated
+  `sections` list from a form view still wins, and an object whose fields join no
+  declared group keeps its flat layout untouched. A derived group declaring
+  ADR-0085 `collapse` renders as a collapsible header, like an authored one.
+- 469b604: Fix: a `drawer` form with no `sections` now honours the object's field-level
+  conditional rules (`visibleWhen` / `readonlyWhen` / `requiredWhen`) and field
+  `group`.
+  
+  `ModalForm` and `DrawerForm` each carried their own copy of the "object-schema
+  field to runtime FormField" loop for the no-sections case, and the drawer's
+  copy had fallen behind: it stopped at `multiple`, so the ADR-0036 predicates
+  never reached the runtime field and `resolveFieldRuleState` had nothing to
+  resolve. A hidden field rendered anyway, a frozen field stayed editable (with
+  the server then dropping the write), and a conditionally-required field never
+  blocked the submit.
+  
+  Both containers now build that list through one shared `buildFlatFields`, which
+  resolves each field through the same `fromObjectSchema` the sectioned path uses
+  — so the next field-mapping fix lands once and reaches every container.
+- d7be3bd: `EmbeddableForm`'s thank-you redirect stops being mount-blind: an in-app destination now goes through the host's injected navigate.
+  
+  The redirect ended in one unconditional `window.location.href = url`. That is
+  right for the external destination this key deliberately admits, and wrong for
+  the in-app one it equally admits: a rooted path such as `/thanks` assigned to
+  `location.href` resolves against the ORIGIN root, so under a host mounted at a
+  sub-path — the framework CLI configures one for every embedded deployment, and
+  the console runs at basename `/_console` — the submitter landed outside the
+  application, usually on the host's own 404. Nothing refused either half of that
+  authoring, so the failure was silent. This is objectui#4989 defect 4 on the key
+  that card explicitly did not cover, and it is fixed here through the seam
+  objectui#5111 landed (`HostNavigationContext`, `@object-ui/react`).
+  
+  The destinations are now split by who can travel to them:
+  
+  - an **app-relative** destination (`/thanks`, `thanks`, `?ok=1`, `#done`) is
+    handed to the host's navigate when a host supplied one, so a mounted host
+    places it inside its mount; with no provider the behaviour is byte-for-byte
+    what it was — a host with no router has no basename, so origin-rooted
+    resolution is already correct there;
+  - an **external** destination admitted by `allowedRedirectHosts` keeps
+    browser-level navigation **unconditionally**. This is the seam's own declared
+    input contract, not a conservatism: `HostNavigationValue.navigate` documents
+    `to` as an application-relative path, "never an absolute URL", because a host
+    navigate is a client-side router transition. Since a relative reference cannot
+    carry an authority, the seam is now structurally incapable of being handed a
+    cross-origin URL.
+  
+  A same-origin **absolute** URL — the one shape those two arms do not name — also
+  keeps browser-level navigation. Routing it through the seam would mean rewriting
+  the author's full address into a path a mounted router then places at a
+  different address; an author who spelled out the whole address asked for that
+  address.
+  
+  Not changed, deliberately: `isRedirectUrlSafe` and `allowedRedirectHosts` —
+  WHICH destinations are followed. That acceptance set (same-origin OR the
+  author's allowlist) is this key's own contract, a refused destination reaches
+  neither the seam nor the browser, and objectstack#7496's relative-only ruling
+  belongs to `submitBehavior.url` and is not imported onto this key. The wait's
+  ownership (objectui#5049) and the thank-you panel's copy (objectui#5073) are
+  carried over unchanged: unmounting or pressing "Submit Another Response" still
+  cancels a pending redirect, seam or no seam.
+- a954b48: A public form's thank-you countdown ("Redirecting in {{seconds}} seconds…") now
+  actually counts down, instead of rendering a number once and leaving it frozen
+  for the whole wait.
+  
+  All ten locale packs document `publicForm.redirecting`'s `{{seconds}}` as "the
+  remaining seconds", but `EmbeddableForm` computed it exactly once — at the render
+  that first shows the thank-you panel — from `pendingRedirect.delayMs`, and never
+  touched it again. On the 3 second default delay, a submitter saw a fully static
+  "Redirecting in 3 seconds…" for the entire wait (objectui#5083).
+  
+  The number is now owned by a per-second `setInterval`, on the same ownership
+  model PR #5070 established for the redirect wait itself: an effect keyed on the
+  accepted destination (`pendingRedirect`), cancelled on unmount and on
+  `handleReset`'s `Submit Another Response` — the exact regression surface
+  objectui#5049 fixed for the navigation timer, restated here rather than
+  reintroduced. The interval also stops itself once it reaches 0, rather than
+  ticking indefinitely past a wait that has already ended.
+  
+  Nothing about WHICH destinations are followed or refused changes
+  (`isRedirectUrlSafe` / `allowedRedirectHosts`, objectui#4989), and neither does
+  the navigation wait's own ownership (objectui#5049 / PR #5070) — this is the
+  display only.
+- bda9b12: A public form's thank-you panel no longer promises a redirect its own guard just
+  refused, and the `texts.redirectBlocked` string can finally reach a screen.
+  
+  `EmbeddableForm` decided whether to redirect from `isRedirectUrlSafe` /
+  `allowedRedirectHosts`, but the panel's copy was keyed on something else: whether
+  a `thankYouPage.redirectUrl` had been *authored* (objectui#5073). An author who
+  declared a cross-origin destination without allowlisting its host therefore got a
+  submitter who was told `Redirecting in 3 seconds…` and was then never redirected.
+  The guard did its job; the screen contradicted it. That screen is the terminal
+  state of a public form, so nothing came after to correct the impression.
+  
+  On the same path, the `texts.redirectBlocked` string the refusal set was
+  unreachable in every locale. It was recorded with `setError(...)`, whose banner
+  lives in the form branch — and `setSubmitted(true)` has already run one statement
+  earlier, so the component is showing the thank-you branch, which renders no error
+  at all. That was the only assignment of the key anywhere; pressing
+  `Submit Another Response` cleared it rather than showing it.
+  
+  Both now follow the verdict:
+  
+  - The countdown renders on `pendingRedirect` — the destination that was actually
+    accepted — and reads its seconds from the delay captured with it, so the
+    displayed wait is the wait being served. A refused destination, and the
+    honeypot's silent fake-success (which accepts no destination either), simply
+    omit the line.
+  - A refused destination renders `texts.redirectBlocked` in the thank-you panel
+    when the author declared it — the case the key exists for, in the author's own
+    words to the public. Undeclared means silence; the author keeps the existing
+    `console.warn`, which is the channel for the person who can fix the
+    declaration.
+  
+  Which destinations are refused is unchanged: `isRedirectUrlSafe` and
+  `allowedRedirectHosts` are untouched, as is the timer ownership introduced for
+  objectui#5049. Nothing was ever at risk in the data — the write succeeds before
+  any of this — the harm was a false statement on the confirmation screen and a
+  shipped, translated string no user could see.
+- e354dd0: A public form's thank-you redirect no longer outlives the form that armed it, and
+  "Submit Another Response" now cancels it.
+  
+  `EmbeddableForm` armed the `thankYouPage.redirectUrl` wait with a bare
+  `setTimeout` inside the submit handler: the handle was not stored, nothing cleared
+  it, and no part of the component owned it (objectui#5049). Two consequences, and
+  the second needs no unmount at all:
+  
+  - For the whole of the delay a full-page navigation was pending that survived the
+    form being taken off screen — an embed removed by the host page, a route change,
+    a re-keyed subtree. With `redirectDelay` unset that window is the 3000 ms
+    default, so this was the normal state of every submit on this surface rather
+    than an edge authoring; the thank-you panel says as much out loud with
+    `Redirecting in {{seconds}} seconds…`.
+  - Under `allowMultiple`, `Submit Another Response` only flipped `submitted` back
+    to false while the pending navigation kept ticking. The component invited the
+    submitter into a fresh form and then, about three seconds later, threw the whole
+    page away while they were typing the next response.
+  
+  The wait now lives in an effect keyed on the accepted destination, with a
+  `clearTimeout` cleanup, so unmounting cancels it; and `handleReset` drops the
+  destination, so pressing `Submit Another Response` cancels it too. The button
+  offers the submitter a fresh form, and that offer cannot be honoured alongside
+  discarding the page a moment later. This is the same move `ObjectForm` /
+  `WizardForm` (objectui#5033) and `apps/console`'s `FormPage` already made for
+  their own copies of this defect.
+  
+  Nothing else changed. Which destinations are followed and which are refused is
+  still decided by the same `isRedirectUrlSafe` / `allowedRedirectHosts` guard, on
+  the same line as before — only who owns the wait changed. The delay is captured
+  together with the destination at the moment the write is accepted, so a host
+  re-rendering with a different `redirectDelay` mid-wait cannot restart the pause
+  under the submitter. The countdown copy is untouched. No data was ever at risk:
+  the write has already succeeded before the wait begins, so the harm was a
+  surprising navigation — and, on the `allowMultiple` path, the loss of what the
+  submitter had just re-typed.
+- f68018d: A form's declared redirect delay no longer outlives the form that armed it.
+  
+  `ObjectForm` and `WizardForm` consumed `submitBehavior: { kind: 'redirect' }` by
+  arming the `delayMs` wait with a bare `setTimeout` inside the submit handler. The
+  handle was not stored, nothing cleared it on unmount, and no part of the component
+  owned it — so for the whole of the declared delay there was a pending full-page
+  navigation that survived the form being taken off screen (objectui#5033). A
+  submitter who dismissed the modal or drawer variant after the confirmation, who
+  clicked an in-app link, or whose host re-keyed the subtree for its own reasons was
+  pulled away from wherever they had gone by a timer belonging to a form that no
+  longer existed. The longer the authored delay, the wider that window — and a
+  non-trivial delay is the intended authoring, since `delayMs` exists so the
+  confirmation is readable before the redirect.
+  
+  The wait now lives in an effect keyed on the accepted destination, with a
+  `clearTimeout` cleanup, so unmounting cancels it. This is the same move
+  `apps/console`'s `FormPage` already made for its own copy of this defect.
+  
+  `delayMs` semantics are unchanged: the pause is still a pause, an unset value is
+  still "go now" (a zero timer, exactly as the in-handler version scheduled it), and
+  which destinations are followed or refused is untouched — the contract verdict
+  that decides WHETHER to navigate is the same one, only WHEN it happens is now
+  owned by the component. The delay is captured together with the destination at the
+  moment the write is accepted, so a host re-rendering with a different `delayMs`
+  mid-wait cannot restart the pause under the submitter. Nothing was ever at risk of
+  being lost: the write has already succeeded before the wait begins, so the harm
+  was a surprising navigation, not a corrupted record.
+- 375efb4: Publish the authoring surfaces of the four GA `object-*` blocks
+  
+  `object-form`, `object-grid`, `object-master-detail-form` and `object-metric`
+  each honoured far more keys than they declared as registry `inputs`. An author —
+  very often an AI author — who wrote one of the undeclared keys got an
+  `unknown-prop` report from `sdui-parser` on a key that works, while the designer
+  panel and the generated `sdui-intrinsics.d.ts` denied it existed.
+  
+  68 keys are now declared with descriptions written to teach correct authoring:
+  `object-form` +20 (record binding, button labels, post-submit behaviour, mobile
+  overrides), `object-grid` +21 (sorting, pagination, grouping, selection, row and
+  bulk actions, navigation, export), `object-master-detail-form` +10, and
+  `object-metric` +14 (formatting, comparison, drill-down). No renderer behaviour
+  changes — this documents what already shipped, so the manifest, the generated
+  `.d.ts`, the designer panel and the renderers finally agree.
+  
+  Ten of `object-grid`'s spec-declared keys are deliberately NOT published:
+  its own `@deprecated` legacy spellings (`fields`, `staticData`, `selectable`,
+  `pageSize`, `showSearch`, `showPagination`, `defaultSort`, `defaultFilters`,
+  `resizableColumns`, `title`). The renderer keeps reading them so existing
+  documents render, but recommending a deprecated alias as new authoring surface
+  would harden it into a second dialect. Each canonical replacement — `columns`,
+  `data`, `selection`, `pagination`, `searchableFields`, `sort`, `filter`,
+  `resizable`, `label` — is declared, and each carries a description naming the
+  legacy spelling it supersedes.
+- 800f455: fix(fields): grid columns are keyed by the declared `name`, so spec-compliant grid metadata renders populated cells
+  
+  `GridField` declared its own column interface keyed by `field` and read
+  `c.field` at every site (`key=`, `row[…]`, the blank row, cell writes, the
+  column chooser, the running-total lookup), while the published
+  `GridColumnDefinition` in `@object-ui/types` — and the grid documentation, and
+  the `fields-grid` catalog examples — declare the key as `name`. Metadata
+  authored against the published type therefore rendered a grid with the correct
+  row count and every cell empty, plus a React "unique key" warning per column.
+  
+  The renderer now reads the declared `name`, and the master-detail derivation
+  (`deriveColumns` / `hydrateColumns` / `pickAmountField`) produces and consumes
+  the same key. There is deliberately **no** `col.field ?? col.name` alias: one
+  spelling at the producer (AGENTS.md #0.1).
+  
+  **Breaking for `field`-keyed columns.** Grid / line-item / master-detail
+  subform columns spelled `{ field: 'amount' }` must be re-spelled
+  `{ name: 'amount' }`. This affects author-supplied `columns` on the `grid`
+  field, `record:line_items`, `object-master-detail-form` details and a
+  relationship field's `inlineColumns`. Auto-derived columns (no explicit
+  `columns` block) need no change. List-view and `object-grid` columns are a
+  different contract (`ListColumn`) and keep their own `field` key.
+- 3b03704: `mobile.fullscreenLongText` now reaches fields the spec spells `richtext` (objectui#4831).
+  
+  `ObjectForm` is the one and only producer of the `mobile_fullscreen` flag: when a form
+  sets `mobile: { fullscreenLongText: true }` it stamps that flag onto the metadata of
+  every long-text field, and the widget renders an expand affordance plus a full-height
+  editing dialog from it. The list of types it stamped was four hand-written literals —
+  `textarea`, `field:textarea`, `field:markdown`, `field:html` — and `field:richtext` was
+  not among them.
+  
+  `richtext` is the name `@objectstack/spec`'s `FieldType` gives this type; `markdown` and
+  `html` are the other two, and all three are registry keys on ONE widget, `RichTextField`,
+  which has read the flag since objectui#3301. So the consumer side was complete and two of
+  the widget's three keys were stamped: a field authored exactly as the spec prescribes
+  (`type: richtext`) rendered the rich-text editor with no expand button, on a form whose
+  `mobile` documentation promises "textarea/rich-text get an expand button". `markdown` and
+  `html` beside it worked. This is the same hole objectui#4250 found in this package's
+  `WIDE_FIELD_TYPES`, which is why the twin set already lists `richtext` and this one did
+  not.
+  
+  Adding the missing key is the whole change; no other type's behaviour moves, and a form
+  that has not opted in still stamps nothing.
+- 958d757: The plugin-form documentation-site page now teaches the `validation` shape the
+  form renderer actually reads, so a copied example validates instead of only
+  looking as though it does.
+  
+  `content/docs/plugins/plugin-form.mdx` carried the same two defects
+  `packages/plugin-form/README.md` did before it was rewritten (objectui#5075 /
+  objectui#5118): the README half was fixed and the documentation-site mirror was
+  not touched.
+  
+  `### Form Field` redeclared a local `interface FormField` whose `validation` was
+  `ValidationRule[]`. No `ValidationRule` type exists in this repository under any
+  spelling, and `validation` is not an array — it is `FieldValidationRules`
+  (`packages/types/src/form.ts`), an object keyed by rule name. The block also
+  listed `defaultValue` and `className`, neither of which is a declared member of
+  `FormField`, and marked `type` and `label` required when `name` is the only
+  required key of the 23. The section no longer declares a local interface at all
+  — a hand-written `interface` in a documentation snippet compiles nowhere, which
+  is how it drifted this far — and references the declared keys instead, each one
+  measured against the renderer's read points.
+  
+  `### Form with Validation` authored the array to match, and that spelling fails
+  silently rather than loudly. The only reader of the key spreads it into the rule
+  object handed to react-hook-form (`const rules: any = { ...validation }`,
+  `packages/components/src/renderers/form/form.tsx:1652`); spreading an array
+  produces numeric keys, react-hook-form recognises none of them, and every rule
+  is dropped without an error. Measured against the real renderer: the old snippet
+  submits a two-character username under `minLength: 3` with no message shown,
+  while the rewritten one blocks it. The example is now annotated `FormSchema`, so
+  the array spelling is a compile error (TS2559) rather than a runtime surprise,
+  and a JSON variant is given alongside it for metadata authoring.
+  
+  Three facts a reader could previously only discover by experiment are now
+  stated: `validation.required` supplies the required *message* while `required` /
+  `requiredWhen` on the field decide whether it is required; there is no `email`
+  rule name, an email check is a `pattern`; and a hand-authored `pattern` has to
+  carry a RegExp, because react-hook-form applies a pattern only when its value is
+  `instanceof RegExp` — it is the object-metadata path (`buildValidationRules`)
+  that compiles a declared string into one.
+  
+  The two `DOC_TYPE_EXEMPTIONS` entries this page held in
+  `scripts/check-doc-component-types.mjs` are deleted with it. They exempted
+  `minLength` / `maxLength` as "ValidationRule discriminants under a field's
+  `validation[]`" — a reason whose every clause was the fiction being removed —
+  and without them the gate now fails if the array spelling returns.
+- bfb64ee: `plugin-form` README: the "Integration with Data Sources" section now teaches the adapter's real path instead of two keys no form renderer reads.
+  
+  The section taught backend wiring as two keys on a form schema — `dataSource`
+  (the adapter itself) and `resource: 'users'` — on an un-annotated
+  `const schema = { … }`. Neither key is read anywhere on either form route:
+  
+  - **`dataSource`** is *discarded* by the basic form. The renderer reads its
+    adapter off `SchemaRendererContext`
+    (`packages/components/src/renderers/form/form.tsx:1004`) and passes it down per
+    field (`:2061`); a same-named key arriving on the schema or props is dropped by
+    the discard destructures at `form.tsx:304` and `:2168`, so it reaches neither a
+    widget nor the DOM.
+  - **`resource`** is declared on neither `FormSchema` nor `ObjectFormSchema`. The
+    key exists in the protocol, but on `CRUDSchema` (`packages/types/src/crud.ts`,
+    `type: 'crud'`); no form renderer reads it under any spelling.
+  
+  Both survived compilation because `FormSchema` and `ObjectFormSchema` extend
+  `BaseSchema`, which declares `[key: string]: any` — so an invented key is never a
+  type error, merely never read. A reader who copied the block got a form that did
+  not connect to a backend, with nothing reported: what appeared to work was the
+  hand-written `onSubmit` closure, which genuinely runs (the renderer awaits it at
+  `form.tsx:1428`) using the adapter its *closure* captured, entirely independently
+  of the two keys beside it.
+  
+  The section is rewritten around the real mechanism: the adapter is injected once
+  by `SchemaRendererProvider` and travels on context, the metadata route uses
+  `object-form` with its required `objectName` + `mode`, and the TypeScript route
+  is a bare `form` whose `onSubmit` owns persistence. Both examples now carry real
+  type annotations (`ObjectFormSchema` / `FormSchema`) in line with the rest of the
+  file — an un-annotated object literal type-checks whatever is written in it. A
+  closing note records the one thing a top-level `dataSource` *does* mean on a
+  schema node: the spec's element binding (`{ object }`, objectstack#6953), which
+  explicitly rejects a live adapter (`element-data-source.ts:131` refuses any value
+  carrying a `find` method).
+  
+  Documentation only — no source, type or behavior change. This also removes a
+  self-contradiction inside the same README, whose "Registering a component under
+  your own key" section already stated the rule correctly ("never a `dataSource` —
+  that travels on `SchemaRendererContext`").
+- e09f9e8: Docs only: `packages/plugin-form/README.md`'s Schema API and Examples now spell
+  the keys the form renderers actually read (objectui#5075). Three connected
+  drifts, judged against the build product's `dist/index.d.ts` under `strict`:
+  
+  - **`validation` was written as an ARRAY** of `{ type, value, message }` entries
+    in three places. The real key is `FormField.validation?: FieldValidationRules`
+    — an OBJECT keyed by rule name (`required`, `minLength`, `maxLength`, `min`,
+    `max`, `pattern`, `validate`). The array form is worse than a type error,
+    because its runtime failure is SILENT: the only reader spreads the value into
+    the rule object handed to react-hook-form (`const rules: any = { ...validation }`,
+    `packages/components/src/renderers/form/form.tsx:1652`), and spreading an array
+    into an object literal yields numeric keys (`{ '0': …, '1': … }`).
+    react-hook-form's field validator reads exactly `required`, `maxLength`,
+    `minLength`, `min`, `max`, `pattern`, `validate`, `valueAsNumber` off its
+    descriptor, so every documented rule was dropped with nothing thrown — a form
+    copied from this README looked validated while validating nothing. The rewrite
+    also records two facts a reader could not have guessed: `validation.required`
+    supplies the required MESSAGE only (presence is decided by the field's own
+    `required` / `requiredWhen`), and a hand-authored `pattern.value` must be a
+    RegExp, since react-hook-form only applies a pattern whose value
+    `instanceof RegExp` and it is the object-metadata path (`buildValidationRules`)
+    that compiles a declared string into one.
+  
+  - **`type: 'multi-step-form'` is registered nowhere**, and `steps` is not a key
+    on any form schema — so the whole "Multi-Step Form" example rendered the
+    unknown-component placeholder, with the fields inside `steps` never read. The
+    example is replaced by the two real entry points: an `object-form` with
+    `formType: 'wizard'`, whose steps are its `sections` (this is what
+    `ObjectForm` routes to `WizardForm`), and the exported `WizardForm` itself
+    with inline section fields and no data source — the shape closest to what the
+    old snippet was reaching for. No new schema type was registered to make the
+    old spelling true.
+  
+  - **The `FormField` reference block declared a local `interface FormField`**,
+    which type-checks whatever it says because it is unrelated to the real type.
+    Five of its rows were wrong (`type` and `label` are OPTIONAL; `validation` is
+    the object above; `defaultValue` and `className` are not declared keys — the
+    form-level `defaultValues` and `span` / `colSpan` / `fieldContainerClass` are),
+    it named a `ValidationRule` type that exists nowhere in the repo, and it listed
+    7 of the real 23 keys. The block is now a key table over the real declaration,
+    with `FormSchema`'s own keys beside it, and both examples are annotated with
+    their real types — the annotation is the point: `FormField` and `BaseSchema`
+    both declare `[key: string]: any`, so an un-annotated `const schema = { … }`
+    accepts any invented key and a nonexistent key is never a compile error.
+  
+  No renderer behaviour changes, and no capability, export or type was added to
+  make an example true.
+- 03e5f97: `packages/plugin-form/README.md`: three assertions about this package's export
+  surface were false, and the export names are now taken from the built
+  `dist/index.d.ts` (TS compiler API `checker.getExportsOfModule`) with every
+  TypeScript block compiled against those same declarations under `strict`.
+  
+  - **`formComponents`** — fiction, and not a name that could be corrected: there
+    is no aggregate component map on the surface at all, so the "Manual
+    Registration" section described a mechanism that does not exist. Copying it got
+    `undefined` and threw on `Object.entries(undefined)`. It is replaced by what
+    actually happens: registration is a side effect of importing the entry, whose
+    six `ComponentRegistry.register(...)` calls claim
+    `plugin-form:object-form`, `view:form`, `plugin-form:embeddable-form`,
+    `plugin-form:form-analytics`, `plugin-form:object-master-detail-form` and
+    `record:line_items` — the two `skipFallback: true` calls being why bare `form`
+    and bare `line_items` are *not* taken over. The section also lists the real
+    export surface, and shows the thing the old snippet was reaching for: putting
+    an exported component on a schema type of your own, with the caveat that the
+    package's own registered renderers are internal wrappers that first resolve
+    `dataSource` from `SchemaRendererContext`.
+  - **`FormSchema` / `FormField`** — real types imported from the wrong package.
+    Both are protocol types declared in `@object-ui/types` (`src/form.ts`); this
+    package imports them and does not re-export them, so the documented import was
+    a `TS2305` pair. Only the import path changed — no re-export was added to make
+    the old path true, since widening a package's public surface is a contract
+    change and not a documentation fix. The section now also points at the form
+    types that *are* on this entry (`TabbedFormSchema`, `WizardFormSchema`,
+    `ModalFormSchema`, …).
+  - **`isRuntimeDefault` "(re-exported here)"** — the create-defaults section
+    claimed the predicate is re-exported by this package. It is re-exported by
+    `src/schemaDefaults.ts` for internal use only, never from the entry, and the
+    package publishes just the `"."` export — so `import { isRuntimeDefault } from
+    '@object-ui/plugin-form'` is another `TS2305`. The parenthetical now says where
+    the re-export actually lives.
+  
+  No code, types or runtime behaviour change — the diff is one README plus this
+  changeset. It declares a patch because `README.md` is in the package's published
+  `files`, so the correction reaches npm with the next release.
+- ae804ec: `ObjectForm` and `WizardForm` now consume a declared `submitBehavior: { kind: 'redirect' }` the way objectstack#7496 ruled it (objectui#4989): the destination is a **relative** path, `{{record.field_name}}` tokens are substituted from the record the submit just wrote and URL-escaped as the redirect is built, and a destination outside the contract is **refused on screen** instead of being dropped in silence.
+  
+  Both call sites previously read the value through `isSameOriginUrl` — resolve against `window.location.href`, compare origins — and navigated when that answered yes. That is not an open redirect (a cross-origin destination never reached the navigation) but it diverged from the ruled contract three ways, all fixed here:
+  
+  - **An out-of-contract destination was dropped in silence.** When the guard answered no the `if` simply did not fire: no toast, no error, no confirmation. The write had already succeeded, so the submitter was left facing a still-filled form with no feedback about what happened — and the obvious next move, submitting again, wrote a second record. A refusal now shows the spec's own author-facing prescription in an alert beside the confirmation that the record WAS written, toasts it, and replaces the filled form so there is nothing left to resubmit. Silence is the one outcome the ruling's consumer half rules out.
+  - **A same-origin ABSOLUTE url was followed**, where the contract is relative-only — so this renderer accepted a spelling the authoring door refuses, which is how a rejected spelling stays alive in a corpus. The verdict is no longer restated here at all: `resolveSubmitRedirect` asks `@objectstack/spec`'s own `FormViewSchema` at the moment of use, so an absolute URL, a protocol-relative `//host`, a backslash, a whitespace or control-character smuggle, a malformed token or a document-relative path is refused with the spec's own wording — and a later widening of the ruling is followed by the version pin rather than by an edit here.
+  - **`{{record.field_name}}` tokens were never substituted**, so an authored `/thanks?ref={{record.id}}` navigated with the literal braces in the query. Substitution now happens where the ruling assigns it — when the redirect is built — from the values as submitted with whatever the DataSource answered layered on top, and every interpolated value goes through `encodeURIComponent`, so a token is a value in the path and never a way to add path structure.
+  
+  `delayMs` semantics are unchanged. `navigateOnSuccess` is a different declared key with its own dialect and its own open contract question, and is deliberately untouched; `isSameOriginUrl` survives because that key still needs it.
+  
+  **Escalated rather than guessed at, and since ruled:** this change left a ruled in-app path handed to a browser-level navigation, which resolves it against the origin root, so under a host mounted at a sub-path the destination still left the app (objectui#4989 defect 4). Applying the mount means learning it, and every mechanism available to a published renderer package changes its contract. The maintainer ruled the mechanism on 2026-08-17 — an optional injected navigation seam — and it ships in the same release; see the `plugin-form-injected-navigation-4989` changeset for what a host now supplies and what a host that supplies nothing still gets.
+- 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.
+- 2165d88: Rename four component-props types off the names `@objectstack/spec` starts owning in
+  17.0.0, keeping the old spellings as deprecated aliases. No behaviour changes and no
+  importer breaks.
+  
+  `@objectstack/spec/ui` exports `ObjectCalendarProps`, `ObjectFormProps`, `ObjectGridProps`
+  and `ObjectKanbanProps` from 17.0.0, where each is the AUTHORED props document of the
+  matching element — a serialisable authoring surface (`z.input< typeof
+  ObjectGridPropsSchema >`). The same-named interfaces here are the RENDERERS' props: a live
+  `dataSource`, records pre-fetched by a parent, and the host callbacks. Two different things
+  under one word, so the local ones are renamed rather than derived, following the split this
+  repo already made for `PageHeaderProps` -> `PageHeaderComponentProps` and the
+  `Record*ComponentProps` family in `@object-ui/types`:
+  
+  | package | new name | old name |
+  |---|---|---|
+  | `@object-ui/plugin-calendar` | `ObjectCalendarComponentProps` | `ObjectCalendarProps` |
+  | `@object-ui/plugin-form` | `ObjectFormComponentProps` | `ObjectFormProps` |
+  | `@object-ui/plugin-grid` | `ObjectGridComponentProps` | `ObjectGridProps` |
+  | `@object-ui/plugin-kanban` | `ObjectKanbanComponentProps` | `ObjectKanbanProps` |
+  
+  Every old name is still exported from its package barrel as a `@deprecated` alias denoting
+  the SAME type, pinned per package by `spec-symbol-4650.test.ts`, so existing imports keep
+  compiling. New code should use the `ComponentProps` spelling.
+  
+  `@object-ui/app-shell` carries no API change: its `SECRET_MASK` — the ADR-0100 credential
+  read mask, which 17.0.0 moves into `@objectstack/spec/data` — is renamed to
+  `OBJECTUI_SECRET_MASK` at its declaration in `views/metadata-admin/widgets.tsx`. That
+  constant is package-internal and is not re-exported from the barrel, so nothing published
+  changes; the rename exists so the local copy cannot be read as the spec's own definition
+  while this repo is still pinned below the release that exports it.
+- Updated dependencies [88085e3]
+- Updated dependencies [69251bf]
+- Updated dependencies [57e668f]
+- Updated dependencies [516663d]
+- Updated dependencies [41ac1b7]
+- Updated dependencies [1eaf0a1]
+- Updated dependencies [a09bc33]
+- Updated dependencies [460c4d0]
+- Updated dependencies [0ae27f7]
+- Updated dependencies [2533ec5]
+- Updated dependencies [78c0f9a]
+- 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 [8b9dc62]
+- Updated dependencies [1184192]
+- Updated dependencies [a2a9747]
+- Updated dependencies [65e88e6]
+- Updated dependencies [a1609a6]
+- Updated dependencies [53f23bc]
+- Updated dependencies [c4533dc]
+- Updated dependencies [be60815]
+- Updated dependencies [37f6844]
+- Updated dependencies [93de4f6]
+- Updated dependencies [2b50261]
+- Updated dependencies [384f30d]
+- Updated dependencies [ac600e5]
+- Updated dependencies [97fba31]
+- Updated dependencies [232f61a]
+- Updated dependencies [d374caf]
+- Updated dependencies [5673576]
+- Updated dependencies [c1ef923]
+- Updated dependencies [911ceaa]
+- Updated dependencies [98eab36]
+- Updated dependencies [af5e292]
+- Updated dependencies [3fbbea1]
+- Updated dependencies [0bffb18]
+- Updated dependencies [800f455]
+- Updated dependencies [5458414]
+- Updated dependencies [3241559]
+- Updated dependencies [7f96b10]
+- Updated dependencies [167ec42]
+- Updated dependencies [616a2a5]
+- Updated dependencies [6c68b13]
+- Updated dependencies [0046d8f]
+- Updated dependencies [f1d4748]
+- Updated dependencies [bea374e]
+- Updated dependencies [b1119ec]
+- Updated dependencies [5607092]
+- Updated dependencies [9f23d2b]
+- Updated dependencies [578e025]
+- Updated dependencies [af025ee]
+- Updated dependencies [d109a4d]
+- Updated dependencies [598c89a]
+- Updated dependencies [4a0bd17]
+- Updated dependencies [b8b9af4]
+- Updated dependencies [d8b9259]
+- Updated dependencies [31676be]
+- Updated dependencies [8c0d52e]
+- Updated dependencies [aff10e2]
+- Updated dependencies [70a774b]
+- Updated dependencies [9ce096f]
+- Updated dependencies [e05db88]
+- Updated dependencies [7458a41]
+- Updated dependencies [ad13d63]
+- Updated dependencies [5ffcc14]
+- Updated dependencies [d971e51]
+- Updated dependencies [97abb24]
+- Updated dependencies [deb157a]
+- Updated dependencies [9c60144]
+- Updated dependencies [e7747f1]
+- Updated dependencies [d2ce342]
+- Updated dependencies [9695da7]
+- Updated dependencies [ac2f332]
+- Updated dependencies [a777058]
+- Updated dependencies [75444e3]
+- Updated dependencies [58b8346]
+- Updated dependencies [2d0bd16]
+- Updated dependencies [a9e17b4]
+- Updated dependencies [b8ce7dc]
+- Updated dependencies [dad51e5]
+- Updated dependencies [1c9c342]
+- Updated dependencies [787c738]
+- Updated dependencies [8396656]
+- Updated dependencies [dbbd38a]
+- Updated dependencies [61556dc]
+- Updated dependencies [8871c14]
+- Updated dependencies [93fe362]
+- Updated dependencies [dfc6975]
+- Updated dependencies [3cf4de0]
+- Updated dependencies [c9dc811]
+- Updated dependencies [144ef9b]
+- Updated dependencies [138ab04]
+- Updated dependencies [a0b9e91]
+- Updated dependencies [99bd015]
+- Updated dependencies [21e4585]
+  - @object-ui/types@17.6.0
+  - @object-ui/fields@17.6.0
+  - @object-ui/i18n@17.6.0
+  - @object-ui/react@17.6.0
+  - @object-ui/components@17.6.0
+  - @object-ui/core@17.6.0
+  - @object-ui/permissions@17.6.0
+
+## 17.5.0
+
+### Patch Changes
+
+- 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.
+
+- c32a8a1: `richtext` fields are placed like the long-form fields they are — four layout sets stopped spelling the type three ways the spec rejects
+
+  `@objectstack/spec` spells the WYSIWYG type `richtext`, one word, and **rejects** `rich_text` and `rich-text`: both exist only as typo keys in the spec's own `suggestFieldType` table, so `FieldSchema` refuses a field declared with either. Four sets that place fields by matching the RAW type string carried nothing else — `SKIP_TYPES` in the related list spelled it `rich_text`, both `WIDE_FIELD_TYPES` and `SECONDARY_FIELD_TYPES` spelled it `rich-text` — so each set was inert for the only spelling a producer can emit, and every one of them named the type it was failing to handle.
+
+  For a real `richtext` field that meant: it was auto-derived into a related-list column, it never spanned the full row in a multi-column detail section or form (unlike `markdown` and `html` sitting right beside it in the same sets), and it stayed in the dense primary section of the record page instead of dropping into "More details". All four move together — half of them would have left the detail page and the form disagreeing about the same field, which is worse than the uniform gap.
+
+  The dead spellings are dropped rather than kept alongside the live one: the alias table is the single place aliases belong, and a set that carries both invites the next drift. The pins are derived from the spec's own `FieldType` vocabulary instead of enumerated, so a member that stops being a real type name fails by name — replacing an assertion that was green only because the set contained the string it asked about.
+
+  `markdown` joins `richtext` and `html` in the related list's `SKIP_TYPES`, on a measurement rather than on the assumption that it renders raw. It does not: markdown and richtext both render through `MarkdownCellRenderer`, formatted and sanitized. The reason none of the three works in a table is that the formatted output is block-level — a heading, paragraphs, a list — inside a single-line truncating cell, so a document shows as one clipped heading with the rest invisible. `textarea` stays derived for the same reason read the other way: it renders as plain truncated text, which is a useful column. Author-declared columns are untouched — this set only filters the zero-config auto-derive walk.
+
+- Updated dependencies [0e67b53]
+- Updated dependencies [ceccdcf]
+- Updated dependencies [d6e5124]
+- Updated dependencies [debad27]
+- Updated dependencies [dc2aa3e]
+- Updated dependencies [ee66e2e]
+- Updated dependencies [e2e6360]
+- 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 [4dadf0d]
+- Updated dependencies [ae10a01]
+- Updated dependencies [0f21348]
+- Updated dependencies [d2e2caf]
+- Updated dependencies [92876f0]
+- Updated dependencies [f279deb]
+- Updated dependencies [4b70d28]
+- Updated dependencies [eb7f586]
+- Updated dependencies [e901131]
+- Updated dependencies [ebb4e0e]
+- Updated dependencies [3a9021e]
+- Updated dependencies [d9d3463]
+- Updated dependencies [2a40f69]
+- Updated dependencies [bec3e14]
+- Updated dependencies [613b167]
+- Updated dependencies [b4d3c22]
+- Updated dependencies [1f9b905]
+- Updated dependencies [8f60d73]
+- Updated dependencies [cb13400]
+- Updated dependencies [828549a]
+- Updated dependencies [e1ade8f]
+- Updated dependencies [bc64bfe]
+- Updated dependencies [abb0f81]
+- Updated dependencies [38ab505]
+- Updated dependencies [3e19fe7]
+- Updated dependencies [bb58d1d]
+- Updated dependencies [433ff9f]
+- Updated dependencies [5cc847c]
+- Updated dependencies [e7663f2]
+- 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 [36310dc]
+- Updated dependencies [52d878a]
+- Updated dependencies [405e808]
+- Updated dependencies [49ae9f4]
+- Updated dependencies [a3ae404]
+- Updated dependencies [bfdf3d4]
+- Updated dependencies [bb68488]
+- Updated dependencies [c0f9a4b]
+- Updated dependencies [b1e42d0]
+- 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 [f5e1143]
+- 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 [5bf09fd]
+- Updated dependencies [06915b0]
+- Updated dependencies [ff84b05]
+  - @object-ui/i18n@17.5.0
+  - @object-ui/react@17.5.0
+  - @object-ui/components@17.5.0
+  - @object-ui/core@17.5.0
+  - @object-ui/fields@17.5.0
+  - @object-ui/types@17.5.0
+  - @object-ui/permissions@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.
+
+- 1bd6faa: fix(fields,plugin-form): stop the inline child grid from collapsing `datetime`/`time` columns onto the `date` control
+
+  `deriveMasterDetail`'s `fieldTypeToColumnType` mapped `date`, `datetime` and `time` onto the single `date` grid column type, and `GridField` renders that as `<input type="date">`. The consequence was not cosmetic: that control emits a bare `YYYY-MM-DD` on change, so a user who merely re-picked the **day** of a `datetime` cell silently wrote the record's time component out of existence — a `14:30` became midnight with no warning and no undo.
+
+  `GridColumn['type']` now carries `'datetime'` and `'time'` alongside `'date'`, and each renders its own control with its own read/write adapter:
+
+  - `datetime` → `<input type="datetime-local">`, read through `toDateTimeInputValue` and written back through `fromDateTimeInputValue`, so the stored shape stays ISO-8601 and read and write share one basis (the contract `DateTimeField` already follows, objectui#3127).
+  - `time` → `<input type="time">`, round-tripping the stored zone-less `HH:mm[:ss]` verbatim.
+  - `date` → unchanged.
+
+  The read-only surfaces are fixed with it. `displayText()` and the read-only table both fell through to `String(value)` and printed the raw stored ISO on screen (`2026-06-17T00:00:00.000Z`); each temporal type now formats as itself — a day for `date`, day + local time for `datetime`, the wall clock for `time`. That could not be fixed before the type collapse was undone, because with one column type the renderer had no way to know which of the two to show.
+
+  Authors writing explicit grid `columns` can now declare `type: 'datetime'` / `type: 'time'`; previously those spellings were not part of the exported union.
+
+### Patch Changes
+
+- 8497579: A required field whose `defaultValue` is a runtime token is submittable from a create form
+
+  `@objectstack/spec` lets a field's `defaultValue` be a runtime _instruction_
+  rather than a value — the `DEFAULT_VALUE_TOKENS` family (`'NOW()'`,
+  `'current_user'`) or a CEL Expression envelope. The server resolves those per
+  insert, in `ObjectQL.applyFieldDefaults`, for any field that arrives absent or
+  null, which is why a create form must leave them empty: seeding the literal text
+  `NOW()` into a datetime input and submitting it suppresses the very resolution
+  the declaration asked for.
+
+  Correct for an optional field. Combined with `required: true` it deadlocked:
+
+  ```ts
+  remind_at: Field.datetime({ required: true, defaultValue: 'NOW()' }),
+  ```
+
+  the control opened empty, the client-side required rule refused the submit, and
+  there was nothing sensible for the user to type — the declaration had already
+  said what the value is, and omitting the field is exactly what makes the server
+  supply it. Same shape as the `required` + static-default case, one layer down.
+
+  In **create** mode a runtime `defaultValue` now suppresses the client-side
+  `required` rule, and the field is omitted from the payload. The producer
+  guarantees the value at insert, so the field is not "missing" — it is
+  server-owned. `required: true` alongside a runtime default is coherent authoring
+  (storage-level required, producer-guaranteed), not an authoring error.
+
+  Both halves matter. Suppressing the rule alone would have been half an answer: a
+  rendered control registers with the form whether or not anything seeded it, so
+  an untouched runtime-default field still reached the payload as `undefined` — or
+  as `''` once anything focused it. `undefined` is invisible to a
+  `JSON.stringify` inspection while remaining a KEY a data source may translate
+  into an explicit column write, and `''` is neither absent nor null, so it stores
+  a blank and defeats the declaration outright.
+
+  Three boundaries came with it, each pinned in both directions:
+
+  - **Create only.** An edit form shows a persisted row, where the token was
+    resolved at insert; blanking a required column there is a real removal and is
+    still refused.
+  - **Runtime defaults only.** A static literal default _is_ seeded into the
+    control, so if the user clears it they have removed a value that was really
+    there — `required` still fires.
+  - **The rule, not the field.** A value the user does type is submitted normally
+    and outranks the declared default. Only the "must not be empty" check is
+    suppressed.
+
+  Seeding and this rule read ONE predicate (`isRuntimeDefault`), so a form can
+  never seed a field it also refuses to submit. The suppression also drops the
+  required marker and `aria-required` for that field in create mode, since both
+  are driven by the same boolean — the honest reading, as the user really is not
+  required to provide the value. Surfacing what the server _will_ supply, as a
+  non-authoritative preview, is a separate follow-up.
+
+  Not extended to `requiredWhen` (the conditional-required CEL rule), which is
+  resolved downstream in the form renderer against the live record.
+
+- f0c9a90: Create forms now open with the object schema's declared `defaultValue`s
+
+  A field declared `required: true, defaultValue: 'draft'` opened the console's
+  create dialog with an empty select and a required marker: the user had to pick a
+  value the system already knew, with every neighbouring option — some with side
+  effects — one click away. `defaultValue` + `required` produced the worst create
+  experience of any modelling choice, strictly worse than declaring no default.
+
+  The server was never the problem. Omitting the field from a create request
+  stores the declared default, because `ObjectQL.applyFieldDefaults` resolves it on
+  insert. The gap was container-side: `ObjectForm` seeded its opening values from
+  the object schema, and the five other object-form containers did not — their
+  create branch set the form data to `initialData || initialValues || {}` and never
+  looked at the schema. The console's create dialog is the global `<ModalForm>`,
+  one of those five. Modal, Drawer, Tabbed, Split and Wizard now seed through one
+  shared module (`schemaDefaults`), so a create form opens preselected and
+  submittable.
+
+  Three boundaries came with it, each pinned in both directions:
+
+  - **Create only.** An edit form shows a persisted row as the server holds it.
+    `ObjectForm`'s pass had been running in every mode, so a column the record
+    leaves unset showed the default — arming a silent write of a value the user
+    never chose on the next save of any other field. It is now gated on the same
+    "no persisted record" test the data-fetch effect uses.
+  - **Static defaults only.** A `defaultValue` may be an instruction the server
+    resolves per insert — the `NOW()` / `current_user` runtime tokens
+    (`DEFAULT_VALUE_TOKENS`) or a CEL Expression envelope. `ObjectForm` had been
+    seeding those verbatim, which put the literal text `NOW()` into a datetime
+    input and then submitted it as the field's value, suppressing the very
+    resolution the declaration asked for (`applyFieldDefaults` only fills fields
+    that arrive empty). Those are now left empty for the server.
+  - **Callers still win.** `initialData` / `initialValues` outrank a schema
+    default — a lookup prefill or a duplicate-record seed is the more specific
+    instruction.
+
+  Only the field-level `defaultValue` is honoured, not a select option's
+  `default: true`, even though `@objectstack/spec`'s `SelectOptionSchema` declares
+  that key: the insert path resolves `defaultValue` and nothing else, so seeding
+  from option-level `default` would preselect values the server would never have
+  applied — a UI-only second default contract.
+
+- 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.
+
+- 022002a: `PageComponentSchema.dataSource` now reaches the remaining object-bound public
+  blocks: `object-gantt` / `object-timeline` / `object-map` / `object-pivot` /
+  `object-master-detail-form` / `embeddable-form` / `record:line_items`
+  (objectstack#7121).
+
+  objectstack#6953 wired the spec's per-element data binding
+  (`dataSource: { object, view?, filter?, sort?, limit? }`) to the eight blocks it
+  named and left the same declaration inert on these seven. Each gates its fetch on
+  its own object key and nothing mapped `dataSource.object` onto it, so a page
+  written the way the spec documents rendered an empty gantt / an empty timeline
+  rail / a map with no markers / an empty cross-tab / a field-less form — 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, through the
+  shared `ElementDataSourceGate` (no change to it or to the resolution layer): 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 on every one of
+  these blocks instead of degrading to the object's full scope.
+
+  Each block maps **only** the keys it genuinely reads, which for this batch means
+  several keys stay deliberately unmapped rather than being parked somewhere
+  plausible:
+
+  - `object-gantt` and `object-map` take `object` / `filter` / `sort`; neither has a
+    row cap or a field-list read site.
+  - `object-pivot` takes `object` / `filter`; a cross-tab orders itself by its own
+    row/column grouping and cannot be computed over a truncated page.
+  - `object-timeline` takes `object` only — its fetch is
+    `find(objectName, { options: { $top: 100 } })`, with no filter/sort read site
+    at all, so a named view is error-checked and then contributes nothing.
+  - `embeddable-form` and `object-master-detail-form` take `object` only (the
+    parent object, in the master-detail case); a form that writes one record has no
+    collection query for `filter` / `sort` / `limit` to narrow.
+  - `record:line_items` takes `object` onto **`childObject`** — the collection it
+    actually lists — and nothing else: its query is the parent FK plus a fixed
+    `$top: 500`, and its `columns` are editable `GridColumn` objects rather than a
+    field-name projection a view could supply.
+
+  The per-block coverage table, including every residual gap named above, is in
+  `content/docs/guide/data-source.md`.
+
+  No behaviour change for a block that carries no `dataSource`: the binding-free
+  path returns the schema by reference, so nothing remounts and nothing refetches.
+
+- 6d762da: The five locale keys behind #3546's eight no-fallback `t()` call sites are now defined in all ten packs, so the built-in-view toasts, the activity-timeline source link, the wizard's required-field toast and the Gantt refresh button's accessible name are translated instead of falling back to English — or, on two surfaces, to the key itself (part of #3546).
+
+  `scripts/check-i18n-call-site-keys.mjs` measured 258 keys that a `t()` call site asks for and no pack defines. These five were the subset with no working inline default: `console.objectView.cannotEditMetaView`, `console.objectView.cannotDeleteMetaView`, `detail.viewSource`, `gantt.toolbar.refresh` and `wizard.missingRequired`. Adding a `defaultValue` is deliberately not the fix — that mechanism is what kept all 258 invisible for months.
+
+  **Two of the eight sites really did render the raw key**, and both go through a binding with nothing in front of i18next. `ObjectView.tsx` calls `useObjectTranslation()` directly, so five toasts read `console.objectView.cannotEditMetaView` / `cannotDeleteMetaView` on screen; the `|| 'Built-in views cannot be renamed.'` guards next to them were dead on every path, because i18next answers a miss with the key itself and a non-empty string never falls through `||`. Those four unreachable English strings are removed rather than repaired: one key served four call sites (rename / pin / set-as-default / configure), so the pack copy covers any change to a built-in view instead of naming one operation. `RecordActivityTimeline.tsx` fails the same way for a subtler reason — `useDetailTranslation` is `createSafeTranslation(..., 'detail.back')`, and because `detail.back` does resolve, the probe hands back i18next's `t` for every key and bypasses the defaults map wholesale, so `detail.viewSource` reached the user verbatim.
+
+  **The other two sites were not rendering a raw key**, contrary to the issue's description, and are fixed here as the milder "English in all ten languages" class. `wizard.missingRequired` is its own hook's probe key, so the probe failed and `createSafeTranslation` correctly served its English default. `gantt.toolbar.refresh` goes through `useGanttTranslation`, which deliberately does not use `createSafeTranslation` and falls back per key — so the refresh button's `aria-label` was "Refresh", in English, never the key. Screen-reader users heard an English word rather than an identifier; a `zh` session now hears 刷新.
+
+  Regression cover is provider-mounted on purpose: with no `I18nProvider` the defaults maps answer every one of these keys and the assertions pass while the console is broken, which is precisely the false-green the issue documents. For the two sites whose English output was already correct, `en` cannot discriminate before from after — the `zh` assertions are the ones that pin the fix.
+
+- 11c1e71: Resolve a `select` field declared `multiple: true` to the `field:multiselect` widget, so the object form's visible label actually names the chip picker it renders (objectui#3986).
+
+  `mapFieldTypeToFormType` keyed the widget id on the field's `type` string alone, so an object-schema `{ type: 'select', multiple: true }` picklist — a spec-legal, entirely ordinary shape — became `field:select`. `SelectField` then delegated to `MultiSelectField` on `config.multiple`, so the component that RENDERED was the chip picker while everything keyed on the widget id still answered for the single-value combobox. Above all the label-association declaration (`ComponentMeta.labelling`, objectui#3961), which the form renderer resolves per widget id: the host emitted `<label for>` at the chip row's wrapper `div`, where a `for` is inert — `HTMLLabelElement.control` returns `null`. Visually the field had a label; in the accessibility tree that label named nothing. Measured on the object-form path, `role=group` + accessible name went from 1 for a `multiselect`-typed field (fixed in objectui#3975) to 0 for this one.
+
+  Declaring `select` itself `labelling: 'group'` was not available: a single-value select's trigger is a labelable `button[role=combobox]` whose `for` association works, and a bare `select` is a builtin the renderer resolves without consulting the registry at all. The fix is therefore at the producer — the widget id now carries the arity, so one place decides which widget renders and the declaration can no longer be addressed to a widget that is not rendering.
+
+  - `mapFieldTypeToFormType(fieldType, config?)` takes an optional second argument — the rest of the field definition, of which only `multiple` is read. Existing single-argument calls are unchanged, and so is every type outside the new table: `select` is the only one whose `multiple` form is a different WIDGET. The spec's multi-capable set is larger (select / lookup / file / image, with `radio` on the select branch and `user` storing like `lookup`), but `LookupField`, `FileField` and `ImageField` each render both arities themselves, so their id — and their labelling declaration — is already right for either.
+  - The four object-form producers pass the pair: `ObjectForm`, `DrawerForm`, `ModalForm`, and `sectionFields` (Tabbed / Wizard / Split / Drawer / Modal). In `sectionFields` the id is now computed once from the EFFECTIVE pair, after view-level overrides have merged, because `multiple` is itself a spec `FormField` key: a view restating only `multiple: true` over a single-value object field moves the widget too, and `multiple: false` moves it back.
+  - `SelectField`'s `multiple` delegation is KEPT, not retired. Measured, it stays reachable from three entrances that never consult the alias map: the inline grid editor (`FieldEditWidget` finds `select` in its own table first), `ActionParamDialog` (`resolveFormWidgetType` returns `select` from `fieldWidgetMap` first), and hand-written SDUI addressing `field:select` by name with `multiple` on its metadata.
+
+  Read-only rendering of these widgets is untouched (objectui#4005), as is the built-in `Select` branch (objectui#3976).
+
+- 523be48: `object-timeline` and `record:line_items` now apply the filter / sort / row cap they are given, so a named `dataSource.view` narrows them instead of contributing nothing
+
+  These were the two residual gaps in objectstack#7121's per-block coverage table
+  (objectstack#7137). Both blocks are object-bound lists, both accepted the spec's
+  per-element `dataSource` binding, and neither had a read site for `filter` or
+  `sort` anywhere in its fetch:
+
+  - `object-timeline`'s entire query was
+    `find(objectName, { options: { $top: 100 } })`.
+  - `record:line_items`' was the parent FK plus a fixed `$top: 500`.
+
+  So `dataSource: { object, view: 'hot' }` resolved the view — a typo still reported
+  a configuration error, it never degraded into an unfiltered query — and then
+  dropped everything the view said. The rendered rows could be **wider than the view
+  they named**, silently, which is exactly the class of mistake AI-authored metadata
+  hides best: the page looks like it works. objectstack#7121 deliberately left the
+  keys unmapped and recorded the gap rather than writing composed values onto schema
+  keys nobody read; this closes it at the fetch instead.
+
+  What each block now reads:
+
+  - **`object-timeline`** — `$filter: schema.filter`,
+    `$orderby: convertSortToQueryParams(schema.sort)`, and
+    `$top: schema.limit ?? 100`, matching the form `object-gantt` / `object-map` /
+    `object-calendar` already use. Its registry mapping gains
+    `filter` / `sort` / `limit`; `columns` stays unmapped, because a timeline
+    projects the fields its `timeline` config names.
+  - **`record:line_items`** — the composed filter is **AND-combined** with the parent
+    relationship condition through `mergeFilterNodes`, never substituted for it, the
+    same way `record:related_list` composes its own since objectstack#7118: a
+    line-items panel is always scoped to the record it sits on, so an _additional_
+    criterion can only narrow this parent's children and can never surface another
+    parent's rows. `sort` becomes the load order and `limit` the row cap (default
+    500). `columns` stays unmapped — here they are `GridColumn[]` driving an editable
+    grid, not a field-name projection, so a view's column list would be the wrong
+    _shape_ rather than merely a wider answer.
+
+  **Behaviour change worth knowing about:** the timeline's default window is now a
+  real cap. `{ options: { $top: 100 } }` nested the limit under a key that is not a
+  `QueryParams` field and that no adapter in this repo reads (`convertQueryParams`
+  maps `params.$top`), so the intended window never reached the wire and a timeline
+  over a large object fetched whatever the server chose to return. It is now sent as
+  `$top`, and authorable via `limit` or a view's `pagination.pageSize`.
+
+  `@object-ui/core` gains `convertSortToQueryParams`, the sort→`$orderby` lowering
+  the three sibling blocks each inline privately. It is shared rather than copied
+  twice more, and is slightly more faithful to the declared contract than those
+  copies: a sort entry that omits `order` means ascending instead of being dropped
+  (the string spelling `"amount"` already meant ascending in the same copies), and
+  nothing orderable yields `undefined` rather than a truthy empty `{}`. Migrating
+  the three existing copies onto it is objectstack#7148 and is not done here.
+
+- Updated dependencies [794c497]
+- Updated dependencies [993336f]
+- Updated dependencies [f0a625a]
+- Updated dependencies [b5980f4]
+- Updated dependencies [8aad9fd]
+- Updated dependencies [6719877]
+- Updated dependencies [56ff091]
+- Updated dependencies [0186cdc]
+- Updated dependencies [7864f03]
+- Updated dependencies [ea41a59]
+- Updated dependencies [0cbdca8]
+- Updated dependencies [d229dfa]
+- Updated dependencies [ecae400]
+- Updated dependencies [4bc6c23]
+- Updated dependencies [d3e738a]
+- Updated dependencies [c3b01a7]
+- Updated dependencies [f5f8744]
+- Updated dependencies [7ed3360]
+- Updated dependencies [69becd2]
+- Updated dependencies [5e52495]
+- Updated dependencies [0fa5e4d]
+- Updated dependencies [b750823]
+- Updated dependencies [5bfaabd]
+- Updated dependencies [e06810e]
+- Updated dependencies [ab3ad4f]
+- Updated dependencies [65bb513]
+- Updated dependencies [c97a45e]
+- Updated dependencies [b19162d]
+- Updated dependencies [c2fd122]
+- Updated dependencies [1bd6faa]
+- Updated dependencies [ac2139c]
+- Updated dependencies [b14ab3a]
+- Updated dependencies [e24d767]
+- Updated dependencies [8c60819]
+- Updated dependencies [aca561a]
+- Updated dependencies [e64a52e]
+- Updated dependencies [844d17f]
+- Updated dependencies [d8a0be4]
+- Updated dependencies [48132f7]
+- Updated dependencies [4dcd52a]
+- Updated dependencies [42ae5c6]
+- Updated dependencies [0ef9dfd]
+- Updated dependencies [f4b97c8]
+- Updated dependencies [1d723e3]
+- Updated dependencies [0109f54]
+- Updated dependencies [7e5bb5d]
+- Updated dependencies [fbc23e0]
+- Updated dependencies [6d762da]
+- Updated dependencies [e6fdbdc]
+- Updated dependencies [54233b1]
+- Updated dependencies [c2ecbae]
+- Updated dependencies [f9faa7d]
+- Updated dependencies [97b63d7]
+- Updated dependencies [6bb454a]
+- Updated dependencies [11c1e71]
+- Updated dependencies [523be48]
+- Updated dependencies [7e2b7e9]
+- Updated dependencies [33526fd]
+- Updated dependencies [32413ec]
+- Updated dependencies [c1e1e6b]
+  - @object-ui/components@17.4.0
+  - @object-ui/react@17.4.0
+  - @object-ui/core@17.4.0
+  - @object-ui/fields@17.4.0
+  - @object-ui/i18n@17.4.0
+  - @object-ui/types@17.4.0
+  - @object-ui/permissions@17.4.0
+
 ## 17.3.0
 
 ### Minor Changes
@@ -1268,6 +2421,7 @@ undefined` — swallowing the very errors the command exists to print. Now reads
   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
@@ -1282,6 +2436,7 @@ undefined` — swallowing the very errors the command exists to print. Now reads
 
   **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
@@ -2459,6 +3614,7 @@ parentData, details)` — emits a parent `update` op (index 0) then diffs each
 ### Patch Changes
 
 - 89ae109: Fix click navigation and required-FK form rendering
+
   - **plugin-grid**: ObjectGrid's `getSelectFields()` now always includes `id` in
     the SELECT projection. Previously, when a view configured `columns` without
     `id`, the SQL driver stripped it from results, and row-click handlers silently
@@ -2521,6 +3677,7 @@ parentData, details)` — emits a parent `update` op (index 0) then diffs each
   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.
@@ -2598,11 +3755,13 @@ parentData, details)` — emits a parent `update` op (index 0) then diffs each
   `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.