@object-ui/plugin-detail 17.2.0 → 17.5.0

package/CHANGELOG.md

@@ -1,5 +1,815 @@
 # @object-ui/plugin-detail
 
+## 17.5.0
+
+### Patch Changes
+
+- ceccdcf: Action confirm dialogs and success toasts now honour the bundle's translated
+  `confirmText` / `successMessage`, not just `label` (objectui#4265).
+
+  A TranslationBundle entry for an action carries three keys under one
+  `_actions.<name>` node — `label`, `confirmText`, `successMessage` — and
+  `useObjectLabel()` has always exposed a resolver for each. What had drifted was
+  the call sites: `page:header` (authored record pages), `record:quick_actions`
+  and the related-list row menu resolved the button `label` only and dispatched
+  the authored `confirmText` / `successMessage` untouched. One bundle entry met
+  two fates: the button rendered the translation, the confirm dialog rendered the
+  authored English.
+
+  All action-rendering surfaces now go through one resolver,
+  `useActionTextLocalizer()` (new, exported from `@object-ui/react`), which
+  applies the existing `actionLabel` / `actionConfirm` / `actionSuccess`
+  resolvers over the three keys together. Fallback is unchanged: with no bundle
+  entry — or an entry lacking a key — the authored text renders. A bundle cannot
+  introduce a `confirmText` or `successMessage` the metadata never declared.
+
+- 6d01319: Inline edit no longer offers a record picker for a spec-spelled `autonumber` field that carries a `reference_to`
+
+  `TEXTUAL_REF_FALLBACK_TYPES` — the detail page's one definition of "machine-computed" — spelled the auto-number type `auto_number` only. `@objectstack/spec`, the designer and the metadata importer all spell it `autonumber`, and the set is matched by RAW spelling, so it carried half the type.
+
+  The reader that had no gate in front of it is `InlineFieldInput`'s reference fallback, `!!field.reference_to && !TEXTUAL_REF_FALLBACK_TYPES.has(type)`, on exported public API. A field typed `autonumber` keeps a `reference_to` for relational metadata — which is the entire reason this set exists — so it took the lookup branch and rendered the RECORD PICKER: a searchable list of records offered as replacements for a machine-generated identity. The `auto_number` spelling of the identical field rendered the textual fallback, as intended. Both spellings are now members, matching how `plugin-form` carries both in each of its non-input sets.
+
+  The editability half of the same report (objectui#4219) was already closed from another direction by #4228, whose shared exclusion resolves aliases before matching — a field typed `autonumber` offers no inline affordance in either host. The two gates are a union, so this fix also removes the union's dependence on which spelling the metadata happens to use: previously `autonumber` was held by the exclusion gate alone and `auto_number` by both, and losing either gate would have re-opened a different half of the defect depending on how the field was authored.
+
+  Pins land with it: the reference fallback for `autonumber` (red before this change — the picker really did render), `auto_number` and a real `lookup` as controls in both directions, and set membership asserted directly so the union statement is checked rather than described.
+
+- 63fe8fd: `record:related_list` and the detail synthesizer now declare two shapes they already accepted at runtime.
+
+  `RecordRelatedListRenderer`'s `schema` prop made `objectName` required, which rejected the exact authoring shape the per-element `dataSource` binding exists to support (`{ relationshipField, dataSource: { object, view } }`) — the gate maps the binding onto `objectName` before the body reads it, so the key is supplied, not missing. It is optional on the wrapper's input now, and required everywhere else.
+
+  `ObjectDefLike.fieldGroups` is derived from the spec's authorable field group instead of restating it. The hand-written list had drifted: it omitted `icon` and `description`, both of which the synthesizer passes through to detail section descriptors, so an object definition declaring the group icon the code honours did not type-check against it.
+
+- 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.
+
+- 6314e87: Inline-editing an `address` on the record detail page now edits it as real sub-fields, instead of collapsing it to one text box reading `[Object]` and saving a string over the structured value.
+
+  `InlineFieldInput`'s type switch routed the scalar and relational families to their dedicated widgets; every structured-object type matched nothing and fell through to the terminal raw text input at the end of the component. That fallback stringifies an object value through `coerceToSafeValue`, whose general-object case extracts `name || label || externalId || id || _id` and otherwise returns the literal `[Object]`. A stored address carries none of those keys, so the edit box read `[Object]`.
+
+  The display half was cosmetic; the write half was not. The fallback is a plain input wired to `onChange(v)`, so whatever the user typed was emitted as a **string** that replaced the whole `{ street, city, state, postalCode, country }` object on save — and `[Object]` was what the user saw as the current value they were correcting, which makes typing over it the natural gesture. An ordinary double-click inline edit therefore destroyed the sub-field structure. This is the input path only: objectui#4037 fixed the display registry, and read mode (including the inline-edit read state before editing starts) already rendered a formatted address.
+
+  `location` and `geolocation` are fixed with it. Both store objects too (`{ latitude, longitude }`), both reached the same terminal input, and both produced the identical `[Object]`-then-overwrite pair — one defect in three spellings, not three defects.
+
+  No new editor was written and no consumer-side tolerance was added. All three route to the widgets the create/edit dialog already uses (`AddressField` / `LocationField` / `GeolocationField`, the form's own structured-value editors), so the two entry points cannot diverge on the value shape they write back, and `coerceToSafeValue` is left untouched — the routing is what stops an address from ever reaching it. `autoFocus` follows the numeric branches' convention and lands on each widget's first sub-input (street / the coordinate box / latitude).
+
+  String-valued types are unchanged: `text`, `textarea`, `email`, `phone`, `url`, `color`, `code`, `time`, `qrcode` and the rest keep the terminal text input, where stringification is the identity and nothing is lost.
+
+- 5e2e9fa: A `password` or `secret` field on the record detail page is no longer inline-editable: it renders no pencil / double-click affordance and produces no editor, on both the details body and the highlights strip.
+
+  Both types are **masked on read** — `getCellRenderer` returns a fixed bullet run for either — so the value the row could hand an editor was never the credential. `InlineFieldInput` had no branch for either type, so both reached the terminal raw text input at the end of the component, and the row's payload value was seeded into a `type="text"` box: rendered in clear, selectable and copyable, in a control the user reads as holding their credential. Committing the row then wrote that placeholder back verbatim over the field. For `secret` the overwritten value is an opaque reference into an encrypted store (ADR-0100), so the write destroyed the pointer, not just the display. Nothing in the flow said so; the failure surfaced later, wherever that credential was used.
+
+  The decision already existed one package over. `INLINE_EXCLUDED_FIELD_TYPES` in `@object-ui/fields` excludes both types with exactly this reasoning, and the grid honours it through `isInlineExcludedFieldType()`. The detail hosts gated on readonly / computed / system only and never consulted it, so the detail page reproduced the precise failure the set exists to prevent. Both hosts now consult that same alias-aware contract (`isInlineExcludedDetailFieldType`, a narrow-only union of the authored and the object type, matching the computed gate under objectui#3355) rather than growing a second hand-maintained list — so the rule cannot drift between the grid and the detail page again.
+
+  Consulting the shared set closes the container family on the detail page with it: `object`, `composite`, `record`, `grid`, `repeater` and `vector` rode the same plain-text fallback with an object-shaped value, and are now excluded too. The spec spelling `autonumber` is likewise excluded, where the detail computed gate only knew the `auto_number` spelling. The heavy-editor family (`markdown`, `html`, `richtext`) loses its one-line text box on the detail page — those are authored in the record form, which has the real editors.
+
+  The binary/attachment family is deliberately exempt and keeps its detail editor. It is in the shared set for a grid-cell reason — a cell cannot host an upload dropzone — while `InlineFieldInput` routes `image` / `avatar` / `signature` / `file` (and the `video` / `audio` spellings) to the same upload widgets the record form uses. That exemption is pinned against the routing it claims, so it cannot outlive it.
+
+  Re-authoring a credential is unchanged and still belongs in the record form, which has the widget for it (`PasswordField`).
+
+- 297534b: Align 43 inline `defaultValue` strings with the `en` pack, and make the call-site gate enforce it (objectui#3810)
+
+  `t(key, { defaultValue: 'English text' })` only renders that text when i18next
+  **misses** the key. Where the key exists in `packages/i18n/src/locales/en.ts` the
+  pack value always wins, so the inline string is dead code — and 43 of those dead
+  strings said something different from the sentence users actually read.
+
+  `scripts/check-i18n-call-site-keys.mjs` (objectui#3530) now compares the two
+  whenever a call site carries a literal `defaultValue` for a key `en` defines, and
+  fails on any byte of difference. It is a hard rule with **no baseline**: the
+  repo-wide census measured 43 sites in 19 files out of 851 literal inline defaults,
+  and all 43 are aligned here, so there is no debt for a ratchet to hold. A
+  `defaultValue` on a key that is _not_ yet in `en` stays legal — that transition
+  runs for months (objectui#3546) and belongs to the existing `missing-key` rule,
+  which keeps reporting it alone.
+
+  Every fix moved the CALL SITE to the pack's wording. `en.ts` is untouched: its
+  values are what users read today, and changing one would oblige the same change in
+  the nine other packs (`scripts/check-i18n-en-drift.mjs`, objectui#3650). Six of the
+  43 differed only in an ellipsis (`...` against U+2026) — invisible in review, which
+  is how they survived three i18n gates that are each blind to this class by
+  construction.
+
+  The visible effect is confined to hosts that render these components with **no**
+  `I18nProvider` and no initialised i18next instance. There, react-i18next's
+  not-ready `t` returns the `defaultValue`, so the inline string was the rendered
+  one; it now matches what a provider-backed app has always shown. Inside the
+  console — provider mounted — nothing users see changes. The clearest converging
+  examples: the workspaces screen was written as "Organizations" at nine call sites
+  while every user has been reading "Workspaces"; the forgot-password success line
+  was written as "If an account exists, a reset link has been sent." while the pack
+  asserts "We've sent a password reset link to {{email}}."
+
+- 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.
+
+- e076fd5: Inline-edit toggle reads "Edit fields" without an I18nProvider, matching every locale pack
+
+  `DETAIL_DEFAULT_TRANSLATIONS` said `Edit fields inline` where all ten packs say
+  `Edit fields`, so `InlineEditSaveBar`'s toggle announced two different names for one
+  control — the map's on provider-less hosts (standalone embeds, the preview gallery),
+  the pack's in the console. The pack wins; the map row now mirrors it byte for byte.
+
+  The three ungated defaults maps (`plugin-detail`, `plugin-list`, `plugin-designer`) are
+  now compared key-by-key against the `en` pack by a new gate, generalizing the
+  collaboration-only precedent from objectui#3440. `LIST_DEFAULT_TRANSLATIONS` and
+  `DESIGNER_DEFAULT_TRANSLATIONS` are exported for it, as `DETAIL_DEFAULT_TRANSLATIONS`
+  and `COLLAB_DEFAULT_TRANSLATIONS` already were.
+
+- 456aac8: `@object-ui/plugin-detail` now declares `react-router-dom` as a peer dependency (`^6.0.0 || ^7.0.0`), the range its three siblings already use.
+
+  It has been importing the router all along — `PermissionFacetLink.tsx` and `record-reference-rail.tsx` both take `Link` and `useParams` from it — while its manifest named it in no field at all. That resolved locally for a reason that does not travel: the workspace root declares `react-router-dom` in its own `devDependencies`, so a `node_modules/react-router-dom` symlink exists at the root of this repository and Node's upward directory walk reaches it from every package directory. A consumer's install has no such root, and this package's rollup config externalises every bare specifier, so the published `dist/index.js` carried an import of a package the manifest never asked for.
+
+  Consumers already installing `@object-ui/app-shell`, `@object-ui/layout` or `@object-ui/plugin-designer` were unaffected — all three declare the same peer — so this closes the case of a consumer that pulls `plugin-detail` on its own.
+
+  A new repository gate, `pnpm check:phantom-deps`, now asserts that every bare specifier a released package imports under `src/` is declared by that package rather than merely resolvable from it, so the next one of these fails on the pull request that introduces it (objectui#4394).
+
+- 7d04b0e: `record:details` stops publishing a `layout` key the spec removed and the renderer never honoured
+
+  `record:details` declared `layout: enum ['auto','custom']` with `defaultValue: 'auto'` and the description "auto uses the object highlightFields; custom uses explicit sections". None of that was ever implemented. The renderer's only `schema.layout` read tested `'inline'` | `'compact'` — two values the schema never permitted — so both legal values fell through the same ternary and the key selected nothing. `auto` and `custom` have behaved identically for as long as both have existed.
+
+  Two directions were wrong with zero diagnostics: `layout: 'auto'` plus explicit `sections` still rendered the sections, and `layout: 'custom'` with no sections silently fell back to the flat body rather than reporting the missing groups. Because the input carried a `defaultValue`, this was not stale documentation — it was the manifest, the generated `sdui-intrinsics.d.ts` and the designer panel actively offering the key. An AI author writing `layout: 'custom'` believed it took effect.
+
+  `@objectstack/spec` 17.0.0 removed the property (objectstack#6946, ADR-0087 D2); `17.0.0-rc.6` is pinned here, so the key is already rejected on parse with a named migration message pointing at `os migrate meta --from 16`. This release completes the objectui half of that retirement: the input declaration is gone, and so is the dead `inline`/`compact` branch — the synthesized layout is now the constant it always resolved to.
+
+  Nothing that worked stops working. The body-source contract is unchanged and is now the only one declared: **`sections` renders the explicit groups; omitting it falls back to the flat body derived from the object's fields.** That is pinned in both directions, plus the empty-array boundary between them, in `recordDetailsBodySource.test.tsx`.
+
+  One gate got sharper on the way through. The parity test's "declares no top-level input the spec does not accept" check read raw `.shape` keys — but an ADR-0087 D2 tombstone stays _in_ the shape as a `z.never()`, so a retired key still answers "is this declared?" with yes. That is precisely why this input survived the rc.6 pin bump with every derived gate green. The check now filters tombstoned members out, so it catches the next D2 retirement instead of waving it through.
+
+- c32a8a1: `richtext` fields are placed like the long-form fields they are — four layout sets stopped spelling the type three ways the spec rejects
+
+  `@objectstack/spec` spells the WYSIWYG type `richtext`, one word, and **rejects** `rich_text` and `rich-text`: both exist only as typo keys in the spec's own `suggestFieldType` table, so `FieldSchema` refuses a field declared with either. Four sets that place fields by matching the RAW type string carried nothing else — `SKIP_TYPES` in the related list spelled it `rich_text`, both `WIDE_FIELD_TYPES` and `SECONDARY_FIELD_TYPES` spelled it `rich-text` — so each set was inert for the only spelling a producer can emit, and every one of them named the type it was failing to handle.
+
+  For a real `richtext` field that meant: it was auto-derived into a related-list column, it never spanned the full row in a multi-column detail section or form (unlike `markdown` and `html` sitting right beside it in the same sets), and it stayed in the dense primary section of the record page instead of dropping into "More details". All four move together — half of them would have left the detail page and the form disagreeing about the same field, which is worse than the uniform gap.
+
+  The dead spellings are dropped rather than kept alongside the live one: the alias table is the single place aliases belong, and a set that carries both invites the next drift. The pins are derived from the spec's own `FieldType` vocabulary instead of enumerated, so a member that stops being a real type name fails by name — replacing an assertion that was green only because the set contained the string it asked about.
+
+  `markdown` joins `richtext` and `html` in the related list's `SKIP_TYPES`, on a measurement rather than on the assumption that it renders raw. It does not: markdown and richtext both render through `MarkdownCellRenderer`, formatted and sanitized. The reason none of the three works in a table is that the formatted output is block-level — a heading, paragraphs, a list — inside a single-line truncating cell, so a document shows as one clipped heading with the rest invisible. `textarea` stays derived for the same reason read the other way: it renders as plain truncated text, which is a useful column. Author-declared columns are untouched — this set only filters the zero-config auto-derive walk.
+
+- 3f5f87c: `SchemaRenderer` states its real contract — a typed, required `schema` and a deliberate forwarding surface
+
+  `SchemaRenderer` is the renderer loop: every registered SDUI component is rendered through it. It handed `forwardRef` a props type of `{ schema: SchemaNode } & Record<string, any>`, which puts `string` into `keyof Props`, so `'ref' extends keyof Props` was always true, React's `PropsWithoutRef` took its `Omit` branch, and `Omit` over a type carrying a string index signature keeps only the index signature. Every declared prop was erased. Measured on the pre-fix source: `keyof ComponentProps<typeof SchemaRenderer>` was `string` and `ComponentProps<typeof SchemaRenderer>['schema']` was `any`, while the type argument went on declaring `SchemaNode`. The other half is the same defect seen from the call site — `<SchemaRenderer />` with no schema at all, `<SchemaRenderer schema={12345} />`, and an arbitrary misspelled prop each type-checked in silence. This is objectui#4422 / PR #4438's trap in the most central component in the repo, spelled `Record<string, any>` rather than `[key: string]: any`, which is why every previous sweep's grep and both shipped guards' detector reported the site as clean.
+
+  Graded **minor, not major**, on objectui#4528's reasoning: the type argument has always DECLARED `schema`; the index signature erased it from the resolved type, and restoring what the declaration documents is a fix to the published contract rather than a contract break.
+
+  **The forwarding surface is kept, deliberately.** This component forwards every prop it does not read to the component the schema names, resolved at runtime from a plugin-extensible registry — `packages/react/README.md` documents exactly that, and `@object-ui/components`' form renderer consumes the `onSubmit` it shows being forwarded. Closing that surface would state a false contract and would force every leaf plugin's props into this package. So the two halves are separated: the `forwardRef` type argument is the honest `SchemaRendererProps`, with no index signature for `PropsWithoutRef` to collapse, and the open surface is stated once in an explicit export annotation, which nothing routes through `Omit`. The published `.d.ts` shows the erasure disappearing: `ForwardRefExoticComponent<Omit<{ schema: SchemaNode } & Record<string, any>, "ref"> & RefAttributes<any>>` becomes `ForwardRefExoticComponent<SchemaRendererProps & Record<string, any> & RefAttributes<any>>`.
+
+  `SchemaRendererProps.schema` is declared as `BaseSchema | string | null | undefined` — what this component actually handles. It previously declared `@object-ui/core`'s `SchemaNode` interface, which requires `type: string` and so contradicted the component's own early returns for strings and nullish, while every caller held `@object-ui/types`' wider union. The erasure hid that mismatch completely.
+
+  **One declared behaviour change.** A non-object, non-string primitive schema now renders as its own text. It previously fell through to the shallow copy `{ ...schema }`, which spreads a primitive to an empty object, lost the `type` the renderer then looked up, and surfaced the red "Unknown component type: undefined" box — an accident of the spread rather than a decision. The declared props type excludes `number` / `boolean` so no author is invited to pass them; the runtime handling is defence-in-depth for untyped callers and stored metadata. Strings, `null`, `undefined`, `0` and `false` render exactly as before, and an object naming an unregistered type still gets the error box; all four are pinned.
+
+  Latent defects the erasure had been hiding, each surfaced by the repo-wide type-check and fixed at its call site: `DashboardRenderer` cast its widget schema to `Record<string, any>`, dropping the `type` every branch of `getComponentSchema` sets; `DashboardGridLayout`'s equivalent now states its return type instead of inferring a union that admitted a shape with no `type`; and `ReportViewer` handed a section's `content` array to the renderer whole, so a multi-node section rendered the unknown-component box instead of its content — arrays are mapped rather than widened into the renderer's declared input.
+
+  A repo-wide structural guard replaces the two per-package siblings' blocked direction: it judges every `forwardRef` in `packages/*/src` (219 sites) and its detector resolves `Record<string, …>` and `string`-keyed mapped types in addition to literal index signatures — the spelling the previous detector went blind on. It judges the type argument only, where an index signature is an accidental eraser, and never an export annotation, where one is a stated contract.
+
+- 2fea4d2: `detail.showEmptyRelated` renders Russian and Arabic again — the "+N empty" button no longer falls through to English at the counts it takes most often
+
+  This was the repo's only pre-existing i18next plural family, and all ten packs defined exactly two slots: `_one` and `_other`. i18next asks `Intl.PluralRules` for the one suffix a language needs for that number, and when the pack has no such slot it walks `fallbackLng` to `en`. Russian has four plural categories and Arabic six, so `ru` at counts 2-4 (`few`) and 5-20, 25-30, … (`many`), and `ar` at 0, 2, 3-10 and 11-99, resolved nothing locally and rendered the English string. The call site is the collapsed-empties button in the record detail's reference rail, whose count is the number of empty related lists — 2 to 4 are the most common values it ever takes, so a Russian user essentially always read English.
+
+  The fix is a base key (no suffix) beside the two existing slots, in all ten packs. The base key is always in i18next's lookup chain, so every category a pack did not enumerate resolves to it, in that pack's own language — and, unlike adding `_few`/`_many` to `ru` alone, it keeps the ten packs' key sets identical, which full key parity requires. Same shape objectui#3546 slice six established for `perm.facet.*`. Where the base key is genuinely reachable it carries a count-invariant phrasing: `ru` uses the «Существительное: {{count}}» form the pack already writes 22 times, `ar` the «{{count}} مفرد(جمع)» marker it uses throughout. For `en`/`de`/`zh`/`ja`/`ko` the base key cannot be reached at all (their categories are covered by the two existing slots) and repeats `_other` for parity; `fr`/`es`/`pt` reach it only from a million up, where the plural form is already correct. No English copy moves.
+
+  The provider-less path needed the same row for a different reason: `createSafeTranslation`'s fallback resolves `defaults[key]` literally and never appends a plural suffix, so the two suffixed rows in plugin-detail's defaults table were unreachable through it and that path answered with the raw key. It now carries the base key too.
+
+  Parity across packs turned out to be necessary and not sufficient — ten identical key sets were green throughout, because the defect is one level below key names: the slot the language needs is not in the set. So the invariant "a plural family must carry a base key" is now asserted over all ten packs in `all-locales-key-parity.test.ts`, where it is pack-intrinsic and fails at PR time without needing a call site to exist. It went red on all ten packs before this change and names the family that is missing its base.
+
+- dad805d: Six i18n keys no longer render as raw key strings on hosts with no `I18nProvider` (objectui#4396)
+
+  `detail.saving`, `list.resetSortToDefault`, `appDesigner.widgetProperties`, `appDesigner.addWidget`, `appDesigner.modeEdit` and `common.delete` were read through `createSafeTranslation` without a row in their hook's defaults table and without an inline `defaultValue` at the call site — the only two fallbacks that path has. On a provider-less host (standalone embedding, the preview gallery, host apps that never mount a provider) `fallbackT` therefore returned the key itself, so users saw `detail.saving` in the inline-edit save button, `list.resetSortToDefault` on the sort popover's reset control, `appDesigner.widgetProperties` as the dashboard inspector heading, `appDesigner.addWidget` as its toolbar label, `appDesigner.modeEdit` as a button's accessible name, and `common.delete` on the designer's destructive confirm.
+
+  Each key now has a row in its consumer hook's defaults table, byte-identical to the `en` pack value. No pack was edited, no key added, no call site changed.
+
+- 35997ce: fix(plugin-detail): synthesize page components in the spec's `properties` carrier so Studio page-create can persist
+
+  Creating a page in Studio never completed. The create path seeds a record
+  page's `regions` from `buildDefaultPageSchema(objectDef)` and PUTs the result,
+  and every node that synthesizer emitted carried its widget props at the TOP
+  level of the component — `{ type: 'page:header', recordChrome: true }`,
+  `{ type: 'page:tabs', items: [...] }`, and the same for `record:highlights`,
+  `record:path`, `record:details`, `record:related_list`, `record:history` and
+  `record:reference_rail`. ADR-0089 D3a closed `PageComponentSchema` with
+  `.strict()`, so those keys are not stripped, they are a parse error
+  (`Unrecognized key(s) on this view/page schema: 'recordChrome', 'actions'`).
+  The server refused the body and no page row was ever stored.
+
+  The props now go where the spec declares them — the node's `properties` bag,
+  which is where `ComponentPropsMap` defines `page:header.recordChrome` and
+  `page:tabs.items` in the first place. Nothing is dropped and nothing changes on
+  screen: a header still defaults to record chrome ON, an author's
+  `recordChrome: false` is still carried (and now actually persists), the tabs
+  keep their items, and `SchemaRenderer` hoists `properties` back onto the node
+  before dispatch, so every renderer receives exactly the props it did before.
+
+  One code path does the wrapping for every node the synthesizer builds, so there
+  is a single answer to "what may go in a page write". Slot overrides are
+  untouched — a node handed in by a caller is still placed verbatim.
+
+- b388950: fix(plugin-detail): the record detail header honors `userActions` predicates
+
+  `userActions.delete` reached the record detail header in its **boolean** form
+  but not in its **predicate** form. `userActions: { delete: false }` removed
+  Delete from the row kebab, the selection bar and the detail header, because the
+  host lowers the boolean into `schema.showDelete`. `userActions: { delete: {
+visibleWhen: … } }` reached only the row kebab: the header ANDed
+  `schema.showDelete ∧ objectAllowsDelete ∧ canDeleteRecord` and never evaluated
+  the predicate, so an author upgrading from "nobody may delete this object" to
+  "these records may not be deleted" silently lost the surface they were most
+  likely to have tested on.
+
+  The header now folds the per-record predicates in as a fourth conjunct,
+  evaluated against the open record through the same helper family the row
+  surfaces use — `userActionPredicates` from `@object-ui/core` for the parse (the
+  import `RelatedList` already makes) and `useRowPredicate` from
+  `@object-ui/react` for the evaluation:
+
+  - `delete.visibleWhen` / `edit.visibleWhen` false → the header affordance is
+    hidden (fails closed; `visibleWhen: false` counts as a declared gate).
+  - `delete.disabledWhen` / `edit.disabledWhen` true → the header affordance
+    renders disabled rather than disappearing, matching the row kebab.
+
+  The existing permission and record-writability gates are unchanged, so a
+  predicate that holds can never resurrect a button the user may not press. The
+  boolean form stays the host's channel — a bare boolean yields no predicate.
+
+- Updated dependencies [0e67b53]
+- Updated dependencies [932cbcd]
+- Updated dependencies [734d186]
+- Updated dependencies [3fc2971]
+- Updated dependencies [f7c6430]
+- Updated dependencies [ae10a01]
+- Updated dependencies [92876f0]
+- Updated dependencies [828549a]
+- Updated dependencies [e1ade8f]
+- Updated dependencies [3e19fe7]
+- Updated dependencies [bb58d1d]
+- Updated dependencies [5cc847c]
+- Updated dependencies [fa21254]
+- Updated dependencies [33c32bf]
+- Updated dependencies [66fb4fa]
+- Updated dependencies [6d641c9]
+- Updated dependencies [45e1949]
+- Updated dependencies [92250d6]
+- Updated dependencies [58bebf6]
+- Updated dependencies [405e808]
+- Updated dependencies [c0f9a4b]
+- Updated dependencies [ac853ce]
+- Updated dependencies [fa51109]
+- Updated dependencies [d46f9b8]
+- Updated dependencies [2fea4d2]
+- Updated dependencies [7f1cb33]
+- Updated dependencies [2e3b0c0]
+- Updated dependencies [78fa331]
+- Updated dependencies [31ab1ac]
+- Updated dependencies [0082db8]
+- Updated dependencies [06915b0]
+- Updated dependencies [ff84b05]
+  - @object-ui/i18n@17.5.0
+
+## 17.4.0
+
+### Minor Changes
+
+- ecae400: Retire the `capability-multiselect` field widget name, which existed only on the docs-site registration path and which nothing ever stamped (objectui#3308, ADR-0049 enforce-or-remove)
+
+  `field:capability-multiselect` was registered by `registerFields()` and only there. That function's sole caller is the docs site, so the key never existed on the live path (`registerAllFields()`, run at module import, iterates `fieldWidgetMap` — which never listed it). A field authored with `widget: 'capability-multiselect'` therefore resolved to nothing in every real application, while the comment above the registration described it as usable from a record form: a code comment promising a capability that does not exist, which is the worst direction for a metadata renderer AI-authored apps read as authority.
+
+  Nothing stamped the hint either. ADR-0056 P1 stamps `permission-facet-link` on all six `sys_permission_set` facets — `system_permissions` included — through the single `ObjectStackAdapter.getObjectSchema` choke point, and P2 put the capability editor in Studio. The widget name was a leftover from an intermediate iteration of that rollout.
+
+  Removed, with a tombstone at each site:
+
+  - `@object-ui/fields` — the `field:capability-multiselect` registration and the comment that advertised it. **Breaking in name only**: the key was unreachable outside the docs site, so no application could have resolved it. A field still carrying the hint now degrades to its declared `type` renderer, the defined behavior for an unregistered widget.
+  - `@object-ui/plugin-detail` — `InlineFieldInput`'s `widget === 'capability-multiselect'` branch, the hint's last honoring surface. Leaving one consumer for a name no producer emits and no form resolves is the same declared-vs-enforced split, inverted. The sibling `permission-facet-link` branch is untouched and pinned.
+  - `@object-ui/components` — the dead `capability-multiselect` entry in the form renderer's `DATA_SOURCE_FIELD_TYPES` set, which could never match a resolvable widget.
+  - `@object-ui/plugin-form` — a comment naming `capability-multiselect` as the widget stamped onto `sys_permission_set.system_permissions`; it names `permission-facet-link` now, which is what is actually stamped.
+
+  `CapabilityMultiSelectField` itself is **unchanged and still exported**: Studio's `PermissionMatrixEditor` imports and renders it directly, which is ADR-0056 P2's design. Only the widget name is retired — the component is not a registry field widget and its doc comment now says so.
+
+  `registerFields()` is also **kept**, with its `@deprecated Use registerAllFields() instead` note corrected. The two are not interchangeable: it registers `createFieldRenderer(widget)`, which synthesizes the label, description and the local `value`/`onChange` state that lets a bare field node (`{ type: 'currency', label: 'Amount' }`) render standalone in the docs demos. Retiring it needs a decision about where that demo chrome goes; the note now records that instead of implying a drop-in replacement.
+
+### Patch Changes
+
+- f0a625a: `disabled: ''` no longer greys out the remaining five action surfaces (objectui#3849)
+
+  objectui#3842 / PR #3851 fixed the "is a `disabled` gate DECLARED?" test on
+  `action:button` and app-shell's `DeclaredActionsBar`. Five same-shaped sites were
+  outside that PR's scope and stayed on `!= null`, so within one component the
+  `visible` gate asked `hasDeclaredVisibilityGate` while the `disabled` gate on the
+  next line asked `!= null` — two spellings of one question:
+
+  - `@object-ui/components` — `action:icon`, `action:group`'s inline button
+    (`InlineActionButton`) and dropdown item (`DropdownActionItem`), and
+    `action:menu`'s item (`ActionMenuItem`).
+  - `@object-ui/plugin-detail` — `record:quick_actions`' `QuickActionButton`.
+
+  Why the missing `!== ''` half is a defect on this key and not on `visible`:
+  `toPredicateInput('')` is `undefined` and `evaluateCondition(undefined)` is
+  `true`. On `visible` that `true` means SHOW, so an over-broad "declared" test and
+  a permissive empty predicate cancel out. On `disabled` it means DISABLE, so they
+  compound — `disabled: ''` (an empty predicate: nothing declared) rendered a
+  permanently greyed-out control, with nothing the author could write to un-grey
+  it. Unlike #3842's approvals inbox, these five are the general action face
+  (toolbars, dropdowns, record quick actions), so the reach is wider even though no
+  single high-value host owns them.
+
+  **Behaviour change surface, deliberately narrow.** Only `disabled: ''` changes —
+  from disabled to clickable, which is what "no predicate" asked for. `disabled:
+true` still disables, `disabled: false` and an absent `disabled` still do not, and
+  no expression-valued `disabled` changes verdict. On the four sites that also carry
+  the legacy non-spec `enabled` fallback, one consequence follows: an empty
+  `disabled` now falls THROUGH to that leg instead of short-circuiting on the empty
+  predicate, so an action spelling both (`disabled: ''` + `enabled: true`) becomes
+  clickable. `record:quick_actions` has no `enabled` leg, so its chain is the single
+  gate.
+
+  Routing those legacy `enabled` legs through the same definition is
+  behaviour-preserving by derivation rather than a fix: the leg is negated
+  (`disabled = !isEnabled`), so an empty predicate's `true` already arrived as "not
+  disabled" — the verdict "no gate declared" produces. #3842's four-shape derivation
+  table is reproduced next to the new pins, together with the statement that no
+  `enabled` case can go red by reverting that leg.
+
+  `hasDeclaredVisibilityGate` keeps its historic name (the objectui#3842 ruling): the
+  predicate is key-neutral, and one implementation behind two names is how a repo
+  grows dialects. The three `@object-ui/components` sites import it relatively;
+  `record:quick_actions` takes it from the package barrel, the cross-package route
+  objectui#3835 opened. Every call site says so in a comment.
+
+- 5bfaabd: `PageComponentSchema.dataSource` now reaches every object-bound block, not just
+  `list-view` — and `element:record_picker` stops discarding `view`
+  (objectstack#6953).
+
+  objectstack#5576 wired the spec's per-element data binding
+  (`dataSource: { object, view?, filter?, sort?, limit? }`) to `list-view` and left
+  the same declaration inert on every other page component. Two gaps remained, and
+  both were silent:
+
+  - **`element:record_picker` read four of the five keys and dropped `view`.** So
+    `dataSource: { object: 'account', view: 'hot' }` — the spec's own example —
+    built a picker over EVERY account instead of the rows the saved view selects.
+    Nothing threw and nothing rendered an error; the option list was simply wider
+    than what was authored, which also means a user could select a record the page
+    said was out of scope.
+  - **`object-grid` / `object-form` / `object-kanban` / `object-calendar` /
+    `object-chart` / `object-metric` / `record:related_list` read none of it.**
+    Each gates its fetch on its own `objectName`, and nothing mapped
+    `dataSource.object` onto it, so a page written the way the spec documents
+    rendered an empty grid / a field-less form / a board with no cards / an empty
+    month / an empty chart / a static metric number — with no request and no
+    diagnostic anywhere. Spec-valid metadata rendering nothing is the
+    objectstack#4413 shape.
+
+  Composition follows objectstack#5576's landed semantics unchanged on every block:
+  a named saved view supplies the baseline, a key written on the component itself
+  overrides it, an explicit binding key overrides both, `filter` AND-combines
+  ("additional filter criteria" — a binding can narrow a view, never widen it), and
+  a `view` name that does not resolve renders a configuration error instead of
+  degrading to the object's full scope.
+
+  - `@object-ui/react` — new `useElementDataSourceSchema(schema, mapping, dataSource?)`
+    and `ElementDataSourceGate` apply a resolved binding to the schema keys a given
+    block reads, plus `ElementDataSourceErrorPanel` / `ElementDataSourceLoadingPanel`
+    for the two non-final states. One precedence table for all blocks rather than
+    one copy per block — that copy is how "additional filter criteria" would have
+    become two dialects.
+  - A mapping names **only** keys its block genuinely reads. A composed value
+    written onto a key the block ignores would be accepted and dropped, which is
+    the defect being removed, one layer deeper — so a kanban's swimlane `columns`
+    never receive a view's field list, and a block with no row cap leaves `limit`
+    unmapped. The per-block coverage table, including two residual gaps that are
+    named rather than papered over, is in `content/docs/guide/data-source.md`.
+
+  No behaviour changes for a block that carries no `dataSource`: the binding-free
+  path returns the schema by reference, so nothing remounts and nothing refetches.
+
+- 7b3e048: `record:highlights` publishes the `readonly` entry key, so an AI author can discover it from the manifest
+
+  `readonly` on a `fields[]` entry has been enforced for a while — the renderer copies it
+  through normalization and `HeaderHighlight`'s editability gate refuses inline editing on a
+  chip carrying it (objectstack#5077) — and `@objectstack/spec` declares it on
+  `RecordHighlightsField` (objectstack#5176 / PR #5607). The block's own published authoring
+  surface never mentioned it: the `fields` input still spelled the entry shape
+  `{name,label?,icon?,type?}`, and since the registry `inputs` are what
+  `gen-manifest.ts` serializes into `sdui.manifest.json`, an author reading the manifest was
+  told the key did not exist. The `fields` description now states the full entry shape and
+  what `readonly` does, which is the discoverability the manifest is for.
+
+  `readonly` is documented **inside** the `fields` description rather than declared as an
+  input of its own, because that is where the contract puts it. The spec's
+  `RecordHighlightsProps` has exactly three top-level keys (`fields`, `layout`, `aria`) and
+  carries `readonly` per ENTRY. A top-level `{ name: 'readonly', type: 'boolean' }` input
+  would publish a key the platform silently discards: the generated `sdui.manifest.json` and
+  `sdui-intrinsics.d.ts` would advertise a `readonly` prop, the manifest gate validates
+  top-level props only and would raise no diagnostic, `RecordHighlightsProps` is a plain
+  `z.object` so the unknown key is stripped on parse without error, and the renderer — which
+  reads `field.readonly` per entry — would never see it. An author who trusted that surface
+  would be left with the machine-owned column still hand-editable and no diagnostic anywhere
+  explaining why. `ComponentInput` is flat by design, so an array-of-objects input publishes
+  its member keys in prose, as `record:path.stages` and `record:alert.action` already do.
+
+  A new spec-parity test derives both directions from `@objectstack/spec` at runtime instead
+  of restating today's key list: every key of `RecordHighlightsField`'s object arm must be
+  named in the `fields` description, and the block must declare no top-level input that
+  `RecordHighlightsProps` does not accept. Nothing previously cross-checked the registry
+  `inputs` against the spec, so both drift directions were silent. No runtime behaviour
+  changes.
+
+- aca561a: Four spec keys the renderers already honoured are now discoverable from the published `inputs`
+
+  `record:details.hideFields`, `record:related_list.relationshipValueField`,
+  `record:related_list.add` and `element:text_input.defaultValue` were declared by
+  `@objectstack/spec` and read by their renderers, while the registry `inputs` —
+  the surface `gen-manifest.ts` serializes into `sdui.manifest.json` and
+  `sdui-intrinsics.d.ts` — never mentioned them. Nothing anywhere reported the
+  mismatch, and every layer that reads a manifest said the opposite of the
+  runtime: the keys were in no designer panel and no generated `.d.ts`,
+  `sdui-parser`'s prop walk returned `unknown-prop` for an author who wrote one,
+  and the renderer honoured it regardless. That is objectui#3407's original
+  complaint (`readonly` was enforced and honoured, the description just never said
+  so) on four more keys.
+
+  Each description is derived from what the renderer actually does, not from
+  restating the spec's one-liner, because the two can differ and the published
+  text is what an AI author reads:
+
+  - `hideFields` documents bare field names only — the renderer tolerates
+    `{name}` / `{field}` entries but the spec is `z.array(z.string())` and rejects
+    them, so teaching that spelling would publish a dialect the contract refuses;
+  - `relationshipValueField` publishes the renderer's `'id'` default and says that
+    the resolved value drives the list filter, the Add-picker link value and the
+    pre-filled create form together;
+  - `add` publishes its member shape in prose (`ComponentInput` is flat and has no
+    member-shape slot) with each default taken from the renderer — including
+    `picker.labelField`, where the renderer defaults to `name` while the spec's
+    own wording says "the object title field". It also names `picker.filter` as a
+    KNOWN GAP rather than documenting it as a restriction: the spec declares it
+    and nothing reads it, so an author would otherwise believe their picker is
+    scoped when it offers every record (objectui#3831);
+  - `defaultValue` distinguishes the two behaviours an author can get — seeding a
+    bound page variable once while it is still empty, versus the native
+    uncontrolled initial value with no variable bound.
+
+  `element:text_input` is not in the public tier, so its gap was not in
+  `sdui.manifest.json` at all — it was in the JSX-page compiler's prop whitelist,
+  which `renderers/layout/page.tsx` builds from `getKnownTypes()` plus these same
+  `inputs`, making the undeclared `defaultValue` a live `unknown-prop` warning.
+
+  The repo-wide parity gate now runs in both directions over one covered set and
+  one exemption discipline, so neither direction can be forgotten again the way
+  the reverse half was after PR #3806. Nine spec keys stay deliberately
+  unpublished, each with a written reason and a tracking issue: two the renderers
+  do not read at all (objectui#3829), three retired upstream by ADR-0087
+  tombstones, `page:tabs.type` (a carrier collision, objectstack#6776), two
+  `targetVariable` declarative hints (objectui#3834), and
+  `element:record_picker.filter` (objectui#3830).
+
+- 6d762da: The five locale keys behind #3546's eight no-fallback `t()` call sites are now defined in all ten packs, so the built-in-view toasts, the activity-timeline source link, the wizard's required-field toast and the Gantt refresh button's accessible name are translated instead of falling back to English — or, on two surfaces, to the key itself (part of #3546).
+
+  `scripts/check-i18n-call-site-keys.mjs` measured 258 keys that a `t()` call site asks for and no pack defines. These five were the subset with no working inline default: `console.objectView.cannotEditMetaView`, `console.objectView.cannotDeleteMetaView`, `detail.viewSource`, `gantt.toolbar.refresh` and `wizard.missingRequired`. Adding a `defaultValue` is deliberately not the fix — that mechanism is what kept all 258 invisible for months.
+
+  **Two of the eight sites really did render the raw key**, and both go through a binding with nothing in front of i18next. `ObjectView.tsx` calls `useObjectTranslation()` directly, so five toasts read `console.objectView.cannotEditMetaView` / `cannotDeleteMetaView` on screen; the `|| 'Built-in views cannot be renamed.'` guards next to them were dead on every path, because i18next answers a miss with the key itself and a non-empty string never falls through `||`. Those four unreachable English strings are removed rather than repaired: one key served four call sites (rename / pin / set-as-default / configure), so the pack copy covers any change to a built-in view instead of naming one operation. `RecordActivityTimeline.tsx` fails the same way for a subtler reason — `useDetailTranslation` is `createSafeTranslation(..., 'detail.back')`, and because `detail.back` does resolve, the probe hands back i18next's `t` for every key and bypasses the defaults map wholesale, so `detail.viewSource` reached the user verbatim.
+
+  **The other two sites were not rendering a raw key**, contrary to the issue's description, and are fixed here as the milder "English in all ten languages" class. `wizard.missingRequired` is its own hook's probe key, so the probe failed and `createSafeTranslation` correctly served its English default. `gantt.toolbar.refresh` goes through `useGanttTranslation`, which deliberately does not use `createSafeTranslation` and falls back per key — so the refresh button's `aria-label` was "Refresh", in English, never the key. Screen-reader users heard an English word rather than an identifier; a `zh` session now hears 刷新.
+
+  Regression cover is provider-mounted on purpose: with no `I18nProvider` the defaults maps answer every one of these keys and the assertions pass while the console is broken, which is precisely the false-green the issue documents. For the two sites whose English output was already correct, `en` cannot discriminate before from after — the `zh` assertions are the ones that pin the fix.
+
+- 4178d5a: `record:details` 的 `sections` 输入说明改为从 spec 形状派生的对象形,不再教已被退役的「Section IDs」
+
+  `inputs` 不是文档,而是发布出去的编写契约:`gen-manifest.ts` 把它序列化进
+  `sdui.manifest.json`(保存门 + parser 白名单)和 `sdui-intrinsics.d.ts`。而
+  `record:details.sections` 的说明写的是 `Section IDs to show (required when layout
+is "custom")` —— 那是 17.x 以前的形状。pin 版 `@objectstack/spec@17.0.0-rc.5` 的
+  `RecordDetailsProps.sections` 是对象数组 `{ name?, label?, columns?, fields }`,
+  objectstack#5611 把 `z.array(z.string())` 那条拼法**删掉**而不是 union 进来(既无
+  producer 也无 consumer,一种形状而不是两套事实契约)。
+
+  照旧说明写 `sections: ['contact_info', 'address']` 的作者,在四层之间拿不到任何
+  诊断:`['a','b']` 对 manifest 门是合法 `array`(门只看顶层键名 + 粗类型),上游
+  `validateComponentProps` 是 advisory 级,spec 只在真的走 parse 的路径上才拒,而
+  `RecordDetailsRenderer` 对每个条目读 `s.name` / `s.label` / `s.fields` —— 字符串上
+  三者全 `undefined`,该 section 一个字段都不渲染。`layout: 'custom'` 时 sections 是
+  详情页正文的唯一来源,所以结果是一张没有报错的空白详情页。
+
+  新说明逐键派生自 spec 各成员的 `.describe()` 与渲染器实读:`fields` 必填、按序渲染;
+  `label` 是标题(省略即无标题、无边框);`name` 是 snake_case 稳定标识与 i18n 锚点
+  (标题走 `objects.{object}._sections.{name}.label`);`columns`(1-4)是本 section 的
+  字段栅格宽度,省略则由渲染器推导;并明确写出字符串条目不被接受。渲染器另外还认的
+  `title` / `showBorder` / `hideEmpty` **故意不写进说明** —— spec 的 section 对象没有
+  声明它们,parse 时会被静默剥掉,发布它们等于教作者写契约丢弃的键。
+
+  同时新增 `recordDetailsInputs.spec-parity.test.ts`:两个方向的断言都在运行时从 spec
+  schema 派生(每个 spec 成员键都能从说明里发现;本 block 不声明 spec 不接受的顶层
+  input),所以下一次 spec 变形会先让测试红,而不是又一次静默张开。仅说明文本变化,无
+  运行时行为改动。
+
+- 54233b1: Record detail pages: a header ⟳ that refreshes the record, its related lists and its tab counts in place — no browser reload
+
+  Concurrent-editing scenario from the shop floor (MES work orders): operator A sits on a record's detail page while operator B starts or reports the same order. A had no way to see the new state except F5, which throws away the open tab, the scroll position and any in-progress inline edit along with the stale data.
+
+  The pipeline for this already existed — the objectui#2269 invalidation bus refetches every mounted reader in place, and `RecordContext.refresh` had been declared for it — but nothing produced that field and no UI reached for it. Three changes give it a trigger:
+
+  - **`RecordDetailView` produces `RecordContext.refresh`**, publishing `notifyDataChanged({ objectName: '*' })`. The wildcard is deliberate: a user reaches for refresh because of a write made by SOMEONE ELSE, which this client never saw and therefore cannot attribute to particular objects. `'*'` marks everything mounted as stale, so the main record, every related child list and the tab-count badges all refetch — no remount, so tab / scroll / draft state survive. First phase covers the standalone record route; embedded hosts (list drawer, split-pane preview) keep their existing chrome unchanged.
+  - **`page:header` renders the ⟳** at the far end of the header row when — and only when — the host provides `refresh`. It is page chrome rather than a header action, so its position is the same on every record page regardless of which business actions the object declares, and it can never be collapsed into the `⋯` overflow. Styled as that `⋯` trigger's twin so the row reads as one button family. Its accessible name and tooltip come from the existing `common.refresh` key, so the icon-only button is not English-only in the other nine locales. The icon spins for a short floor after a click, because the bus is fire-and-forget and a warm backend would otherwise finish before the click looked like it landed.
+  - **`RelatedList` accepts the `'*'` wildcard** on the legacy `objectui:related-changed` event, matching what `dataChangeMatches` already does for the bus's own readers. This listener compared the payload's object name to its own, so a wildcard invalidation reached everything on the page except the related lists — a concrete foreign object name is still ignored.
+
+  Hosts that provide no `refresh` render exactly as before.
+
+- 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` 的列 —— 类型全绿、查询错误、无任何诊断。
+
+- acc34c5: `record:related_list`: an `add` without `add.picker` no longer takes the whole related list down.
+
+  The Add-picker gate compared only `add` for truthiness and then read `add.picker.object` bare, so page metadata declaring `add` but omitting the (spec-required) `picker` threw during render and `SchemaRenderer` replaced the entire related list with a "Component failed to render" card whose message never mentioned `picker`. Both the Add button and the picker dialog now gate on the resolved `add.picker.object` — the list body renders as usual, only the unconfigured Add affordance is withheld, and a console hint names the missing key. Off-spec `add` still does nothing, so no lenient second dialect is introduced; producing-side validation of page metadata is tracked separately.
+
+- c4768a7: `record:related_list` — the declared `filter` reaches the query, and the Add button answers to the same gate as its dialog
+
+  - **`filter` is consumed** (objectstack#7118). The spec declares
+    `RecordRelatedListProps.filter` ("additional filter criteria") and this repo
+    published it as a registry input, but nothing read it: `RelatedList` built its
+    query from `{ [relationshipField]: parentId }` alone, so an authored filter was
+    accepted by every gate and silently dropped — the list answered with every child
+    of the parent. It is now AND-combined with the parent condition (never
+    substituted for it, so an additional criterion can only narrow), lowered through
+    the repo's single filter sink so the spec's `[{ field, operator, value }]`
+    vocabulary and a composed `dataSource` binding both work. With nothing authored
+    the query is unchanged. As a consequence a saved view named through
+    `dataSource: { object, view }` no longer contributes its columns/sort/limit while
+    its filter is discarded — the list can no longer be wider than the view it names.
+    On the legacy raw-URL fallback path, which cannot express an operator, a declared
+    filter is refused with a console explanation instead of dropped.
+  - **The Add button now requires `dataSource`** (objectui#3895), matching the picker
+    dialog and the add callback. In hosts that supply no `RecordContext` — Studio
+    designer previews, context-free embeds — the button rendered and did nothing at
+    all when clicked; the affordance is now withheld where the capability behind it
+    is absent.
+
+- Updated dependencies [7864f03]
+- Updated dependencies [f5f8744]
+- Updated dependencies [69becd2]
+- Updated dependencies [5e52495]
+- Updated dependencies [b750823]
+- Updated dependencies [ac2139c]
+- Updated dependencies [b14ab3a]
+- Updated dependencies [8c60819]
+- Updated dependencies [e64a52e]
+- Updated dependencies [844d17f]
+- Updated dependencies [4dcd52a]
+- Updated dependencies [42ae5c6]
+- Updated dependencies [6d762da]
+- Updated dependencies [f9faa7d]
+- Updated dependencies [33526fd]
+- Updated dependencies [32413ec]
+  - @object-ui/i18n@17.4.0
+
+## 17.3.0
+
+### Minor Changes
+
+- 5af2852: The record detail page now shows a read-gated approval panel (#3461). A record in approval used to expose NOTHING about the running approval to anyone but the current pending approver — `useRecordApprovals` was consumed solely to inject the header Approve/Reject buttons, while the pending-approver list, decision progress, and the `sys_approval_action` timeline existed only in the Approval Center's drawer, a `setup`-app surface that business roles can't navigate to (and whose backing object is tenant-wide, so granting read there is over-broad). The submitter couldn't tell whom to nudge; the record's own audit history was no help either, since the engine mirrors business fields as `runAs:'system'` and decisions never enter record history. The new surface is an **Approvals tab** on the record page — a peer of Details/Related (same promotion Attachments got in objectstack#4358), emitted by `buildDefaultTabs` only when the record actually has requests, with a request-count badge and the label localizing through the tab strip's KNOWN_LABEL_DICT (审批). The tab wraps the new `record:approvals` node (`RecordApprovalsPanel`), visible to EVERY viewer who can read the record: current flow/step with the enriched flow-steps strip, server-computed decision progress (quorum tally, per-group 会签 ticks), the waiting-on chips with server-resolved names and group labels (never raw ids), one chronological action timeline merged across all of the record's requests (a multi-level flow opens one request per node), decision comments and attachments, and an inline remind button for the submitter (`viewer.is_submitter`, with an id-match fallback for older backends) that POSTs the existing `/approvals/requests/:id/remind`. The host threads its live `useRecordApprovals` read through the node so the tab and the header decision buttons never disagree; on authored pages the `record:approvals` renderer self-fetches, and an authored page that omits the node gets a bottom-of-page fallback append so the approval story is never lost to a custom layout. Copy reuses the Approval Center's `approvalsInbox.*` keys so the two surfaces can't drift; `useRecordApprovals` now exposes the full `requests` array plus `listApprovalActions` / `remindApprovalRequest`, and its `ApprovalRequestLite` carries the display enrichment (`process_label`, `step_label`, `flow_steps`, `viewer`, `round`) the single-read endpoint already sent.
+
+### Patch Changes
+
+- 532cf8b: Deliver the required state to the control in the five renderers outside the object form that still painted it as an asterisk only (objectui#3299 — the same defect #3290/#3298 fixed in `form.tsx`).
+
+  Each site converges on the reference shape (`EmbeddableForm.tsx`): the control carries `aria-required={required || undefined}` and the asterisk is `aria-hidden="true"`, so assistive tech announces required once, as a state — instead of hearing a bare "asterisk" folded into the accessible name, or nothing at all.
+
+  - `@object-ui/app-shell` — `ActionParamDialog` (both the boolean row and the default branch, delivered through the real field widgets' `toDomProps` whitelist) and `CreateViewDialog` (display label, machine name, and every type-specific required-field selector).
+  - `@object-ui/components` — the custom `ActionParamDialog` (all five typed branches, including the Radix select trigger) and `FieldContainer`, whose existing Slot injection (`id` / `aria-describedby` / `aria-invalid`) now also injects `aria-required`, covering every consumer in one place.
+  - `@object-ui/plugin-detail` — `InlineCreateRelated`'s create-tab inputs.
+
+  Deliberately NOT the native `required` attribute (#3290 ruling): each of these hosts runs its own validation, and native `required` would arm the browser's constraint-validation bubble beside it. The SDUI controls that already use native `required` (`renderers/form/{input,textarea,select,checkbox}.tsx`, `basic/text-input.tsx`) are unchanged — they don't have a second validator, so their channel is already correct.
+
+- b71fc92: Localize the last untranslated console-chrome accessible names (objectstack#5430)
+
+  Four icon-only controls still carried hardcoded English accessible names, so
+  under a non-English session they were the only English left in the record
+  chrome — and because the controls have no visible label, that literal _is_ the
+  control to a screen reader and to the hover tooltip.
+
+  - `page:header`'s `role="toolbar"` — now `detail.pageHeaderActions` (its `⋯`
+    overflow trigger eight lines below was fixed in #5407; the toolbar was missed)
+  - `ReactionPicker`'s `role="listbox"` popup — now `detail.emojiPicker`
+  - `ReactionPicker`'s per-reaction chip, which built its name by concatenation
+    with English pluralization baked in (`reaction${count !== 1 ? 's' : ''}`) —
+    now `detail.reactionCount` / `detail.reactionCountOne`
+  - `NavigationOverlay`'s drawer close and split-panel close — now `common.close`
+    (the key the rest of the console already uses) and `common.closePanel`
+
+  The pluralized label follows this repo's **two-key** convention
+  (`detail.relatedRecords`/`relatedRecordOne`, `lookup.recordCount`/`recordCountOne`)
+  rather than an i18next `_one`/`_other` pair: zh/ja/ko have no separate singular
+  form, so those packs would legitimately omit the `_one` half and
+  `all-locales-key-parity` would read that as a lost key.
+
+  All five new keys are added to all ten locale packs.
+
+- 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.
+
+- bbbde12: Behavior change — **an authored display `type` can NARROW inline editability, but never WIDEN it** (objectui#3355).
+
+  Both detail-surface editability gates (`HeaderHighlight`, the `record:highlights` strip; `DetailSection`, the details body) used to resolve ONE effective type with display precedence — `viewFieldType || objectFieldType`. An authored non-computed `type` therefore ERASED the object's `formula` / `summary` / `rollup` / `auto_number` declaration from the gate's view, and a machine-owned column became inline-editable.
+
+  The gate now reads the two types separately and takes their UNION: a field is non-editable if the authored entry type **or** the object field's type is computed. Renderer/editor selection keeps the old precedence, so nothing about the display changes — only who may write.
+
+  What flips:
+
+  - `{ name: 'supply_share', type: 'number' }` authored over an object field declared `rollup` (or `formula` / `summary` / `auto_number`) — a display override written to fix formatting — no longer offers a pencil / double-click editor. This is the shipped configuration behind objectstack-ai/objectstack#5077: a hook-maintained rollup was overwritten by hand from the header strip and stayed corrupted until an unrelated child-row touch re-fired it (downstream yinlianghui/hotcrm-heimao#61).
+  - Narrowing is unchanged: an authored `type: 'formula'` still locks a plain object column.
+  - Fields with no authored computed type over a plain object column stay editable, and the entry-level `readonly` declaration from objectui#3356 is still honored.
+
+  The object schema is authoritative about what is machine-computed; a presentation override has no business granting write access. The rule now lives in ONE shared helper, `isComputedFieldType` in `fieldEnrichment.ts` — beside `enrichDetailField`, the module both hosts already share — with the computed-type set moved there too (still re-exported as `TEXTUAL_REF_FALLBACK_TYPES`), so the strip and the body cannot drift apart again.
+
+- 5a24ad9: Localize `RecordDetailDrawer`'s drag-resize handle (objectstack#5733)
+
+  `packages/plugin-detail/src/RecordDetailDrawer.tsx` carried a byte-identical twin
+  of the literal objectstack#5506 removed from `NavigationOverlay`: a
+  `role="separator"` drag handle on the drawer's left edge with a hardcoded
+  `aria-label="Resize drawer"`. #5506's sweep fenced on `packages/components`, so
+  this second copy survived it.
+
+  The handle has no visible label, so that string IS the control as far as a
+  screen reader is concerned — a zh/ja/de session got one English announcement in
+  an otherwise localized drawer. It is not a dormant branch either: `resizable`
+  defaults to `true`, and the drawer is what plugin-kanban / plugin-calendar /
+  plugin-gantt open on row, card and event click.
+
+  It now reads `t('common.resizeDrawer')` — deliberately the SAME key #5506 gave
+  the other handle (already present in all ten locale packs) rather than a new
+  `detail.resizeDrawer` twin, so one control rendered from two packages cannot end
+  up with two translations that drift apart.
+
+  `common.resizeDrawer` is also added to `DETAIL_DEFAULT_TRANSLATIONS`, the map
+  `createSafeTranslation` falls back to when no `I18nProvider` is mounted. Without
+  that entry the name would degrade to the raw key for every provider-less host —
+  which is the regression the accompanying no-provider test pins.
+
+- 23018cc: `record:highlights` now honours a `readonly: true` on an authored field entry, so a header chip for a platform-owned column no longer offers inline edit. `HeaderHighlight`'s editability gate already consulted `field.readonly`, but the renderer rebuilt each entry from a fixed `{name,label,icon,type}` list and dropped `readonly` one layer before that check, so the gate could never fire from authored metadata — a hook-maintained rollup or approval-written grade could be overwritten by hand from the detail-page header strip and stayed wrong until an unrelated write re-fired the computation. `readonly` is now a declared key on `HighlightField` and on the `RecordHighlightsComponentProps.fields[]` entry union, mirroring `DetailViewField.readonly` (objectstack#5077).
+- 58a00f0: Give `InlineCreateRelated`'s card-header close button an accessible name (objectui#3411 — the neighbouring defect found while implementing #3381/PR #3410, in the same file and left outside that PR's scope fence as a different class).
+
+  The button is icon-only: its sole child was a lucide `X`, with no text, `aria-label`, `aria-labelledby` or `title`. lucide-react excludes childless, a11y-prop-less icons from the accessibility tree (it defaults them to `aria-hidden="true"`), so the button had no name source at all and its computed accessible name was the empty string — a screen reader announced a nameless "button". Unlike the placeholder case in #3381 there was no browser-side fallback to soften it: the name was empty in every implementation. WCAG 4.1.2 / 2.4.6.
+
+  The fix is `aria-label="Close"` on the button, plus an explicit `aria-hidden="true"` on the icon so the intent is local rather than inherited from the icon library's default. `aria-label` rather than #3381's visually hidden `<label>` because this control has no visible copy for a label to stay in step with — the drift that ruling guarded against cannot arise here — and it matches the shape the repo's other close buttons already use (shadcn's dialog/sheet, `DashboardEditor`).
+
+  No props, spec or visible-copy change; the component's rendering is otherwise identical.
+
+- 53811d1: Associate the label with its control at the two form surfaces where the two were never programmatically connected (objectui#3341 — found while implementing #3299/PR #3340, and deliberately left out of that PR's scope fence as a different class of defect).
+
+  `aria-required` reaching the control (#3299) only fixes the required _state_; at these two sites the control's accessible _name_ was still wrong, because the label pointed at nothing:
+
+  - `@object-ui/plugin-detail` — `InlineCreateRelated`'s create-tab fields rendered a `<label>` with no `htmlFor` beside an `<Input>` with no `id`, and the two were siblings rather than wrapper/child. The field label was unreachable for assistive tech, and clicking the label did not focus the input. The ids are namespaced with `React.useId`, because `field.name` alone is unique only within one instance and a detail page mounts one of these per related list.
+  - `@object-ui/components` — the custom `ActionParamDialog`'s `select` branch rendered `<Label htmlFor={param.name}>` but never put the matching `id` on its Radix `SelectTrigger`, so the reference dangled. The textarea / number / date / text branches already set `id={param.name}`; select was the only one that did not.
+
+  `SelectTrigger` renders a `<button role="combobox">`, and `button` is a labelable element, so the plain `htmlFor`/`id` pair is the correct association there — no `aria-labelledby` required. No spec change and no widget-props contract change.
+
+- b17ce4c: Give `InlineCreateRelated`'s "Link Existing" search box a real accessible name (objectui#3381 — the neighbouring defect found while implementing #3341/PR #3380, and left out of that PR's scope fence as a different class).
+
+  The box carried a `placeholder` and nothing else: no `<label>`, no `aria-label`, no `aria-labelledby`. Its accessible name therefore fell through to the placeholder, which is the last resort in HTML-AAM and fails in two ways — the name a browser derives from it is the one thing that disappears the moment the user types, and the fallback is not implemented uniformly (`dom-accessibility-api` has no placeholder step at all, so under test the control computed to the empty string while a browser would have said "Search Contact…").
+
+  The fix is a visually hidden `<label htmlFor>` pointing at a `React.useId`-namespaced input id — the same shape #3341 left on the create tab, rather than an `aria-label`, so the accessible name stays a real label element instead of a detached string that can drift from the visible copy. The label text and the placeholder are now derived from one expression (the placeholder only adds the ellipsis), and the id uses a hyphenated `link-search` segment so it cannot collide with a create-tab field literally named `search`. The decorative magnifier is explicitly `aria-hidden` — lucide already defaults childless icons to that, but spelling it out keeps the intent local and independent of the icon library's defaults.
+
+  No props, spec or rendered-copy change: the placeholder string is byte-identical to before.
+
+- c7fba27: `field:permission-facet-link` now registers through `withFieldCarrier` — the
+  repo's only raw `field:` registration bypassed the single-metadata-carrier seam
+  (objectui#3233), so under the SDUI path (`SchemaRenderer` passes `schema`,
+  never `field`) the widget read `field === undefined` and silently rendered an
+  anonymous facet summary (`field?.name` empty, no facet branch selected). The
+  form and inline-edit hosts were unaffected — they pass `field` directly, which
+  the carrier forwards unchanged. Fixes objectui#3307.
+- 12bf669: The record discussion panel now says "loading" while it is loading, instead of
+  "No comments yet" (objectui#3209).
+
+  FROM: opening any record page showed the discussion/chatter panel asserting
+  `No comments yet` for the whole first leg of the page, then contradicting
+  itself when the comments appeared. TO: the panel shows the loading row until
+  the feed has actually answered, and only then commits to "this record has no
+  comments".
+
+  objectui#3205 gave `RecordActivityTimeline` the render branch that prefers a
+  loading row over the empty copy, and `RecordChatterPanel` already forwarded
+  `loading` to it in both positions — but on the chatter chain **nothing
+  produced the signal**, so that branch could never fire. `record:activity`
+  computes its own flag and was visibly fixed by #3205; chatter was not. The
+  four wiring points are one chain and are all closed here, because any one of
+  them left open still ships the empty copy to some user:
+
+  - `RecordDetailView` — the host that OWNS the feed fetch — now derives a
+    `feedLoading` flag from its two reads (`sys_comment` + `sys_activity`);
+  - `<DiscussionContextProvider loading={feedLoading}>` publishes it (the field
+    was already declared on `DiscussionContextValue`, and already read by
+    `record:activity`);
+  - the auto-appended `<RecordChatterPanel loading={feedLoading}>` — the panel
+    authored pages get when they place no discussion slot — receives it
+    directly;
+  - the `record:chatter` / `record:discussion` renderer forwards
+    `loading={discussion?.loading}`, so a hand-placed block is on the same
+    chain as the synthesized one.
+
+  The two reads run in parallel, so the flag closes over **both**: it clears on
+  `Promise.allSettled`, and a REJECTED read counts as an answer. A deployment
+  without the audit plugin 404s `sys_activity` and an object with
+  `enable.feeds: false` 403s `sys_comment`; neither may pin the panel in a
+  permanent spinner, which would be a worse bug than the one being fixed. The
+  flag is keyed by `object:recordId` rather than being a plain boolean, so the
+  first render of a record already reads as loading (no one-frame flash of the
+  empty state) and navigating between records cannot show the previous record's
+  settled answer.
+
+  No tolerance was added at the consumer. The timeline still does not guess that
+  "no items yet and just mounted" means loading — that guess is wrong the moment
+  a record genuinely has no comments, and the signal belongs to whoever owns the
+  fetch. Same shape as objectui#3165 / #3205: divergence converges at the
+  producer.
+
+- Updated dependencies [b71fc92]
+- Updated dependencies [65516ba]
+- Updated dependencies [94c5b7c]
+- Updated dependencies [ca0fa8f]
+- Updated dependencies [3889ffb]
+- Updated dependencies [7e2406a]
+- Updated dependencies [4eeb932]
+- Updated dependencies [5c856ec]
+- Updated dependencies [68b6a28]
+- Updated dependencies [0554e88]
+- Updated dependencies [28b2e65]
+- Updated dependencies [825bbe3]
+- Updated dependencies [6195841]
+- Updated dependencies [5dd0127]
+- Updated dependencies [a415684]
+- Updated dependencies [5af2852]
+- Updated dependencies [a6ec93d]
+- Updated dependencies [c7ed4c3]
+- Updated dependencies [2409e1d]
+- Updated dependencies [789fe3e]
+  - @object-ui/i18n@17.3.0
+
 ## 17.2.0
 
 ### Minor Changes
@@ -1341,6 +2151,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
@@ -1355,6 +2166,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
@@ -1789,6 +2601,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
   unknown @-tokens. 9 unit tests.
 
   `@object-ui/app-shell` `RecordDetailView` now:
+
   1. Serializes the resolved mention ids into `sys_comment.mentions`
      (previously hard-coded `'[]'`, so servers had no idea who was being
      pinged).
@@ -1809,6 +2622,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
   and the renderer also falls back to a value/label heuristic (matches
   `closed_lost`, `lost`, `failed`, `cancelled`, `失败`, `流失`, `丢单`, etc.)
   so existing CRM-style picklists get the treatment without migration.
+
   - **Lost** stages render in a visually separated group with a left
     border, destructive (red) tint, pill shape, and `✗` glyph — mirroring
     the Salesforce / HubSpot alt-terminus pattern that signals "this
@@ -1838,6 +2652,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
   - Stage chevron (`record:path`): bump completed-stage contrast (emerald-800 text on emerald-500/15, was 700 on /10) and future-stage text from `foreground/70` to `foreground/85` for legibility.
   - i18n: add `notifications.emptyUnread`, `notifications.filterUnread`, `notifications.filterAll` (en + zh) so the InboxPopover Unread/All sub-filter renders in the active locale.
 - 5425608: CRM UX polish pass — calmer enterprise look across detail + kanban.
+
   - **plugin-kanban**: column headers now use a 2px muted accent stripe with
     neutral foreground titles + a quiet grey count pill instead of full
     rainbow gradient + colored title + colored count. Pipeline boards
@@ -1862,12 +2677,14 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
 - 5633edd: feat(detail,grid): tab + selection motion polish
 
   **plugin-detail**
+
   - `DetailTabs` and the auto-tabs path in `DetailView` (5 inline
     `<TabsContent>` instances: details, related, activity, discussion,
     history) now fade in when their tab becomes active, eliminating
     the harsh flash when switching tabs.
 
   **plugin-grid**
+
   - `BulkActionBar` slides in from the bottom + fades in when a
     selection is made, instead of popping into existence.
   - The "N items selected" counter re-animates on every count change
@@ -1896,6 +2713,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`
@@ -1917,6 +2735,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
 - d1ec6a2: Fold inline-edit into the page-header overflow menu (HubSpot/Lightning
   pattern) and remove the orphan "Edit fields" toolbar row that previously
   floated between the tab strip and the first detail section.
+
   - `@object-ui/app-shell` `RecordDetailView`: injects a new `sys_inline_edit`
     system action that appears in the ⋯ overflow menu and dispatches a
     `objectui:record:inline-edit-toggle` window CustomEvent (filtered by
@@ -1933,6 +2752,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
     in `page:accordion` / `page:tabs` items.
 
 - cf30cc2: Polish Lightning record detail page layout.
+
   - `record:details` sections now render with Card chrome by default when a `title` is present, restoring visual grouping that was missing on pages like the opportunity detail page.
   - Section labels can be translated via the `{ns}.objects.{objectName}._sections.{name}.label` convention. Author each section with a stable `name` (e.g. `info`, `forecast`) and the renderer picks up the locale-specific label automatically. Falls back to the literal `label` when no translation exists.
   - The `page:header` action toolbar now collapses into a `⋯` overflow menu when more than two actions are present. The first business action stays inline; secondary system actions (Edit / Share / Delete) move into the menu, with destructive styling applied to Delete.
@@ -1947,6 +2767,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
   `CONCURRENT_UPDATE`). `RecordDetailsRenderer` catches it and opens a
   new `<ConcurrentUpdateDialog>` showing the user's pending value next
   to the server's current value, with three resolution paths:
+
   - **Reload latest** — discard the pending edit and refetch.
   - **Overwrite anyway** — retry against the server's freshest version
     (still OCC-checked, but acknowledges "I've seen the newer version").
@@ -1962,6 +2783,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
   backend support in `@objectstack/rest@>=4.2.0`.
 
 - 49b1760: Polish the ConcurrentUpdateDialog and add i18n.
+
   - Internationalise all dialog strings (title, body, button labels, "your edit" / "current value" headings, audit-trail line) through `useDetailTranslation`. Locale strings added to `@object-ui/i18n` for English and Chinese.
   - Replace the plain dialog header with an amber warning badge + `AlertTriangle` icon to communicate that this is a conflict, not a routine confirmation.
   - Visually differentiate the two value blocks: amber tint for the user's pending edit, sky tint for the server's current value. Both wrap long values cleanly.
@@ -1977,17 +2799,20 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
 - bd8447d: Three platform-wide detail polish items.
 
   **Tighter page rhythm**
+
   - Outer `PageRenderer` padding `p-4 md:p-6 lg:p-8` → `p-3 md:p-4 lg:p-6`
     and outer body wrap `space-y-8` → `space-y-6` so list / detail / home
     pages share the same edge rhythm. Cuts ~16px of edge slack on lg.
 
   **Highlights KPI treatment**
+
   - `HeaderHighlight` now renders numeric / currency / percent / decimal
     values as KPI numbers (`text-xl md:text-2xl font-semibold tabular-nums`)
     instead of the uniform `text-sm font-semibold`, so amount / probability
     / count fields read as headline stats — Salesforce-style key facts.
 
   **Discussion footer upgrade**
+
   - `RecordActivityTimeline` now uses `RichTextCommentInput` (bold / italic /
     list / code, `@`-mention autocomplete, preview toggle, Send) instead of
     a bare `<textarea>`.
@@ -2002,6 +2827,7 @@ pi-TgoJ4_DM55Fqz` — untranslated, and leaking the object's machine name and th
   accordion in flush mode dropped all per-item borders so the collapsed
   "Quotes / Products / Open Tasks" triggers stacked with zero visual
   separation.
+
   - `@object-ui/plugin-detail` `DetailSection`: override the `CardTitle`
     className to `text-base font-semibold tracking-tight`, slim down
     `CardHeader` padding (`py-3 px-4 sm:py-4 sm:px-6`) and `CardContent`
@@ -2016,6 +2842,7 @@ hover:no-underline` (Shadcn's hover-underline default looks busy on
     CRM-style related-list lists).
 
 - d51a577: feat(platform): Discussion attachments + @mention directory + Reference Rail aside
+
   - **Discussion attachments** — `RichTextCommentInput` now accepts an `extraSlot`
     and a `canSubmitEmpty` flag so hosts can mount the existing
     `CommentAttachment` composer beneath the editor without forking the toolbar.
@@ -2039,6 +2866,7 @@ hover:no-underline` (Shadcn's hover-underline default looks busy on
   custom `Page`. Catalog-style objects (Product, Task) ship with the rail
   off by default; hub objects (Account, Opportunity, Contact, Case) keep it
   on.
+
   - `RecordDetailView` now reads `(objectDef as any)?.detail?.hideReferenceRail`
     and `…?.hideRelatedTab` and threads them to `buildDefaultPageSchema`.
   - The Reference Rail renderer also accepts entries authored as either a
@@ -2089,6 +2917,7 @@ hover:no-underline` (Shadcn's hover-underline default looks busy on
   not only contacts of that account).
 
   Two coupled fixes:
+
   1. `RelatedList` now requires `parentId` + `referenceField` to auto-
      fetch. When both are present it calls `dataSource.find(api,
 { $filter: { [referenceField]: parentId } })`. When either is
@@ -2134,6 +2963,7 @@ hover:no-underline` (Shadcn's hover-underline default looks busy on
   default detail view. They were missing cross-cutting affordances and
   shipped with English-only tab labels and heavy bordered section cards
   even when the host locale was Chinese. Track 1 closes the visible gap:
+
   - **app-shell `RecordDetailView`**: the `assignedPage` branch now wears
     the same chrome as the default branch — lifecycle managed-by badge
     and presence avatars in the top-right, `MetadataPanel` debug panel,
@@ -2236,6 +3066,7 @@ hover:no-underline` (Shadcn's hover-underline default looks busy on
   layout — only the auto-inference default changed.
 
 - b14fe09: Phase P.0 + P.5: tighten record-detail header chrome.
+
   - `RecordTitleChip` collapses the title row to a single baseline-aligned line — H1, eyebrow object label, copy-id, favorite star — instead of the previous two-row title + subtitle layout.
   - `record:details` extends the highlight-field dedup set to also exclude the title field resolved from `objectSchema.primaryField` (or the standard `name`/`full_name`/`title`/`subject`/`display_name`/`label` fallbacks). Removes the duplicate row that previously echoed the H1 (e.g. "客户名称: Acme Corporation") inside the field grid.
 
@@ -2278,6 +3109,7 @@ populated` disclosure that expands on click. The expanded view shows
   result was visually noisy ("有的下划线，有的有边框，有的没边框").
 
   This change commits to a single design language:
+
   - **Highlights** (`HeaderHighlight`): drop the `Card`/`CardContent`
     wrapper. Render as a borderless `<section>` of stat cells with a
     subtle `border-b` separator. The tab strip below now carries the
@@ -2298,6 +3130,7 @@ populated` disclosure that expands on click. The expanded view shows
   by their tabular content. No internal package APIs changed.
 
 - 74962b0: feat(detail): record:discussion schema component + flush accordion variant
+
   - New `record:discussion` schema type lets authors place the record
     chatter feed anywhere in a custom Page schema. Wired through a
     shared `DiscussionContext` provider on the `assignedPage` branch
@@ -2311,6 +3144,7 @@ populated` disclosure that expands on click. The expanded view shows
     or `和` (e.g. `Notes & Attachments` → `备注与附件`).
 
 - 8b850b5: feat(detail): record:path chevron stepper + record:highlights surface refresh (Phase E)
+
   - `record:path` now renders Salesforce Lightning-style chevron segments
     (clip-path arrows + overlap) with a primary glow on the current step
     and a check mark on completed steps. On mobile (`<sm`) it falls back
@@ -2335,6 +3169,7 @@ populated` disclosure that expands on click. The expanded view shows
   accordion, discussion slot) that custom Lightning pages already enjoy.
 
   Changes:
+
   - `buildDefaultPageSchema` now emits `page:tabs.items` (correct shape
     for the renderer) rather than `tabs`.
   - `PageHeaderRenderer.resolvedTitle` honors `objectSchema.primaryField`
@@ -2358,6 +3193,7 @@ populated` disclosure that expands on click. The expanded view shows
   customize the header or one tab.
 
   **Slot menu (v1):**
+
   - `header` — replaces `page:header`
   - `actions` — replaces the `record:quick_actions` action bar
   - `highlights` — replaces the chips + chevron path strip
@@ -2385,6 +3221,7 @@ populated` disclosure that expands on click. The expanded view shows
   ```
 
   **API changes:**
+
   - `PageSchema` (in `@object-ui/types`): adds `kind?: 'full' | 'slotted'`
     (default `'full'`) and `slots?: PageSlotMap`.
   - `usePageAssignment` (in `@object-ui/react`): result now exposes a
@@ -2394,6 +3231,7 @@ populated` disclosure that expands on click. The expanded view shows
     `options.slots` map that overrides individual regions at synthesis time.
 
 - 34b66bf: feat(detail): synthesize Related / Activity / History tabs + record:quick_actions header (Track 3 Phase G slice 4)
+
   - `buildDefaultPageSchema` now accepts `headerActions`, `related`,
     `showActivity`, and `history` options. When provided, the synthesizer
     emits a `record:quick_actions` node after `page:header` and appends
@@ -2418,6 +3256,7 @@ populated` disclosure that expands on click. The expanded view shows
 
   Two regression fixes surfaced by the Phase J browser canary across CRM
   record detail pages:
+
   1. **`record:path` now localizes stage labels.** The renderer threads
      `useSafeFieldLabel().translateOptions` against the record-context's
      `objectName` + the schema's `statusField`, so picklist labels match the
@@ -2494,6 +3333,7 @@ populated` disclosure that expands on click. The expanded view shows
 - 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
@@ -2529,6 +3369,7 @@ Lin` and no `name` field now renders as `Bob Lin` everywhere — instead of
 ### Patch Changes
 
 - 0d8eb98: feat(detail): Salesforce-style record header + section field grid
+
   - `page:header` now renders an icon chip (resolves Lucide names via
     `LazyIcon`) plus subtitle, so detail pages can show
     "Name / Company" without an extra component.
@@ -2577,6 +3418,7 @@ Lin` and no `name` field now renders as `Bob Lin` everywhere — instead of
   detail view (`TypeError: titleFormat.replace is not a function`) and printed
   `Failed to evaluate expression: ${[object Object]}` for every action visibility
   predicate.
+
   - `@object-ui/core`: `ExpressionEvaluator.evaluate` / `evaluateCondition` now
     unwrap Expression envelopes transparently.
   - `@object-ui/react`: new `toPredicateInput()` helper to safely normalize
@@ -2628,6 +3470,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.