@object-ui/i18n 17.3.0 → 17.6.0

package/CHANGELOG.md

@@ -1,5 +1,1914 @@
 # @object-ui/i18n
 
+## 17.6.0
+
+### Minor Changes
+
+- deb157a: Retire the field designer's `Indexed` toggle — the ObjectStack spec has no
+  field-level index flag
+  
+  `indexed` was never a `FieldSchema` key. The field-level flag built no index
+  (objectstack#2377 removed it) and, since objectstack#4001 replaced silent
+  drops with loud rejection, `FieldSchema.safeParse` refuses it by name. Ticking
+  `Indexed` in Studio therefore made `PUT /api/v1/meta/object/:name` fail with
+  `422 INVALID_METADATA`, and — because the key was stored — every later save of
+  that object stayed blocked until the author found and cleared the toggle.
+  
+  Both field designers stop offering the control and stop authoring the key
+  (`ObjectFieldInspector`'s Advanced section; `FieldDesigner`'s advanced
+  section, `MetadataFieldsPage`, `MetadataService`, `metadataConverters`), the
+  `designer.field.indexed` / `appDesigner.fieldDesigner.indexed` labels retire
+  with it across all ten locale packs, and `DesignerFieldDefinition.indexed` is
+  removed from `@object-ui/types`.
+  
+  Drafts and objects that already carry the key are un-poisoned on load rather
+  than migrated, so an edit-and-save round-trip of previously blocked metadata
+  now succeeds. The strip is keyed to the retired key alone — every other
+  unknown key on a field definition still survives the round-trip.
+  
+  Declare indexes on the object instead: `indexes: [{ name, fields, unique }]`.
+- 9c60144: **Breaking (published API):** `NavigationRenderer` no longer accepts `resolveGroupLabel` or `resolveItemLabel`. If your build just broke on one of these props, delete the prop — it never did anything.
+  
+  Both were id-keyed label resolvers on `NavigationRendererProps` (`@object-ui/layout`), typically wired to `useObjectLabel().navGroupLabel` from `@object-ui/i18n` to translate sidebar group and leaf labels from a client translation pack keyed `{ns}.apps.{appName}.navigation.{nodeId}.label`.
+  
+  **They could never fire.** The renderer guards convention-based resolution with `isCustomized` — a case-insensitive "the authored label differs from this branch's comparison target" test. On the `object` / `dashboard` branches the target is the object or dashboard name, and the test is meaningful: it protects an author's custom label (`Projects`) from being overwritten by an `objects.project.label` translation. On the two id-keyed branches the target was the nav node's own **`id`** — `grp_workspace`, `group_sales` — while the label was its text — `Workspace`, `Sales`. Those never compare equal, so the guard was true for every real navigation entry and the resolver beneath it was unreachable. The only node that could have reached it is one whose label is literally its own id.
+  
+  Nothing regresses when they go, because nothing was using them to begin with: **app-navigation localization is owned solely by the server-side `/meta` boundary.** `translateApp` (`@objectstack/spec`, `src/system/i18n-resolver.ts`) rewrites every navigation node's `label` by id, and `@objectstack/rest` applies it before the metadata reaches the client — so nav labels arrive already localized and the client-side path was never the one answering. One owner, not two.
+  
+  **If you wired these hooks to localize navigation, your labels were never being localized by them.** Move the translation to the server side: add it to the app's i18n bundle that `translateApp` reads, keyed by navigation node id. A client-side pack keyed `apps.*.navigation.*.label` changes nothing in the sidebar.
+  
+  Also in this change:
+  
+  - `useObjectLabel().navGroupLabel` (`@object-ui/i18n`) is **kept**, but its docstring no longer promises `"Sales" → "销售"` for sidebar groups — that promise was false, and a live docstring describing an unreachable path is how an agent or a developer ends up wiring a translation pack and receiving silent non-localization. It is now documented for what it is: a plain reader for `{ns}.apps.{appName}.navigation.{groupId}.label` with no first-party caller, pointing at the server boundary for anything nav-related.
+  - `UnifiedSidebar` (`@object-ui/app-shell`) drops the two prop wirings, including a `studio` carve-out that existed only to stop `resolveItemLabel` from re-translating an already-translated "Package management" label.
+  - The `object` / `dashboard` / `viewName` branches — `resolveObjectLabel`, `resolveDashboardLabel`, `resolveViewLabel` — are untouched and keep both their resolvers and the `isCustomized` guard.
+- b8ce7dc: Show the current organization in the console top bar for users with exactly one
+  membership.
+  
+  `WorkspaceSwitcher` is a multi-membership affordance — with one organization
+  there is nothing to switch to, so it renders nothing — and it was also the only
+  place the console ever displayed the organization name. On a deployment whose
+  tenancy posture puts an organization wall in force (`isolated` or `group`), that
+  left a single-membership business user with no indication anywhere of which
+  organization they were looking at, while every list on the page was silently
+  scoped to it. Found in a downstream multi-tenant acceptance run.
+  
+  The new `CurrentOrganizationIndicator` renders the active organization name
+  read-only — no trigger, no menu, no click target — in exactly the case the
+  switcher declines. The switcher's own visibility rule is unchanged, and
+  deployments without an organization wall (`single` posture, or a server that
+  reports no posture at all) render nothing new: the top bar stays
+  organization-silent where organizations are not a scope the user is inside.
+  
+  Adds one translated string, `organization.current.label`, in all ten packs.
+
+### Patch Changes
+
+- 69251bf: `AddressField` is translatable, shows no US example placeholders, and formats its readonly line in the reader's address order.
+  
+  The five sub-labels ("Street Address", "City", "State / Province", "ZIP /
+  Postal Code", "Country") were English string literals with no i18n key. On a
+  non-English console every address field showed five English words in the middle
+  of an otherwise fully translated form, and an app had no way to reach them: the
+  parts are not fields on the object (`billing_address` is a single `address`
+  column), so a translation bundle had nothing to key on, there is no `subLabels`
+  property to declare, and the widget cannot be replaced from metadata. They now
+  resolve through `fields.address.street` / `.city` / `.state` / `.postalCode` /
+  `.country`, added to all ten locale packs. The `en` values are byte-identical to
+  the literals they replace, and `FIELD_DEFAULTS` carries the same five, so
+  English and provider-less rendering are unchanged.
+  
+  The five input placeholders (`123 Main St`, `San Francisco`, `CA`, `94102`,
+  `United States`) are **removed** rather than keyed. They were untranslated and
+  US-specific — a zh/ja/ar user was shown an American address as the example of
+  what to type — and the right example is a function of the address's country,
+  not the reader's language, which no channel in the stored value can supply
+  today. Each box keeps the visible label that names it.
+  
+  The readonly line's part order now follows the reader's display locale
+  (`useDisplayLocale()`): `zh`, `ja` and `ko` read largest-first (`Country, ZIP
+  State, City, Street`), every other locale keeps the unchanged small-to-large
+  order (`Street, City, State ZIP, Country`). The display cell renderer takes the
+  same locale through the same shared `formatAddress`, so a stored address reads
+  identically in a readonly form and in a grid cell.
+- 57e668f: An admin override of an approval now looks like one — before the click, and in the timeline afterwards.
+  
+  A platform/tenant admin who holds **no slot** in a request's pending-approver
+  slate saw the exact same filled **Approve** / **Reject** / **Reassign** a
+  designated approver sees: no distinct styling, no warning, nothing. One unmarked
+  click takes framework#3424's privileged branch, which is *authoritative* — it
+  finalises the node even under `per_group` / `unanimous` / `quorum`, silently
+  bypassing every co-sign group that has not voted. The measured consequence in a
+  real app project was a PM who clicked Approve *"to see if it was real"* and
+  finalised a stage for an approver who never acted, then filed it as "countersign
+  is broken". The backend was working as designed; the console gave the admin no
+  way to see that.
+  
+  Two halves, both client-side:
+  
+  - **Affordance.** A viewer the server reports as `can_act: false` **and**
+    `can_override: true` now gets a warning-styled action labelled as an override
+    (`Override Approve`), and the dialog it opens **names the pending approvers
+    being bypassed**. The wording is the fix, not decoration — a warning that does
+    not say what is about to be bypassed would not have stopped that click.
+  - **Timeline.** `sys_approval_action.via_override` has been written since
+    framework#4466 and sent on the wire ever since, but **no console surface read
+    it** — an override rendered byte-for-byte like an ordinary approval in both the
+    record page's approvals panel and the Approval Center. Override rows are now
+    marked with an `Admin override` chip and a distinct timeline dot. This is
+    framework#4466's own *Expected* ("surfaced in the timeline"), which never
+    landed.
+  
+  Nothing here relaxes anything. Who may act or override is unchanged, the request
+  the console sends is byte-identical, and no audit record is altered — this only
+  renders one that was already being written, and adds friction in front of a
+  privileged path.
+  
+  Two details worth knowing, because both are load-bearing:
+  
+  - The warning rides the **param dialog's** title and description rather than a
+    chained `confirmText`. These decision actions collect params, so the param
+    dialog is already the confirm — nothing is POSTed until its own Confirm — and
+    putting a second dialog in front of it produces a first prompt that reads as
+    "the action ran" (framework#7278, maintainer ruling 2026-08-10). One condition,
+    one wording, one dialog.
+  - The notice travels as its own dispatch key, **not** folded into the action's
+    `description`. The runtime resolves `description` through
+    `_actions.<name>.description`, preferring a bundle hit over the passed literal,
+    and `plugin-approvals` ships exactly such an entry for `approval_reject` — so a
+    warning routed that way would have been silently replaced by the ordinary
+    reject copy in every locale carrying the bundle. A safety notice a translation
+    can delete is not a safety notice.
+  
+  Which actions get the treatment is read from each action's **own declared
+  `visible` gate** (does it OR in `can_override`?), not from a hard-coded name
+  list, so a future decision action still ships as metadata alone — and
+  `approval_recall`, gated on `is_submitter`, is never relabelled. Every new string
+  goes through the `approvalsInbox.*` i18n path in all ten locale packs.
+- 516663d: RecordAttachmentsPanel no longer offers a Retry for an api-disabled `sys_attachment` read.
+  
+  `OBJECT_API_DISABLED` (404, `enable.apiEnabled: false`) and its sibling
+  `OBJECT_API_METHOD_NOT_ALLOWED` (405, the operation is absent from
+  `enable.apiMethods`) are pure functions of the object's metadata — no user, no
+  session, no request body — so every retry of every persona re-fetches the
+  identical refusal. Before this change both landed in `RecordAttachmentsPanel`'s
+  `unavailable` state and offered a Retry that was guaranteed to change nothing,
+  the same wrong advice `ListView`'s error panel already stops giving for list
+  reads.
+  
+  The panel gains a fifth status, `api-unavailable`: no Retry button, and honest
+  copy ("The attachments list is not available on this object.", new
+  `detail.attachmentsApiUnavailable` key in all ten locale packs) instead of
+  "We couldn't load the attachments for this record." The pre-existing `denied`
+  (authorization) and `unavailable` (network/5xx/expired-session) states and
+  their affordances are unchanged.
+  
+  `ListView.classifyLoadError` — the classifier that already separated this case
+  into its own `api-disabled` kind for list views — is lifted out of
+  `packages/plugin-list/src/ListView.tsx`'s module scope into
+  `@object-ui/react` (`classifyLoadError`, `LoadErrorKind`), so both surfaces
+  consume one classification instead of `RecordAttachmentsPanel` re-deriving it.
+  `ListView`'s own behavior is unchanged — it now imports the function it
+  previously defined locally. The classifier delegates its api-disabled check to
+  `isApiAccessDeniedError` (`@object-ui/data-objectstack`), removing a second,
+  independently-maintained copy of the same code list.
+- 41ac1b7: RecordAttachmentsPanel distinguishes a DENIED attachment list from an empty one.
+  
+  A `sys_attachment` list read refused for authorization reasons (HTTP 403 /
+  `PERMISSION_DENIED` / `FORBIDDEN` / a row-level-security denial) was swallowed
+  into the panel's empty state, so a member denied the parent record was told
+  "No attachments yet. Upload a file to get started." about a record holding
+  2095+ attachments — and was offered an Upload the server would refuse.
+  
+  The panel now classifies that refusal with the same `isPermissionError`
+  predicate the kanban, calendar and form surfaces branch on, renders a distinct
+  denied state ("You don't have access to these attachments.", new
+  `detail.attachmentsAccessDenied` key in all ten locale packs), and withdraws
+  the Upload affordance. The denied state renders the translated sentence and
+  nothing sourced from the error — no status code, no server text, no row count.
+  The empty state is now reserved for a genuine 200-with-zero-rows; non-authz
+  failures keep their pre-existing handling.
+- 1eaf0a1: RecordAttachmentsPanel distinguishes an UNLOADED attachment list from an empty one.
+  
+  A `sys_attachment` list read that failed for any non-authorization reason — a
+  network failure (server unreachable, DNS, aborted request), a 5xx, or a 401 /
+  `AUTH_REQUIRED` (an expired session is authentication, not authorization, so the
+  denied predicate deliberately does not claim it) — was swallowed into the
+  panel's empty state. All three rendered "No attachments yet. Upload a file to
+  get started.": an affirmative claim about the record's contents, made by a panel
+  that never got an answer, over a record that may hold thousands of files.
+  
+  The panel now carries the same four-way status vocabulary its siblings use —
+  `loading` / `loaded` / `denied` / `unavailable` — and every state that means
+  "the panel does not know" is answered before `rows.length === 0` is allowed to
+  mean "the record holds nothing". A failed read renders a distinct unavailable
+  state ("We couldn't load the attachments for this record.", new
+  `detail.attachmentsLoadFailed` and `detail.retryLoadAttachments` keys in all ten
+  locale packs) with a **retry** — unlike the denied state, an outage and a lapsed
+  session are both things a second attempt can fix — and withdraws the Upload
+  affordance, because offering an upload against a list the panel could not reach
+  is the same over-assertion as the empty state it replaces. Like the denied
+  state, it renders the translated sentence and nothing sourced from the error: no
+  status code, no server message, no host.
+  
+  The empty state is now reserved for a genuine 200-with-zero-rows, and the
+  denied state (403 / `PERMISSION_DENIED` / `FORBIDDEN` / a row-level-security
+  denial) is unchanged. The "table not provisioned on an older stack" case is
+  unaffected: the ObjectStack adapter degrades a bare 404 to `{ data: [], total: 0 }`,
+  so it resolves through the success path and still renders the empty state.
+  
+  This restores a house rule that had already landed twice as a bug fix —
+  `HomeActionCenter` may only say "You're all caught up" once the inbox has
+  answered, and an unloadable app list is UNKNOWN rather than "no default app".
+- 2e82ab2: The config panel footer translates: `ConfigPanelRenderer`'s Save / Discard labels come from the locale pack.
+  
+  `saveLabel` and `discardLabel` carried the English literals `'Save'` and
+  `'Discard'` as parameter defaults, and no caller in the repo passes either prop,
+  so the sticky footer that appears the moment a config draft is dirty stayed
+  English in every locale — inside panels whose every other string had already
+  been routed through `t()`. The fix is in the renderer rather than per-caller:
+  the footer is the renderer's own chrome, so a caller-side fix would translate
+  one panel's footer and leave the next host's English.
+  
+  Both labels now resolve through `createSafeTranslation` — the mechanism this
+  package already uses for its built-in copy in `form.tsx`,
+  `fullscreen-editor.tsx`, `data-table.tsx` and friends. An explicitly passed
+  `saveLabel` / `discardLabel` still wins, unchanged and untranslated.
+  
+  `common.save` is reused rather than twinned: it already ships `Save` in all ten
+  packs and is what the console's other save buttons read. `common.discard` is
+  new, because the packs carried no shared spelling of the word — the three that
+  existed are each scoped to one surface (`form.discard`,
+  `console.settingsView.discard`, `console.objectView.discard`) and the last of
+  them diverges from the other two in zh/ko/fr. Its ten values are the majority
+  spelling, byte-identical to `form.discard` and `console.settingsView.discard`.
+  
+  Both English defaults are byte-identical to the literals they replace, so a
+  host that mounts no `I18nProvider` renders exactly what it did before.
+- ef0d150: The dashboard config sidebar translates: `WidgetConfigPanel` and `DashboardConfigPanel` are wired through `t()`.
+  
+  Both panels build a `ConfigPanelSchema` — breadcrumb, section titles, field
+  labels, placeholders, help text and option labels — and neither imported a
+  translation hook at all, so all 61 of their user-visible strings were English
+  literals. Both are exported from the package barrel and mounted by
+  `DashboardWithConfig` as the dashboard editing sidebar, so a user on any
+  non-English console opened a panel that stayed English inside chrome that had
+  translated around it.
+  
+  They now resolve through a new `dashboard.config.*` namespace — 75 keys, added
+  to all ten locale packs. The namespace sits beside `dashboard.trend.*` and
+  `dashboard.filters.*`, which is where this package's other translated surfaces
+  already read from, and the panels reach it through
+  `useConfigPanelTranslation`, a `createSafeTranslation` hook whose
+  `CONFIG_PANEL_DEFAULT_TRANSLATIONS` map carries the English defaults for hosts
+  that mount no `I18nProvider`.
+  
+  The keys are authored fresh against the wording the panels actually ship rather
+  than restored from the retired `configPanel.*` block: that vocabulary had no
+  reader, was never validated against a shipped label, and covered 16 of the 61
+  strings. Where the two name the same word the translations are reused.
+  
+  Every `en` pack value and every built-in default is byte-identical to the
+  literal it replaces, so English rendering and provider-less rendering are
+  unchanged — asserted row by row, in both directions, against a frozen table of
+  the pre-change literals.
+- f34226e: Delete two dead i18n namespaces — `configPanel.*` (16 keys) and `renderer.*` (13 keys) — from all ten locale packs.
+  
+  290 translated strings (29 keys x 10 packs) with **no reader anywhere in the
+  repo**. Measured with `node scripts/check-i18n-dead-keys.mjs`, the reverse sweep
+  from objectui#4658: it subtracts the referenced key set (the AST walk that
+  `check-i18n-call-site-keys.mjs` already uses, plus plural suffixes, plus
+  `returnObjects` branches, plus every dynamic template head) from the pack key
+  set, then re-checks each survivor with a fixed-string grep over the whole repo.
+  Both namespaces scored a clean sweep — `configPanel.*` 16/16 CONFIRMED and
+  `renderer.*` 13/13 CONFIRMED, zero NEEDS-REVIEW, and a fixed-string grep for all
+  29 keys returns nothing at all outside `packages/i18n/src/locales/`.
+  
+  `configPanel.*` is a dashboard-widget config-panel vocabulary (`layout`,
+  `columns`, `gap`, `rowHeight`, `refreshInterval`, `appearance`, `theme`,
+  `general`/`advanced`, …). The two components that surface exactly that
+  vocabulary — `packages/plugin-dashboard/src/WidgetConfigPanel.tsx` and
+  `DashboardConfigPanel.tsx` — import no translation hook at all and hardcode the
+  same words in English (`title: 'Layout'`, `label: 'Columns'`, `label: 'Gap'`,
+  `label: 'Show description'`, `label: 'Theme'`). The two config panels that do
+  use i18n read other namespaces: `ViewConfigPanel.tsx` reads
+  `console.objectView.*`, `ReportConfigPanel.tsx` reads `common.*` and
+  `report.editor.*`. No component reads `configPanel.*`.
+  
+  `renderer.*` is SchemaRenderer placeholder/status vocabulary (`noPageSchema`,
+  `noFormSchema`, `noDashboardSchema`, `pageRendering`, `dashboardRendering`,
+  `formRenderingMode`, …). It is dead in the stronger sense: the English strings
+  have no hardcoded twin either — `No page schema provided`, `No form schema
+  provided`, `No dashboard schema provided`, `Page rendering`, `Dashboard
+  rendering` and `Form rendering in` each return zero hits repo-wide outside the
+  packs, and `packages/react/src/SchemaRenderer.tsx` imports no translation hook.
+  The messages themselves are gone from the product, not merely un-translated.
+  
+  No behaviour change is possible: a key with no reader cannot be read. No test
+  fixture pinned any of the 29 keys, and neither i18n baseline JSON names one, so
+  nothing else had to move.
+  
+  Part of #4730.
+- 564b605: Delete two dead i18n namespaces — `workflow.*` (58 keys) and `publicForm.demo.*` (36 keys) — from all ten locale packs.
+  
+  940 translated strings (94 keys x 10 packs) with **no reader anywhere in the
+  repo**. Measured with `node scripts/check-i18n-dead-keys.mjs`, the reverse sweep
+  from objectui#4658: it subtracts the referenced key set (the AST walk that
+  `check-i18n-call-site-keys.mjs` already uses, plus plural suffixes, plus
+  `returnObjects` branches, plus every dynamic template head) from the pack key
+  set, then re-checks each survivor with a fixed-string grep over the whole repo.
+  `workflow.*` scored 54/58 CONFIRMED with the other 4 appearing only in two i18n
+  test fixtures — mentions, not consumers; `publicForm.demo.*` scored 36/36 with
+  zero textual footprint anywhere outside the packs.
+  
+  `workflow.*` is a complete BPMN/workflow-designer vocabulary (`userTask`,
+  `serviceTask`, `parallelGateway`, `boundaryEvent`, `importBpmn`/`exportBpmn`,
+  `undo`/`redo`, …). Its one plausible consumer,
+  `packages/plugin-designer/src/ProcessDesigner.tsx`, hardcodes English
+  (`{ label: 'User Task', value: 'user-task' }`) and imports no translation hook
+  at all, while six sibling components in the same package do use one — the
+  vocabulary was never wired up. `publicForm.demo.*` is demo content (contact and
+  support form titles, field labels, industry/issue-type/priority options) for a
+  public-form showcase page that does not exist in this repo.
+  
+  No behaviour changes: a key with no reader cannot be read. The `publicForm.*`
+  parent namespace and every other namespace are untouched.
+- a1609a6: Console list filters: a `between` range is submitted only when both bounds are filled, and six operator labels stop rendering as raw i18n keys.
+  
+  Two defects in the list-view filter panel (objectstack#8815), both in the Console
+  render layer, with no workaround available downstream.
+  
+  **A half-filled range no longer refuses the whole view.** Picking a date column
+  and 「介于」 draws two inputs — that part landed in objectui#3958 — but typing
+  only one bound produced `["2024-01-01", ""]`, and both write paths read "is this
+  row filled in?" with one shape-blind predicate (`null` / `''` / empty array).
+  An array of length 2 passed it, so the empty bound went to the server, which
+  refuses the query outright (`400 INVALID_FILTER`): the list showed
+  「该视图的查询被拒绝」 and the filters the user had already applied stopped
+  applying too. The saved-view fold persisted the same half-range, so the refusal
+  came back on every later read of that view, for every user of it.
+  
+  The spec cannot intercept this — `ViewFilterRuleSchema` accepts
+  `["2024-01-01", ""]` because it counts the two slots rather than what is in
+  them, while refusing a scalar or a one-element array. Authoring validation is
+  therefore green on exactly the shape that fails at query time, which makes not
+  emitting it the producer's job. `@object-ui/components` now exports
+  `isFilterValueComplete(operator, value)` — arity-aware, so a `pair` row needs
+  both bounds — and the two consumers that had each kept a copy of the old
+  predicate (`plugin-list`'s `convertFilterGroupToAST`, `app-shell`'s
+  `foldFilterGroupToSpecRules`) read it instead. A half-filled range is now
+  dropped exactly as a half-typed `equals` row already was: no filter, rather than
+  a filter the server will reject. Bounds of `0` and `false` stay real bounds.
+  
+  **Six operator labels are translated in all ten locale packs.**
+  `startsWith`, `endsWith`, `isNull`, `isNotNull`, `exists` and `notExists` were
+  missing from every pack, so i18next resolved them to the raw key and the dropdown
+  showed `filterBuilder.operators.isNull` beside translated entries. The
+  component's own defaults table could not cover it: that table serves only the
+  no-provider path, and the Console mounts a provider. The report named four —
+  a `date` column's bucket offers the four nullness operators; a `text` column
+  showed all six.
+  
+  Because the label key is built dynamically (`t(\`filterBuilder.operators.${op}\`)`),
+  no existing gate could see the gap: the call-site checker classifies a template
+  key as `missing-prefix` and only asks whether the prefix resolves, and
+  cross-pack parity is satisfied when all ten packs are missing a key together.
+  A new parity test pins the packs against `FILTER_BUILDER_OPERATORS` in both
+  directions, so an operator added to the dropdown now fails loudly until every
+  pack labels it.
+- 37f6844: FilterConditionField can author the spec's `$icontains` — case-insensitive contains is reachable from the filter UI.
+  
+  `@objectstack/spec`'s `FieldOperatorsSchema` gained `$icontains` between
+  `17.0.0-rc.2` and `rc.5`, and every driver and evaluation face the platform
+  ships now executes it. `FilterConditionField` had no builder operator that could
+  author it, so the capability was unreachable from the sharing-rule criteria
+  builder and sat in that widget's parity test as an explicit `KNOWN_UNREACHABLE`
+  entry.
+  
+  The FilterBuilder gains a `containsCaseInsensitive` operator ("Contains (ignore
+  case)", translated in all ten locale packs). `condToMongo` emits
+  `{ field: { $icontains: value } }` and `kvToCondition` reads it back, so a saved
+  criteria reopens in the visual builder instead of falling into the raw-JSON
+  editor. Today's `contains` is unchanged and still emits the case-SENSITIVE
+  `$contains`; whether it should have been case-insensitive all along is a product
+  question that stays open, and stored filter views keep meaning what they meant.
+  
+  The fold is ASCII-only by contract — `café` does not match `CAFÉ`.
+  
+  The new operator is **opt-in per consumer**: `FilterBuilder` takes an
+  `extraOperators` prop, and only `FilterConditionField` passes it. The one
+  dropdown feeds three at-rest dialects and only the MongoDB-style criteria this
+  widget writes can carry the operator — the spec's `VIEW_FILTER_OPERATORS` (saved
+  views) and `VALID_AST_OPERATORS` (the live grid's filter AST) have no
+  case-insensitive contains, so offering it there would author a filter those
+  paths cannot execute. Every other FilterBuilder is unchanged.
+- 2b50261: `FilterBuilder` gives the set and range operators an input that matches the value shape the spec accepts, and stops minting the shape it refuses.
+  
+  Three independent paths let one filter row end up with `operator: 'in'` and a
+  SCALAR `value` — the shape `ViewFilterRuleSchema` refuses at save time since
+  objectstack#6227, and the shape the query path answered `400 INVALID_FILTER` on
+  before that (objectstack#5869):
+  
+  - Changing the operator dropdown wrote `{ operator }` alone, so the seed `''`
+    (or whatever the previous family had produced) survived the switch into
+    `in` / `not_in` / `between`. The operator and the shape of its value are one
+    edit, so they are now made together: switching families re-shapes the value —
+    a typed scalar becomes a one-element list, an empty one becomes `[]`, a range
+    keeps its first bound and leaves the second open, and a list collapsing to a
+    scalar keeps its first entry.
+  - A plain text or number column has no static `options`, so `in` fell through to
+    the single-value input and the user could only ever type a scalar into it.
+    Those columns now get a token input (type, Enter or comma commits, `×` or
+    Backspace removes) that always emits an array; `between` gets its two bounds
+    instead of one box. The lookup picker's no-DataSource fallback, which also
+    handed back a scalar while `multiple`, emits a list too.
+  - The multi-value families were decided from a local `["in", "notIn"]` literal,
+    already one spelling adrift: `notIn` is an alias and the canonical member is
+    `not_in`, so a stored view read back in canonical form got the single-value
+    input for a set operator. The families are now read from `@objectstack/spec`'s
+    exported `VIEW_FILTER_LIST_VALUE_OPERATORS` / `VIEW_FILTER_PAIR_VALUE_OPERATORS`
+    and folded through `normalizeFilterOperator`, so both spellings of one operator
+    get one answer and a family the spec widens is picked up without an edit here.
+  
+  `foldFilterGroupToSpecRules` is unchanged and needed no change: it normalizes the
+  operator and carries `value` through verbatim, so the shape that reaches storage
+  is the producer's to get right. An untouched `in` row arrives as `[]`, which the
+  fold's existing incomplete-row rule already drops.
+  
+  Four locale keys are added to all ten packs for the new inputs
+  (`filterBuilder.addValue` / `.removeValue` / `.rangeStart` / `.rangeEnd`).
+- af5e292: Emit explicit file extensions on relative import specifiers, so the published
+  entries can be imported by Node's own ESM resolver.
+  
+  `@object-ui/react`'s built entry re-exported through extensionless relative
+  specifiers (`export * from './SchemaRenderer'`). Node does not extension-search
+  relative specifiers, so `import('@object-ui/react')` under plain Node — an SSR
+  host, or any consumer without a bundler — failed with `ERR_MODULE_NOT_FOUND`.
+  Bundled consumers were never affected and are unchanged by this.
+  
+  `@object-ui/types`, `@object-ui/core` and `@object-ui/i18n` carried the same
+  emission; `@object-ui/react`'s entry stayed unloadable until they were fixed
+  too, because evaluation crosses into them. No exported API changed.
+- bea374e: A KPI card's sub-caption now translates from its own convention key
+  
+  objectui#4032 item 4. The metric card renders two authored strings, and they
+  are two different authored fields:
+  
+  | authored field        | rendered as             | bundle key                                |
+  |-----------------------|-------------------------|-------------------------------------------|
+  | `widget.description`  | the shared card header  | `dashboards.<d>.widgets.<id>.description` |
+  | `options.description` | the KPI sub-caption     | `dashboards.<d>.widgets.<id>.subCaption`  |
+  
+  Only the first resolved. The metric dispatch spread `...options` straight
+  through, so the sub-caption reached `MetricWidget` as the raw authored English
+  and a `zh` dashboard showed a translated header above an untranslated caption.
+  
+  They get two keys, not one — the objectstack#5428 item-4 ruling (2026-08-06):
+  "两个作者字段两个 key". That is why PR #4358 landed items 1-3 and deliberately
+  stopped here: at the time `@objectstack/spec` accepted no segment for the
+  sub-caption and the only key it would take was `description`, the shared key the
+  ruling forbids. objectstack#8056 added `subCaption` to the widget translation
+  node, and it ships in `@objectstack/spec@17.0.0` — the version this repo pins.
+  
+  The server half already existed: `translateDashboard` overlays `subCaption` onto
+  `options.description` on the `/meta` path, so a served document was already
+  correct. This is the client half — the same key path, for the app bundles
+  objectui loads into `I18nProvider` itself.
+  
+  - `@object-ui/i18n` gains `widgetSubCaption(dashboardName, widgetId, fallback?)`,
+    mirroring `widgetDescription` limb for limb rather than re-implementing
+    namespace discovery inside the plugin.
+  - `DashboardRenderer`'s `tWidgetSubCaption` composes the two channels in the
+    order `tWidgetTitle` already fixed — the authored value is collapsed to the
+    active language first (an inline per-locale map, the `pickLocalized` seam),
+    and the plain string that falls out is offered to the bundle as its fallback —
+    so a bundle entry always wins over an inline map, and neither channel is
+    replaced by the other. The resolved value is assigned after the `...options`
+    spread in both the `object-metric` and static-value branches.
+  
+  The separation is pinned in both directions, because a shared key is exactly
+  what a later tidy-up would reach for: the `description` key never reaches
+  `options.description`, and `subCaption` never reaches `widget.description`. On a
+  `kpi` / `gauge` / `bullet` widget both are on screen at once, so one shared key
+  would make a single translation entry overwrite the other field's text.
+  
+  Untranslated dashboards are unchanged: with no bundle entry the resolver hands
+  back exactly what the spread would have, and with nothing authored and nothing
+  translated it answers `undefined` rather than `''`, so a card that has no
+  sub-caption grows no caption row.
+- d109a4d: The `organizations.*` picker locale family (avatar menu / console picker —
+  `mine`, `title`, `heading`, `subtitle`, `searchPlaceholder`, `new`, `current`,
+  `emptyTitle`, `emptyDescription`, `noMatches`) is now internally consistent in
+  all eight non-en/zh packs (`ar`, `de`, `es`, `fr`, `ja`, `ko`, `pt`, `ru`).
+  
+  `en` and `zh` were renamed from "organization" to "workspace" terminology in
+  full; the other eight packs only had `create` follow, leaving each pack mixing
+  both nouns in one dropdown (e.g. `de.ts` read `create: "Workspace erstellen"`
+  directly beside `mine: "Meine Organisationen"`). Since PR #4638 restored the
+  avatar menu's "My Workspaces" entry, both lines render two apart in the same
+  menu. Each pack now uses the workspace term its own `create` key already
+  committed to (`Arbeitsbereich`-style German phrasing → `Workspace`, French
+  `espace de travail`, Japanese `ワークスペース`, Korean `워크스페이스`, Spanish/
+  Portuguese `espacio de trabajo` / `workspace`, Russian `рабочее пространство`,
+  Arabic `مساحة عمل`), with grammatical agreement (gender, definiteness,
+  particles) adjusted per key.
+  
+  The sibling `organization.*` (singular) namespace — organization
+  **management**, a deliberately distinct surface per the comment separating the
+  two blocks in `en.ts` — is untouched in every pack.
+- ad13d63: Removed five locale keys that had no call site in any package, app, example,
+  or e2e test: `console.objectView.striped`, `console.objectView.bordered`,
+  `console.objectView.virtualScroll`, `appDesigner.stripedRows`, and
+  `appDesigner.bordered`. Deleted from all ten packs (`en` plus the nine
+  translations) to keep `all-locales-key-parity.test.ts` green.
+  
+  The `console.objectView.*` three describe grid options ObjectStack retired
+  upstream (objectstack#7176, 2026-08-10) and objectui stopped forwarding
+  (objectui#4649); the `appDesigner.*` pair is textually identical in name only
+  and was independently dead — no `AppCreationWizard.tsx` control, no fallback
+  entry in `useDesignerTranslation.ts`'s `DESIGNER_DEFAULT_TRANSLATIONS`, and no
+  mention anywhere in the repo outside the locale packs themselves.
+  
+  No runtime behavior changes: nothing rendered these labels before this patch.
+- a9e17b4: `auth.forgotPassword.successDescription`'s address hole is now spelled with
+  single braces (`{email}`) instead of i18next's double braces (`{{email}}`),
+  in all ten locale packs.
+  
+  This is a spelling-only change — rendered output is byte-identical in every
+  language, because the hole was never filled by i18next in the first place:
+  `ForgotPasswordForm` substitutes the address itself once the user submits
+  the form (the label renders before the address exists, so `t()` cannot do
+  it). `{{email}}` and a genuinely unfilled i18next hole were indistinguishable
+  at the call site, and passing `email` as an interpolation argument — the
+  natural "fix" for what looks like a missing argument — would let i18next
+  consume the hole and cause the address to be appended a second time
+  (objectui#4135).
+  
+  Converging on `{x}` for every hole a component fills downstream of `t()`
+  (the convention `resendOtpCountdownText`'s `{seconds}` already used) puts
+  this hole outside i18next's `{{…}}` syntax entirely, so the ambiguity is
+  gone by construction rather than fenced by an exemption. Accordingly,
+  `scripts/check-i18n-call-site-keys.mjs`'s `EXTERNALLY_INTERPOLATED_HOLES`
+  registry entry for this key is retired — the gate needs no exemption for a
+  hole i18next was never going to touch.
+  
+  `ForgotPasswordForm.tsx`'s replacement marker and its own built-in default
+  label move to the same spelling in the same change, as does the inline
+  `defaultValue` at `apps/console/src/pages/auth/ForgotPasswordPage.tsx`'s
+  call site.
+- 8871c14: Gate Home's metadata-authoring CTAs on the `manage_metadata` capability the
+  server reports, with a visible localized reason.
+  
+  "Build an app" and "Start with a template" were gated on `useIsWorkspaceAdmin()`
+  — a ROLE check. On a multi-tenant deployment that deliberately withholds
+  metadata authoring from tenants, a workspace owner is an admin by role yet holds
+  no `manage_metadata`, so the most prominent CTA on their home page led into
+  `/studio`, a filled-in new-package dialog, and a capability refusal at submit.
+  
+  Both cover cards are now disabled, with the reason shown on screen and in the
+  tooltip, whenever the session lacks the capability. The marketplace shortcut in
+  the apps strip is withheld with them (it targets the same route, so leaving it
+  live would have made the gate cosmetic), as is the "Build with AI" hero CTA
+  (its output is draft metadata that cannot be published without the capability).
+  On a workspace with no apps yet, the admin empty state explains the posture
+  instead of directing the owner to build their first application.
+  
+  The gate consumes the answer `GET /api/v1/auth/me/permissions` already returns,
+  surfaced through the permissions provider — no permission logic is re-derived in
+  the client. Unknown capabilities fail OPEN: a backend that reports no
+  `systemPermissions` at all is indistinguishable from one reporting an empty set,
+  and the server enforces regardless, so nothing is withheld on missing client
+  data. New key `home.build.noCapability` in all ten locale packs.
+- 21e4585: A write-warning toast now words each strip reason on its own instead of calling everything that is not `readonly_when` "read-only".
+  
+  `emitWriteWarning` picked its sentence with a two-way conditional on
+  `reason === 'readonly_when'`. The other arm was never "readonly" — it was
+  "everything that is not `readonly_when`", so any reason the server-side write
+  path gained afterwards was announced to the user as a read-only lock, pointing
+  them at a permission problem that does not exist. That is the same defect
+  objectui#3484 / framework#3794 fixed for `readonly_when` itself, one reason
+  later.
+  
+  The reason is now resolved through a table declared
+  `Record<DroppedFieldsEvent['reason'], …>`, mirroring the framework side of the
+  same seam (`service-automation`'s `DROPPED_REASON_LABEL`) and the shape the
+  spec's own `DroppedFieldsEventSchema` comment asks consumers for. The next reason
+  added upstream is a `type-check` failure here, unworded, where the conditional
+  compiled forever — which is what re-exporting THE spec type rather than a
+  hand-widened `string` was for all along.
+  
+  Not a latent fix: the pinned spec (`@objectstack/spec` 17.0.0-rc.6) already
+  carries `primary_key` (objectstack#6437), the strip that keeps a payload `id` the
+  update dispatch ruled is not an identifier out of the targeted rows' primary key.
+  Until now a user who triggered it was told the field was read-only. It gets its
+  own wording in all ten locale packs: "The record's identifier cannot be changed
+  by a save, so it did not take effect".
+  
+  One more line was added for a reason ahead of this bundle's pin — the adapter
+  reads `reason` structurally off the wire without checking it against the enum, so
+  a server newer than the bundle can deliver a value no table can have an arm for.
+  It names the fields and claims nothing about the cause, rather than throwing
+  inside a listener invoked as `void emitWriteWarning(...)` (which would cost the
+  user the whole toast, including the reasons that did resolve) or reusing a
+  wording that would state a cause we do not know.
+- Updated dependencies [2533ec5]
+- Updated dependencies [bbe8b86]
+- Updated dependencies [8477be5]
+- Updated dependencies [279fb13]
+- Updated dependencies [ad07b65]
+- Updated dependencies [41f498b]
+- Updated dependencies [e1d4251]
+- Updated dependencies [ac600e5]
+- Updated dependencies [c1ef923]
+- Updated dependencies [af5e292]
+- Updated dependencies [167ec42]
+- Updated dependencies [b1119ec]
+- Updated dependencies [9f23d2b]
+- Updated dependencies [af025ee]
+- Updated dependencies [31676be]
+- Updated dependencies [9ce096f]
+- Updated dependencies [e05db88]
+- Updated dependencies [5ffcc14]
+- Updated dependencies [d971e51]
+- Updated dependencies [d2ce342]
+- Updated dependencies [dfc6975]
+  - @object-ui/core@17.6.0
+
+## 17.5.0
+
+### Minor Changes
+
+- 0e67b53: `/accept-invitation/:invitationId` is one route, one component, one namespace — the console now renders the invitation page that actually shows you the invitation
+
+  Two components shipped for this single URL. The console routed its own thin page, which offered nothing but an Accept and a Decline button: it never told the user which organization they had been invited to, in what role, or when the link expires, and accepting left them in whatever organization they were already in. App-shell's page — exported as `DefaultAcceptInvitationPage`, routed by nobody — fetches the invitation, shows the organization, the role and the expiry date, and switches the user into that organization on accept. Console now routes that one. The thin page is deleted.
+
+  Behind them sat two i18n namespaces for one screen: `acceptInvitation.*` (12 keys) for the thin page and `organization.accept.*` (14) for the richer one, both freshly translated into ten languages by different slices of objectui#3546, neither wrong when read on its own. That is 26 keys of duplicated copy with no gate to tell the next author which of the two to edit — the failure mode this repo already has an uncollected precedent for. `acceptInvitation.*` is removed from all ten packs, and its absence is pinned negatively so it cannot drift back: the slice-three test now asserts that no pack defines any of the 12 retired keys (nor an emptied namespace root left by a partial revert), and that neither consuming package asks `t()` for one.
+
+  One behavior needed repairing before the swap was safe rather than after. `?redirect=` is a basename-stripped path by contract in this console — `LoginPage` re-prefixes it with the mount before navigating — and the thin page built it from the route param, correctly. App-shell's page built it from `window.location.pathname`, which already carries the mount, so a console served under a `<base href="/console/">` would have sent the user back to `/console/console/accept-invitation/…` after signing in. It now reads the router (`useLocation`), like every other producer of that parameter in this repo. Under the default `/` mount the two spellings are identical, which is why only a basename case can see the difference; that case is now a test.
+
+  Nothing published was removed: `DefaultAcceptInvitationPage` keeps its export and simply becomes the routed implementation. Downstream apps mounting it get the redirect fix and are otherwise untouched.
+
+- ae10a01: Console chrome reaches the bundle — the list switcher, the aggregate footer, the dialog a11y fallbacks and the whole Settings namespace screen stop being English on non-English consoles
+
+  Six strings on the two screens a user looks at most were hardcoded English literals rather than bundle lookups, so they stayed English on every non-English console with nothing an app could author to change them. They are not object, field, view or action labels — no key in `TranslationData` reaches them — while the console's own bundle already ships zh-CN, ja-JP, es-ES, de, fr, pt, ru, ko and ar and translates hundreds of neighbouring strings. Omissions from an otherwise complete bundle, not a missing capability.
+
+  **Two of the six needed no new keys at all, which is the more interesting half.** The list-view mode switcher named its nine visualizations from a private `VIEW_LABELS` table while `console.objectView.viewType*` — the same nine words — had been resolved through the bundle by the create-view picker for months; the switcher now reads those keys, so the picker's 「画廊」 and the switcher's 「画廊」 cannot drift apart in nine languages. The create/edit dialog's close button is the remainder of a fix that already landed: objectstack#5505 routed the `sr-only` close label through `common.close` for the two Shadcn-synced primitives, but `MobileDialogContent` is a hand-written wrapper outside that regeneration zone with its own close button, and it is exactly what `ModalForm` renders — so the dialog the report measured was the one place still announcing "Close" in English.
+
+  The aggregate footer is the one the original report singled out: the **number** was already locale-formatted and the **prefix** was a hardcoded `Avg: ` / `Sum: `. All eleven aggregation kinds now take their prefix from `grid.summary.*`, and the label/value join is its own key rather than a `': '` baked into the renderer — the separator is translatable content, so zh sets a fullwidth colon and fr the French space-before-colon. The numbers are untouched. The form dialog's `sr-only` description fallback joins the packs too; it is clipped, not visible, so the only way an app could displace it was to author a `description` and thereby put a visible subtitle on every dialog.
+
+  **The Settings namespace screen converts as one unit.** `SettingsView` routed zero framing copy through i18n — save/failure toasts, the env-lock and crypto refusals, the load-error card, the empty-route state, the navigation buttons, the unsaved-changes save bar — while its immediate sibling `SettingsHub`, in the same directory, resolved everything through `t('console.settingsHub.*')`. A zh-CN admin read correctly translated field labels sitting inside an English save bar, because `useSettingsLabel` translates a namespace's authored content but reaches none of the chrome around it. All of it now resolves through a `console.settingsView.*` namespace placed beside the hub's, including the crypto-refusal strings that objectui#4579 deliberately left in English rather than leave one translated string among a dozen literals.
+
+  The save-bar counter was an English plural rule executing in every locale (`change` plus an `s` when the count exceeds one). It is now a real i18next plural family — base key plus `_one` and `_other` in all ten packs — not the `(s)` spelling translated nine ways. The base key is the load-bearing part: i18next asks `Intl.PluralRules` for the one suffix a language needs and, finding no such slot, falls back to English, so without it Russian would read English at counts 2-20 and Arabic at 2-99. Russian and Arabic take the "noun: {count}" form their packs already use for this exact reason, and the counter is verified rendering in-language at 1, 2 and 5.
+
+  The Beta badge reuses the hub's existing key rather than minting a twin, and the refusal messages interpolate their subject through the bundle instead of concatenating a translated word onto an English prefix.
+
+- 66fb4fa: The console's language menu now asks the app which locales it actually ships, instead of always offering the same ten.
+
+  `LocaleSwitcher` built its items from a module-level `LANGUAGES` constant — exactly the ten codes `@object-ui/i18n` ships packs for — and never consulted the app, even though `GET /api/v1/i18n/locales` has been serving that list all along. It failed in both directions at once. An app shipping a locale outside those ten (`th`, a regional `pt-BR`) had no way to be selected from the console: the bundle could be complete and lint clean, and the menu simply had no entry for it. An app shipping only `en` and `zh` still listed all ten, so picking 日本語 handed the user the console's own chrome in Japanese with everything app-authored in the fallback language — a half-translated UI its author never opted into.
+
+  The menu is now the **intersection**: the app's own locale list ∩ what the renderer can actually resolve (built-in packs, `config.resources`, and — for an app that wires a dynamic `loadLanguage` loader, which is how the console gets its packs — the locales that loader can fetch). Both failure directions close in the same change: an app-shipped locale becomes offerable, and locales the app does not ship disappear. The endpoint is reached through a new `loadLocales` prop on `I18nProvider`, wired exactly like the existing `loadLanguage`: the app owns the transport, the provider owns what is done with the answer. An app that does not wire it keeps today's menu unchanged.
+
+  **The restore validation widened in lockstep, because otherwise this fix would have minted the next bug.** A restored language was validated against "the locales this provider can produce" — built-in packs plus `config.resources` — a bound that was correct only for as long as the menu offered exactly the built-in ten. The moment the menu grows to the app's real list, a locale the user can now pick is a locale that bound rejects, so a user-picked app locale would have been purged on the next page load. It now also accepts a locale a wired dynamic loader may be able to fetch, and the bound stays honest rather than absent: only well-formed BCP-47 tags qualify (`constructor`, `__proto__`, `en_US` are still rejected, as is any stored locale in an app with no loader), and the app's own locale list adjudicates the choice for real once it arrives — a locale the app has since dropped is reverted and purged rather than left locking the UI to a language with no translations.
+
+  Labels come from the built-in native names where they exist (`中文`, `日本語`, … are unchanged) and from `Intl.DisplayNames` for everything else, so an app locale is named in its own language rather than by its code. The endpoint's own `label` is deliberately not used for display: the server sets it to the code echoed back, which would have put `th` in the menu where `ไทย` belongs.
+
+  While the app's list is in flight the switcher renders nothing, following the sibling menus in the same folder — the ten never flash past on an app that only ships two. When there is no backend, the endpoint fails, or the app answers with nothing this renderer can produce, the built-in ten remain as the offline fallback, so the menu is never empty and never unusable.
+
+- 92250d6: One home for the number-display policy — and a percent stops meaning two different things between a list cell and a dashboard measure
+
+  `formatDisplayNumber`, `shouldGroupDisplayNumber` and `DisplayNumberFormatOptions` move from `@object-ui/i18n` into `@object-ui/core`. `@object-ui/i18n` re-exports all three under the same names, so every existing import path keeps working unchanged and both spellings resolve to the same function object; nothing published was removed.
+
+  The move is what fixes the bug. `@object-ui/core`'s `formatMeasure` needed exactly this policy and could not import it — `core` is the React-free engine and is a runtime dependency of React-free consumers (the `object-ui` VS Code extension, `@object-ui/data-objectstack`), while `i18n` depends on `i18next`/`react-i18next` and peer-depends on React. So `formatMeasure` carried a parallel `Intl` implementation, recorded at both ends as deliberate duplication, and the two drifted in the one place a hand-built string and `Intl` disagree. A German session read `1.234,5 %` from a list cell and `1.234,5%` from a dashboard measure showing the same number. The function is pure, so the boundary was never a property of the code — only of where the code sat; moving it down removes the obstacle instead of working around it. `core` imports nothing from `i18n`, so the new edge adds no cycle.
+
+  **Behaviour change — a measure's percent sign now follows the locale.** `formatMeasure` appended a literal `%` in every locale; it now renders the locale's own percent convention, the same one the list-cell `formatPercent` has used since the fix to its own machine-locale defect. Measured to change output in de, fr, es, ru, sv, cs, fi (a no-break space appears before the sign), tr (the sign moves to the FRONT: `%1.234,5`) and ar (its own percent sign plus U+061C). English, Japanese and Chinese are byte-identical — their convention is a bare trailing sign — which is why this was invisible in an English session.
+
+  **No numeral moves, in any locale, at any magnitude.** The obvious route to the locale's convention is `Intl`'s `style: 'percent'`, but that style expects a fraction, so a value already in percentage points would have to be divided by 100 for `Intl` to multiply it straight back — and that round trip is lossy. Measured, it moves 27,581 of 1,200,013 ordinary-magnitude en-US forms at rounding ties (`0.175` at two decimals becomes `0.17%` instead of `0.18%`), plus `MAX_SAFE_INTEGER` and everything from 1e23 up, where `100,000,000,000,000,000,000,000%` becomes `99,999,999,999,999,990,000,000%`. The percentage points are formatted directly instead, through a new `style: 'percentPoints'` on `DisplayNumberFormatOptions`; that route was measured to produce a byte-identical percent affix to `style: 'percent'` across all 171 locale tags tested while moving none of those 1,200,013 forms. Callers holding a fraction keep using `style: 'percent'`, whose behaviour is unchanged — naming the two cases apart is what stops the next caller from reaching for the lossy one.
+
+  `@object-ui/i18n`'s entry declaration is byte-identical, but the declaration it points at now lives in `@object-ui/core` and the package gains that dependency, so it takes the same minor bump rather than a patch.
+
+- ac853ce: i18n: retire the reader-less `common.search` key from all ten locale packs
+
+  `common.search` (`Search`, no ellipsis) had exactly one consumer: `LookupField`
+  built its dialog placeholder by concatenating the key with three ASCII full
+  stops. objectui#4375 / PR #4391 retired that concatenation — the placeholder is
+  the reused `table.search` pack value (`Search…`, one U+2026 glyph), which is what
+  brought it under objectui#3878's glyph pin. That left `common.search` with zero
+  readers repo-wide while it still existed in all ten packs.
+
+  Re-verified before deleting, repo-wide: no `t()` call site in any package or app,
+  no MDX or JSON reference, and the one dynamic template-literal reader of the
+  `common` namespace takes a two-member union parameter (`'openChat' |
+'closeChat'`) that cannot resolve to it. No user-visible string changes — this key never rendered.
+
+  The dormant copy in `@object-ui/fields`' no-provider fallback table
+  (`useFieldTranslation.ts`'s `FIELD_DEFAULTS`) goes with it. That table is a
+  module-local `Record<string, string>` read only when no `LocalizationProvider`
+  is mounted; it is not exported, so removing an entry no reader asks for changes
+  no rendered output and narrows no public type. Hence patch for that package,
+  while the pack change is a minor: deleting a key from `en` narrows the exported
+  `TranslationKeys` type (`typeof en`), so code indexing `TranslationKeys` at
+  `common.search` stops type-checking. Same grading, for the same reason, as
+  objectui#4145's `report.editor.*` retirement. No runtime consumer existed to
+  break.
+
+  Retiring a key from `common` was the ruled decision on objectui#4392 rather than
+  keeping it as vocabulary: nothing pins a dormant key's meaning, so its next
+  reader inherits an unreviewed contract, and a dormant key beside a live
+  `table.search` is where a second dialect gets started. The objectui#4328
+  dead-surface family has consistently chosen removal for zero-consumer surfaces.
+
+  The neighbouring `common.select` (minted one commit earlier by objectui#4386 /
+  PR #4397) is a different key and is untouched.
+
+  A negative pin (`packages/i18n/src/__tests__/common-search-retired-4392.test.ts`)
+  fails if the key returns to any pack, if any package reads or re-declares it, or
+  if a dynamic `common.*` reader grows a `search` member — every existing i18n gate
+  runs call site to key, and none of them can see a key with no call site.
+
+- fa51109: i18n: retire the orphaned `report.editor.*` namespace — 105 of its 106 keys, in all ten locale packs (~1050 translated strings)
+
+  The namespace labelled the hand-rolled report editor form. That form no longer
+  exists: `ReportConfigPanel`'s body is `ReportDefaultInspector`, a spec-driven
+  inspector whose labels come from the report spec's own metadata rather than from
+  a pack namespace. Until objectui#4137 the namespace had exactly one live reader,
+  and it was the objectui#4118 defect itself — the panel borrowing
+  `report.editor.title` (the label of the report's Title _field_) to name itself.
+  Moving that slot onto a purpose-built `report.editor.panelTitle` left the other
+  105 keys with no reader anywhere.
+
+  Re-verified before deleting, repo-wide and per key: no `t()` call site, no
+  dynamic `t()` template form, and no JSON or MDX reference reads any of the 105.
+  No user-visible string changes — these keys never rendered.
+
+  `report.editor.panelTitle` survives in all ten packs and is untouched; the
+  deletion sweeps around it. `report.editor` therefore remains a live namespace
+  holding exactly that one key.
+
+  This narrows the exported `TranslationKeys` type (`typeof en`), which is why it
+  is a minor rather than a patch: code indexing `TranslationKeys` at a retired key
+  stops type-checking. No runtime consumer existed to break.
+
+  A negative pin (`packages/i18n/src/__tests__/report-editor-retired-4145.test.ts`)
+  names all 105 retired keys and fails if any returns to any pack, since every
+  existing i18n gate runs call site to key and none of them can see a key with no
+  call site.
+
+- 78fa331: console: seed the UI language from the tenant's server-side locale
+
+  `GET /auth/me/localization` has always been fetched on every boot, but its
+  `locale` only ever fed currency/date formatting — the UI language was decided
+  entirely client-side, so a tenant configured `zh-CN` still handed every new
+  device an English console until each user switched by hand.
+
+  The tenant locale now sits in the language precedence chain, between the user's
+  own choice and the browser's:
+
+  1. the user's explicit choice (`objectui-locale`)
+  2. the tenant's server locale, cached at `objectui-locale-seed`
+  3. the browser language
+  4. `en`
+
+  The server value is cached in a slot of its own and is never written into the
+  explicit-choice slot, so it can never masquerade as a preference the user
+  expressed: only a manual switch promotes a language to an explicit choice. A
+  cached seed applies synchronously at bootstrap, and the in-app fetch refreshes
+  that cache from every successful answer, so a tenant that changes its locale
+  reaches choice-less devices on their next boot without an old seed pinning
+  them. On a device's true first visit the fetch is raced against a ~500ms
+  timeout alongside the console's existing pre-mount round-trips and fails open
+  to the browser language; a seed that arrives after the bound is cached for the
+  next boot rather than re-languaging a live session. A tenant locale this build
+  ships no pack for falls through to the next tier instead of half-rendering.
+
+  No platform additions: no new endpoint, no client read/write API, and
+  `sys_user_preference` is untouched.
+
+- 0082db8: The timeline's gantt bucket labels and its row-label default speak the session language
+
+  objectui#4513 routed every `Intl` call in the timeline renderer through `useDisplayLocale()`, so a Chinese session renders `2026年8月` on the month axis and `2026年8月11日` on item dates. Three sibling strings in the same renderer never went through `Intl` at all and stayed English on that same Chinese axis: the `week` header (`Week 1`), the `quarter` header (`Q3 2026`), and the gantt row-label column default (`Items`). The half-fixed state was the visible one — a Chinese date axis with English bucket labels beside it.
+
+  They are a translation concern rather than a locale-resolver one, and that distinction is the fix: a locale TAG formats a date, only a TRANSLATION spells a word. All three now resolve through the package's existing channel — `useTimelineTranslation` / `TIMELINE_DEFAULT_TRANSLATIONS`, the `createSafeTranslation` factory `ObjectTimeline` already uses for `timeline.bucket.*` — under three new keys carried by all ten locale packs: `timeline.scale.week`, `timeline.scale.quarter`, `timeline.gantt.rowLabel`.
+
+  The week number and the quarter/year ride the channel's own `{{hole}}` parameters rather than being concatenated, because the word order belongs to the translation: Chinese puts the year first (`2026年第3季度`), which no `Q${q} ${year}` template can produce at all. Only the row-label DEFAULT moved — an author who writes `rowLabel` still supplies their own string, and the `year` scale stays a bare `String(getFullYear())` with no vocabulary in it to translate.
+
+  English output is byte-identical to the retired literals: the `en` pack values are the same two templates the code used to interpolate by hand. `generateTimeScaleHeaders` is a pure exported function and cannot host a hook, so the translate fn is threaded in as an optional fifth parameter on the seam #4513 opened for `locale`, defaulting to the package's own defaults table — the same lookup the channel serves with no `I18nProvider` mounted. Existing three- and four-argument call sites are unaffected.
+
+  One consequence is worth stating because it looks like a bug and is not: dates and vocabulary resolve through different channels on purpose. `useDisplayLocale()` puts the tenant's regional default first (how this organization writes dates), while `t` follows the UI language (what this user reads). A tenant configured `en` whose user reads Chinese chrome therefore sees `Aug 2026` beside `第 1 周` — the same split `timeline.bucket.*` has always had.
+
+### Patch Changes
+
+- 932cbcd: An app you are not allowed to open now says so, instead of reporting that it may still be publishing
+
+  `GET /api/v1/meta/apps` is filtered per session server-side (`filterAppForUser`), so an app withheld by its `requiredPermissions` and an app that does not exist were byte-identical to the console: both simply absent from the list. With one fact and two conditions, `AppContent` rendered its only copy for an absent app — "This app is not available yet — it may still be publishing. Try again in a moment." — over a permanent authorization decision, under a Retry button that could never succeed.
+
+  That is not a cosmetic complaint. On a downstream acceptance round one role hit this screen while another opened the same app fine, and because the copy names a transient deployment state the finding was filed as a suspected platform defect and carried through two test batches before a clean-baseline investigation found the account was missing a permission-set binding. The gate had been working exactly as designed; the message is what sent everyone to the wrong place.
+
+  The maintainer ruling (2026-08-12) took the contract half first. objectstack#8013 made the BY-NAME route answer an explicit denial — `403` with the ADR-0112 catalog code `PERMISSION_DENIED` in the declared `{ success: false, error: { code, message } }` envelope — for an app that exists and whose `requiredPermissions` the session lacks, while the LIST route stays filtered exactly as before, with no `authorized: false` flag, so the enumeration surface is not widened past what a direct by-name probe already implies. Absence keeps answering `404 RESOURCE_NOT_FOUND`, and so do the two neighbouring refusals the same ruling deliberately left alone: an unpublished app (ADR-0045 §3 keeps it externally unobservable) and an app gated by an absent optional service (ADR-0057 D10 — nothing was denied to the caller).
+
+  This is the console half. When a requested app is missing from the list and the existing post-publish readiness re-check still cannot find it, the console asks the by-name route which of the two it is, through a new `ObjectStackAdapter.probeAppAccess(name)`. On the measured code it renders a plain authorization message with a way back to the launcher; on anything else — an absent app, an unreachable server, a host that injected a DataSource without the probe — today's publishing copy renders byte for byte, retry button included.
+
+  Two properties of that seam are load-bearing rather than incidental. It branches on the ADR-0112 **code**, never the status (objectui#4408): the two answers under test are both errors one status apart, and a status-reading implementation passes the happy path while going blind exactly where the defect lives. And only `denied` moves the copy: this bug exists because the console asserted a state it had not measured, so a probe that fails, times out or cannot be issued must leave the screen alone rather than guess in the other direction.
+
+  `probeAppAccess` is deliberately separate from `getApp` rather than a flag on it: `getApp` degrades every failure to `null` — the very conflation being undone — and memoises in the adapter's metadata cache, where a verdict about the CALLER would outlive the session it described. New public API on the adapter (`probeAppAccess`, `isAppPermissionDeniedError`, `APP_PERMISSION_DENIED_CODE`, `AppAccessVerdict`), purely additive; nothing existing changed shape. Three new `empty.*` keys ship in all ten locale packs.
+
+- 734d186: The console's Applications page is localized — its own chrome only, never the
+  server's words (objectui#4307).
+
+  `AppManagementPage` was raw English end to end: headings, the search field, the
+  selection and bulk controls, the six per-row actions with their tooltip/ARIA
+  pairs, the status badges, and every toast. It was the last un-i18n'd system page,
+  and #4233 / PR #4300 had just given it four live mutations — so the gap became
+  user-visible on every non-English console at the moment operators started using
+  it. 45 keys land under `appManagement.*` in all ten packs, reached through
+  `useObjectTranslation` with the call site's `defaultValue` inline, which is the
+  convention the neighbouring system pages already follow.
+
+  The split that shapes this change is between the strings the PAGE authors and
+  the strings the SERVER authors. `PUT`/`DELETE /api/v1/meta/app/:name` is gated on
+  `manage_metadata` (ADR-0066 D1), so a refusal like `forbidden: manage_metadata
+required` is the server's diagnosis of one specific request; there is no fixed
+  catalogue of those sentences to key against. Each failure toast is therefore a
+  keyed template with a `{{reason}}` hole, and what fills the hole is passed
+  through byte for byte, untranslated. The one part that IS the page's own — what
+  it says when the server sent no message at all — is keyed as
+  `appManagement.toast.unknownError`.
+
+  Two smaller things follow from doing the conversion properly rather than
+  mechanically. The per-failure entry of a bulk toast and the separator between
+  entries are keys, not literals, because bracket style and list punctuation are
+  locale properties (the same rule, and the same past defect, as
+  `validation.formInvalidJoiner`). And the row's controls now name an app through
+  the resolver the visible heading two lines away already used, with `t` passed:
+  an app carrying objectui's keyed label form previously rendered `Select [object
+Object]` into its checkbox's ARIA label.
+
+- 3fc2971: A null-keyed group renders as an explicit bucket instead of silently vanishing from a chart (objectui#4466)
+
+  `buildChartSeries`' single-dimension branch passed rows through verbatim, so a row whose category VALUE is `null` reached recharts with a null category and drew no mark. The visible outcome was not an empty chart but a quietly wrong one: rows `[{user_id: null, event_count: 51}, {user_id: 'Dev Admin', event_count: 2}]` drew exactly ONE bar — the dominant group, 51 of 53 events, dropped while the y-axis scale still accommodated it, so the chart understated its own data and the axis proved the data had been there. With every group null it drew axes, gridlines and an axis title with zero marks and no empty state, which is the shipped first-boot state of the built-in System Overview board's "Events by User" (every seeded `sys_audit_log` row is written with `user_id = NULL`).
+
+  The mapping lives in the shared series layer, so dashboard widgets and standalone `ObjectChart` get one answer rather than a per-chart patch in the recharts wrapper. It resolves the two-answers disagreement the card names as well: an empty result set keeps the designed empty state, a non-empty result always draws bars — the null bucket included.
+
+  `@object-ui/core` gains `NULL_CATEGORY_LABEL` and `ChartSeriesOptions`; `buildChartSeries` and `findChartSeriesRow` each take an optional trailing `options`. Both additive — every existing call site compiles and behaves identically, and a result with no null category is still returned by array identity. The two helpers are a pair on purpose: the caller matches a clicked segment against rows that still carry the raw `null`, so `findChartSeriesRow` reads the bucket label back to that row and the newly-visible bar keeps its drill-through instead of resolving to `-1`.
+
+  The label goes through the i18n channel (`chart.nullCategory`, en `(None)` / zh `(未指定)`, all ten packs), passed down by the renderer: `@object-ui/core` is React-free and cannot read the locale bundle, so it takes the resolved string the same way `dimensionOptionTranslator` takes a resolver. Its English constant is the floor for a provider-less host, not the mechanism.
+
+  `hasNoCategoryKey` (framework#4033) is untouched and now documented against this: a row that does not carry the category key AT ALL is a different defect — a dimension grouped by but never projected — and keeps its explanatory placeholder. The bucket deliberately never ADDS the key to such a row, which is what keeps that guard's signal alive. Key absent → the placeholder; key present with a null value → the bucket.
+
+- f7c6430: The build-history panel tells an operator a 503 means "the commit store could not be reached — retry", instead of `commits HTTP 503`
+
+  `packages/app-shell/src/preview/commitHistory.ts` flattened every non-OK response to a bare status code (`commits HTTP {status}` for the read, `HTTP {status}` for the revert). Nothing was ever swallowed and no fictional "no history" was ever rendered — those fail-loud properties held, and still hold, which is why objectstack#5980's 503-ification (ADR-0110 D3) needed no follow-up here. What was lost is the meaning the backend already sends, on the one screen where it matters most: this is the rollback surface, read by an operator who is usually mid-incident. A 503 says the read/write did not happen and is worth retrying; a 404 says the store answered "no". They now read differently, and 404, 500 and 503 stay tellable apart.
+
+  Failures now throw a `CommitStoreError` carrying `status`, the ADR-0112 `code`, and a `retryable` flag, and the panel renders a sentence rather than a number. The revert half gets a deliberately different sentence: a write that could not reach the store may still have landed, and re-issuing it appends a _second_ revert commit to an append-only log, so the copy asks the operator to re-read the timeline before retrying rather than simply saying "try again".
+
+  Two details of the report this fixes were checked against the producer and came back different, and both are the reason the copy is authored client-side. The semantic code arrives at **`error.code`**, not `details.code` — `HttpDispatcher.errorFromThrown` parks it in `details` and `buildApiError`/`splitSemanticCode` lift it out and drop `details` (objectstack#3842) — so a consumer reading `details.code` would run a check that can only pass vacuously. And the envelope's own `message` for this class is _withheld_: `declaresServerFault` (objectstack#5811) is true for a 5xx carrying a string code, so the prose on the wire is the generic `Internal server error`. Rendering it would have been strictly worse than the bare status code it replaced. Classification therefore keys on the HTTP status first and treats the code as a second signal, which also means a 503 shed by a proxy with an HTML body still produces the retryable reading.
+
+  Adds `preview.history.loadFailedUnavailable` and `preview.history.revertUnavailable` to all ten locale packs.
+
+- 92876f0: Doc comments no longer cite `@objectstack/spec` symbols the pinned spec has retired
+
+  Eight exported declarations carried a doc comment claiming alignment with a
+  `@objectstack/spec` symbol that `17.0.0-rc.6` does not export — four locale
+  formatting shapes in `@object-ui/i18n` (`SpecPluralRule`, `SpecDateFormat`,
+  `SpecNumberFormat`, `SpecLocaleConfig`) and four activity-feed shapes in
+  `@object-ui/types` (`FieldChangeEntry`, `Mention`, `Reaction`,
+  `RecordSubscription`). A citation that points at nothing is worse than a stale
+  one: the next reader cannot tell whether the protocol retired the symbol,
+  renamed it, or never had it.
+
+  Measuring all eight against the published registry answered that question, and
+  the answer was not "these names never existed". Every one was a real export the
+  protocol retired on purpose, and every local key set was faithful to the schema
+  it named. The feed four left `@objectstack/spec/data` in the `16.0.0` major,
+  when the feed surface was replaced by the data API over `sys_comment` /
+  `sys_activity`. The i18n four left `@objectstack/spec/ui` in `17.0.0-rc.6`
+  itself — they were still present in `rc.5` — retired under ADR-0049
+  enforce-or-remove because no authorable shape carried them and nothing ever
+  parsed them.
+
+  Each comment now records that provenance, including the version the symbol left
+  and what (if anything) replaced it, so the shapes read as declarations these
+  packages own rather than as a view onto a protocol type. Type shapes, runtime
+  behaviour and exports are unchanged — the published `.d.ts` files differ only in
+  comment text, which is why this is graded `patch`.
+
+- 828549a: The gantt's conflict dialog shows the number of affected tasks again, not a literal `{2}`
+
+  `gantt.conflict.body` was resolved at the render site with a literal string replace on **single** braces — `t('gantt.conflict.body').replace('{count}', String(n))` — while all ten locale packs spell the placeholder the i18next way, `{{count}}`. `"…{{count}}…".replace("{count}", "2")` consumes the inner seven characters and leaves the outer pair behind, so every user on every loaded pack read "自动重新排程 **{2}** 个受影响的任务？". The dialog now interpolates through i18next (`t('gantt.conflict.body', { count })`), the idiom `gantt.delete.body` already used.
+
+  The two sibling keys three lines away in the same file, `gantt.autoScheduleDlg.body` and `.skipped`, were **not** broken — pack and call site both used single braces, and they rendered correctly. They are converted anyway, because that split is the whole mechanism: two write-confirmation dialogs in one component carried two different interpolation idioms, so `conflict.body` drifting to the i18next spelling in the packs (which is the correct spelling, and matches every other placeholder in the bundle) silently broke the render. Leaving the auto-schedule keys on the literal-replace idiom leaves the same trap armed for the next translator. All ten packs and the plugin's bundled English fallback table now agree on `{{count}}` for all three; only the braces moved, no translation was reworded.
+
+  `gantt.quickFilter.resultSummary` stays deliberately single-brace — its `ObjectGantt` call site really does resolve `{shown}`/`{total}` with a literal replace, and that convention is pinned by its own parity test. It is now the only key in the gantt namespace on that idiom, and the comments at both spellings say so.
+
+  Nothing caught this, and each gate was silent for its own reason: the cross-pack parity check compares en against each pack, and all eleven spellings agreed; the en-drift check compares a pack against its own history, and the packs were born matching. Both are **relative** comparisons, and the defect lived in the **absolute** relationship between a pack's spelling and the syntax the call site resolves. The existing render test asserted the dialog body contains `'1'` — which `{1}` satisfies. The new pin asserts the absolute form directly, under a real loaded pack, for every way a placeholder can survive to the screen.
+
+- e1ade8f: An illegal gantt dependency link now says why it was refused, instead of doing nothing
+
+  Dragging a dependency onto a target the gantt refuses — itself, a locked row, a group row, or one that would close a dependency cycle — produced no feedback of any kind: no toast, no dialog, no cursor change, no target outline, not even a console warning. The guard was right and completely invisible, so a user drawing a legitimate-looking dependency got a dead interaction and no way to learn the constraint. The rejection was silent in both places it could have shown: a refused bar never became the drop target, so it got no hover treatment at all, and the release handler only ran its body when a target _had_ been registered, so the drop itself was a no-op.
+
+  Both halves are now wired, and both read the **same** verdict. `canReceiveLink`'s four-branch boolean became `classifyLinkTarget`, which returns which branch refused (or `null`), with the boolean derived from it. The hover affordance and the drop toast are two consumers of that one classification, so the reason a user is shown cannot drift from the reason the link was actually refused — there is no second classifier to disagree. The branch names are the leaves of the new `gantt.link.rejected.*` keys, so a branch added later without a message surfaces as a missing key rather than as a plausible-but-wrong sentence.
+
+  During the drag, a refused bar under the pointer gets `cursor: not-allowed` and a destructive outline; on release it raises a toast naming the reason. Four messages, one per branch, in all ten packs. Both the cursor and the outline are driven from inline `style` rather than utility classes, matching the bar's existing read-only cursor three lines away and for the same reason recorded there: `cursor-not-allowed` and the ring alpha utilities are not emitted in the prebuilt components CSS, so a class would look correct in a DOM test and render nothing in a browser.
+
+  Deliberately unchanged: a host veto through `onBeforeDependencyCreate` stays silent. That rejection carries a reason only the host knows, and the gantt has none to show — surfacing it means exposing a rejection-reason output on the public component, which is a separate contract rather than a rider on this one. The four built-in reasons are the gantt's own policy and are the only ones it can explain.
+
+  One of the four, `group`, has no end-to-end path today: a `type: 'group'` row renders no bar, so the drag can never target it. The message is kept anyway — without it the branch would render a raw key on screen if it ever did fire — and the test pins the reachability fact, so it goes red the day group rows gain a bar. Filed as objectui#4209.
+
+- 3e19fe7: i18n copy: one ellipsis glyph across the ten packs, `usted` in the es draft-preview empty state, and a pt sentence that stops contracting `de` onto its own hole
+
+  Three locale-copy defects that no gate could see, because all three are _value_ defects on keys whose names, placeholders and key sets were already correct.
+
+  **One ellipsis (objectui#3878).** `en` ended 33 values with three ASCII full stops (`Loading...`, `Ask anything...`) and 110 with the typographic ellipsis `…`, and the nine translation packs had copied `en` value by value — so a user could read both glyphs on one screen: `common.loading` beside `dashboard.loading`, `console.ai.askAnything` beside its own panel's siblings. All ten packs now spell it `…` (U+2026), per the maintainer-authorized consistency pass registered on objectstack#6015. 312 pack values changed: 34 in `en` (the 33 trailing plus the one mid-sentence `collaboration.commentPlaceholder`) and 278 across the nine. Eleven inline `defaultValue` call sites were re-synchronised with the new `en` text, which `scripts/check-i18n-call-site-keys.mjs` requires byte-for-byte.
+
+  The convention is now pinned so the split cannot regrow: `packages/i18n/src/__tests__/ellipsis-glyph-3878.test.ts` fails, by key name, on any value in any of the ten packs that holds three ASCII full stops. It is deliberately wider than "a trailing `...` in `en`", because the census showed the narrow rule would have shipped with two holes in it — `collaboration.commentPlaceholder` puts the ellipsis mid-sentence, and `list.loading` had the packs wrong while `en` was already right, which no `en`-only rule can see.
+
+  Fifteen module-local **no-provider fallback** entries were moved with the packs, across `useCollaborationTranslation`, `useFieldTranslation`, `useDetailTranslation`, `ObjectGrid`, `KanbanImpl`, `data-table` and `ConnectionStatus`. Those maps exist to render when no `LocalizationProvider` is mounted, and each one's own docblock requires it to stay byte-identical to the `en` pack — a requirement objectui#3440 already enforces mechanically for the collaboration map. Leaving them behind would have made the provider-less path disagree with the provider path on ten keys.
+
+  **es `usted` (objectui#3875).** `preview.empty.notReadyDescription` said `Revisa la conversación` — the tú imperative — in a namespace that is otherwise 23:1 usted, and it renders _underneath the usted draft-preview banner at the same moment_, not before or after it. `Revisa` → `Revise`; nothing else in the sentence carries a register. The neighbouring `approvalsInbox` namespace is legitimately tú and was left alone.
+
+  **pt contraction (objectui#3877).** `ConcurrentUpdateDialog` splits `detail.concurrentUpdateDescription` on `{{field}}` and renders a bolded label in the gap, and pt left a bare `de` in front of that gap. When the multi-field conflict branch passes the record label (`este registro`), Portuguese users read `de este registro` — a contraction error every native speaker sees, and one that no spelling of the leaf value could fix (`deste registro` renders `de deste registro`). The pt sentence is rewritten so the hole is preceded by the verb `afeta` instead of any preposition, which closes the whole class rather than trading `de` for an `em` or `a` that contract just as hard. pt only; `en` is unchanged.
+
+  No behavior, no keys added or removed, no placeholder changed.
+
+- bb58d1d: i18n: the two search placeholders become pack values, and four values the packs served in English get translated
+
+  **objectui#4375** — `ListView` and `LookupField` built their search placeholder as
+  `t(key) + '...'`, so the ellipsis was a literal concatenated in code: it stayed ASCII
+  in all ten locales on screens where objectui#3878 had converged everything else on
+  U+2026, and no pack could opt out of it (sharpest in `ar`, where a left-to-right run
+  was appended to right-to-left text). Both now read `table.search`, which is already
+  the repo's search-input placeholder key — `data-table`, `RecordPickerDialog` and
+  `PeoplePicker` render it too — and is translated with the right ellipsis in all ten
+  packs. No new keys.
+
+  **objectui#4376** — `list.loading` served the English `Loading records…` in eight of
+  the nine translation packs (`zh` alone had translated it); `designer.undo` and
+  `designer.redo` were English in all nine; `appDesigner.snakeCaseHint` in `ko`, `pt`,
+  `ru` and `ar`. All translated, reusing each pack's own established vocabulary. A new
+  pin (`untranslated-identity-4376.test.ts`) fails on any value byte-identical to `en`
+  inside a non-Latin pack unless the key is on an explicit 22-entry allowlist.
+
+- 5cc847c: The console shows a standing impersonation banner, with an exit that fails loudly (#4467).
+
+  While `session.impersonatedBy` is present, `ConsoleShell` renders a banner naming BOTH
+  parties — the impersonated user, whose name every write is recorded under, and the
+  administrator who started it — plus a stop affordance. It derives from the session rather
+  than from client memory of the click, so it survives a full SPA reboot, a new tab and a
+  browser restart, and it cannot disagree with who the server thinks is acting. An ordinary
+  session renders `null` and its chrome is unchanged.
+
+  The exit calls `POST /auth/admin/stop-impersonating` over the same data lane and then
+  awaits a session refresh. The server restores the administrator from the `admin_session`
+  COOKIE, so a deployment that blocks cookies cannot exit this way — the banner says so and
+  stays up instead of appearing to succeed, which would leave the operator doing ordinary
+  work under someone else's identity.
+
+  Ten locale packs carry the banner's copy.
+
+- fa21254: Kanban: a drop that makes fields required now collects them instead of dead-ending
+
+  Dragging a card into a column whose value flips a field's `requiredWhen` predicate to TRUE used to PATCH the column value alone. The engine refused the whole update — correctly, that is what the predicate declares — and the board had no way to finish the move: the only path to closing a won deal was to abandon the board and open the record form. HotCRM's opportunity pipeline is the reported case (`win_reason` is required when `stage == "closed_won"`), but the dead end belonged to every board whose target column carries a conditional requirement.
+
+  The board now evaluates the target column's predicates BEFORE writing anything. If the move would make fields required while they are still empty, it opens a small dialog collecting exactly those fields, then submits the column value and everything collected as ONE PATCH — never two writes, which would leave the record in the refused state if the second one failed. A drop that triggers no predicate is untouched, down to the PATCH body.
+
+  The verdict comes from `@object-ui/core`'s `resolveFieldRuleState` — the same evaluator the record form, the wizard and the line-item grid already resolve `visibleWhen`/`readonlyWhen`/`requiredWhen` with, delegating to `@objectstack/formula`'s CEL engine. The board's prompt and the server's enforcement therefore reach the identical verdict rather than drifting through a second hand-rolled predicate evaluator. Emptiness is core's `isMissingForRequired`, the presence contract the form and the server share, so a `false` boolean and a `0` count as answers and are not re-asked.
+
+  Every control in the dialog is `@object-ui/fields`' `FieldEditWidget`, the same widget the record form renders for that field type — a select edits as a select, a date as a date picker — so this adds no second set of field-rendering decisions.
+
+  Four kinds of field are deliberately NOT collected, and each falls through to the unchanged PATCH where the server's refusal (legible since objectstack#7525) speaks for itself: one that already has a value, one `visibleWhen` hides, one that is readonly, and one whose type has no edit widget at all. A dialog row with no control would be a worse dead end than the one being fixed.
+
+  Cancelling writes nothing and leaves the card in its original column; a combined PATCH that is still refused for some other reason surfaces the refusal and rolls back exactly as a plain rejected move does, rather than looping the dialog on an arbitrary server error.
+
+  `@object-ui/i18n` carries two new `kanban.*` strings for the dialog, translated across all ten packs. Its public type surface is unchanged — the `.d.ts` was measured identical before and after — hence the patch bump.
+
+- 33c32bf: List sort: the picker stops borrowing the filter whitelist, and a header click is no longer a one-way door out of the view's declared sort
+
+  `filterableFields` was applied to the single field set both toolbar builders read, so a whitelist authored for _filtering_ silently became the _sort_ whitelist too. A view could declare a two-level default sort — `plan_start_date` then `name` — and get a sort panel that offered neither field and rendered both of its rows blank: the declared sort worked on load and could then be neither reproduced nor modified, and there was no way to express "sortable but not offered as a filter condition" short of widening the filter builder as collateral. The whitelist now narrows the filter builder alone, which is the contract it was written for; the sort picker starts from every field the view can name and applies its own sortability rules.
+
+  Those rules are about what the sort can honestly reach, so a second one joins the existing relational exclusion: a `formula` field is withheld. It has no materialised column, so ordering by one is refused by the server outright (objectstack `UNMATERIALIZED_SORT_TYPES`) — and it matters here precisely because the base set widened, since a formula field previously reached the picker only if someone had whitelisted it. The exclusion is `formula` alone and deliberately not the spec's `COMPUTED_VALUE_TYPES`: `summary` and `autonumber` are computed too, each gets a real maintained column, and both order correctly. Either rule keeps its existing escape hatch — a field the current sort already uses stays listed, which for a formula field is the only way to remove the offending row.
+
+  One consequence worth naming: the hint explaining the relational omission used to be gated by the same whitelist. A view whitelisting only `status` showed a near-empty sort picker and no word about why; the withheld relational field now reaches the rule that withholds it, so the explanation appears with it.
+
+  The second half is the way back. One column-header click replaces the whole sort array, so a view shipping a multi-level default lost it for the rest of the session — the declared `sort` behaved as an initial value only, recoverable just by reloading the page. The sort panel gains a **Reset to view default** control that restores the declared array whole: multi-level, in declared order, not merely cleared. It reads the view's declared sort through the same resolver the initial render already uses, so there is one answer to "what did this view declare". It is disabled while the active sort already matches that default, and absent entirely for a view that declares no sort — there is no default to return to, and clearing the sort under that label would be a second, differently-named way to do what removing the rows already does. The header click's own semantics are unchanged: it still replaces the array, it just no longer does so irreversibly.
+
+- 6d641c9: Members & invitations tabs gate their affordances by org role instead of letting the server's 403 be the UI (#4475)
+
+  A user whose organization role is `member` opened the workspace members page and
+  was shown an enabled **Invite member** button plus a per-row **Member actions**
+  menu carrying **Remove member** — on every row, the workspace Owner's included.
+  Nothing was hidden or disabled; the action only failed after the user had
+  committed to it. The Settings tab of the same page already gated correctly; the
+  members and invitations tabs never got the same treatment.
+
+  The affordances are now narrowed to the roles that can actually use them, keyed
+  on the active member's role — the same source the role-change menu on this page
+  already reads. Which roles those are is **measured against the routes that
+  enforce them**, not assumed to be "owner":
+
+  | affordance        | route                             | permission              | roles                         |
+  | ----------------- | --------------------------------- | ----------------------- | ----------------------------- |
+  | Invite member     | `/organization/invite-member`     | `invitation:["create"]` | owner, admin, delegated_admin |
+  | Remove member     | `/organization/remove-member`     | `member:["delete"]`     | owner, admin                  |
+  | Cancel invitation | `/organization/cancel-invitation` | `invitation:["cancel"]` | owner, admin                  |
+
+  Three different gates, because `delegated_admin` holds `invitation:["create"]`
+  without `member:["delete"]` and deliberately without `cancel` — so it keeps the
+  invite button and the copy-link action while losing remove and cancel. A single
+  owner check could not express that.
+
+  An actor left with no row action at all gets no menu rather than a trigger that
+  opens onto nothing, and the members page explains the absence where the Invite
+  button used to sit, in the Settings tab's own voice. An unresolved role is
+  treated as the least privileged, so nothing privileged is offered to a viewer
+  whose membership could not be read.
+
+  Reading the pages is unaffected: the member list and the invitation ledger still
+  render in full. Whether `org_member` should be able to read the invitation
+  ledger at all is a separate, server-side question.
+
+- 45e1949: Numbers render in the user's locale, and a `Field.number` year is no longer `2,026`
+
+  Every numeric field the console rendered went through an `Intl.NumberFormat` built with the locale hardcoded to `en-US` and `useGrouping` never set. Two defects rode in that one construction: a `zh-CN` or `de-DE` console still grouped and pointed decimals the US way, and a four-digit **year** stored as `Field.number({ scale: 0 })` rendered as `2,026` — in every locale, with no field property able to turn it off. Apps had been converting year columns to `Field.text` to escape it, permanently trading numeric comparison, range filters and dataset dimension types for a display detail.
+
+  The construction had been copied into five places — the number cell renderer, the currency cell renderer, the `CurrencyField` widget, the compact `formatNumber` helper, and the dashboard `MetricWidget` — so fixing any one surface never changed the answer. They now share one formatter, `formatDisplayNumber` in `@object-ui/i18n`, which owns the locale and the grouping policy together, plus one locale resolver, `useDisplayLocale`.
+
+  `useDisplayLocale` composes the two locale channels this repo already had rather than adding a third: the tenant's regional default (`useLocalization().locale`, ADR-0053) when an org has configured one, otherwise the active UI language (`useObjectTranslation().language`) so grouping and decimal marks follow a language switch. That second step is what covers the case the report was measured in — a fresh database, where the tenant localization endpoint has no locale to give.
+
+  Grouping is now suppressed when a field declares `scale: 0` and carries no currency, which is what makes years, fiscal periods and other ordinals render plainly. This is an **interim default** with an accepted cost: a large scale-0 _count_ loses its separators too. It holds only until the spec gains an authorable presentation hint, which is being specified separately, contract-first; when that lands it overrides this heuristic.
+
+  Three surfaces deliberately keep their separators, because a zero-decimal display there does not come from a field declaration: the dashboard `MetricWidget` (its decimals are parsed from a numeral.js format pattern, and its own contract calls the separators load-bearing — "`1,930,000` not `1930000`"), the `element:number` aggregate renderer, and every currency path including amounts whose currency code could not be resolved. An **undeclared** `scale` also keeps grouping — absent means "decimals unknown", not "integer".
+
+  `formatCurrency`, `formatCompactCurrency` and `formatNumber` each take a new optional trailing `locale` argument. Existing calls are unaffected; omitting it now follows the runtime default rather than forcing US conventions.
+
+- 58bebf6: Organization & invitation console: translate the English holdouts a zh session was left reading (#4474)
+
+  Three families of string, one sweep over `console/organizations/`:
+
+  - **Role names** now come from the single shared `ORG_ROLE_LABELS` map at every
+    site. The role badges on the members and invitations pages were rendering the
+    raw server identifier (`owner`) under a CSS `capitalize` that made it look like
+    a label in English and left it untranslated everywhere else; the accept page
+    did the same in its role row and inside its otherwise-translated sentence. The
+    map's four `organization.roles.*` keys existed in no locale pack, so even the
+    dropdown that did consult it fell through to English — all ten packs now carry
+    them. An unrecognized role renders verbatim rather than blank.
+  - **Server-echoed errors** are mapped by better-auth's stable `code`, never by
+    matching its English text. `createAuthClient` was dropping that code for every
+    `organization.*` call while preserving it for sign-in/sign-up, so the console
+    had nothing to key on; all sixteen organization methods now go through the same
+    `toAuthError` helper. Messages are unchanged — the code simply stops being
+    thrown away. An unmapped code still shows the server's own sentence.
+  - **Icon-only `aria-label`s** (member actions, copy invitation link, cancel
+    invitation, and a fourth on the share-link copy button) are translated — for an
+    icon-only control this is the only name a screen reader gets.
+
+- 405e808: `pickLocalized` reads own properties only, and takes only string values, on every limb
+
+  The resolver read four of its six limbs — the exact tag, the base language, `default` and `en` — with a bare bracket access. Bare access walks the prototype chain, so a locale that happened to name an `Object.prototype` member resolved to that member and the function stringified it into the label: `pickLocalized({ en: 'Pricing' }, 'constructor')` returned `function Object() { [native code] }`, and the same held for `toString`, `valueOf`, `hasOwnProperty`, `isPrototypeOf`, `propertyIsEnumerable` and `toLocaleString`. Those same four limbs also skipped the `typeof === 'string'` filter the regional and last-resort limbs already applied, so a non-string value short-circuited the chain and rendered as `[object Object]`.
+
+  Both guards now apply uniformly. A guarded limb **misses** rather than aborting the resolution, so an unusable entry falls through to the next limb exactly as an absent one does — `pickLocalized({ en: 'Pricing' }, 'constructor')` is now `'Pricing'` (the `en` limb), and only a map with no usable entry at all resolves to `''`. An empty-string value is still a hit, because `''` is a label the author wrote.
+
+  No real language tag can observe this: no BCP-47 tag is an `Object.prototype` member, and the inline locale map is declared `z.record(<tag>, z.string())`, so every in-contract input resolves byte-identically to before. What it changes is agreement with the backend twin `resolveI18nLabel` (objectstack#6765), which shipped with exactly these two narrowings recorded as deliberate departures from this function because on a server the locale can arrive in an `Accept-Language` header. That recorded rule divergence is now zero; the only remaining difference is how each side spells a miss (`''` here for a text node, `undefined` there for a producer's fallback chain), which is pinned as an identity in the cross-resolver parity table.
+
+- c0f9a4b: Studio surfaces the runtime authoring gate's advisory findings instead of discarding them client-side
+
+  The framework's runtime authoring gate produces two kinds of verdict on a metadata write. Errors become a 422 and the author sees them. Advisories ride a **200** — the save succeeded, the row persisted, the version bumped — and until objectstack#7435 the server dropped them into a deduped `console.warn` behind a process-level set. That landing put them on the wire as an optional `advisories[]` on the save response, emitted only when non-empty, and objectui was still throwing them away one layer further out: `MetadataClient.save` parsed the body, returned it as an opaque `T`, and every call site awaited it for its side effect and discarded the value.
+
+  The measured case the fix is built on: a `nightly_purge` flow whose only defect is a `delete_record` node with `multi: true` and no filter yields `errors = 0 / advisories = 1`. The save returns 200, the flow goes live, and nothing anywhere tells the author it deletes every row. That matters most for exactly the authors Studio serves — a Studio tenant or an MCP/AI author has no `os lint` and no CLI config for `sys_metadata` overlay rows, so this gate is not the weakest of four doors, it is the only one.
+
+  `MetadataClient` now carries an `onSaveAdvisory` sink, invoked after a save whose response carried a non-empty `advisories[]`, and the console wires it in `useMetadataClient` — the one hook every app-shell write path takes its client from, so a single wiring covers `ResourceEditPage`, `StudioDesignSurface`, `EmbeddedItemEditor`, `DatasourceResourcePage`, `ObjectHooksPanel` and any future call site rather than a toast copied into twenty of them. The finding shape is re-exported from `@objectstack/spec` (`RuntimeAuthoringIssue`) rather than restated, so it cannot fork from the 422 `issues[]` it deliberately shares a declaration with.
+
+  The affordance is the warning tier and says "Saved" first. A successful save that reads as a failure is the specific defect this surface must not ship, so the toast acknowledges the write, lists `rule` + `message` + `hint` per finding with `where` as secondary context, and renders that text **verbatim** — `message` and `hint` are server prose composed by the gate's rules, not i18n keys. Only the frame around them is translated (`console.saveAdvisoryTitle`, ten packs). The sink is best-effort in both directions: a malformed finding is dropped rather than printed as blanks, and a throwing renderer cannot turn a save the server already committed into an error.
+
+  **What this does not surface yet, and why.** Studio's designer saves as a **draft** on every edit, and drafts are never gated — the framework returns at its D1 early-return (`if (args.state !== 'active') return null`) before running a single rule, so a draft save produces no findings at all rather than producing some that get withheld. The publish step that promotes a draft to active _does_ run the gate, but the publish route returns no `advisories` field until objectstack#7294 lands. So a draft-then-publish flow renders nothing today, at both of its doors, for two different reasons; the active-mode save door renders findings now. That gap is pinned as a test rather than left for a reader to rediscover.
+
+- d46f9b8: i18n: `createSafeTranslation`'s provider-less fallback now honours a call site's inline `defaultValue`
+
+  `fallbackT` looked its key up in the hook's hand-written `defaults` map and, on a miss, rendered the
+  **raw key** to the user — then ran every option, `defaultValue` included, through the interpolation
+  loop as if it were a `{{defaultValue}}` variable. So `t('perm.facet.none', { defaultValue: 'None' })`
+  showed `perm.facet.none` on a host with no `I18nProvider`, which is a supported scenario (standalone
+  embedding and tests are the whole reason this factory exists).
+
+  The lookup order is now `defaults[key]` -> a string `defaultValue` -> the key, matching i18next,
+  which serves the provider path: the defaults map is the pack value's stand-in here, so it keeps the
+  pack's winning position. `defaultValue` is also excluded from the interpolation loop as a reserved
+  name — it selects the string, it does not fill holes in one. Non-string `defaultValue` is ignored.
+  The provider path is untouched.
+
+  Measured over all 26 `createSafeTranslation` hooks in the repo: 27 keys reach a hook whose defaults
+  map lacks them, 21 of those carrying an inline `defaultValue` that used to be dropped (16 keys in
+  `plugin-detail` alone). Those 21 now render their English instead of a raw key on provider-less
+  hosts; the other 6 pass no inline default and still need a map or pack entry.
+
+- 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.
+
+- 7f1cb33: List sort: the relational hint stops recommending a formula field, the one type the server refuses to sort by
+
+  The Sort panel withholds columns that link to another record and explains why, and the last sentence of that explanation named the remedy: _add a formula field holding it_. A formula field is exactly what the platform will not order by. The server keeps `UNMATERIALIZED_SORT_TYPES = new Set(['formula'])` and, since objectstack#6994, a sort naming one is a hard `400 INVALID_SORT` — before that it degraded silently, returning every row with `asc` and `desc` byte-identical. So an author who read the hint, followed it, and built a formula field arrived at a refusal; and since #4243 withheld formula fields from this very picker, at a field the panel does not offer either. Two doors, opposite advice, for one problem.
+
+  The remedy sentence now names a **stored, denormalised field — written when the source changes** — and rules the formula field out in as many words: it is virtual, no column is stored for it, and the server refuses to sort by one. That is deliberately the server's own vocabulary rather than a third phrasing of the same fact: objectstack#6924 and objectstack#6994 settled on one wording across the refusal doors so an author refused twice is not sent two different ways, and this is the UI door of that same set. The first half of the hint — why relation columns are withheld at all — is unchanged.
+
+  All ten locale packs move together, as `check:i18n-drift` requires of any `en` edit. The same sentence also lives in `plugin-list`'s provider-less fallback table, which is what renders when the component is used outside an `I18nProvider`; it is updated to match `en` byte for byte, because a pack-only reword would have left the retired advice on exactly the surface this fixes.
+
+- 2e3b0c0: fix(list): an `OBJECT_API_DISABLED` list request renders an honest cannot-work state instead of the empty state
+
+  A list pointed at an object whose `enable` block withholds the API rendered its ordinary
+  empty state, so _"this page cannot work, and never could"_ reached the user as _"you have no
+  records"_ (objectui#4408). The reported instance — `Setup › Advanced › Signing Keys`, whose
+  `sys_jwks` declares `enable.apiEnabled: false` — could not load for any persona and said so
+  to nobody. That is also why the upstream defect objectstack#7544 survived review for its
+  whole life: a merely unpopulated page invites nobody to click through.
+
+  The masking had two halves, in two packages, and neither package could see the other:
+
+  - **`@object-ui/data-objectstack`** (minor — see the grading note below) — `find()` degraded
+    **every** 404 into `{ data: [], total: 0 }` and memoised the resource, so the denial arrived
+    at the surface as a successful empty result, indistinguishable from a genuinely empty
+    object. The two `enable`-block denials are now let through instead: `OBJECT_API_DISABLED`
+    (404) and `OBJECT_API_METHOD_NOT_ALLOWED` (405). The memo skips them too — absorbing one
+    would have pinned the object to "empty" for the rest of the session.
+  - **`@object-ui/plugin-list`** — the load-error panel gained an `api-disabled` kind. The 405
+    half was never swallowed, so it already reached this panel, but classified as `network`:
+    _"check your connection and try again"_ for a condition no retry can change. It now says
+    the object is not exposed through the API, that this is a setting on the object rather than
+    a permission, and it offers **no Retry** button, because every retry re-fetches the
+    identical refusal.
+
+  Both denials are pure functions of the object's metadata — no user, no permission, no
+  context — so neither is transient or per-user, which is exactly the case where a silent empty
+  state is most misleading. Discrimination is on the ADR-0112 `code`, never the status: a
+  missing collection, a missing record and a disabled object are all 404.
+
+  **A genuinely empty object still renders the ordinary empty state**, and a backend without an
+  optional collection still degrades to empty — pinned in both directions, at the adapter, at
+  the view, and once end-to-end over a real adapter and a real `ListView`.
+
+  Also closes a code-propagation gap on the same path: `find()`'s raw `$expand`/`$search`
+  branch bypasses `@objectstack/client` and hand-rolled its own error, stamping only `status`.
+  It now carries the ADR-0112 envelope (`code` + `httpStatus`), so a denial arriving on the
+  branch a list takes whenever it expands a lookup or runs a search is no longer anonymous.
+
+  New strings: `list.loadErrorApiDisabledTitle` / `list.loadErrorApiDisabledMessage`, in the
+  `en` pack and mirrored in the list defaults map.
+
+  ## Grading note — why `@object-ui/data-objectstack` is **minor** and not patch
+
+  Two independent reasons, either of which is sufficient under this repo's precedent
+  (objectui#4403 / #4177, and #4485's grading of `@object-ui/core`'s `toDomProps` lift):
+
+  1. **The emitted `.d.ts` grows two NEW exports.** `isApiAccessDeniedError(error: unknown):
+boolean` and `API_ACCESS_DENIED_CODES` (the readonly tuple
+     `['OBJECT_API_DISABLED', 'OBJECT_API_METHOD_NOT_ALLOWED']`) are added to the package's
+     public surface. Additive surface growth is minor.
+  2. **Observable behaviour on a published API moves.** `ObjectStackDataSource.find()` now
+     **REJECTS** for the two `enable`-block denial codes where it previously **RESOLVED** with
+     `{ data: [], total: 0 }`. No signature changed and nothing was removed, but a caller that
+     relied on those two codes arriving as a successful empty result now receives a rejected
+     promise carrying `code` + `httpStatus`, and must handle it.
+
+  Deliberately unchanged, and still resolving to an empty result exactly as before: a bare 404
+  with no code, `OBJECT_NOT_FOUND` (still memoised) and `RECORD_NOT_FOUND`. The behaviour move
+  is scoped to the two denial codes named above and to nothing else.
+
+  Not major: this follows AGENTS.md's version-alignment rule — objectui's major tracks
+  `@objectstack`'s, so this repo's own breaking semantics are declared as minor with the change
+  described in the body, which is what this note is.
+
+- 31ab1ac: fix(print): `window.print()` produces a usable page, and the Print buttons say what they do
+
+  The list, report and dashboard Print controls were bare `window.print()` calls with no
+  print stylesheet, so the browser printed the whole console — sidebar, top bar, chat rail,
+  toasts — with the data table clipped to a single viewport. With no label to the contrary
+  they were being accepted against "export to PDF" requirements, which they have never been.
+
+  - `@object-ui/app-shell/styles.css` gains a shared `@media print` block: it hides the shell
+    chrome, prints the active content area full-width, releases the viewport-height flex chain
+    so long tables paginate instead of clipping, repeats table headers on every sheet, and
+    neutralises dark mode (which otherwise prints white-on-white). One sheet serves list,
+    report and dashboard.
+  - The list and report Print buttons carry a tooltip and accessible name stating that they
+    open the browser's own print dialog and are not a PDF export (new `common.printDialogHint`,
+    translated in all ten locale packs).
+  - The dashboard's `export_dashboard_pdf` action no longer toasts "Preparing PDF export…" —
+    it names the print dialog it actually opens (`dashboardActions.pdfPreparing` is replaced by
+    `dashboardActions.printDialogOpening`).
+
+  No control was removed and no headless detection was added. A real print/PDF primitive
+  remains out of scope (`objectstack-ai/objectstack#1301`, closed NOT_PLANNED).
+
+- 06915b0: fix(i18n): every date branch threads the active locale, so a `zh` session no longer renders half its dates in English
+
+  Date rendering had two locale channels and only one followed the user's
+  language, so the same row could read `逾期 6 天` in one column and `In 3 days`
+  in the next, with a datetime column showing `8/11/2026 12:00 am`
+  (objectui#4468).
+
+  The overdue phrase resolves through the translate fn (the active UI language),
+  while every `Intl` branch took its tag from the raw tenant locale
+  (`useLocalization().locale`) — which is `undefined` on any workspace that never
+  configured one, and `undefined` makes `Intl` use the _machine's_ locale.
+  `DateTimeCellRenderer` passed no tag at all.
+
+  Every date-formatting site in `@object-ui/fields` now resolves through the one
+  existing channel, `useDisplayLocale()` (tenant regional default → active UI
+  language → `en`): `DateCellRenderer` (relative past, relative future, near-today
+  and the beyond-±7-days absolute fallback), `DateTimeCellRenderer`, the read-only
+  `DateField` / `DateTimeField` / `FormulaField` faces, and the sub-grid's
+  temporal cells. English output is unchanged, and the already-localized overdue
+  wording is untouched.
+
+  No public signature changed. `@object-ui/i18n` carries a documentation
+  correction only: `useDisplayLocale`'s docstring claimed `DateCellRenderer`
+  already formatted from this channel, which was the very thing that was not true.
+
+- ff84b05: Stop the report config panel being titled "Title", and the view-settings colour section "Color"
+
+  Two call sites asked for a key whose value was written for a different slot, so the rendered copy was wrong (objectui#4118, surfaced by objectui#3810's census).
+
+  `ReportConfigPanel` used `report.editor.title` for both its heading and the accessible name of its `role="complementary"` landmark. That key is the label of the report's Title _field_ — `report.editor.titlePlaceholder` ('e.g. Pipeline by Quarter') sits directly under it in the pack. So the panel was headed "Title", and a screen reader announced a complementary region named "Title", which says nothing about what the region is. A new `report.editor.panelTitle` ('Edit report' — what the call site's own dead fallback said before objectui#3810 aligned it to the pack) now names the panel, in all ten locale packs.
+
+  `ViewSettingsPopover`'s colour section used `list.color`. On the wide toolbar `ListView` already uses both keys correctly for the two slots of this one feature: the compact `Paintbrush` button is `list.color` ('Color') and the panel it opens is headed `list.rowColor` ('Row Color'). This popover is that same panel on the collapsed/`compactToolbar` surface, so it now takes `list.rowColor` — an existing key, no pack change.
+
+  No `en` value of an existing key changed; `scripts/check-i18n-en-drift.mjs` reports 0 en values changed, 1 key added.
+
+- Updated dependencies [ee66e2e]
+- Updated dependencies [ee26e65]
+- Updated dependencies [5900ac5]
+- Updated dependencies [3fc2971]
+- Updated dependencies [aca27fa]
+- Updated dependencies [dde7283]
+- Updated dependencies [f279deb]
+- Updated dependencies [eb7f586]
+- Updated dependencies [e901131]
+- Updated dependencies [d9d3463]
+- Updated dependencies [613b167]
+- Updated dependencies [abb0f81]
+- Updated dependencies [38ab505]
+- Updated dependencies [7e4f0e5]
+- Updated dependencies [92250d6]
+- Updated dependencies [c1d939f]
+- Updated dependencies [49ae9f4]
+- Updated dependencies [2459a3e]
+- Updated dependencies [d6aa172]
+- Updated dependencies [fe52a04]
+- Updated dependencies [bb68488]
+- Updated dependencies [9461dd3]
+  - @object-ui/core@17.5.0
+
+## 17.4.0
+
+### Patch Changes
+
+- 7864f03: Backfill the auth family's 54 missing locale keys — `auth` 26 + `oauth` 16 + `acceptInvitation` 12 (objectui#3546, slice three)
+
+  `scripts/check-i18n-call-site-keys.mjs` (objectui#3530) measured 54 keys that a
+  `t()` call site asks for and that **no locale pack defined** — 54 distinct keys at
+  54 call sites across the console's six auth pages. All 54 carried an inline
+  `t(key, { defaultValue: 'English' })`, which is exactly the objectui#3517 class:
+  English rendered correctly, and **all ten languages were stuck on it** for
+  months. Nothing here rendered a raw key — slice one (PR #3583) held those sites.
+
+  What that meant on the page: a `zh` user reaching `/login` and switching to the
+  phone/SMS branch got "Email or phone number", "Get code", "Resend in {seconds}s"
+  and "Sign in with password instead" in English; the whole `/oauth/consent` screen
+  — including the four scope sentences describing what a third-party client is
+  about to be granted — was English-only; so was the `/accept-invitation` page and
+  the device-authorization dead end.
+
+  - **`packages/i18n/src/locales/en.ts`** gains the 54 keys. `oauth.consent.*` and
+    `acceptInvitation.*` are new top-level namespaces; the other 26 extend
+    `auth.login`, `auth.forgotPassword`, `auth.device` and `auth.verifyEmail`.
+    Every one of the 52 keys whose call site carries a **string** `defaultValue`
+    gets that exact string, byte for byte (52/52, script-compared), so the pack
+    path and the inline-default path cannot diverge. The two remaining keys —
+    `oauth.consent.title` / `oauth.consent.request` — have **template**
+    defaultValues, where byte identity is structurally impossible (JS `${…}` vs
+    i18next `{{…}}`); both take the interpolation contract the call site actually
+    declares in its options.
+  - **The nine other packs** get real translations, each evidenced against a
+    neighbour key in the same pack (fr's space before `?`/`:`, de's en dash, ru's
+    ё, ar's verb-first placement so an RTL sentence does not open on a Latin
+    client name, zh's full-width punctuation). The one string all ten packs share
+    is `phonePlaceholder` — the E.164 example number, treated like the
+    `name@example.com` the packs already keep untranslated.
+  - **`scripts/i18n-call-site-key-baseline.json`** loses exactly those 54 entries
+    (163 → 109). The file is a ratchet: an unfixed key missing from it fails the
+    build, and a fixed key still listed fails it too.
+  - **No component changed.** An AST sweep of all 122 call sites in these three
+    namespaces found zero dead `t(key) || 'English'` fallbacks (the construct
+    slice one had to delete from `ObjectView.tsx`, where i18next's key-as-value
+    return made `||` unreachable).
+
+  Two holes here are **not** i18next's and must survive translation intact:
+  `resendOtpCountdownText` carries `{seconds}` in single braces because
+  `packages/auth/src/LoginForm.tsx` and `ForgotPasswordForm.tsx` substitute it with
+  a literal `.replace()`, and `oauth.consent.request`'s `{{suffix}}` arrives
+  pre-formatted from the page. Both are pinned in
+  `packages/i18n/src/__tests__/auth-namespace-3546.test.tsx`, in both directions.
+
+- f5f8744: Backfill the `console` namespace's 41 missing locale keys plus the `console.ai.group.` template family (objectui#3546, slice four)
+
+  `scripts/check-i18n-call-site-keys.mjs` (objectui#3530) measured **41 distinct
+  keys at 47 call sites** under `console.*` that a `t()` call site asks for and
+  that **no locale pack defined** — five of those keys have more than one site
+  (`console.ai.dock.maximize` has three), which is why the denominator is measured
+  and never counted by hand. All 47 carried an inline
+  `t(key, { defaultValue: 'English' })`, so this is the objectui#3517 class:
+  English rendered correctly, and **all ten languages were stuck on it**. Nothing
+  here rendered a raw key — slice one (PR #3583) held those sites.
+
+  What that meant on the page: a `zh` user opening `/ai` got "Waiting for
+  server…", "Still working…" and "Connection lost — reconnecting…" in the
+  connection banner, all ten "Designing your app…" progress hints in English, and
+  "Built" / "Not yet built" / "Published" / "Publish failed" on the plan card; the
+  ChatDock's whole chrome (title, resize handle, collapse, "Open full page") was
+  English including two `aria-label`s; the conversation sidebar's date headers read
+  "Today" / "Yesterday" / "Previous 7 days"; a mistyped URL produced an English
+  "Page not found"; and the `?` shortcuts dialog's AI group was English inside an
+  otherwise translated table. Two of these strings ("Not yet built", "TODAY") are
+  named in objectui#2458's mixed-language list.
+
+  - **`packages/i18n/src/locales/en.ts`** gains 46 keys: the 41 measured ones plus
+    the five members of the `console.ai.group.` family. `console.notFound` is a new
+    sub-namespace; the rest extend `console.shortcuts` and `console.ai` (with new
+    `console.ai.dock`, `console.ai.designingPlanHint` and `console.ai.group`
+    objects). Every one of the 41 measured keys takes its call site's inline
+    `defaultValue` **byte for byte** (46/47 sites, script-compared), so the pack
+    path and the inline-default path cannot diverge.
+
+    - The one site that cannot match is `ChatDock.tsx:563`, where a single key
+      (`console.ai.dock.open`) carries two different English strings: the
+      `aria-label` says `Open assistant` and the `title` says
+      `Open assistant (⌘⇧I)`. A key can hold one value, so `en` takes the
+      `aria-label` spelling — an accessible name must not carry a glyph run that
+      screen readers announce as symbols, and `⌘` is a mac-only glyph that a
+      _language_ pack cannot vary per platform. The tooltip therefore stops
+      advertising the shortcut; recorded on objectui#3810 (whose class this
+      divergence joins) rather than papered over.
+
+  - **`console.ai.group.` leaves the ratchet's `missingPrefixes` (4 → 3).** It is a
+    template key — `` t(`console.ai.group.${group.key}`) `` in
+    `ConversationsSidebar.tsx:277` — whose static head matched no `en` key, so every
+    expansion missed. Its value surface is the **closed** `ConversationGroupKey`
+    union, so the repair is an enumeration of all five members, not a wildcard; a
+    test reads the component's own union and label map and fails if a sixth bucket
+    is ever added without a key.
+
+  - **The nine other packs** get real translations, each evidenced against its own
+    `console` neighbours: `zh` full-width punctuation and the pack's single-em-dash
+    status-line style, `ja`/`ko` the pack's `AI ` spacing, `de` formal _Sie_ and
+    its `Wird …` progressive, `fr` straight apostrophes, `es` _usted_ (as the
+    `console.ai` neighbourhood already uses), `pt` the pack's `off-line` spelling,
+    `ru` ё orthography, `ar` verb-first phrasing that never opens an RTL sentence
+    with a Latin token. Where `en` repeats a string the packs already translate
+    (`Go back`, `Publish failed`, `Try again`, `Back to home`, `Assistant`,
+    `Today`, `Yesterday`), the existing neighbour's wording is reused rather than
+    re-invented.
+
+  - **`scripts/i18n-call-site-key-baseline.json`** shrinks by exactly 42 entries
+    (41 keys + 1 prefix family): 109 → 68 keys, 4 → 3 prefixes.
+
+  No component changed: an AST sweep of all 308 `console.*` call sites in the repo
+  found zero dead `t(key) || 'English'` fallbacks among this slice's keys.
+
+- 69becd2: `de` approvals inbox no longer shows two quote typographies on one screen
+
+  Three `approvalsInbox` values quoted the record title with ASCII straight quotes
+  on **both** sides while their own sibling `approvalsInbox.approveOneTitle` used
+  the correct German pair (U+201E low-9 opener, U+201C closer):
+
+  | key                             | before                  | after                   |
+  | ------------------------------- | ----------------------- | ----------------------- |
+  | `approvalsInbox.rejectOneTitle` | `"{{title}}" ablehnen?` | `„{{title}}“ ablehnen?` |
+  | `approvalsInbox.inlineApproved` | `"{{title}}" genehmigt` | `„{{title}}“ genehmigt` |
+  | `approvalsInbox.inlineRejected` | `"{{title}}" abgelehnt` | `„{{title}}“ abgelehnt` |
+
+  A German approver therefore met both typographies in a single screen and inside a
+  single operation pair — German quotes on the approve confirmation, typewriter
+  quotes on the reject confirmation and on both inline toasts. `„…“` is the pack's
+  own majority (50 paired spans) and DUDEN R11, so the three values were the
+  outlier. Keys and the `{{title}}` placeholder are unchanged; this is a
+  value-domain typography fix, and `en` (ASCII on both sides by design) is
+  untouched.
+
+  This is a **different defect shape** from objectui#3876, which paired a German
+  opener with an ASCII closer. Because these three were ASCII on both sides they
+  were self-consistent, so the pairing invariant objectui#3876 left behind could
+  not see them — it scans forward from each `„`, and there was no `„` in them to
+  scan from. The pack's straight-quote census being empty now lets that pin become
+  strictly stronger: `de-quote-pairing-3876.test.ts` asserted an explicit
+  three-key allowlist and now asserts that **no `de` value holds a U+0022 at all**,
+  which covers both defect shapes and needs no per-key maintenance as new values
+  land. The pack census moves from `„` 47 / `“` 47 / `”` 0 / `"` 6 to
+  `„` 50 / `“` 50 / `”` 0 / `"` 0.
+
+  None of the three i18n gates could have caught this: `all-locales-key-parity`
+  compares key sets and placeholder shapes, `check-i18n-call-site-keys.mjs` only
+  asks whether a key resolves, and `check-i18n-en-drift.mjs` fires on `en` value
+  changes — these values were wrong from the day they landed, so no drift event
+  ever existed. All three are value-blind by design, which is why the invariant
+  lives in a test.
+
+- 5e52495: German pack: the 20 values that closed the German opening quote with an ASCII straight quote now close it with `“`
+
+  `packages/i18n/src/locales/de.ts` opened a quoted span with the German low-9
+  quote `„` (U+201E) and closed it with the ASCII typewriter quote `"` (U+0022) in
+  20 keys, so a German user read `Registerkarte „Alle Datensätze" anzeigen` — a
+  mismatched pair. `search.resultsCount` showed it most plainly: the value ended
+  `„{{query}}""`, the mismatched closer immediately followed by the TS string
+  terminator.
+
+  This was never a pack convention. Measured on `main@2937bcf7d` before the fix,
+  the same file already spelled 23 spans the correct German way, `„…“` — the two
+  styles sat side by side, in sibling keys of the same namespace. Every mismatched
+  closer is now `“` (U+201C), which is what German orthography (DUDEN R11) and the
+  majority of the file already used. Affected surfaces: the four empty states
+  (object / page / dashboard / report not found), the search results header, the
+  lookup "create named" action, four `console.objectView` strings, the home
+  getting-started hint, the six `navigationSync` toasts, the local marketplace
+  install toast, and the preview not-ready title.
+
+  No other language pack and no `en` value changed — the counts are unchanged for
+  every other locale, and the mismatch was measured only in `de`.
+
+  ### Counted at landing, in two units
+
+  The card reported "20 values" and the triage re-scan reported "22 mismatched
+  pairs"; both are correct about different units, and the difference is now
+  recorded rather than left to the next reader. 20 keys carried a mismatch;
+  22 mismatch occurrences lived in them, because `navigationSync.renamedPage` and
+  `navigationSync.renamedDashboard` each quote two names in one sentence
+  ("Seite „alt“ in „neu“ umbenannt") and so contribute two each. Full-file counts
+  before → after: `„` 45 → 45, `“` 25 → 47, `”` 2 → 2, `"` 28 → 6.
+
+  ### The durable half, and why it is not the count equality the card proposed
+
+  Three i18n gates run over these packs and none can see a wrong quote:
+  `all-locales-key-parity` compares key sets and placeholder shapes,
+  `check-i18n-call-site-keys.mjs` only asks whether a key resolves, and
+  `check-i18n-en-drift.mjs` fires on `en` **value changes** — these values were
+  wrong from the day they landed, so no drift event ever existed. Without a
+  value-domain assertion the next backfill copies the mismatch from a neighbour
+  again, which is exactly how these 20 accumulated.
+
+  The card proposed asserting `count(„) === count(“)`. That is **false on the
+  correctly fixed file** (45 vs 47) and would have sent the next reader hunting a
+  bug that is not there: two values in this pack, `grid.import.savedMappingHint`
+  and `grid.import.savedMappingPreviewNote`, are still untranslated English prose
+  and quote in the English style `“…”`, so their two `“` are legitimate _openers_.
+  The invariant that is pinned instead is the pairing itself — for every `„`, the
+  first quote character that follows must be `“` — backed by the arithmetic
+  identity `count(“) === count(„) + count(”)`, which stays true if those two values
+  are later translated (47 === 47 + 0) and breaks the moment a mismatch returns.
+  Both carry a presence guard so a broken import cannot make them pass by scanning
+  nothing.
+
+- b750823: `preview.draftBar` speaks one second person in `es` — the draft-preview banner no
+  longer switches from tú to usted when a Spanish user publishes (#3844)
+
+  `DraftPreviewBar` renders two mutually exclusive sentences in the same strip of
+  the same banner: `message` while there are unpublished changes, `messageClean`
+  once there are none. In `es` the two disagreed on register — `message` was tú
+  (`estás viendo`, `publiques`) while `messageClean` (`ve`) and `sampleDataBody`
+  (`Está`, `su`, `Publíquela`) were usted. So a Spanish user who pressed Publish
+  watched the banner change person: same component, same position, same session.
+
+  This is a third defect class in the value-domain blind spot behind #3582 and
+  #3625, and no gate in the repo can see it. Both `es` values are correct
+  translations of their `en` sentences — nothing is missing, nothing is stale, and
+  nothing holds English. The inconsistency is _internal to one pack, on one UI
+  surface_: `scripts/check-i18n-call-site-keys.mjs` only asks whether a key exists
+  in `en`, `all-locales-key-parity` compares key sets and placeholder shapes and
+  never reads values, and `scripts/check-i18n-en-drift.mjs` only fires when an `en`
+  value moves — these two `en` values never moved.
+
+  `message` is the value that changes, because usted is what the pack already says
+  everywhere around it: the `es` pack censuses 102 usted markers to 30 tú (tú being
+  the marked exception, concentrated in the auth, report-editor and organizations
+  neighbourhoods that #3546 slice two deliberately ruled informal); the other three
+  strings of this same object were already usted; and #3546 slice five gave the 19
+  new `preview.unpublishedBar.*` / `preview.history.*` keys usted on the strength
+  of `home.pendingDrafts.published` ("¡Publicado! Sus cambios están activos."). Two
+  smaller divergences inside the same sentence are closed with it, so the banner's
+  two halves stop disagreeing about wording as well as person:
+
+  - **`—` instead of `:`** in `messageClean`, matching `en`, where both sentences
+    open `Draft preview — `. That is the whole of `messageClean`'s diff.
+  - **`activo` instead of `en producción`** for "live". The pack spells this concept
+    `activo` in four neighbouring places including `publishCta` in this very object
+    ("Publicar para verlo activo"), and it reserves _producción_ for the actual
+    production environment (`environment.entitlement.planLockedBody`), so the
+    outlier was ambiguous as well as inconsistent.
+  - **`Vista previa del borrador`** as the shared opening, `del` being the form
+    `messageClean` already used.
+
+  No `en` value changes (the en-drift gate reports 0), no key is added or removed
+  (so `all-locales-key-parity` is untouched by construction), and the nine other
+  packs are not touched. The diff is two values in one file.
+
+  Re-voicing the whole `preview` namespace to tú was considered and rejected — a
+  much larger change that would collide with the adjacent `marketplace.*` (9:0
+  usted) and `console.ai.*`. `preview.empty.notReadyDescription` therefore stays tú
+  here, since #3844's ruling is this banner only; it is filed as #3875 rather than
+  waved through, because `PreviewDraftEmptyState` renders _underneath_
+  `DraftPreviewBar` and so those two show usted and tú on screen at the same time.
+  After this change the `preview` namespace is 23 usted to that 1 tú.
+
+  A gate that checks "one register per namespace" is deliberately **not** here:
+  recognising usted vs tú needs real morphology, and token matching demonstrably
+  cannot — in this pack the token `revisa` is usted in `console.ai.empty.build`
+  (es.ts:1365, "…y usted revisa y publica.") and tú in
+  `auth.forgotPassword.successTitle` (es.ts:1918, "Revisa tu correo electrónico"),
+  the same eight letters in opposite registers. The neighbourhood boundary such a
+  gate would police is human judgement anyway — #3546 slice two's "same rule,
+  different answer". A new `draftBar-es-register-3844.test.ts` pins the four `es`
+  values byte for byte instead, plus the `en` literals, so a future reword of
+  either `en` sentence fails in the same PR that reworded it.
+
+- ac2139c: `grid.import` saved-mapping copy is now translated in ko / de / fr / es / pt / ru / ar instead of served as English
+
+  Five keys — `grid.import.savedMapping`, `chooseSavedMapping`, `manualMapping`,
+  `savedMappingHint` and `savedMappingPreviewNote` — were **byte-identical to `en`**
+  in seven of the nine non-`en` packs, 35 values in all. Only zh and ja had been
+  translated, and two of the five are multi-clause explanatory sentences rather
+  than placeholders or proper nouns, so this was not a deliberately untranslated
+  term: a German, French, Spanish, Portuguese, Russian, Korean or Arabic user
+  picking a saved mapping in the import wizard read English.
+
+  None of the three i18n gates could see it. `all-locales-key-parity` compares key
+  sets and placeholder shapes, so English passed perfectly; the call-site gate only
+  asks whether a key resolves; `check-i18n-en-drift.mjs` fires on an `en` **value
+  change** and these keys arrived in the packs already English, so no drift event
+  ever existed. objectui#3920 also proposed a general "no non-`en` value may be
+  byte-equal to `en`" gate; that is deliberately not part of this change, because
+  values like `auth.*.emailPlaceholder` (`name@example.com`),
+  `fields.image.counter` (`{{current}} / {{total}}`) and
+  `grid.import.templateFileName` are byte-equal across packs correctly, and
+  objectui#3880 records the other face of the family. The five keys are pinned by
+  name instead.
+
+  Each translation reuses vocabulary its own pack already ships rather than
+  inventing a second word for the same concept: `stepMapping` for "mapping"
+  (Zuordnung / Correspondance / Asignación / Mapeamento / Сопоставление / تعيين /
+  매핑), `legacyFallbackNotice` for "type coercion" (Typkonvertierung / conversion
+  de type / conversión de tipos / conversão de tipos / приведение типов / تحويل
+  الأنواع / 형 변환), `view.readonlyTooltip` for "read-only", and `validateHint`
+  for "on the server". `es` follows the usted ruling objectui#3844 measured for
+  this pack; `pt` is the pack's own pt-BR (mapeamento / salvo / no servidor);
+  `ru` keeps its ё; `fr` keeps the straight apostrophe and the space before colon
+  and semicolon; `ar` punctuates with U+060C and U+061B; `ko` uses the 은(는) /
+  이(가) spelling its `fields.file.exceedsMaxSize` already uses for a placeholder
+  whose particle cannot be resolved at authoring time.
+
+  The quote around `{{name}}` follows each pack's measured majority for wrapping a
+  placeholder — de `„…“` (38 spans against 3 ASCII), fr `« … »` with an ASCII
+  space (25 against 18), ru `«…»` (23 against 18), and ASCII `"…"` for ko (38:0),
+  pt (39:0), es (22:19) and ar (27:15). The card cited
+  `residue-namespaces-3546.test.tsx` as pinning "the rest ASCII", but that line
+  pins the `empty.*` family only and its own comment scopes the rule to "the
+  sibling value in the SAME pack"; `grid.import` has no other quoted span, so the
+  census one ring out decides.
+
+  Germanising the two `de` sentences also closes the 45/47 gap
+  `de-quote-pairing-3876.test.ts` documented: that pack's census moves from
+  `„` 45 / `“` 47 / `”` 2 to `„` 47 / `“` 47 / `”` 0, exactly as that file's header
+  predicted, and its `count(“) === count(„) + count(”)` identity still holds. The
+  three literal counts in it were updated and the two keys are now pinned by name
+  there, so `rdqKeys === []` cannot become an assertion that passes because nothing
+  is produced.
+
+  `en`, `zh` and `ja` are untouched, and `grid.import.transform` — the sixth key in
+  the same block, English in the same seven packs, and the third column header of
+  the very table this hint sits above — is deliberately left alone, filed as
+  objectui#3938 and pinned as still-English so the number cannot drift while that
+  issue waits its turn.
+
+- b14ab3a: `grid.import.transform` is now translated in ko / de / fr / es / pt / ru / ar instead of served as English
+
+  The third column header of the import wizard's saved-mapping summary was
+  **byte-identical to `en`** — the literal string `Transform` — in seven of the
+  nine non-`en` packs. zh (`转换`) and ja (`変換`) had translated it, which is what
+  rules out the "deliberately untranslated term" reading; this is the sixth key of
+  the same six-line block objectui#3920 / PR #3936 fixed the other five of, and it
+  was left out of that card only to keep its 5-keys / 35-values census verifiable.
+
+  | pack | before      | after            | the pack's own anchor                                                                    |
+  | ---- | ----------- | ---------------- | ---------------------------------------------------------------------------------------- |
+  | ko   | `Transform` | `변환`           | `savedMappingHint` "이름 변경 + 변환 + 형 변환"                                          |
+  | de   | `Transform` | `Transformation` | `savedMappingHint` "Umbenennung + Transformationen + Typkonvertierung"                   |
+  | fr   | `Transform` | `Transformation` | `savedMappingHint` "le renommage + les transformations + la conversion de type"          |
+  | es   | `Transform` | `Transformación` | `savedMappingHint` "el cambio de nombre + las transformaciones + la conversión de tipos" |
+  | pt   | `Transform` | `Transformação`  | `savedMappingHint` "renomeação + transformações + conversão de tipos"                    |
+  | ru   | `Transform` | `Преобразование` | `savedMappingHint` "переименование + преобразования + приведение типов"                  |
+  | ar   | `Transform` | `التحويل`        | `savedMappingHint` "إعادة التسمية + التحويلات + تحويل الأنواع"                           |
+
+  Each value is the **singular of the word the pack already uses** for `en`'s
+  plural "transforms" in `grid.import.savedMappingHint` — the sentence
+  `SavedMappingSummary` renders directly above this header. That is the anchor
+  rather than `legacyFallbackNotice`'s term, because `en`'s own sentence lists
+  "transforms" and "type coercion" as two different server-side operations and
+  `legacyFallbackNotice` is about the second: reusing de "Typkonvertierung", ko
+  "형 변환" or ar "تحويل الأنواع" for this header would name the wrong operation.
+
+  Why it was worth a card of its own rather than waiting for a general gate: this
+  value is not a hidden string. It is the third `TableHead` of
+  `SavedMappingSummary`, sitting in one row with `csvColumn` and `mapsTo`, which
+  were always translated — so a German user read `Spalte` / `Zugeordnet zu` /
+  `Transform`, two languages in a single header row, directly under the German
+  hint PR #3936 had just landed. Before that PR the whole panel was English and
+  therefore at least self-consistent.
+
+  The three i18n gates are value-blind here exactly as they were for
+  objectui#3920: `all-locales-key-parity` compares key sets and placeholder shapes
+  (the key was present with no placeholder, so English passed perfectly), the
+  call-site gate only asks whether a key resolves, and `check-i18n-en-drift.mjs`
+  fires on an `en` **value change** — this value entered the seven packs already
+  English, so no drift event ever existed. `en`, zh and ja are untouched, and the
+  pin PR #3936 left in `gridImportSavedMapping-i18n-3920.test.ts` asserting these
+  seven were "still English" has been replaced by the translated pin it asked for.
+
+- 8c60819: The inbox popover now spells out what the bell badge is made of
+
+  The bell badge is `unread notification topics + pending approvals`, clamped to
+  "9+" above nine. As one number it is unexplainable: objectstack#7213 measured
+  Home's "pending approvals" card saying 8 while the bell said "9+", and read that
+  as the two counts disagreeing — they never did, the bell was simply carrying a
+  second addend the user could not see.
+
+  The popover already tabs the two streams and puts a count pill on each tab, so
+  the split was partly visible — but those pills clamp at "9+" too. A loaded
+  console therefore showed three "9+"s that reconcile to nothing, which is why
+  sectioning alone did not close this.
+
+  A breakdown line under the popover header now states the exact, unclamped
+  addends beside the exact total — `15 total · 12 notifications + 3 pending
+approvals`. The approvals half is the same `pendingApprovalsCount` the Home card
+  and the Approvals Inbox tab read, so the number a user reconciles against is
+  literally the one they see elsewhere.
+
+  The badge formula, the counting APIs and the "9+" clamp on the badge itself are
+  unchanged — this is a display fix. Three new keys
+  (`notifications.badgeTotal` / `badgeNotifications` / `badgeApprovals`) land in
+  all ten locale packs. They interpolate named placeholders (`{{total}}`,
+  `{{unread}}`, `{{approvals}}`) rather than i18next's `{{count}}`, which would
+  additionally drive plural-key resolution these packs carry no forms for.
+
+- e64a52e: 回填 `perm` + `home` 两命名空间 14 个缺失语言 key,十个语言包补齐(#3546 切片六)
+
+  `scripts/check-i18n-call-site-keys.mjs` 实测:14 个不重复 key / 14 个调用点(1:1),分布在权限集
+  记录的授权面摘要(`PermissionFacetLink`,ADR-0056 P1)与"一键发布全部草稿"的其余几条 toast
+  (`usePublishAllDrafts`:ADR-0038 L3 探针健康、示例数据健康、ADR-0066 ⑨ 能力引用巡检)。
+
+  这 14 处都带内联 `defaultValue`,所以英文一直正常渲染,**十种语言都翻不了** —— 修的是这一半。
+  英文字串一字未改:9 处静态 `defaultValue` 与 en 逐字节相同;另外 4 个计数标签(对象 / 字段规则 /
+  RLS 策略 / 标签页规则)的 `defaultValue` 是带英文单复数分支的模板串,改用 i18next 复数族
+  (`key` + `key_one`)后逐个计数渲染结果与模板串一致。
+
+  复数族刻意带**基础 key** 而不是只写 `_one`/`_other`:i18next 只按语言的 CLDR 类别取一个后缀,
+  取不到就沿 fallback 链落到 `en`。ru(few 2-4、many 5-20)与 ar(two、few 3-10、many 11-99)
+  恰好在用户最先遇到的计数上会因此显示英文;基础 key 让这些类别落回**本语言**。
+
+- 844d17f: Backfill the `marketplace` and `preview` namespaces' 37 missing locale keys plus the `marketplace.disclosure.runtime.` template-key family (objectui#3546, slice five)
+
+  `scripts/check-i18n-call-site-keys.mjs` (objectui#3530) measured 37 keys that a
+  `t()` call site asks for and that **no locale pack defined** — 37 distinct keys at
+  37 call sites across five console components — plus one `missing-prefix` family
+  whose static head matched no `en` key at all, so every expansion missed. All 37
+  carried an inline `t(key, { defaultValue: 'English' })`, which is exactly the
+  objectui#3517 class: English rendered correctly, and **all ten languages were
+  stuck on it** for months. Nothing here rendered a raw key — slice one (PR #3583)
+  held those sites.
+
+  What that meant on the page for a `zh` (or `ja`, `de`, `ar`, …) user: the
+  marketplace's "Your organization" strip, its Install / Installing… / Installed
+  buttons and the version-update affordances were English; the whole ADR-0025 PD4
+  **pre-install permission disclosure** was English — "This package contains code",
+  the trust-tier badge, "Reviewed & approved" / "Not yet reviewed" / "Signed", the
+  four permission group labels (platform services, lifecycle hooks, network,
+  filesystem) and the consent checkbox the user ticks to accept them; the ADR-0045
+  unpublished-app banner and its publish toasts were English; and the entire
+  ADR-0067 build-history sheet — title, description, the per-commit labels, the
+  Revert button and both of its result toasts — was English.
+
+  `marketplace.disclosure.runtime.` is repaired as an **enumeration, not a
+  wildcard**: its value surface is the closed trust-tier enum
+  (`PluginRuntimeSchema` = `z.enum(['node', 'sandbox', 'worker'])`, ADR-0025 §3.6),
+  so all three members are backfilled and the family leaves the ratchet's
+  `missingPrefixes` (3 → 2). A test reads the component's own fallback map and
+  fails if a fourth tier is ever added without a key — the job the prefix entry
+  used to do.
+
+  Each `en` value is byte-identical to the inline `defaultValue` it replaces (36 of
+  36 literal sites; the 37th's `defaultValue` is a template literal whose
+  `${pkg.display_name}` becomes the `{{name}}` hole its call site already passes),
+  so no English string a user sees today changes. The nine translations follow each
+  pack's own neighbourhood — including two namespaces that legitimately take
+  **different** second persons in `zh` (`marketplace` 你, `preview` 您) — and reuse
+  an existing neighbour's translation wherever the `en` string already existed
+  verbatim, so one English string never renders as two different sentences in the
+  same language.
+
+  No component changed: an AST sweep of the whole `marketplace.*`/`preview.*`
+  call-site surface found the slice's own dead-`||`-fallback count to be zero.
+
+- 4dcd52a: `console.objectView.systemViewReadonly` and `console.objectView.expandToPage`
+  are translated in the eight packs that stored English for them, so a Japanese,
+  Korean, German, French, Spanish, Portuguese, Russian or Arabic session reads
+  the system-view hint and the expand affordance in its own language (#3582).
+
+  This is a different defect class from #3546's ledger, and no gate in the repo
+  could see it. There the key was _missing_ from a pack and `fallbackLng: 'en'`
+  rendered English; here the key was **present in all ten** and eight of them
+  stored English as the value. `all-locales-key-parity` compares key _sets_ and
+  placeholder _shape_ — identical before and after this change, and neither key
+  interpolates anything. `scripts/check-i18n-call-site-keys.mjs` and its baseline
+  ratchet ask whether a `t()` key exists in `en`; it did, so these two were never
+  in the 258.
+
+  `systemViewReadonly` carried the sharper half: the eight packs did not hold
+  `en`'s sentence, they held one `en` had already abandoned. `en` says the view
+  is read-only; the eight said `System view defined in code - duplicate to
+customize.` — pointing eight locales at a duplicate-to-customize path the
+  product no longer presents. They are translated against `en`'s **current**
+  read-only meaning, not against the stale English they replaced.
+
+  Each value is built from terminology the same pack already uses rather than
+  invented: `view.readonlyTooltip` supplies "system view" and
+  `console.objectView.cannotEditMetaView` (landed in #3583) supplies "defined in
+  code", so the new hint agrees with the copy beside it in every pack. For
+  `expandToPage`, `detail.openAsFullPage` is the identical English sentence one
+  namespace over and was already translated everywhere — `en` and `zh` hold their
+  two byte-identical to each other, so the eight now do too, and one locale
+  cannot end up with two different words for one action.
+
+  `en` and `zh` are unchanged, byte for byte. No key is added or removed —
+  the diff is 16 values in 8 files. A new
+  `objectView-value-language-3582.test.ts` pins the `en` literal (so the next
+  rewording of `en` fails loudly instead of silently orphaning nine
+  translations), asserts that no pack but `en` serves either English spelling,
+  and requires the zh/ja/ko/ru/ar values to contain characters of their own
+  script. The repo-wide "no ASCII English sentence in a non-Latin pack" gate that
+  #3582 also sketched is deliberately **not** here; it is a separate, lands-green
+  change.
+
+- 42ae5c6: The organization-management console is translatable. The 90 keys under
+  `organization.*` — the org layout and its tabs, the members list, the whole
+  invitation flow, organization settings including the leave and delete
+  confirmations, the accept-invitation page, and the workspace switcher — are now
+  defined in all ten locale packs, so a non-English session reads the org admin
+  surface in its own language instead of English (part of #3546).
+
+  `scripts/check-i18n-call-site-keys.mjs` measured 258 keys that a `t()` call site
+  asks for and no pack defines. `organization.*` was the largest namespace in that
+  tally at 90 keys across 93 call sites in seven components. Every one of them
+  carried an inline `t(key, { defaultValue: 'English' })`, which is why nothing
+  looked broken: English rendered correctly at each site and all ten languages
+  were pinned to it. That is the #3517 class, not the raw-key class slice one
+  (#3583) held — no organization site rendered an identifier, and none had a dead
+  `||` fallback to remove, which was measured before deciding not to touch the
+  components.
+
+  Adding a `defaultValue` is deliberately not the fix; it is the mechanism that
+  kept these invisible for months. The existing defaults stay where they are, and
+  each `en` value is byte-identical to the default at its call site so the two
+  paths cannot render different text.
+
+  `organization` is a new top-level namespace, sitting next to — and distinct
+  from — `organizations`: the singular one is the management surface, the plural
+  one the org picker. The ratchet in `scripts/i18n-call-site-key-baseline.json`
+  shrinks by exactly these 90 entries, from 253 to 163. The
+  `organization.invitations.status.*` template-key family is untouched and still
+  baselined: enumerating an invitation status set is a different repair from
+  backfilling literal keys.
+
+- 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.
+
+- f9faa7d: Backfill the last 17 missing locale keys and both remaining template-key families, emptying the call-site key ratchet (objectui#3546, slice seven — final)
+
+  `scripts/check-i18n-call-site-keys.mjs` (objectui#3530) opened this backlog with
+  **258 keys and 4 template-key families** that a `t()` call site asks for and that
+  **no locale pack defined**. Seven slices later the last of it is paid: this change
+  takes the ratchet from 17 keys to **zero** and from 2 prefix families to **zero**,
+  and the gate now reports every one of the **2320** literal call-site keys
+  resolving against `en`.
+
+  The residue was the long tail — nine namespaces across `app-shell`,
+  `plugin-detail`, `plugin-dashboard`, `plugin-kanban` and `plugin-gantt`, none of
+  them big enough to have been its own slice. 17 distinct keys at **23** call sites
+  (five keys are used at more than one site) plus **3** call sites behind the two
+  families.
+
+  What that meant on the page for a `zh` (or `ja`, `de`, `ar`, …) user: the "App not
+  available" empty state a user lands on when an app is still publishing, including
+  its whole explanation and its Retry button; the interface page's "source is not
+  available" message; the system navigation's **Administration** group header,
+  **Datasources** and **Documentation** entries; the "creating new organizations is
+  disabled on this instance" guard in the workspace dialog; the invitation list's
+  five status labels (All / Pending / Accepted / Rejected / Canceled) on both the
+  filter tabs and every invitation badge; the Gantt dependency-drag hint that names
+  which endpoint the drop will link (`start` / `end`); the record detail's Add,
+  "Record deleted", "No history yet" and the concurrent-update dialog's "this
+  record"; the kanban empty board's column count; the dashboard widget's screen
+  reader "Loading…"; and the page editor's "Edit in studio" tooltip and accessible
+  name. All of it rendered English, in every one of the ten languages.
+
+  Nothing here rendered a raw key — slice one (PR #3583) held those sites, and the
+  three keys the issue body named as unprotected (`detail.viewSource`,
+  `wizard.missingRequired`, `gantt.toolbar.refresh`) have resolved in `en` since.
+
+  Both families are repaired as **enumerations, not wildcards**, and the assertion
+  that used to live in the ratchet's `missingPrefixes` moves into a test that fails
+  if either union grows a member without a key:
+
+  - `gantt.linkEnd.` — the closed union `'start' | 'end'`, declared by GanttView's
+    own `linkDrag` state.
+  - `organization.invitations.status.` — `StatusFilter`
+    (`all | pending | accepted | rejected | canceled`), declared by InvitationsPage.
+
+  Every `en` value is byte-identical to the English the call site rendered before,
+  so no string a user sees today changes: 16 keys match an inline
+  `t(key, { defaultValue: … })`; `dashboard.loading` matches `useSafeTranslate`'s
+  positional fallback `tt(key, 'Loading…')`; `gantt.linkEnd.*` match
+  `useGanttTranslation`'s per-key fallback map; and the five status labels match the
+  CSS-capitalised wire value each badge and tab showed. The nine translations follow
+  each pack's own neighbourhood and reuse an existing neighbour's row wherever the
+  `en` string already existed verbatim **and** that row is grammatical here — the
+  four invitation adjectives are deliberately not reused from the approvals family,
+  because those agree with each pack's word for "request" (`ru` masculine `Отклонён`)
+  while an invitation needs its own agreement (`ru` neuter `Отклонено`).
+
+  `scripts/i18n-call-site-key-baseline.json` is kept rather than deleted: empty is
+  its terminal, load-bearing state — against an empty baseline any NEW unresolved
+  call-site key is unexpected and fails the build.
+
+  No component changed.
+
+- 33526fd: `view.readonlyTooltip` — the tooltip on a view tab's read-only lock — is
+  retranslated in the eight packs (ja/ko/de/fr/es/pt/ru/ar) that still described
+  the retired "duplicate to customize" workflow, so a Japanese, Korean, German,
+  French, Spanish, Portuguese, Russian or Arabic session is told the view is
+  defined in code and read-only, which is what `en` says and what the product
+  does (#3625).
+
+  This is the same stale sentence #3582 fixed one namespace over, but it hid
+  behind a much better disguise. In #3582 the eight packs stored the **English**
+  string, so two cheap criteria could see it: "value equals `en`" and "a
+  non-Latin pack holds pure ASCII". Neither can see this key. Its eight values
+  were **idiomatic translations** — real Japanese, real Cyrillic, real Arabic —
+  of a sentence `en` itself had already abandoned. Nothing about their form was
+  wrong; only their meaning was. Key sets were complete, so
+  `all-locales-key-parity` was green; the key exists in `en`, so the call-site
+  guard and its ratchet were green; the values are distinct and in their own
+  scripts, so every heuristic #3582 sketched would have been green too. Eight
+  locales spent those releases pointing users at a path the product no longer
+  offers, with every gate reporting success.
+
+  Each value is translated against `en`'s **current** meaning and built from
+  words the same pack already uses — "read-only" from its own `view.readOnly` /
+  `view.readonlyAriaLabel`, "defined in code" from
+  `console.objectView.systemViewReadonly` / `cannotEditMetaView` — so the tooltip
+  agrees with the copy beside it instead of introducing a ninth way to say
+  read-only. Nothing is rewritten from the stale text.
+
+  `en` and `zh` are unchanged, byte for byte, and no key is added or removed —
+  the diff is eight values in eight files. A new
+  `viewReadonlyTooltip-semantics-3625.test.ts` tests **meaning** rather than
+  form, in both directions: no pack may name the duplicate/copy workflow in its
+  own language, and every pack must positively carry all three pieces of the
+  sentence ("system view", "defined in code", "read-only") so the negative check
+  cannot pass on a gutted string. It also pins the `en` literal, so the next
+  rewording of `en` fails in the PR that does the rewording rather than orphaning
+  nine translations for another release — which is the invariant this family of
+  defects has actually been missing.
+
+- 32413ec: Resolve `_views` translation keys by the bare view name only — the prefixed full name is no longer a second candidate
+
+  `useObjectLabel().viewLabel` / `viewDescription` / `viewEmptyState` build their key by stripping the object prefix off the runtime view id (`crm_opportunity.pipeline_kanban` → `objects.crm_opportunity._views.pipeline_kanban.<tail>`). Until now, if that bare key missed, the resolver **also** tried the prefixed full name — `objects.crm_opportunity._views.crm_opportunity.pipeline_kanban.<tail>` — so a bundle authored against the prefixed spelling resolved too.
+
+  **Behavior change:** it no longer does. A `_views` entry keyed by the prefixed full name is not read at all; the label falls back to the metadata default, exactly as it would if no translation had been written. Bundles keyed by the bare view name — the only spelling the extractor emits and `os lint` accepts — are unaffected.
+
+  This closes an asymmetry, not a feature. The server-side resolver reads the one bare key (objectstack#5165), so a prefixed-key bundle produced a **translated label in the Console and English everywhere else**: the REST boundary, mobile, plain HTTP and SDUI consumers do not run this second resolution pass. The half-success was harder to notice than a clean miss, and it fossilized a second de-facto spelling of a key the platform has now converged on: per the objectstack#5164 ruling (2026-08-06, option A), the canonical `_views` key is the runtime view identity's bare name, with the i18n extractor deriving it from the view composer (objectstack#6124) and `packages/lint` enforcing that single spelling (objectstack#6038). This is the third and last leg of that convergence.
+
+  The object-name axis is untouched: a bundle written against the short object name (`objects.opportunity._views.…`) still resolves when the runtime presents the namespaced name (`crm__opportunity`).
+
+  **If a label stopped translating after this upgrade,** its `_views` key is written with the object prefix. Drop the prefix — `_views.crm_opportunity.pipeline_kanban.label` becomes `_views.pipeline_kanban.label`. `os lint` names these for you: a prefixed key is reported as `translation-target-unknown`, because no view of the object declares it.
+
 ## 17.3.0
 
 ### Minor Changes
@@ -249,6 +2158,7 @@ first`. The form renderer passes a new `dependsOnLabels` widget prop (the
   ten packs missing it identically kept parity fully green.
 
   ## What changed
+
   - `createTargetOrg` is backfilled into `en` as `Creates in {{org}}`, which makes
     the parity gate demand it from the other nine; each is translated to its pack's
     existing `form`-section tone rather than copied or machine-filled.
@@ -711,7 +2621,7 @@ plan` sentence users reported (cloud#959). Both spec builders now take a transla
 
 ### Patch Changes
 
-- 752e18f: fix(console,app-shell): readable reassign hand-off + "System" label for svc:* audit actors — objectstack#4365 / objectstack#4366
+- 752e18f: fix(console,app-shell): readable reassign hand-off + "System" label for svc:\* audit actors — objectstack#4365 / objectstack#4366
 
   - **Approvals inbox** (`ApprovalsInboxPage`): a reassign timeline entry now
     renders "from A to B" from the structured
@@ -1423,6 +3333,7 @@ os_tianshun_ehr_position — use a unique value or the record id` — with the f
   is byte-identical, it just comes from the pack now.
 
   Adds two guards, both mutation-verified:
+
   - `en` ↔ `zh` full key parity, asserted in both directions. The other eight
     packs are still ~357 keys behind and are tracked separately (objectui#2872
     part a), so they are deliberately not asserted yet.
@@ -2357,6 +4268,7 @@ actionName, spec)`: overlays translated `title` / `description` /
   wired by `RecentItemsProvider` + `useTrackRouteAsRecent` +
   `RecordDetailView`). Multi-device by construction: open a record on
   laptop, see it in `⌘K → Recently viewed` on phone.
+
   - Group renders only when input is empty (no competition with search).
   - Limited to the 5 most recent record-type entries.
   - New i18n key `console.commandPalette.recentRecords` (en + zh seeded;
@@ -2366,6 +4278,7 @@ actionName, spec)`: overlays translated `title` / `description` /
 
   When `useRecordSearch` is mid-flight (debounced fetch across objects
   hasn't returned yet), the palette now surfaces a subtle visual:
+
   - A small pulsing primary-coloured dot next to the **Records** group
     heading, so the user sees that more results may still appear.
   - A `Searching…` placeholder inside the empty state when the user has
@@ -2379,6 +4292,7 @@ actionName, spec)`: overlays translated `title` / `description` /
   - 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
@@ -2410,6 +4324,7 @@ actionName, spec)`: overlays translated `title` / `description` /
   `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`
@@ -2433,6 +4348,7 @@ actionName, spec)`: overlays translated `title` / `description` /
 ### Minor Changes
 
 - 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.
@@ -2498,6 +4414,7 @@ actionName, spec)`: overlays translated `title` / `description` /
   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,
@@ -2553,6 +4470,7 @@ actionName, spec)`: overlays translated `title` / `description` /
   The matrix/summary "Group by" (rows) and "Columns axis" (cols) sections now
   share the same searchable popup picker as the columns section, with a
   commit-on-select single-pick mode wired through `FieldPickerDialog`.
+
   - Per-row field buttons display the human-readable field label and open a
     dialog scoped to swap that single field (already-used fields filtered out)
   - "Add grouping" trigger uses the same dialog
@@ -2562,6 +4480,7 @@ actionName, spec)`: overlays translated `title` / `description` /
   - Bigger row spacing (h-7 / text-xs) — the old `text-[10px]` was unreadable
 
   `FieldPickerDialog` gains:
+
   - `commitOnSelect`: hides the Confirm/Cancel footer; clicking a row commits
     - closes immediately (intended for `singleSelect` flows)
   - `trigger`: custom trigger element override (used by the per-row field button)
@@ -2590,6 +4509,7 @@ actionName, spec)`: overlays translated `title` / `description` /
   in the spec.
 
   New exports from `@object-ui/plugin-report`:
+
   - `JoinedBlocksEditor` — standalone component for embedding the
     block editor anywhere.
   - `validateJoinedBlocks` — pure helper returning translated
@@ -2621,6 +4541,7 @@ actionName, spec)`: overlays translated `title` / `description` /
   The report configuration panel is now safe to open on any spec-shape `Report` and only exposes fields that are actually persisted by `@objectstack/spec`.
 
   `@object-ui/plugin-report`:
+
   - Add a bidirectional `SpecFilterAdapter` so `ReportConfigPanel` can edit
     spec `FilterCondition` filters (`{field: value}`, `{field: {$op: value}}`,
     top-level `$and`/`$or`). Complex / nested filters fall back to a
@@ -2642,12 +4563,14 @@ actionName, spec)`: overlays translated `title` / `description` /
   - 18 new unit tests cover the filter adapter round-trip.
 
   `@object-ui/components`:
+
   - `FilterBuilder` now guards against malformed external `value` props.
     Previously a spec-shape filter (`{is_active: true}`) would crash the
     component on first render; the builder now falls back to an empty
     AND group whenever `value` is not a valid `FilterGroup`.
 
   `@object-ui/i18n`:
+
   - Add `report.editor.*` strings to `en` and `zh`.
 
 - 8442c05: Improve report editor panel usability based on real-user browser testing:
@@ -2727,6 +4650,7 @@ actionName, spec)`: overlays translated `title` / `description` /
   no visible effect — the user/session were nulled but the UI stayed authenticated.
 
   Changes:
+
   - **`@object-ui/auth`** — added `isAuthEnabled: boolean` to `AuthContextValue`
     (`true` only when real auth is in use, `false` for guest/preview modes).
   - **`@object-ui/app-shell`** — `AppHeader` and `AppSidebar` now hide the "Log out"
@@ -2744,6 +4668,7 @@ actionName, spec)`: overlays translated `title` / `description` /
 - fd15918: Comprehensive i18n refactor + CI test fix.
 
   **i18n (`@object-ui/i18n`)**
+
   - Added ~130 new keys under 12 new top-level namespaces: `layout`, `search`,
     `empty`, `renderer`, `actionDialog`, `rowAction`, `navigationSync`,
     `objectActions`, `objectViewActions`, `dashboardActions`, `recordDetail`,
@@ -2755,6 +4680,7 @@ actionName, spec)`: overlays translated `title` / `description` /
 
   **App shell (`@object-ui/app-shell`)** — replaced hardcoded English in 14
   files with `useObjectTranslation`:
+
   - Layout: `AppSidebar`, `ActivityFeed` (locale-aware relative time),
     `MetadataInspector`.
   - Views: `SearchResultsPage`, `ActionParamDialog`, `RecordFormPage`,
@@ -2766,12 +4692,14 @@ actionName, spec)`: overlays translated `title` / `description` /
     `useObjectActions` (delete confirm + success / failure toasts).
 
   **Plugin grid (`@object-ui/plugin-grid`)**
+
   - `ObjectGrid` record-detail panel now translates Empty / Yes / No / System
     via the existing `useGridTranslation` safe-fallback wrapper.
   - `RowActionMenu` adopts a local safe-fallback i18n wrapper for
     `Open menu` / `Edit` / `Delete`, preserving standalone-usage guarantees.
 
   **CLI test fix (`@object-ui/cli`)**
+
   - `cli-bin.test.ts` auto-builds the package on first run when `dist/cli.js`
     is missing, instead of throwing. This unbreaks `pnpm test:coverage` in CI
     (root vitest run does not honor turbo's `^build` deps) and removes the