@object-ui/fields 17.2.0 → 17.5.0

package/CHANGELOG.md

@@ -1,5 +1,1523 @@
 # @object-ui/fields
 
+## 17.5.0
+
+### Minor Changes
+
+- ebb4e0e: The date formatter's last three en-US channels now follow the display locale
+  (objectui#4272).
+
+  objectui#4468 (PR #4512) pointed every date _renderer_ at `useDisplayLocale()`.
+  Three channels were out of its reach because they are properties of the
+  formatter's signature and of its callers rather than of any renderer, so a `zh`
+  console still met English dates in three places:
+
+  - **`formatDate`'s `'short'` branch** hardcoded
+    `toLocaleDateString('en-US', { month: 'short' })`, so it rendered an English
+    month even when the caller had threaded `options.locale` into that very call.
+    Its only consumers are ObjectGrid's two mobile-card date cells, which threaded
+    no locale — fixing either half alone moves nothing, so both land here.
+  - **`formatDateTime` took no options parameter at all**, so no caller could
+    localize it however hard it tried; it always handed `Intl` an `undefined` tag,
+    which means the MACHINE's locale — neither of the repo's two locale channels.
+    The parameter is optional and lands together with its consumers, plugin-gantt's
+    four tooltip call sites.
+  - **The lookup picker's MongoDB `$date` fallback** called a bare
+    `toLocaleDateString()` with no tag.
+
+  One resolver everywhere, as before: `useDisplayLocale()` (tenant regional
+  default → active UI language → `'en'`). `Intl` accepts `'zh'` verbatim, so there
+  is still no mapping table anywhere.
+
+  English output is byte-identical at every touched site — `en` and `en-US` agree
+  on all twelve short month names — and the `'short'` layout itself is unchanged:
+  only the month token is localized, the compact `"Jan 15, '24"` shape around it
+  is a deliberate fixed layout for narrow cards.
+
+  `@object-ui/fields` is `minor` because `formatDateTime`'s new optional parameter
+  is visible in the package's entry `.d.ts`; the plugin packages' own `.d.ts` files
+  are byte-identical, so their change is module-local.
+
+- 36310dc: `formatPercent` groups its output and follows the display locale — the last
+  tooltip/cell channel (objectui#4553).
+
+  PR #4557 threaded the gantt tooltip's number and currency rows and measured that
+  the percent row could not follow: `formatPercent(value, precision)` took no
+  locale parameter, and its whole body was
+  `${percentDisplayValue(value).toFixed(precision)}%`. It built no
+  `Intl.NumberFormat` and never reached `formatDisplayNumber` — so unlike its
+  siblings it did not render in the MACHINE's locale, it rendered in **no** locale:
+  an ASCII decimal mark, never a grouping separator, byte-identical on every
+  machine.
+
+  **English output MOVES, and that is the fix.** Because the function never
+  grouped, `1235%` was wrong in en-US too, not only in German. Grouping and locale
+  therefore land together:
+
+  |            | before  | after          |
+  | ---------- | ------- | -------------- |
+  | en, 1234.5 | `1235%` | `1,235%`       |
+  | de, 1234.5 | `1235%` | `1.235\u00a0%` |
+  | de, 80     | `80%`   | `80\u00a0%`    |
+
+  Values below the grouping threshold are unchanged in English (`80%`, `12.5%`,
+  `33.33%`), so the move is confined to four digits and up. German changes at every
+  magnitude, because the no-break space before the sign is part of the locale's
+  percent convention — which is what routing through `Intl` buys over appending a
+  literal `%`.
+
+  The scaling contract is untouched: `percentDisplayValue` still disambiguates a
+  fraction-stored percent (`0.8` → 80%) from a whole one, so the list cell and the
+  dashboard measure formatter still agree.
+
+  Consumers are threaded in the same change, the parameter never landing
+  speculatively:
+
+  - **fields** — `PercentCellRenderer`, on BOTH of its paths. Its whole-percent
+    branch (`progress` / `completion` fields, which store 0-100 and must skip the
+    fraction scaling) was a second bare `toFixed` call; leaving it behind would
+    have made one grid internally inconsistent, so both branches now share one
+    locale-aware body and differ only in the scaling policy.
+  - **plugin-gantt** — the tooltip percent row, completing objectui#4553's switch.
+  - **plugin-grid** — the mobile card's percent cell, which sits in the same
+    density row as a date cell objectui#4272 had already localized.
+  - **plugin-dashboard** — `renderFieldValue`'s percent branch. It is a plain
+    function rather than a component, so it takes the locale as an optional fourth
+    parameter beside the `tenantCurrency` already threaded that way, and both of
+    its callers pass it and declare it in their memo dependency arrays.
+
+  Bumps follow each package's own `.d.ts` diff, measured in both directions.
+  `@object-ui/fields` and `@object-ui/plugin-dashboard` are `minor` on the
+  objectui#4272 / PR #4544 precedent — quoted from that changeset: "`@object-ui/fields`
+  is `minor` because `formatDateTime`'s new optional parameter is visible in the
+  package's entry `.d.ts`; the plugin packages' own `.d.ts` files are
+  byte-identical, so their change is module-local." Here `formatPercent` and
+  `renderFieldValue` each gain an entry-visible optional parameter, while
+  plugin-gantt's and plugin-grid's `.d.ts` files are byte-identical and stay
+  `patch`.
+
+- 52d878a: fix(fields): `formatPercent` renders percentage points directly — ties round half-up and extremes keep every digit
+
+  `formatPercent` rendered a value that is already in percentage POINTS through
+  `Intl`'s `style: 'percent'`, which expects a FRACTION, so the body divided by
+  100 for `Intl` to multiply straight back. That round trip is not
+  value-preserving: `Intl` formats from the shortest decimal representation of the
+  double it is handed, and the quotient's is not the authored one. A stored
+  `1.005` at 2 decimals rendered `1.00%` where half-up on the authored decimal is
+  `1.01%`; `1.45` at 1 decimal rendered `1.4%` for `1.5%`. Every case was a
+  last-digit off-by-one — the failure mode least likely to be noticed and most
+  likely to be trusted.
+
+  The body now renders through `style: 'percentPoints'` with no scaling round
+  trip. Measured on this repo's runner (node v22.22.2 / ICU 78.2), 27,577 of
+  1,200,003 ordinary en-US forms move (0.005-step grid to 2,000, precisions
+  0/1/2), and the same artefact at the top of the double range is gone too:
+  `Number.MAX_SAFE_INTEGER` percentage points rendered `9,007,199,254,740,990%`
+  and now render `9,007,199,254,740,991%`.
+
+  The locale percent CONVENTION is unchanged — this is a numeral move only.
+  `'percentPoints'` is `Intl`'s `style: 'unit'` / `unit: 'percent'`, re-measured on
+  this call shape across 720 combinations (10 locales x 18 values x 4 precisions):
+  0 convention differences, 130 numeral differences. The no-break space in
+  de/fr/ru/sv, Turkish's prefixed sign, Arabic's own percent sign and Bengali's
+  digits all render exactly as before. Percent SCALING (a stored fraction below 1
+  scaling by 100) is upstream of the render and untouched.
+
+  A percentage point now reads identically in a list cell and in a dashboard
+  measure, which `formatMeasure` already rendered this way.
+
+- 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
+
+- e2e6360: A `Field.address` value now reads as a formatted postal address on the record detail page, instead of stringified JSON.
+
+  The display (read) registry mapped `address` straight to `JsonCellRenderer`, so a populated address rendered as `{"street":"中策路 1 号","city":"杭州",…}` — while a `location` field sitting next to it in the same field group rendered formatted, and the create/edit dialog rendered the very same value as proper Street / City / State / ZIP / Country inputs. The gap was display-side only: the input registry has always carried `address`. Both read surfaces the detail page exposes are affected and both are fixed, because they share one `displayValue` path — read mode, and the inline-edit read state (the row carrying the pencil affordance, before a field is actually being edited).
+
+  Layout is not invented for the read side. `AddressField`'s readonly branch already collapsed a stored address to a single line, and that rule — `Street, City, State ZIP, Country`, with `state` and the postal code sharing one comma group — is now the _only_ implementation, moved into a pure `address-format` module that both surfaces call. A readonly form and a detail page therefore cannot spell one stored address two ways; a second copy next to the renderer would have been a rule that drifts. The module is deliberately React-free, so the eagerly-loaded barrel can format a cell without pulling `AddressField` and its inputs out of the lazy widget chunk.
+
+  Partial values degrade the way the readonly line already did: absent, non-string and whitespace-only parts are dropped rather than spaced over, so a street-only address renders as `中策路 1 号` and never as `, , ,` or as the string `undefined`. Legacy records whose postal code was written under `zipCode` (objectstack#5143) still render it, matching what the input widget reads.
+
+  Nothing is silently swallowed by the change: a value the formatter cannot recognize — an object carrying no known part — keeps today's compact-JSON rendering rather than disappearing, and `{}` or a null value shows the usual empty placeholder. A plain string address passes straight through. `location`, `geolocation`, and the genuinely structural `json` / `object` types are untouched.
+
+  The address _input_ is unchanged on every surface, including the create/edit dialog.
+
+- dde7283: `chatbot` and `chatbot-enhanced` now pass only whitelisted DOM props to their host element (objectui#4431)
+
+  Both registrations destructured `schema` and `className` and forwarded everything else. `SchemaRenderer` hands a registered component the authored node's own keys, the contents of its `props` container, the ARIA it resolved and the host's trailing props — so all of it became attributes on the chat root `div`, because React passes unknown lowercase attributes through in silence and stringifies object values. Measured through the real SDUI path with a data-source adapter attached: **14 non-DOM attributes on each widget**, including `datasource="[object Object]"` (the injected adapter, which only appears on a deployment that really loads data) and a camelCase `arialabel` sitting next to the resolved `aria-label`, so the element carried each ARIA value twice under two spellings — one of them meaningless to assistive technology.
+
+  Both are now consume-or-whitelist: configuration is read off `schema` as before, the evaluated `disabled` verdict is consumed by name, and only `toDomProps`' output reaches the element. The resolved `aria-label` / `aria-describedby`, `role`, `id`, `tabIndex` and the `data-*` family still arrive — dropping them would have been an accessibility regression dressed as a leak fix, so the pin asserts the delivered set exactly, not just the absent one. `chatbot-floating` is untouched: its content mounts through a portal and its root never spread.
+
+  `@object-ui/core` gains the shared executor this migration needs (`utils/dom-props.ts`): `toDomProps` for the SDUI widget contract, plus `pickDomProps` — the mechanism — for a package whose own contract declares a different key set. That is the objectui#4409 dependency direction: plugin packages declare `@object-ui/core` and must not grow a dependency on `@object-ui/fields` to reach a whitelist.
+
+  `@object-ui/fields` keeps its own key list and its compile-time bindings, and now executes them through core's mechanism. Its behaviour is unchanged and its exported `DomProps<P>` is the same structural type. The two lists differ for measured reasons and no longer can drift silently: `name` and `disabled` are legal only on form controls, which is what every field widget renders and what `FieldWidgetComponentProps` declares, while `role` is resolved by `SchemaRenderer` for every SDUI node and is not part of the field contract. A new assertion binds every shared key in both directions, with `role` named as the single deliberate exception.
+
+- 0f21348: Currency amounts now follow each currency's own ISO 4217 fraction-digit
+  convention instead of a hardcoded 2 (objectui#4361).
+
+  Both currency formatting paths in `@object-ui/fields` picked a fraction-digit
+  width and handed it to `Intl.NumberFormat`, which OVERRIDES the digit count
+  `Intl` already knows for the currency being rendered. `formatCurrency` derived
+  its width from the VALUE's wholeness alone (`isWhole ? 0 : 2` — a literal 2 for
+  every currency on earth), and `CurrencyField` defaulted an undeclared
+  `precision` to the same literal. So a yen amount was printed with cents the
+  currency does not have and a dinar amount with one digit fewer than it does:
+
+  |              | before         | after       |
+  | ------------ | -------------- | ----------- |
+  | JPY `1234.5` | `¥1,234.50`    | `¥1,235`    |
+  | KWD `1.5`    | `KWD 1.50`     | `KWD 1.500` |
+  | CLP `1234.5` | `CLP 1,234.50` | `CLP 1,235` |
+  | BHD `2.5`    | `BHD 2.50`     | `BHD 2.500` |
+  | USD `1234.5` | `$1,234.50`    | `$1,234.50` |
+  | USD `1234`   | `$1,234`       | `$1,234`    |
+
+  Both call sites now derive the width from the currency itself
+  (`Intl.NumberFormat(undefined, { style: 'currency', currency })
+.resolvedOptions().maximumFractionDigits`, memoized per code) and switch
+  wholeness against THAT.
+
+  **The whole-number convention is extended, not retired.** Simply dropping both
+  bounds and letting `Intl` decide would have fixed the digit count while turning
+  `$1,234` back into `$1,234.00` — the Salesforce convention `formatCurrency`
+  documents and objectui#4033 pinned. A whole amount still drops the fraction, now
+  for every currency: `KWD 1` renders `KWD 1`, not `KWD 1.000`. Two-decimal
+  currencies are byte-identical to before, which is why the objectui#4033 and
+  objectui#4332 pins pass unchanged.
+
+  **On `CurrencyField`, an explicitly authored `precision` still wins** — it is
+  authored metadata and authored metadata keeps priority, so a JPY field declaring
+  `precision: 2` still renders `¥1,234.50`. Only an ABSENT `precision` derives from
+  the currency; because that derivation is the widget's one precision, it also
+  reaches the spinner `step` and the blur rounding, so a JPY field no longer offers
+  a `0.01` step for a currency with no minor unit. Whether a declared `precision`
+  that contradicts the currency's ISO 4217 digits should be REJECTED at publish
+  time is a contract question, filed upstream in `@objectstack/spec` rather than
+  answered here by overriding the author.
+
+  Reachable wherever the resolved currency is not a 2-decimal one — the field's
+  `currency`, `currencyConfig.defaultCurrency`, or the tenant default (ADR-0053).
+
+- d2e2caf: fix(fields): `formatCurrency` keeps both cents digits on a fractional amount
+
+  The symbol branch passed `minimumFractionDigits: 0` against a
+  wholeness-switched `maximumFractionDigits`, which handed `Intl` the range
+  `[0, 2]` — and `Intl` emits the shortest representation in range, so a real
+  cents value of `.50` was printed as `.5`. Any price ending in a zero cent digit
+  rendered one digit short: `$1,234.50` as `$1,234.5`, `$19.90` as `$19.9`,
+  `$0.50` as `$0.5` — money on a record page and in grid cells reading as a data
+  error rather than a formatting one.
+
+  Both bounds now take the same wholeness-switched width, so the function
+  delivers the contract its own doc comment states: a fractional amount shows
+  exactly two digits, a whole amount still drops `.00` (`$1,234`). The
+  no-currency branch and the bad-currency fallback already behaved this way; only
+  the symbol branch disagreed.
+
+  Reaches every consumer of the shared helper: `CurrencyCellRenderer`,
+  `ObjectGrid`, the dashboard `recordFields` and `ObjectGantt`.
+
+- 3a9021e: fields: the currency adornment has one symbol channel
+
+  `CurrencyField` carried the same one-entry fact twice — a dead `CURRENCY_SYMBOLS`
+  map that nothing read, and a live `currency === 'USD' ? '$' : currency` ternary
+  two lines below it. Both were hand copies of knowledge `Intl` already carries,
+  and both are gone: a new `currencySymbol(currency, locale)` beside
+  `currencyFractionDigits()` reads the `currency` part of the very format the
+  widget's readonly branch already renders amounts with.
+
+  USD is unchanged at the display-locale default. Other currencies now show their
+  real symbol instead of the bare ISO code — `€` for EUR, `¥` for JPY, `£` for
+  GBP — which is what the same widget's readonly mode has always displayed; the
+  edit adornment simply stopped disagreeing with it. Currencies CLDR has no symbol
+  for (KWD, BHD, CHF, ISK, CLP) still render their code, exactly as before.
+
+- 8f60d73: `@object-ui/fields` and `@object-ui/plugin-editor` stop publishing their test declarations
+
+  Both packages' build tsconfigs set `include: ["src"]` with no test exclude, so every test file entered the declaration program and its `.d.ts` was written into `dist/`. Both are published (`private` is false, `files` contains `dist`), so those declarations shipped: 85 from `@object-ui/fields` and one from `@object-ui/plugin-editor`. Adding the test exclude the other twenty-odd packages already use removes them.
+
+  Nothing else about either artifact moves. Measured by building each package both ways from a cleared `dist/`, then diffing the file lists: `@object-ui/fields` goes from 163 files to 78 and `@object-ui/plugin-editor` from 6 to 5, every one of the 86 disappearances is a `*.test.d.ts`, no file appears, and all 83 surviving files are byte-identical by sha256 — including each package's entry `dist/index.d.ts`. The entry type surface is therefore unchanged and no import can break; this is the tarball shedding files nothing resolved.
+
+  The type coverage those files were a side effect of did not go with them. Because the build program read the tests, these two packages counted as "tests type-checked" in `scripts/check-type-check-coverage.mjs` — a correct verdict reached through an emit nobody wanted. Excluding the tests alone would have silently dropped 86 test files out of every `tsc` program, so the same change adds a `tsconfig.test.json` per package, chained from each package's `type-check` script, and the coverage gate stays at 41 of 41 packages compiling their tests with zero declared debt on both sides of the change.
+
+- 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.
+
+- 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.
+
+- bb58d1d: i18n: the two search placeholders become pack values, and four values the packs served in English get translated
+
+  **objectui#4375** — `ListView` and `LookupField` built their search placeholder as
+  `t(key) + '...'`, so the ellipsis was a literal concatenated in code: it stayed ASCII
+  in all ten locales on screens where objectui#3878 had converged everything else on
+  U+2026, and no pack could opt out of it (sharpest in `ar`, where a left-to-right run
+  was appended to right-to-left text). Both now read `table.search`, which is already
+  the repo's search-input placeholder key — `data-table`, `RecordPickerDialog` and
+  `PeoplePicker` render it too — and is translated with the right ellipsis in all ten
+  packs. No new keys.
+
+  **objectui#4376** — `list.loading` served the English `Loading records…` in eight of
+  the nine translation packs (`zh` alone had translated it); `designer.undo` and
+  `designer.redo` were English in all nine; `appDesigner.snakeCaseHint` in `ko`, `pt`,
+  `ru` and `ar`. All translated, reusing each pack's own established vocabulary. A new
+  pin (`untranslated-identity-4376.test.ts`) fails on any value byte-identical to `en`
+  inside a non-Latin pack unless the key is on an explicit 22-entry allowlist.
+
+- 433ff9f: An image field's declared `maxSize` is enforced before the upload starts, not after it finishes
+
+  `ImageField` received a `maxSize` and ignored it. `paramToField` copies `maxSize` onto the field config for every action param regardless of type, so an image param declared with a 5 MB limit handed the widget its constraint and the widget uploaded anyway: a 6.3 MB PNG fired the full `presigned → PUT → complete` chain and rendered a thumbnail, with no rejection anywhere. The sibling file param, declared the same way, refused the identical pick without a single request. Reported from a QA run driving the two side by side (objectui#4141).
+
+  Both of the widget's upload doors now check the limit first. The native picker rejects oversize picks before any request, keeping FileField's partial-acceptance rule — the in-limit members of a multi-select still upload, and only the oversize ones are reported. The crop dialog is the second door and needed the check in its own right: the cropper re-encodes to PNG, so cropping an in-limit JPEG can produce a blob _over_ the limit, and it is the crop's size that is uploaded. A rejected pick or crop now surfaces the same message the file widget has always shown, in a new error row — this widget had no surface for rejections before, because it never rejected anything.
+
+  The guard itself moved into one shared `maxSizeError` helper that both widgets call, rather than a second copy living in the image widget. The check is the only thing between a declared limit and a real upload, and a per-widget copy is what let these two drift apart unnoticed in the first place. Both widgets also share the existing `fields.file.exceedsMaxSize` message: it names a file and a limit, says nothing file-specific, and is already translated in all built-in locales, so no new key was added and no translation is pending. FileField's own behavior is unchanged — same threshold, same message, same partial acceptance.
+
+  An undeclared `maxSize` still means unrestricted; the falsy check is preserved deliberately, so a missing limit can never be read as a zero-byte one.
+
+- e7663f2: fix(detail): inline edit no longer destroys array values or flattens types on the record page
+
+  `InlineFieldInput`'s type switch ended in a raw text input, and every type it had
+  no branch for landed there: the value was displayed through `coerceToSafeValue`
+  and written back as whatever the user typed — a bare string.
+
+  Two damage classes survived the earlier passes. Array-valued fields (`tags`,
+  `checkboxes`, an options-less multi picklist) were offered for editing as
+  `"a, b"` — `coerceToSafeValue` joins arrays — and saved back as that string, so
+  the array was gone. Type-lossy scalars (`toggle`, `slider`, `progress`,
+  `rating`, `radio`) round-tripped through `String()`, so a boolean column
+  received `"true"`, a numeric one `"42"`, and `radio` accepted any free-typed
+  value its option list never offered.
+
+  Types the switch already routes keep their editors. Everything else that the
+  fields package can edit inline now falls back to `FieldEditWidget` — the same
+  control the form renders, `json` → the code editor included — and only genuinely
+  string-valued types (`text`, `textarea`, `email`, `phone`, `url`) keep the plain
+  input. A drift guard asserts every field type is exactly one of routed /
+  excluded / delegated / benign, so a new type can no longer inherit the
+  value-destroying default in silence.
+
+  `@object-ui/fields`: the four fixed-option widgets no longer clear the stored
+  value when the field declares no `options` at all. An empty offered set had two
+  opposite causes — a list that cascaded to zero (clear) and a list that was never
+  authored (nothing to decide) — and the second deleted the value on mount, which
+  the grid's inline cell editor has always been able to trigger. `FieldEditWidget`
+  also forwards `autoFocus` to the widget it renders.
+
+- b953a97: fix(detail): lookup field values link to the referenced record
+
+  A valued lookup on a record detail page rendered as plain text plus a copy
+  button — the referenced document's name was visible but unreachable, so users
+  copied the number and searched for it from the list page instead. Lookup cells
+  inside a related list that pointed at a third object were dead the same way.
+
+  `LookupCellRenderer` — the one cell renderer both surfaces resolve through —
+  now renders the display value as a link to the referenced record. The display
+  name resolution, the copy affordance and every non-lookup field are unchanged,
+  and a lookup with no value still renders its placeholder rather than an empty
+  link.
+
+  The URL is not assembled in the renderer. `RelatedRecordActionsContext` gains
+  an optional `recordHref` / `openRecord` pair, published by the console's
+  `RelatedRecordActionsBridge` from the SAME builder its related-list row
+  navigation already used, so there is one record-route shape rather than a
+  second one. A host that does not provide it (Studio designer, embedded
+  renderers, standalone grids) renders exactly what it rendered before.
+
+- 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.
+
+- ac853ce: i18n: retire the reader-less `common.search` key from all ten locale packs
+
+  `common.search` (`Search`, no ellipsis) had exactly one consumer: `LookupField`
+  built its dialog placeholder by concatenating the key with three ASCII full
+  stops. objectui#4375 / PR #4391 retired that concatenation — the placeholder is
+  the reused `table.search` pack value (`Search…`, one U+2026 glyph), which is what
+  brought it under objectui#3878's glyph pin. That left `common.search` with zero
+  readers repo-wide while it still existed in all ten packs.
+
+  Re-verified before deleting, repo-wide: no `t()` call site in any package or app,
+  no MDX or JSON reference, and the one dynamic template-literal reader of the
+  `common` namespace takes a two-member union parameter (`'openChat' |
+'closeChat'`) that cannot resolve to it. No user-visible string changes — this key never rendered.
+
+  The dormant copy in `@object-ui/fields`' no-provider fallback table
+  (`useFieldTranslation.ts`'s `FIELD_DEFAULTS`) goes with it. That table is a
+  module-local `Record<string, string>` read only when no `LocalizationProvider`
+  is mounted; it is not exported, so removing an entry no reader asks for changes
+  no rendered output and narrows no public type. Hence patch for that package,
+  while the pack change is a minor: deleting a key from `en` narrows the exported
+  `TranslationKeys` type (`typeof en`), so code indexing `TranslationKeys` at
+  `common.search` stops type-checking. Same grading, for the same reason, as
+  objectui#4145's `report.editor.*` retirement. No runtime consumer existed to
+  break.
+
+  Retiring a key from `common` was the ruled decision on objectui#4392 rather than
+  keeping it as vocabulary: nothing pins a dormant key's meaning, so its next
+  reader inherits an unreviewed contract, and a dormant key beside a live
+  `table.search` is where a second dialect gets started. The objectui#4328
+  dead-surface family has consistently chosen removal for zero-consumer surfaces.
+
+  The neighbouring `common.select` (minted one commit earlier by objectui#4386 /
+  PR #4397) is a different key and is untouched.
+
+  A negative pin (`packages/i18n/src/__tests__/common-search-retired-4392.test.ts`)
+  fails if the key returns to any pack, if any package reads or re-declares it, or
+  if a dynamic `common.*` reader grows a `search` member — every existing i18n gate
+  runs call site to key, and none of them can see a key with no call site.
+
+- 06915b0: fix(i18n): every date branch threads the active locale, so a `zh` session no longer renders half its dates in English
+
+  Date rendering had two locale channels and only one followed the user's
+  language, so the same row could read `逾期 6 天` in one column and `In 3 days`
+  in the next, with a datetime column showing `8/11/2026 12:00 am`
+  (objectui#4468).
+
+  The overdue phrase resolves through the translate fn (the active UI language),
+  while every `Intl` branch took its tag from the raw tenant locale
+  (`useLocalization().locale`) — which is `undefined` on any workspace that never
+  configured one, and `undefined` makes `Intl` use the _machine's_ locale.
+  `DateTimeCellRenderer` passed no tag at all.
+
+  Every date-formatting site in `@object-ui/fields` now resolves through the one
+  existing channel, `useDisplayLocale()` (tenant regional default → active UI
+  language → `en`): `DateCellRenderer` (relative past, relative future, near-today
+  and the beyond-±7-days absolute fallback), `DateTimeCellRenderer`, the read-only
+  `DateField` / `DateTimeField` / `FormulaField` faces, and the sub-grid's
+  temporal cells. English output is unchanged, and the already-localized overdue
+  wording is untouched.
+
+  No public signature changed. `@object-ui/i18n` carries a documentation
+  correction only: `useDisplayLocale`'s docstring claimed `DateCellRenderer`
+  already formatted from this channel, which was the very thing that was not true.
+
+- Updated dependencies [0e67b53]
+- Updated dependencies [ceccdcf]
+- Updated dependencies [d6e5124]
+- Updated dependencies [debad27]
+- Updated dependencies [dc2aa3e]
+- 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 [4dadf0d]
+- Updated dependencies [ae10a01]
+- Updated dependencies [92876f0]
+- Updated dependencies [f279deb]
+- Updated dependencies [4b70d28]
+- Updated dependencies [eb7f586]
+- Updated dependencies [e901131]
+- Updated dependencies [d9d3463]
+- Updated dependencies [2a40f69]
+- Updated dependencies [bec3e14]
+- Updated dependencies [613b167]
+- Updated dependencies [b4d3c22]
+- Updated dependencies [1f9b905]
+- 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 [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 [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/types@17.5.0
+  - @object-ui/providers@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.
+
+- 65bb513: fields: remove the docs-demo registration path (`registerFields` + `createFieldRenderer`), and host the docs field examples in a real form
+
+  **Breaking (shipped as `minor` per AGENTS.md §版本号策略 — objectui's major tracks `@objectstack`, so the repo's own breaking changes are `minor` with the break spelled out here):** two public exports are removed from `@object-ui/fields`:
+
+  - `registerFields()` — registered every widget under the same `field:<type>` keys as `registerAllFields()`, but wrapped in a demo-only renderer. Two paths writing the same registry keys meant whoever ran LAST won it for every consumer sharing the registry.
+  - `createFieldRenderer()` — that wrapper. It synthesized a `label`, a description, and a local `useState`/`onChange` around a widget.
+
+  **Migration:** there is nothing to migrate for an application. `registerAllFields()` runs on import of `@object-ui/fields` and is the one registration seam (`registerField(type)` for a single type); no shipped application ever called the removed pair — the docs site was the only caller. Code that rendered a **bare field node** standalone (`{ type: 'currency', label: 'Amount' }`) and relied on the wrapper for label and value state must host the field in a form instead: `{ type: 'form', fields: [{ name: 'amount', label: 'Amount', type: 'currency' }] }`. Seed values through the form's `defaultValues`, not a field-level `value`.
+
+  **Why the removal rather than a relocation** (ruling B of objectui#3798, confirmed by the maintainer; objectui#3308 is the origin, PR #3793 the safety net that first corrected the misleading `@deprecated` note): the wrapper existed only so the documentation could render a bare field node as a labelled, editable input. No application produces that rendering — on the live path a bare field node has no host for its label or its value. So the field docs, which are a first-hand transcription source for AI authors, were teaching a shape that does not work, and an author copying it got a node with neither label nor `onChange`. Relocating the wrapper into the docs site would have preserved that divergence under a new owner. Hosting the examples in a real form removes the reason for the wrapper to exist: the form renderer already owns label and value state, so the docs can only show what an application actually renders.
+
+  The 74 bare-node examples under `examples/schema-catalog/src/schemas/fields-*` are now form-hosted (the other 2 already were). A field's `value` moved to the form's `defaultValues`, because the form renderer spreads react-hook-form's state after the schema props and a field-level `value` is therefore ignored — a catalog guard now pins that so a dead `value` cannot come back.
+
+- b19162d: Build and publish `@object-ui/fields/style.css` — the subpath the package has always declared and never shipped
+
+  `packages/fields/package.json` has declared `"./style.css": "./dist/index.css"` for the package's entire life, while its build was `tsc && vite build` and the package contained no `.css` file for Vite to extract. **No published version up to and including 17.3.0 contains a stylesheet** — the `@object-ui/fields@17.3.0` tarball has zero `.css` files in it. The subpath did not merely render badly, it failed to resolve: a consumer writing the `@import '@object-ui/fields/style.css'` that the quick-start guide taught got a build error. This release is the first one where that import works, so it is a new capability rather than a repair of a working one, and no existing consumer can be relying on the old behaviour — an import that never resolved has no working callers.
+
+  Removing the export was the cheaper option and was rejected on a measurement: fields' class surface is not a subset of what `@object-ui/components` publishes. 155 classes exist only here, and 17 of them (`hover:bg-accent/30`, `ring-destructive/50`, `bg-primary/20`, …) resolve `@theme` tokens declared in unpublished package source, so no consumer-side Tailwind configuration can generate them. Dropping the export would have made the field widgets permanently under-styled with no supported remedy.
+
+  The new sheet is a **supplement, not a replacement** — it is compiled against the components theme and then has every rule that package's sheet already ships subtracted from it, so it is ~22 kB rather than another ~180 kB of near-duplicate CSS. Import it after the components sheet:
+
+  ```css
+  @import "tailwindcss";
+  @import "@object-ui/components/style.css";
+  @import "@object-ui/fields/style.css";
+  ```
+
+  Also adds a workspace-wide guard (`scripts/__tests__/package-files-exist.test.ts`) that fails when any package exports a subpath its published tarball cannot contain, so a stylesheet export with nothing building it cannot recur silently.
+
+- 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
+
+- 0186cdc: `address` widget: the ZIP box now reads and writes `postalCode`, the part name the platform stores
+
+  `AddressField` bound its ZIP input to `zipCode` — a part name that appears
+  nowhere in `@objectstack/spec`. The stored value uses `postalCode`, which
+  `AddressValueSchema` declares and enforces with `$strip` semantics, so the two
+  sides never met:
+
+  - opening a stored address showed an **empty** ZIP box (no input read
+    `postalCode`), while street / city / state / country all populated — four of
+    five parts working is what let this survive review;
+  - anything the user then typed into that box was written back as `zipCode` and
+    **stripped at the contract boundary**. On a new record the postal code was
+    lost outright; on an existing one the correction was silently discarded and
+    the stale stored code remained, with no error anywhere.
+
+  The widget now uses `postalCode` throughout — state key, sub-input id, the
+  `onChange` part name and the read-only formatter. Data written by the previous
+  builds is still **read** through `zipCode` as a compatibility limb, and the
+  first edit of any part normalizes such a record onto `postalCode` rather than
+  writing the split shape back out. Nothing writes `zipCode` any more, and it is
+  deliberately not part of the exported `AddressValue` type, so authoring code
+  cannot spell it.
+
+  `AddressValue` is otherwise unchanged in shape; consumers that referenced
+  `AddressValue['zipCode']` must read `postalCode`.
+
+  Fixes objectstack-ai/objectstack#5143.
+
+- ea41a59: fix(fields): `BooleanField` uses the control id its host hands down, so a boolean field's visible label is really associated with the switch
+
+  A `boolean` / `checkbox` field inside a form emitted **two** labels with the same text, and the visible one pointed at nothing. `<FormControl>` (a Radix `Slot`) hands the control the id its `<FormLabel htmlFor>` already references, and the widget replaced it with the field name — so `label for="_r_3_-form-item"` had no target while the switch carried `id="notifications"`. Clicking the visible label, the normal affordance for a switch/checkbox row, toggled nothing on every generated form in every app; the accessible name survived only through the widget's own `sr-only` label.
+
+  The widget now honours the id it was handed (`id` is a declared key of the widget contract, forwarded by `toDomProps`) and stops emitting its own label when a host supplied one. Standalone rendering is unchanged: with no host id the id still falls back to the field name and then to `useId()`, and the `sr-only` label — the only accessible name the inline grid editor and the console's action-param dialog have — is still emitted.
+
+- 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.
+
+- c97a45e: Group-labelled field widgets now consume the host label's IDREF in their readonly and zero-option states, so the visible label names something there too
+
+  A field declared `labelling: 'group'` (objectui#3961) is named by IDREF: the form
+  renderer publishes its `<FormLabel>`'s own `id`, drops the inert `for`, and hands
+  the widget `aria-labelledby` plus the host control `id`. All seven such widgets
+  consumed that pair on their editable surface only. A field-level
+  `readonly: true`, and an option list that resolved to zero offered options, take
+  early returns that render before the container doing the consuming — so the label
+  published an id that no element in the document referenced.
+
+  Measured on the previous `main`, one field per row in a real form, counting the
+  elements that reference the host label's published id:
+
+  ```
+                               consumers  byLabelText  named group
+  multiselect  readonly+value      0           0           0
+  multiselect  readonly+empty      0           0           0
+  multiselect  zeroOptions         0           0           0
+  multiselect  editable            1           1           1
+  ```
+
+  All seven measured identically in every readonly state; each is 1 now. The
+  user-visible effect is the one objectui#3961 fixed for editable fields: the
+  visible label was the accessible name of NOTHING, so a readonly "Tags" or
+  "Shipping Address" was announced as loose text next to unattributed values. It is
+  not a regression of #3961 or objectui#3975 — before them these same states
+  emitted a `for` pointing at an id no element carried, which named nothing either.
+  The shape changed from a dangling `for` to an unconsumed IDREF; the defect did
+  not.
+
+  Each readonly surface now carries exactly two keys — the host `id` and
+  `aria-labelledby` — plus the `role="group"` that makes them meaningful, in one
+  shared spelling (`toHostGroupProps`). The narrow pair is deliberate: a readonly
+  display has no focusable control, so `aria-describedby` / `aria-required` /
+  `disabled` / the focus handlers have nothing to announce on, and `name` on a
+  `div` is exactly the DOM leak objectui#3291 sweeps for.
+
+  Two widgets answer with a different role than they do while editable, because
+  they render a different surface: `radio` (editable `radiogroup`) shows the chosen
+  option's label as text with no radios in it, and `file` (editable `button`, the
+  dropzone) shows file names with no dropzone. `role="group"` is also what the
+  shared "no options available" box now answers with for `checkboxes` / `radio` /
+  `multiselect`; the single `select` is not group-labelled, keeps its working
+  `for`, and that box emits nothing new for it.
+
+  Standalone rendering is untouched. The grid's inline cell editor and bare SDUI
+  nodes hand down neither key, so nothing is emitted and the markup stays
+  byte-identical — including the `EmptyValue` placeholder, which keeps its own
+  `aria-label` and gains no role. Hosted-and-empty, that placeholder is the whole
+  readonly surface, so it carries the group props: its `aria-label` ("No value") is
+  then outranked by `aria-labelledby` per accname, which is the intended outcome —
+  on the `generic` role that span carries, an author name is prohibited and was
+  never exposed, so the choice was between the field's name and no name.
+
+- d8a0be4: A form-hosted `multiselect` field is now NAMED by its visible label. It was the
+  residual of objectui#3961: that issue's probe audited six widgets and fixed
+  them, and re-running the same probe over the whole widget map afterwards put
+  `multiselect` on the byte-identical failure shape as `checkboxes` — the host's
+  `id` kept, but on the chip row's wrapper `div`, where a `<label for>` is inert
+  HTML (`HTMLLabelElement.control` is `null`, so it activates nothing and
+  contributes no accessible name). Measured on the tree that already carried
+  #3961's fix, one field per row:
+
+  ```
+  checkboxes   for=(none) ownId=…-group-label   byLabelText=1(div[role=group])
+  multiselect  for=…-form-item ownId=(none)     byLabelText=0
+  ```
+
+  Visually the field had a "Tags" label; a screen reader heard only "Alpha" /
+  "Beta" and nothing about what the set of chips was for.
+
+  No new mechanism — #3961's declaration, applied to one more widget:
+  `multiselect` declares `labelling: 'group'` at the registration boundary, so
+  the form renderer publishes its label's `id` and drops the dead `for`, and the
+  chip row answers with `role="group"` + the handed-down `aria-labelledby`.
+
+  Unchanged on purpose: each chip keeps its own accessible name from its text
+  content (the group name sits one level up and does not override it), and
+  STANDALONE rendering — the grid's inline cell editor, a bare SDUI node, where
+  nobody hands an id and there is no host label to point at — emits no role and
+  no IDREF, exactly as before.
+
+- f4b97c8: `percent` / `progress` cells now give the NUMBER shrink priority over the decorative bar (objectstack#5066)
+
+  In a narrow clipping container the percent display renderer sacrificed the wrong
+  half of itself. It emitted a `w-16 shrink-0` bar in front of a shrinkable value
+  span, so in a `record:highlights` chip — `basis-[9rem]`, shrinking toward
+  `min-w-[7rem]` as chips are added, clipping with `truncate` — the 64px bar plus
+  the 8px gap consumed the content box and `truncate` removed what was left of the
+  value. A stored `33.33` carried `33%` in the DOM and read as `3` on screen
+  (measured: 79px clip box, 32px text node, 25px overflow), with no ellipsis and
+  nothing in the accessible name to signal the loss: a silently smaller, plausible
+  number rather than a cosmetic glitch. Downstream the app had to override the
+  highlight's render type to `number` to get its digits back, losing the `%` glyph
+  and the bar entirely.
+
+  The priority is now inverted, on the principle that the number is the CONTENT and
+  the bar is DECORATION: the value span is `shrink-0` and the bar carries
+  `min-w-0 shrink`, keeping `w-16` only as its PREFERRED width, so a squeezed
+  container eats the bar and the digits survive intact.
+
+  The bar is deliberately NOT `flex-1`. `flex-1` would let it GROW as well as
+  shrink, stretching the bar across every wide grid cell and changing a surface
+  that has no bug; `w-16` stays the upper bound, so wide containers render exactly
+  as before and only the shrink direction changed. Below roughly 40px of content
+  the bar has collapsed to nothing and the value clips like any other single-line
+  cell — same floor as the plain number renderer, which is as far as a
+  self-contained renderer fix reaches (the chip's own width is a function of how
+  many chips the record has, so the strip's `@container` cannot see it).
+
+  The neighbouring `number` renderer is untouched.
+
+- c2ecbae: 相关列表 Add 选择器兑现 `add.picker.filter`:作者限定的候选范围现在真的生效
+
+  `record:related_list.add.picker.filter` 被 spec 声明为「Restrict which records the picker offers」,但渲染器从未读过它 —— 挂 `RecordPickerDialog` 时不传任何 filter,对话框照样提供 `picker.object` 的全部记录,选中即建链接行或改父,`os validate` / `os build` 全绿、运行时零诊断。作者写下「只允许指派 active 的岗位」「只允许挂未过期的许可」,得到的是完整候选列表。
+
+  现在它按原样传给 `RecordPickerDialog` 的 `baseFilter` —— 不是 `lookupFilters`,后者会把条件渲染成用户可编辑的筛选栏行,等于把作者的硬性限制降级成建议。
+
+  `baseFilter` 因此接受两种形状,按结构判别(`Array.isArray`):
+
+  - **`QueryParams.$filter` 记录形式**(依赖型 lookup 链)保持原有的键覆盖语义逐字节不变 —— 级联父值必须**替换**同字段上过期的 `lookupFilters` 条目,而不是与之求交。
+  - **spec 的 `ViewFilterRule[]`** 经 `mergeFilterNodes`(仓内唯一的 filter 下沉口)下沉,19 个 operator 全部无损到达服务端,包括记录形式没有 `$op` 可用的 `before` / `after` / `is_empty` / `is_not_empty`。此处**不新增**第二份 operator 词汇表。
+
+  槽位类型同时从 `Record<string, any>` 收紧为 `unknown`:前者会接受规则数组(数组满足 `any` 的字符串索引),旧的对象展开再把它压成 `{"0": {...}}`,于是查询去过滤名为 `0` 的列 —— 类型全绿、查询错误、无任何诊断。
+
+- 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).
+
+- Updated dependencies [794c497]
+- Updated dependencies [993336f]
+- Updated dependencies [f0a625a]
+- Updated dependencies [b5980f4]
+- Updated dependencies [8aad9fd]
+- Updated dependencies [6719877]
+- Updated dependencies [56ff091]
+- Updated dependencies [7864f03]
+- 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 [c2fd122]
+- Updated dependencies [ac2139c]
+- Updated dependencies [b14ab3a]
+- Updated dependencies [e24d767]
+- Updated dependencies [8c60819]
+- Updated dependencies [aca561a]
+- Updated dependencies [e64a52e]
+- Updated dependencies [844d17f]
+- Updated dependencies [48132f7]
+- Updated dependencies [4dcd52a]
+- Updated dependencies [42ae5c6]
+- Updated dependencies [0ef9dfd]
+- Updated dependencies [1d723e3]
+- Updated dependencies [0109f54]
+- Updated dependencies [7e5bb5d]
+- Updated dependencies [fbc23e0]
+- Updated dependencies [6d762da]
+- Updated dependencies [e6fdbdc]
+- Updated dependencies [54233b1]
+- Updated dependencies [f9faa7d]
+- Updated dependencies [97b63d7]
+- Updated dependencies [6bb454a]
+- 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/i18n@17.4.0
+  - @object-ui/types@17.4.0
+  - @object-ui/providers@17.4.0
+
+## 17.3.0
+
+### Minor Changes
+
+- 3889ffb: Console chrome i18n gaps (objectstack#5407).
+
+  - A dependency-gated lookup now names its controlling field by its **label**
+    instead of its raw API name. The sentence was localized but the interpolated
+    name was not, so every locale — English included — read `Select crm_account
+first`. The form renderer passes a new `dependsOnLabels` widget prop (the
+    lookup-side counterpart of `emptyHint`, which it already resolves to labels
+    for the fixed-option widgets); a name the host does not cover still falls
+    back to itself.
+  - The page-header overflow trigger's `More actions` accessible name now reads
+    `detail.moreActions`, the same key `action:menu`'s own overflow trigger uses,
+    so the two cannot diverge per locale.
+  - The activity-feed reaction button's `Add reaction` accessible name is now a
+    bundle key (`detail.addReaction`, added to all ten packs).
+  - The "check the highlighted fields" toast joins field names with a per-locale
+    separator (`validation.formInvalidJoiner`) instead of a hardcoded `、`
+    (U+3001) — right for zh/ja by accident, wrong in English and every Latin
+    locale. Latin packs use `, `, CJK `、`, Arabic `، `.
+  - The Spanish `validation.required` / `validation.unique` templates gained
+    their own masculine head noun (`El campo {{field}} es obligatorio`) so the
+    adjective agrees for feminine field labels too — `Cuenta es obligatorio` was
+    ungrammatical.
+
+- 19b8c9b: Field widgets no longer spread renderer-only props — or arbitrary keys from a
+  field config — onto the DOM element they render (objectui#3291).
+
+  **Behaviour change:** an unknown key written on a field configuration (or on an
+  SDUI `field:*` node) stops becoming an HTML attribute on the rendered control.
+  Nothing reads those attributes, but they were serialized into the DOM, into
+  snapshots, and into anything scraping rendered markup.
+
+  ## What was happening
+
+  Widgets forwarded their leftover props with a bare spread, so whatever a host
+  handed them became an attribute. Measured on a real form with a real widget:
+
+  ```
+  <input placeholder="PH-f" zzcanary="CANARY-STR" zzcanaryobj="[object Object]"
+         zzcanarynum="42" id="…" type="text" value="" name="f">
+  ```
+
+  `zzcanaryobj="[object Object]"` is an ordinary extra key on the field config
+  being `String()`-ed onto an attribute. React 19 does not warn about any of it:
+  an all-lowercase unknown attribute is passed through in complete silence, which
+  is why this went unnoticed.
+
+  Eleven widgets carried a line that looked like it prevented exactly this:
+
+  ```ts
+  const { inputType, ...domProps } = props as any; // "Filter out non-DOM props"
+  ```
+
+  `inputType` is already stripped by the form renderer before a widget sees it,
+  so that line filtered nothing — the comment actively misled. It is gone.
+
+  ## What changed
+
+  - New `toDomProps(props)`, exported from `@object-ui/fields`. It keeps only
+    what may legitimately become a DOM attribute and drops the rest.
+  - The 14 field widgets that spread onto a host element now go through it:
+    `text`, `textarea`, `number`, `boolean`, `date`, `datetime`, `time`, `email`,
+    `phone`, `url`, `password`, `currency`, `percent`, and `select`.
+
+  **It is a whitelist, not a list of keys to drop.** The largest leak source is
+  not any named renderer prop — it is the open tail of author-supplied keys. The
+  form renderer destructures a fixed set of known keys and forwards the rest
+  verbatim, and `SchemaRenderer` is wider still: it spreads the whole authored
+  node as props with no strip layer at all, so on that path a widget's own spread
+  is the only line of defence. A blacklist of today's renderer-only props would
+  pass every canary above and would not stop the next authored key either.
+
+  The forwarded set is the one `FieldWidgetComponentProps` already **declares**:
+  `id`, `name`, `autoFocus`, `tabIndex`, `onBlur`, `onFocus`, `onClick`,
+  `className`, `disabled`, plus `aria-*` and the `data-*` family. Until now that
+  was a type-level claim a widget could violate at runtime just by spreading;
+  `toDomProps` is its executable form.
+
+  Two compile-time assertions tie the helper to the declaration, and it is worth
+  being exact about which drift each one prevents:
+
+  - the contract's DOM pass-through block is now a named type
+    (`FieldWidgetDomProps`), and **both directions are compiler-bound**:
+    forwarding a key the contract does not declare fails to compile, and
+    declaring a DOM key the helper does not forward fails to compile too. The
+    second direction guards _declared but not delivered_ — a key that
+    type-checks, reads as supported, and silently never reaches the element. The
+    leak test structurally cannot see that class of bug: it looks for attributes
+    that arrive, not for ones that go missing.
+  - `className` and `disabled` are bound in the **forward direction only**. They
+    are DOM-legal and are forwarded, but they live in the controlled-input block
+    because widgets also interpret them, so they are deliberately outside
+    `FieldWidgetDomProps`.
+
+  An HTML global attribute the contract does not declare (`role`, say) is no
+  longer forwarded. It only ever arrived through the open spread. If a field node
+  should be able to author one, declare it on `FieldWidgetComponentProps` and add
+  it to the whitelist — the fix belongs at the contract, not in a wider spread.
+
+  ## Regression gate
+
+  A new contract test renders **every** registered field widget through **both**
+  hosts — the real form renderer and `SchemaRenderer` — and fails on any
+  attribute HTML does not define for that element. It walks real DOM attributes
+  rather than listening for React warnings (React 19 is silent for the exact case
+  that leaked), asserts a validation error genuinely rendered before scanning the
+  error variant, and calibrates its own judge against two fixtures: standard
+  markup that must produce zero findings, and planted fake attributes that must
+  all be found. A new widget type is covered automatically — the sweep is derived
+  from the widget registry, so adding one without covering it fails the test.
+
+- 56409c2: Field widgets are finally told when their field fails validation, and the props
+  slot that carries it takes the name the published contract gives it
+  (objectui#3222).
+
+  **Breaking** for anyone implementing a field widget (see migration below). The
+  repo version policy keeps this a `minor` — objectui's major tracks
+  `@objectstack`'s — so read the bump as "breaking within objectui".
+
+  ## The a11y defect this fixes
+
+  `@objectstack/spec/ui`'s `FieldWidgetPropsSchema` — the published contract that
+  third-party and AI-authored field widgets are written against — has always
+  declared `error?: string`. `@object-ui/fields` declared its own slot as
+  `errorMessage`. That looked like a naming split; it was worse:
+
+  ```
+  producers of `errorMessage` anywhere in packages/ + apps/ :  0
+  reads of `errorMessage` in packages/fields/src            : 15  (7 widgets)
+  reads of `props.error`                                    :  0
+  ```
+
+  The slot was dead under BOTH spellings. No host ever passed it: the form
+  renderer showed validation text through its own `<FormMessage/>` and never
+  forwarded the prop. So `EmailField`, `CurrencyField`, `UrlField`,
+  `RichTextField`, `PercentField`, `TextAreaField` and `PhoneField` each computed
+  `aria-invalid={!!errorMessage}` from a value that was `undefined` forever —
+  **`aria-invalid` had never once been set, and a screen reader was never told
+  the field had failed validation.**
+
+  Worse than "never set": `<FormControl>` is a Radix `Slot` that hands its child a
+  CORRECT `aria-invalid`, but a widget's own attribute is written after the props
+  spread, so it wins. Those seven widgets were actively overwriting the right
+  answer with `false`.
+
+  FROM: `renderFieldComponent` received no validation state, and the widget props
+  type declared `errorMessage?: string`, which nothing produced.
+  TO: the form renderer passes react-hook-form's `fieldState.error?.message` down
+  as `error` when it renders a registered widget, and the props type declares
+  `error?: string`. Both ends of the contract are live for the first time; a
+  rename alone would only have swapped one dead key for another.
+
+  ## Migration for widget authors
+
+  ```diff
+  -export function MyField({ value, onChange, field, readonly, errorMessage }: FieldWidgetComponentProps< string >) {
+  -  return <Input value={value} aria-invalid={!!errorMessage} />;
+  +export function MyField({ value, onChange, field, readonly, error }: FieldWidgetComponentProps< string >) {
+  +  return <Input value={value} aria-invalid={!!error} />;
+  ```
+
+  No alias is kept. `errorMessage` was retained nowhere on purpose — a tolerant
+  second spelling is exactly the de-facto second contract AGENTS.md #0.1 forbids,
+  and it is what would let a missed call site go quiet again. Because
+  objectui#3221 had already removed the type's `[key: string]: any`, every missed
+  site is a compile error rather than a silent `any`, so the compiler — not grep
+  — validated this rename.
+
+  ## Responsibilities are split, not duplicated
+
+  The widget consumes `error` **only** to drive `aria-invalid` on the control it
+  renders (which only it can do — `aria-invalid` has to sit on the input element).
+  The message TEXT stays with `<FormMessage/>` in the form renderer. A widget that
+  also renders the text double-displays it, and the docs, the agent prompt and the
+  tests all now say so.
+
+  For the same reason `required` — also declared by the spec, also never delivered
+  — is deliberately NOT lowered into widget props: the required marker has exactly
+  one author, the renderer's `<FormLabel>`, and giving widgets the flag invites a
+  second asterisk. The a11y state a widget could legitimately carry is
+  `aria-required`, which needs no contract change at all (`AriaAttributes` is
+  already part of the type and widgets already forward it).
+
+  Builtin field types are unaffected: they render inside `<FormControl>`, whose
+  Slot already supplies `aria-invalid`, so `error` is stripped there rather than
+  leaking into the DOM as a stray attribute.
+
+  Docs updated to match: `content/docs/guide/plugin-development.md`,
+  `skills/objectui/guides/plugin-development.md` and
+  `.github/prompts/component.prompt.md` — the last of which additionally used the
+  spec's non-generic type alias as a generic (`FieldWidgetProps< number >`) and
+  destructured a `mode` prop that exists on neither type.
+
+- 042e09d: **BREAKING (v17)** — field widgets receive their metadata on ONE key, `field`.
+  `schema` is removed from the widget contract (objectui#3233).
+
+  ## What changed
+
+  `schema` was a second carrier for what `field` already means. Two producers fed
+  it: `SchemaRenderer` passed the authored node as `schema`, and the form
+  renderer's `renderFieldComponent` passed `schema={props.field || props.schema ||
+props}` _alongside_ `field`. The predictable result was ~30 widgets resolving
+  their config as `field || schema` — one concept, two spellings, a de-facto
+  second contract (AGENTS.md #0.1).
+
+  - `FieldWidgetComponentProps` no longer declares `schema`. Reading
+    `props.schema` is now a compile error, not a silent `any`.
+  - Both producers converged. The form renderer passes `field` only. The SDUI node
+    → `field` translation happens exactly once, in a new registration adapter
+    (`withFieldCarrier`), which every built-in field widget is registered through.
+  - All `field || schema` reads in `@object-ui/fields` are now plain `field` reads.
+
+  ## Migrating a widget you wrote
+
+  **Reading the metadata** — replace the fallback with the single key:
+
+  ```diff
+  -const config = field || (props as any).schema;
+  +const config = field;
+  ```
+
+  **Registering a widget** — if your widget can be rendered from a schema node
+  (anything `SchemaRenderer` dispatches, not just forms), wrap it once so it still
+  gets `field`:
+
+  ```diff
+  +import { withFieldCarrier } from '@object-ui/fields';
+  +
+  -ComponentRegistry.register('color', ColorField, { namespace: 'field' });
+  +ComponentRegistry.register('color', withFieldCarrier(ColorField), { namespace: 'field' });
+  ```
+
+  `withFieldCarrier` forwards the node **by reference** — nothing is copied,
+  narrowed or renamed — and consumes `schema` so it cannot reach the DOM through a
+  widget's `...props` spread.
+
+  A third-party widget that still reads `props.schema` and is **not** re-registered
+  through the adapter will read `undefined` in v17 and silently render an empty /
+  default state. That is the deliberate cost of a major boundary: one contract
+  beats N dialects, and a widget that picks the wrong spelling should fail at
+  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
+    receives from `SchemaRenderer` (`element:*`, `page:*`, grids, reports). Only
+    the _field-widget_ contract retired it. In particular `renderFieldComponent`
+    still passes `schema` when a form field type resolves to a plain component
+    through the bare-name fallback (e.g. `type: 'text'` reaching the display text
+    widget) — that component's contract is the node, and dropping it there would
+    render `undefined.className`.
+
+  ## Payload equivalence
+
+  Every path that used to deliver a payload through `schema` now delivers the
+  identical object through `field`, and both halves are pinned by tests asserting
+  **object identity**, not shape:
+
+  - form path — `packages/components/src/renderers/form/__tests__/form-field-carrier.test.tsx`
+  - SDUI path — `packages/fields/src/__tests__/field-carrier-sdui.test.tsx`
+
+- 30ae33a: `RichTextField` honours `mobile_fullscreen`, so `mobile.fullscreenLongText` is
+  finally true of rich text too (objectui#3301).
+
+  `ObjectFormSchema.mobile.fullscreenLongText` has always been documented as
+  "textarea/rich-text get an expand button", and `ObjectForm` has always stamped
+  `mobile_fullscreen` onto `field:markdown` / `field:html` fields to deliver it.
+  Both of those types resolve to `RichTextField`, and that widget never read the
+  flag: a producer with no consumer. Turning the setting on gave a phone user an
+  expand affordance on their textareas and nothing at all on their markdown or
+  HTML fields, with nothing anywhere reporting that half the feature was inert.
+
+  FROM: `RichTextField` ignored the flag entirely (`grep fullscreen` over that
+  file returned nothing). TO: it reads `field.mobile_fullscreen` — the same single
+  metadata carrier `TextAreaField` reads, and nowhere else — and renders the same
+  expand affordance and full-height editing dialog.
+
+  **The affordance now has one implementation, not two.** One form-level setting
+  should produce one behaviour, so the expand button, the dialog and the
+  draft/commit semantics moved into a shared `FullscreenFieldEditor` that both
+  widgets render; only the EDITOR is per-widget. A second hand-written copy of
+  that state machine would be the same defect this release fixes, with an extra
+  step — it drifts, and nothing reports the drift. The rich-text dialog hosts the
+  widget's real editing surface (same format indicator, same editor), not a bare
+  textarea, so whatever that editor grows into, both positions get it at once.
+
+  Behaviour is identical across the two widgets and unchanged for
+  `TextAreaField`: the dialog seeds its draft from the committed value at open
+  time, keeps typing local (a react-hook-form field is not marked dirty by an
+  edit the user may still cancel), commits once on "Done", and discards on
+  "Cancel". Test ids follow the existing convention per widget —
+  `richtext-fullscreen-toggle` / `-dialog` / `-input` / `-save` alongside the
+  `textarea-*` ones, since a single form can contain both.
+
+  There is deliberately no prop spelling of the flag and no `??` fallback chain in
+  either widget. The field metadata is the one carrier (objectui#3233), so a
+  misspelled or misplaced flag stays inert and visible rather than being quietly
+  caught by a tolerant consumer.
+
+  Also removes a dead type from the producer: `ObjectForm` stamped the flag on
+  `'string-multiline'`, a string that `grep -rn` finds exactly once across both
+  this repo and `objectstack` — that line itself. No producer emitted it, no
+  registry key matched it, no widget read it. The remaining four stamped types
+  (`textarea`, `field:textarea`, `field:markdown`, `field:html`) each have a real
+  reader.
+
+### Patch Changes
+
+- b7165ce: AddressField / GeolocationField sub-inputs now derive their DOM ids from a `useId()` prefix + sub-field name (the RadioField / CheckboxesField `groupId` paradigm) instead of hardcoded literals ("street", "city", "state", "zipCode", "country", "latitude", "longitude"). Two address or geolocation fields in one form no longer produce duplicate DOM ids, and each sub-label's `htmlFor` resolves to and focuses its own field's input instead of the first match in the document (#3343).
+- 7d08c3f: `TextAreaField` / `RichTextField` now honour `disabled` on their fullscreen editing path. `disabled` used to reach the inline control only: `showFullscreenButton` never consulted it, neither widget forwarded it to `FullscreenFieldEditor`, and that component did not declare the prop at all. A disabled long-text or rich-text field therefore sat correctly greyed out next to a live expand button whose dialog accepted any edit and wrote it straight back through `onCommit` — reproduced dynamically before the fix as toggle `disabled=false`, dialog input `disabled=false`, `onChange` called with "EDITED WHILE DISABLED". The state was easy to miss precisely because the visible control looked right.
+
+  `FullscreenFieldEditor` now declares `disabled`: the expand button stays (disabled means "not interactive, muted", unlike `readonly`, which suppresses the affordance entirely via each widget's read-only early return) but is disabled and refuses to open, the dialog's editor is disabled through a new third `children` argument, and "Done" is both disabled and gated before `onCommit`. The dialog locks on its own rather than trusting the button, because the form renderer folds `isSubmitting` into `disabled` — so a submit starting while the dialog was already open used to leave the field editable for the duration of the submit. Cancel and Esc stay live in every state. This is the registered-widget half of the same defect #3400 / #3401 fixed on the built-in `form.tsx` path, so both render paths now give the same metadata the same behaviour (#3402).
+
+- 6fe485b: fix(fields): translate the registered path's fullscreen long-text dialog (objectui#3404)
+
+  `FullscreenFieldEditor` — the expand button and dialog that `TextAreaField`
+  (`field:textarea`) and `RichTextField` (`field:markdown` / `field:html`) render
+  when `ObjectFormSchema.mobile.fullscreenLongText` is on — shipped four English
+  literals: the toggle's accessible name (`Edit {label} fullscreen`), the title
+  fallback `Edit text`, `Cancel` and `Done`.
+
+  No translation was missing. `form.fullscreen.*` and `common.cancel` have shipped
+  in all ten locale packs since objectui#3272 translated the built-in branch; this
+  path simply never consumed them. The result was visible inside a SINGLE form: a
+  zh session saw 「取消 / 完成」 on a built-in-rendered long-text field and
+  `Cancel / Done` on a registered-widget one.
+
+  All four now consume those existing keys — **no new keys, no locale-pack
+  change**. The dialog also gained the sr-only `form.fullscreen.description` the
+  built-in branch already carries, so it has an accessible description
+  (`aria-describedby`) instead of none.
+
+  Copy resolves through `useFieldTranslation()` (`createSafeTranslation`), as the
+  built-in branch does, whose English defaults are byte-identical to the literals
+  they replace — so widgets rendered with no `I18nProvider` (standalone/embedded
+  hosts) render exactly what they did before rather than raw i18n keys.
+
+- 825bbe3: The option widgets' "this list cannot be filled" message now has one source, and
+  it is translated (objectui#3231).
+
+  FROM: `SelectField`, `MultiSelectField`, `RadioField` and `CheckboxesField` each
+  carried their own copy of the empty/gated state, each destructured the declared
+  `emptyHint` prop into `_emptyHint` and dropped it, and each rendered a hardcoded
+  English literal (`'No options available'`, `` `Select ${…} first` ``) even in a
+  Chinese or Japanese session. TO: one shared `OptionsEmptyState` — the host's
+  `emptyHint` when it supplied one, otherwise a translated fallback
+  (`fields.options.empty` / `fields.options.selectFirst`, added to all ten locale
+  packs).
+
+  `emptyHint` was declared, produced by the form renderer and transported, then
+  lost three times over — so no registered widget could ever render it. All three
+  breaks are fixed, because closing only the last one delivers nothing:
+
+  - `isOptionField` compared the raw resolved type against `'select'` /`'radio'` /
+    `'multiselect'` / `'checkboxes'`. Object-derived forms emit
+    `mapFieldTypeToFormType`'s prefixed ids (`field:select`), which matched none of
+    them, so for every option field coming from an object schema — the normal case
+    in the console — the whole cascade block was skipped and no hint was computed
+    at all. It now normalizes the `field:` prefix, the same normalization
+    `stripRegisteredFieldProps` already applied a few lines below.
+  - `stripRegisteredFieldProps` then removed the `emptyHint` key from what was
+    left. It is now forwarded to the four cascade option types, alongside
+    `dependentValues`. This stays an allow-list rather than a blanket
+    pass-through: every other registered widget spreads its leftover props onto a
+    DOM node, where an unknown `emptyHint` attribute is a React warning.
+  - the widgets themselves discarded it. Keeping it out of the `...props` spread
+    was correct; not using it afterwards was not.
+
+  User-visible effect: a dependency-gated option list now prompts with the
+  controlling field's **label** ("Select Country first") instead of its raw
+  metadata name, in the session's language; an unconfigured list says so in the
+  session's language too. The gate sentence is one i18n key shared by the renderer
+  and the widget fallback, so the two sides cannot word it differently.
+
+  Untouched: the built-in (unregistered) `select` branch of the form renderer,
+  which already consumed `emptyHint`. That is a separate live path.
+
+- 34d9169: The record picker's filter panel now sends the AUTHORED value of a picked `select` filter option instead of the control's stringified form. Radix `Select` speaks strings — options render as `String(opt.value)` and `onValueChange` returns that string — and the panel stored it as-is, so a filter option whose value is a number or a boolean queried `{ level: "1" }` against records storing `level: 1`. The user picked an option that plainly has records and got an empty list. This bit the `lookup_filters` auto-derivation in particular: `lookup_filters: [{ field: 'level', operator: 'in', value: [1, 2, 3] }]` derives options whose values keep the author's type (`LookupFilterDef.value` is `unknown`), so every non-string option in the picker was unfilterable. The control's string is now mapped back through `col.options` at the control boundary — the control speaks string, the payload keeps the authored type — reusing the `matchOptionValue` / `toControlValue` semantics `@object-ui/components` introduced for the standalone form's select (#3090), rather than coercing in `filterValuesToRecord`, which would have to guess whether `"1"` meant `1` or `"1"`. Options coming from the object schema are strings by spec and round-trip unchanged, and the `number` / `boolean` filter inputs (which already converted explicitly) are untouched — the `select` branch is lifted to their standard, resolving the three-way inconsistency (#3422).
+- 5881a2c: The lookup "Browse all records" Record Picker's filter panel now offers the
+  options a `select` field declares in its schema (objectui#3336). `LookupField`
+  turns each typed picker column into a filter column, and those carried no
+  `options` — so the filter panel's dropdown opened EMPTY and the column could
+  not be filtered at all, even though the same column's table cells had rendered
+  the authored option labels since objectui#3333.
+
+  `RecordPickerDialog` now fills a `select` filter column's missing `options`
+  from `fieldsMeta` (the referenced object's schema `fields` map) through the
+  same resolver — and the same i18n option translation — the table cells use, so
+  the filter dropdown and the cells can never disagree about what an option is
+  called. Explicitly authored filter `options` still win (including the ones
+  auto-derived from an `in`/`notIn` `lookup_filters` entry), and a select field
+  whose schema declares no options keeps an empty dropdown: no options are
+  synthesised from the loaded page's raw stored values.
+
+- 9bc3709: The lookup "Browse all records" Record Picker now formats its columns with
+  the same field metadata the list view uses (objectui#3333). Previously the
+  dialog handed cell renderers a bare `{ name, type }` descriptor, so a
+  `select` column had no `options` and fell back to title-casing the raw
+  stored value (`manufacturing` rendered as "Manufacturing" instead of the
+  authored option label, e.g. "03 制造") — while the same field displayed
+  correctly in the list view and on the record detail page.
+
+  `RecordPickerDialog` gains an optional `fieldsMeta` prop (the referenced
+  object's schema `fields` map). When provided, each column's field descriptor
+  is enriched from the schema — `options` (run through the shared i18n option
+  translation), `currency`, `scale`, `precision`, `format`, `reference_to`, … —
+  and columns authored as plain strings in `lookup_columns` inherit the schema
+  field's `type`, so they format identically to typed columns. `LookupField`
+  passes the referenced object's schema it already fetches for `titleFormat`.
+  Callers that don't pass `fieldsMeta` keep the previous behavior.
+
+- 49f7449: `field:select` now announces its validation state to assistive tech: the
+  widget's DOM pass-through lands on the Radix `SelectTrigger` — the focusable
+  `<button role="combobox">` a user actually interacts with — instead of
+  `Select.Root`, which renders no DOM element of its own and silently dropped
+  every `aria-*` the form renderer delivered (objectui#3306).
+
+  Before this, a required select that failed validation showed the red message
+  while a screen reader was told nothing: `aria-invalid`, `aria-describedby`
+  (the link to the message text) and `aria-required` (objectui#3290's state
+  channel) all landed on Root and vanished. All three now reach the trigger,
+  and the widget computes `aria-invalid` from the published `error` slot after
+  the spread, the objectui#3222 discipline — a valid field explicitly says
+  `aria-invalid="false"` rather than staying mute.
+
+  Two keys deliberately stay on Root: `name` (Root forwards it to the hidden
+  native `<select>` that takes part in form submission) and `disabled` (Root is
+  the single authority that disables trigger, items and hidden select together).
+
+  Guarding the whole class forward, a new registry-wide sweep
+  (`widget-aria-invalid-registry-e2e.test.tsx`, the objectui#3291 leak-sweep
+  paradigm) renders every registered field widget through the real form, drives
+  a real validation failure, and asserts `aria-invalid="true"` appears inside
+  the field's row. The 29 widget types measured not to deliver yet are pinned in
+  a ratchet ledger (tracked in objectui#3318): fixing one turns its ledger row
+  red until the entry is removed, so the ledger only ever shrinks.
+
+- c7ed4c3: `TagsField` no longer ships a hardcoded Chinese input placeholder
+  (objectui#3342, AGENTS.md Commandment #-1). The placeholder now resolves
+  through the pinned chain: the author-declared `field.placeholder` wins
+  (previously ignored by this widget); otherwise the widget's own copy arrives
+  via `useFieldTranslation()` under the new `fields.tags.placeholder` key, added
+  at full parity across all locale packs (Chinese lives in the zh pack, not in
+  code); with no `I18nProvider` mounted the English default from FIELD_DEFAULTS
+  renders — never a raw key.
+- 2409e1d: `TextAreaField`'s character counter now announces itself in the session locale. The counter block — rendered only when the field declares `maxLength` — carried the accessible name `Character count: {n} of {max}` as an English literal, and the element is an `aria-live="polite"` region, so a zh/ja/ar session had that English sentence read out on every keystroke while sighted users saw only the language-independent `{n}/{max}` digits. Nothing was wrong on screen, which is why it survived: only screen reader users could perceive it (#3406).
+
+  Unlike #3404, no key existed to consume — none of the ten locale packs had any character-count string. `fields.textarea.characterCount` is new in all ten, interpolating `{{count}}` and `{{max}}` as one sentence rather than parts assembled in code, because `ja` and `ko` put the cap before the count ("of {{max}} characters, {{count}}"), an order no concatenation can produce. The English pack value and the `FIELD_DEFAULTS` fallback are byte-identical to the literal they replace, so an `en` session and a provider-less embed both render exactly what they did before.
+
+  Behaviour is unchanged: `aria-live="polite"` and the per-keystroke recompute are deliberately untouched here and tracked separately (#3408).
+
+- 789fe3e: `TextAreaField`'s character counter no longer re-announces itself on every keystroke. Measured on `main` in a zh session with `maxLength: 500`, typing a 52-character sentence one character at a time produced 52 distinct screen-reader announcements totalling 979 spoken characters — roughly 19x the text being written, each one cutting off the reader's echo of the letter just typed. The counter element was simultaneously the visible `{n}/{max}` digits, the carrier of the translated sentence and the `aria-live` region itself, so "re-render" and "announce" were the same event; the field also had no `aria-describedby`, so focusing it said nothing about the cap at all (#3408).
+
+  It is now the three-node shape the GOV.UK Design System character-count component uses: the visible digits are `aria-hidden` and purely decorative; the counter sentence (`fields.textarea.characterCount`, unchanged in all ten packs) has moved onto the textarea's `aria-describedby`, so focus reads "Character count: 12 of 500" once and then stays quiet; and a separate visually-hidden `aria-live="polite"` region carries a new near-limit warning, `fields.textarea.charactersRemaining` (new in all ten packs), which stays silent until the value is inside the last 10% or last 20 characters of the cap — whichever the typist reaches first — and updates only after typing pauses for a second. The same 52-keystroke probe now produces zero announcements; a run that types all the way onto a 500-character cap produces five. Any `aria-describedby` the host already supplied (the form renderer's description and error-message ids) is appended to, never replaced.
+
+  No metadata change: the counter still renders exactly when the field declares `maxLength` (or the legacy `max_length`), and a widget rendered with no `I18nProvider` still shows the same English sentences.
+
+- f789c3b: `TextAreaField`'s fullscreen edit dialog now gives screen reader users the character count it has always shown sighted ones. The dialog's footer counter was a bare `{n}/{max}` span: no accessible name, nothing `aria-live`, and nothing tying it to the dialog's textarea — so browse mode read "5 slash 500" if it happened to sweep the footer, and focusing the input said nothing about the cap at all. The inline surface of the same field has carried a proper three-node counter since #3408, so the fullscreen branch was at zero for the same field, the same cap and the same user (#3417). It is reachable on any phone form with `ObjectFormSchema.mobile.fullscreenLongText` on, for every long-text field that declares a limit.
+
+  The counting UI is now ONE shared `CharacterCount` component that both surfaces render, instead of two hand-written copies that could only drift. In the dialog it renders `aria-hidden` digits plus a visually-hidden description carrying `fields.textarea.characterCount`, wired to the dialog's textarea through `aria-describedby`, so focus reads "Character count: 12 of 500" once and the count follows the draft as it is edited. The description ids are per surface, because the dialog's draft and the committed value diverge as soon as the user types.
+
+  The dialog deliberately gets NO live region: it is a modal opened to write at length, the description already delivers the cap on focus, and the inline surface's `aria-live` region stays mounted behind the overlay. The inline surface is unchanged — same DOM, same threshold-gated debounced announcements, same ten locale packs and the same English fallbacks with no `I18nProvider` mounted. No new i18n keys and no metadata change: the counter still renders exactly when the field declares `maxLength` (or the legacy `max_length`).
+
+- a321fa4: `TextAreaField`'s mobile fullscreen flag converges on its one real producer
+  (objectui#3232).
+
+  FROM: the widget resolved the "show the expand affordance" decision through a
+  four-way `??` chain — a `mobileFullscreen` (camelCase) prop, the field
+  metadata's `mobile_fullscreen`, a `mobile_fullscreen` prop, and
+  `schema.mobile_fullscreen`. TO: a single read of the field metadata's
+  `mobile_fullscreen`, resolved through the `field || schema` carrier pair every
+  widget in this package already uses.
+
+  No runtime behaviour changes, because three of those four reads were
+  permanently `undefined`:
+
+  - `mobileFullscreen` (camelCase) had **no producer anywhere in the repo** — the
+    only occurrences of that spelling were the widget's own read and the
+    destructure that kept it off the DOM spread. The doc comment nonetheless
+    claimed "the host form passes `mobileFullscreen`", so the contract it
+    described had never held.
+  - `mobile_fullscreen` as a **prop** cannot arrive: the form renderer's
+    `stripRegisteredFieldProps` explicitly removes `mobile_fullscreen` and
+    `fullscreen` from the props forwarded to registered field widgets.
+  - `schema.mobile_fullscreen` was the same object `field || schema` already
+    resolves, so it could only ever restate the metadata read.
+
+  What actually drives the affordance — and is now the only thing that does — is
+  the field metadata flag `ObjectForm` stamps onto long-text fields from
+  `ObjectFormSchema.mobile.fullscreenLongText`. That path is unchanged and is now
+  pinned by tests (button, dialog, and the committed edit), so the cleanup cannot
+  have silently removed the working behaviour.
+
+  Also untouched: the built-in (unregistered) `textarea` branch of the form
+  renderer, which reads `mobile_fullscreen || fullscreen` off the form-field
+  props and renders its own `FullscreenTextarea`. That is a separate live path.
+
+  Why this is worth a changeset rather than a silent tidy-up: reads that nobody
+  writes are not free. They document a contract that does not exist — the next
+  author follows the comment, passes the prop, and is ignored without a word —
+  and a `??` chain that accepts four spellings and rejects none is exactly where
+  a misspelled key hides. With one source, a wrong spelling has no read path left
+  to absorb it. Per AGENTS.md #0.1 and Prime Directive #12, divergence like this
+  converges at the producer, not by accumulating tolerance at the consumer. No
+  host-override prop was invented in its place: inventing a key with no producer
+  is the same mistake in the other direction.
+
+- 8d8094a: 20 more registered field widgets now announce a failed validation to assistive
+  tech: `multiselect`, `radio`, `checkboxes`, `tags`, `lookup`, `master_detail`,
+  `user`, `owner`, `file`, `image`, `location`, `object`, `color`, `rating`,
+  `code`, `avatar`, `address`, `geolocation`, `qrcode` and `object-ref` carry
+  `aria-invalid="true"` on their real focusable control after a validation
+  failure, where before the red message rendered while a screen reader was told
+  nothing (objectui#3318, the registry-wide gap objectui#3306's sweep measured).
+
+  Each widget follows the objectui#3222/#3306 pattern: the `toDomProps(props)`
+  whitelist spread goes onto the control the user actually focuses — the input,
+  the lookup trigger button, the radiogroup (`role="radiogroup"` is the
+  ARIA-designated carrier for a set of radios), every chip/checkbox/star of the
+  composite option widgets, the upload dropzone/button — followed by an explicit
+  `aria-invalid={!!error}` computed from the published `error` slot. Wrapper
+  `<div>`s never carry the state, and `name` is withheld from non-form-control
+  elements (the objectui#3291 leak class).
+
+  `Combobox` (`@object-ui/components`) now accepts standard button attributes
+  and forwards them to its focusable `role="combobox"` trigger, giving
+  combobox-based widgets an element to deliver `aria-invalid` /
+  `aria-describedby` to — the same seam objectui#3306 opened on
+  `SelectTrigger`.
+
+  Nine types remain on the objectui#3318 ratchet ledger with their blockers
+  documented there (`formula`/`summary`/`auto_number`/`vector` render no
+  focusable control; `grid`, `slider`, `signature` need component-level design;
+  `filter-condition`/`recipient-picker` deliver in their editable states but
+  render a dependency-gate hint with no control in a fresh form).
+
+- Updated dependencies [18cd432]
+- Updated dependencies [532cf8b]
+- Updated dependencies [680080a]
+- Updated dependencies [a7651e6]
+- Updated dependencies [d915c47]
+- Updated dependencies [b71fc92]
+- Updated dependencies [65516ba]
+- Updated dependencies [94c5b7c]
+- Updated dependencies [ca0fa8f]
+- Updated dependencies [34595eb]
+- Updated dependencies [3889ffb]
+- Updated dependencies [5781fb1]
+- Updated dependencies [7e2406a]
+- Updated dependencies [9e9e9a9]
+- Updated dependencies [56409c2]
+- Updated dependencies [042e09d]
+- Updated dependencies [9cbcbf4]
+- Updated dependencies [85c4c9c]
+- Updated dependencies [fd54c3e]
+- Updated dependencies [4eeb932]
+- Updated dependencies [5c856ec]
+- Updated dependencies [23018cc]
+- Updated dependencies [53811d1]
+- Updated dependencies [68b6a28]
+- Updated dependencies [0554e88]
+- Updated dependencies [d915c47]
+- Updated dependencies [f44d872]
+- Updated dependencies [28b2e65]
+- Updated dependencies [509104a]
+- Updated dependencies [825bbe3]
+- Updated dependencies [6195841]
+- Updated dependencies [5dd0127]
+- Updated dependencies [06632e9]
+- Updated dependencies [a415684]
+- Updated dependencies [a4cff5b]
+- Updated dependencies [175bd79]
+- Updated dependencies [5af2852]
+- Updated dependencies [f833d3a]
+- Updated dependencies [a6ec93d]
+- Updated dependencies [2a9513d]
+- Updated dependencies [71be406]
+- Updated dependencies [d22ae31]
+- Updated dependencies [c7ed4c3]
+- Updated dependencies [2409e1d]
+- Updated dependencies [789fe3e]
+- Updated dependencies [8d8094a]
+  - @object-ui/core@17.3.0
+  - @object-ui/components@17.3.0
+  - @object-ui/types@17.3.0
+  - @object-ui/i18n@17.3.0
+  - @object-ui/react@17.3.0
+  - @object-ui/providers@17.3.0
+
 ## 17.2.0
 
 ### Minor Changes
@@ -1074,6 +2592,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
   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
@@ -1088,6 +2607,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
 
   **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
@@ -1863,6 +3383,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
   assuming USD.
 
 - d912a60: CRM polish — denser kanban cards, smarter currency, calmer dates.
+
   - **plugin-kanban card body**: drop the verbose `Label: value` two-column
     grid in favor of a single-column dense list (values only, with the
     field label preserved as a hover `title` for accessibility). Pipeline
@@ -1891,6 +3412,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
   `defaultCurrency` is set on the field/column, formatting is unchanged.
 
   Fixed call sites:
+
   - `@object-ui/fields`: `formatCurrency`, `formatCompactCurrency`, and
     `CurrencyCellRenderer` no longer default-param `'USD'`.
   - `@object-ui/i18n`: `formatCurrency()` falls back to `formatNumber`
@@ -2051,6 +3573,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
 - d714e85: Lookup display-name resolution now falls back through a Salesforce-style chain
   when an `$expand`'d reference object lacks a top-level `name`/`label`/
   `display_name`/`title` field:
+
   1. Standard display fields (existing behaviour)
   2. `salutation first_name last_name` composite — handles person records that
      only carry first/last name parts
@@ -2240,6 +3763,7 @@ Lin` and no `name` field now renders as `Bob Lin` everywhere — instead of
 ### 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
@@ -2253,6 +3777,7 @@ Lin` and no `name` field now renders as `Bob Lin` everywhere — instead of
     to create child records.
 
 - 1b6dc64: fix: complete Tailwind v3→v4 migration cleanup
+
   - Rename deprecated `flex-shrink-0` → `shrink-0` and `flex-grow-N` →
     `grow-N` (Tailwind v4 dropped the long-form aliases). Affects
     data-table, fields/index, FileField, ChatbotEnhanced,
@@ -2317,6 +3842,7 @@ Lin` and no `name` field now renders as `Bob Lin` everywhere — instead of
   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.
@@ -2379,24 +3905,29 @@ Lin` and no `name` field now renders as `Bob Lin` everywhere — instead of
 - 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.
@@ -2424,11 +3955,13 @@ Lin` and no `name` field now renders as `Bob Lin` everywhere — instead of
   `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.