diff --git a/.changeset/3719-settings-valuedomain-combobox.md b/.changeset/3719-settings-valuedomain-combobox.md
deleted file mode 100644
index f39d01bbcc..0000000000
--- a/.changeset/3719-settings-valuedomain-combobox.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-'@object-ui/console': patch
----
-
-Setup's settings selects now follow the specifier's `valueDomain` declaration instead of
-treating the curated `options` table as the domain (objectui#3719).
-
-Since objectstack#5712 / PR objectstack#6581 a settings specifier may declare
-`valueDomain` (`iana_time_zone` | `iso_4217_currency` | `iso_3166_alpha2`), and when it
-does the **standard's membership is the enforcement boundary** — the server accepts
-`timezone: 'Europe/Zurich'` and `currency: 'CHF'`, neither of which is in the manifest's
-list. The console kept drawing those keys as closed dropdowns, so an admin could author
-only the 17 curated zones and 9 curated currencies while the contract took the whole
-domain; every other legal value was reachable by API or `OS_LOCALIZATION_*` env only. The
-keys' own descriptions had promised "IANA zone" / "ISO 4217 code" all along.
-
-`case 'select'` in `SettingsField` now keys the control off the declaration. Declared →
-an editable combobox: the curated options stay on as suggestions (native `<datalist>`, the
-same suggest-but-allow-anything affordance `FlowReferenceField` uses — no new dependency),
-free text is committed verbatim, and an out-of-domain value is refused by the server with
-`invalid_value` + `constraint: { valueDomain }` into the field-error slot that already
-exists.
-
-**Undeclared → the closed dropdown is untouched**, which is half the change rather than a
-caveat. Those `options` are still exhaustive under objectstack#5131 (the sms/mail provider
-selects), and `localization.locale` had its domain declaration deliberately **rejected** in
-objectstack#6515 because its options *are* the shipped catalogs. Widening those to free
-input would be a regression wearing this fix's clothes, so the two branches are pinned
-against each other from the specifier data rather than from a list of key names — a key
-that gains a domain server-side joins the right side of the pin with no edit here.
-
-Root cause, because it will recur: `Specifier` in `pages/settings/types.ts` is a
-hand-written **local mirror** of the server's shape, not an import, so nothing tells it when
-the schema grows — and TypeScript reports nothing, because a narrower mirror is a
-structurally valid reading of a wider object. `valueDomain` is added there and the file
-header now says to check the mirror first when a settings feature "doesn't render".
diff --git a/.changeset/3880-es-done-listo.md b/.changeset/3880-es-done-listo.md
deleted file mode 100644
index 032c5075e8..0000000000
--- a/.changeset/3880-es-done-listo.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-'@object-ui/i18n': patch
----
-
-The Spanish pack renders `Done` as `Listo` at every one of the four sites that say it
-(objectui#3880, triage adjudication 2026-08-09). `grid.bulk.done` — the footer button that
-dismisses the bulk-action result dialog — read `Hecho` while `common.done`, `view.done` and
-`form.fullscreen.done` all read `Listo`, so the same English word rendered two ways in
-Spanish across dialogs a user meets in one session.
-
-Adjudicated a typo rather than a deliberate contextual split, on three checks. All four
-keys hold the byte-identical `en` value `Done`, and all four call sites are the same
-control: a dialog-footer button whose click finishes or dismisses the surface
-(`BulkActionDialog` `onClose(result)`, `ManageViewsDialog` `onOpenChange(false)`,
-`fullscreen-editor` `commitFullscreen`, `InviteMemberDialog`'s invitation-created footer).
-The nine other packs each render all four identically (de `Fertig`, fr `Terminé`, pt
-`Concluído`, ru `Готово`, ja `完了`, ko `완료`, zh `完成`, ar `تم`), so no other translation
-pass had found a context worth splitting on. And the neighbouring `Hecho`/`Deshecho`
-pairing that could have justified it does not hold: `grid.bulk.undo` is the verb `Deshacer`,
-and `Deshecho: ` is `undonePrefix`, a result-line status rather than a button.
-
-`Hecho` moved to the 3:1 majority `Listo`, which is the value objectui#3546 slice seven had
-already chosen for `common.done`. `packages/i18n/src/__tests__/residue-namespaces-3546.test.tsx`
-pinned the old outlier as a recorded example of deliberate divergence; that pin now asserts
-the four as one value instead, and its note keeps the history plus the `Pending`/zh row,
-which remains a genuine deliberate split.
-
-No `en` value changes, so no other pack is asked to follow. This is the value half of
-objectui#3880 only — the card's 281/164 shared-string census stays on the card as
-documentation, and is explicitly not a gate: 164 of those groups diverge legitimately.
diff --git a/.changeset/3909-query-params-filter-union.md b/.changeset/3909-query-params-filter-union.md
deleted file mode 100644
index e17e77ec51..0000000000
--- a/.changeset/3909-query-params-filter-union.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-'@object-ui/types': patch
-'@object-ui/fields': patch
----
-
-`QueryParams.$filter` now declares both shapes the data sources actually accept — the
-MongoDB-style field-keyed record, or a `FilterArray`, the ObjectQL AST sugar bound from
-`@objectstack/spec/data` (objectui#3909).
-
-**Nothing is narrowed and no accepted value changes.** `Record<string, any>` already
-accepted arrays structurally — they satisfy its string index — so the union documents
-shapes that were always legal rather than admitting new ones. Measured both ways under
-`tsc --strict`: all five inputs `translateFilterToAST` enumerates assign to the old and
-new declarations alike, and both reject a bare number and a bare string identically. A
-downstream `turbo run build` over all 43 dependent packages is green, which is the
-evidence a published type change breaks no consumer.
-
-The harm was entirely on the type face, and it was two-sided. The declaration blocked
-nothing while describing one legal shape as though it were the only one — objectui#3831
-is what that cost, a rule array accepted by a `Record<string, any>` slot, object-spread
-flattened to `{"0": {...}}`, types green, and the query filtering on a column literally
-named `0`. And someone writing a new consumer would read the type and its record-only
-`@example`, conclude the array path was illegal, and add a tolerant conversion for it —
-the "widen the consumer to tolerate the producer" shape AGENTS.md #0.1 forbids. Two
-producers have fed arrays through this slot all along: `plugin-list`'s
-`buildEffectiveFilter` (grid and export) and `plugin-view`'s `ObjectView` (calendar /
-kanban / gallery / timeline). The runtime was right; the declaration was narrow.
-
-The array half is **bound** to the spec's `FilterArray` rather than restated locally, so
-it cannot fork from the vocabulary the servers parse — the same failure two hand-written
-operator lists had in objectui#3948. The doc comment names `translateFilterToAST` as the
-authoritative accepted set instead of carrying a second list to drift from.
-
-`@object-ui/fields` drops the local cast this defect forced. PR objectui#3908 wrote
-`filter as Record<string, any>` at one assignment in `useRecordQuery`, deliberately, as
-debt rather than widening the shared type. `hasFilter` is now a type predicate narrowing
-to the `$filter` slot's own type, so the assignment needs no cast and the guard cannot
-drift from the declaration it guards. Type-only throughout; no runtime behaviour changes.
diff --git a/.changeset/3917-retire-action-condition-branch.md b/.changeset/3917-retire-action-condition-branch.md
deleted file mode 100644
index 717b205f5b..0000000000
--- a/.changeset/3917-retire-action-condition-branch.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
-'@object-ui/types': minor
----
-
-Retire the `ActionCondition` `{ expression, then, else }` branch shape from
-`ActionSchema.condition` (objectui#3917, maintainer ruling 2026-08-09 route B,
-enforce-or-remove).
-
-`@object-ui/types` declared `condition` as a branch DSL — `expression` plus `then` /
-`else` sub-actions — and shipped a zod mirror (`ActionConditionSchema`) that accepted it.
-**Nothing ever read `expression`, `then` or `else`**: a repo-wide grep for
-`condition.expression|then|else` has zero non-test hits. The only consumer of the key is
-`ActionRunner.execute`, which reads it as a **predicate gate** (boolean / bare CEL /
-`${...}` template / `{ dialect, source }` envelope). A branch object carries no `source`,
-so the runner's normalizer read it as "no gate declared" and executed the action
-unconditionally: the predicate was never evaluated, `then` / `else` were never dispatched,
-and `os validate` / `os build` stayed green with zero diagnostics. Two docs pages taught
-the shape with worked examples, so an author following the documentation
-("amounts over 1000 go to manager approval") got unconditional execution.
-
-What changes:
-
-- `ActionCondition` is removed from `@object-ui/types` (and from the barrel export).
-- `ActionSchema.condition` is retyped to the predicate the runtime actually honours:
-  `boolean | string | { dialect?: string; source: string }` — the same three arms
-  `ActionRunner`'s own `ActionDef.condition` carries, and the same vocabulary `visible`
-  and `disabled` use.
-- `ActionConditionSchema` is removed from `@object-ui/types/zod` (and from the zod
-  barrel); the `condition` key now validates against that predicate union.
-- The two teaching sites (`content/docs/core/enhanced-actions.mdx` Conditional Execution,
-  `content/docs/api/schema-reference.md` ActionSchema table) are rewritten to the live
-  vocabulary: `condition` is a gate; a branch is expressed as separate actions with
-  mutually exclusive `condition`s.
-
-**The zod parse verdict flips in both directions**, measured on `origin/main` @ `2aff580b5`
-against this branch: the branch object went from **accepted** to **refused**
-(`invalid_union` on `condition`), and every live predicate spelling — `false`,
-`'data.amount > 1000'`, `'${data.amount > 1000}'`, `{ dialect: 'cel', source: ... }` —
-went from **refused** to **accepted**. The old schema required `expression`, so the shape
-the runtime honours was the one the schema rejected.
-
-**Breaking for TypeScript authors of `ActionCondition` and for metadata authoring
-`condition: { expression, then, else }`** — marked `minor` per this repo's
-version-alignment rule, which reserves `major` for following `@objectstack` across a major
-(AGENTS.md 版本号策略; same classification as the `MobileOverrides` retirement,
-objectui#4919). Runtime behaviour is unchanged: an authored branch object did nothing
-before and does nothing now. What changes is that the contract no longer claims otherwise
-— the mistake now surfaces at authoring time as a type error and a named zod refusal,
-instead of a silent no-op that type-checks, validates and runs the action anyway.
diff --git a/.changeset/4420-bulk-delete-visiblewhen.md b/.changeset/4420-bulk-delete-visiblewhen.md
deleted file mode 100644
index eafb37e6e6..0000000000
--- a/.changeset/4420-bulk-delete-visiblewhen.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-'@object-ui/core': patch
-'@object-ui/plugin-grid': patch
-'@object-ui/plugin-list': patch
----
-
-The selection bar's built-in **Delete** now honours `userActions.delete.visibleWhen`
-per selected record (objectui#4420). It used to read that key as a bare boolean — the
-object-level verdict only — so ticking a record the author's predicate excludes still
-offered the red Delete, and pressing it deleted the record the predicate was written to
-protect. The row kebab on the same screen hid its Delete correctly, so one declared key
-meant two different things on two surfaces.
-
-Ruled by the maintainer on 2026-08-17 (behaviour 1 of the card's three): **filter the
-operation and report the skipped**. The bar evaluates the predicate once per selected
-record, the delete runs over the allowed subset, and the excluded records are reported
-rather than silently dropped. The button itself is never hidden or disabled by the
-predicate — a mixed selection is not punished for one stray tick — and a selection where
-every row is excluded is a legible refusal rather than an unexplained absence.
-
-- `@object-ui/core` gains `partitionRowsByPredicate`, the set-shaped counterpart of
-  `evalRowPredicate`: the fail-closed per-record fold a bulk gate needs, written once.
-  A bulk gate evaluates N records in a loop, which is why it can never be a hook.
-- `@object-ui/plugin-grid`'s bulk bar routes an excluded selection through
-  `BulkActionDialog`, whose existing `bulk-skipped-notice` slot reports the skipped
-  count; a selection with nothing excluded keeps the consumer's own delete flow
-  untouched. `resolveRowCrudAffordances` now also returns `objectDeletePredicates` —
-  the bulk half of the same predicates, gated on the object verdict rather than on the
-  row `onDelete` wiring. The dialog declines to run over zero records.
-- `@object-ui/plugin-list`'s non-grid bulk bar (kanban / calendar / gallery / …) filters
-  the built-in `delete` to the eligible subset and states the skipped count inline.
-
-Custom bulk action ids are untouched: they route through the action runner carrying
-their own gates. This is a UI affordance — server enforcement was never the leak.
diff --git a/.changeset/4730-objectview-config-keys-retired.md b/.changeset/4730-objectview-config-keys-retired.md
deleted file mode 100644
index 16c14f7c04..0000000000
--- a/.changeset/4730-objectview-config-keys-retired.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-'@object-ui/i18n': patch
----
-
-The `console.objectView.*` config-panel vocabulary is retired — 116 keys removed from each
-of the ten packs, 1160 translated strings that nothing read (objectui#4730, maintainer
-ruling 2026-08-19).
-
-The namespace held 209 keys per pack. 116 of them labelled a view-configuration settings
-panel that does not exist: appearance and density toggles, accessibility attributes,
-conditional-formatting rules, row-action and inline-edit switches, quick-filter builders,
-an advanced-settings tier. `packages/app-shell/src/views/ViewConfigPanel.tsx` — the panel
-they were written for — was migrated off the legacy `buildViewConfigSchema` engine onto
-`ViewVariantInspector`, a spec-driven inspector whose field labels come from
-`@objectstack/spec` metadata rather than from this namespace. The panel was replaced; the
-keys were not cleaned up with it.
-
-Removed under objectui#4658's three-legged evidence standard, re-measured on this branch's
-merge base rather than inherited from the card: zero `t()`/`tt()` call sites, zero textual
-occurrence of the dotted key anywhere in the repo outside the packs that define it, and a
-consumer spot-check confirming no i18n wiring. The 93 live keys stay — the create-view
-dialog fields, the view-type catalogue, `new`/`save`/`cancel`, the object-not-found copy,
-plus the 38 keys whose spelling still appears somewhere the AST pass cannot see, which are
-out of scope here.
-
-Four of the retired keys name `ListViewSchema` properties that are still active —
-`rowActions`, `inlineEdit`, `hiddenFields`, `filterableFields`. They are retired anyway, by
-the ruling's own words: a live schema property is not a consumer of a locale string; only a
-labelled UI control is. If such a panel is ever specified, its keys are re-authored
-alongside it.
-
-`packages/i18n/src/__tests__/objectView-config-keys-retired-4730.test.ts` pins the removal
-by name. Every i18n gate in this repo runs call site → key, so none of them can see a dead
-key come back: the parity gate is fully satisfied by 116 dead keys present in all ten packs,
-and the reverse sweep that found them (`scripts/check-i18n-dead-keys.mjs`) is report-only by
-design. The pin is the only thing that would notice.
diff --git a/.changeset/4850-misplaced-eslint-disable.md b/.changeset/4850-misplaced-eslint-disable.md
deleted file mode 100644
index 06a3767dab..0000000000
--- a/.changeset/4850-misplaced-eslint-disable.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
----
-
-Comment-only fix: two `eslint-disable-next-line` directives were placed on the
-wrong line and had never suppressed anything since they landed.
-
-- `apps/console/src/pages/developer/PublicFormsPage.tsx` — the
-  `react-hooks/exhaustive-deps` directive was an inline block comment inside the
-  `useEffect(() => { load(); }, [])` statement, so its "next line" was a blank
-  line, not the statement itself. Moved above the statement with the reason
-  written out (mount-once by design; refresh is explicit via the Refresh
-  button and post-mutation `await load()` calls).
-- `packages/react/src/SchemaRenderer.tsx` — the
-  `@typescript-eslint/no-explicit-any` directive's `--` reason wrapped onto a
-  second comment line, so its "next line" was that continuation comment, not
-  `type ForwardedProps = Record<string, any>;`. Collapsed to one line so the
-  directive is immediately above its target.
-
-No logic changes. Verified with `eslint --report-unused-disable-directives`:
-both directives are now effective (the two warnings they were meant to
-suppress are gone) and neither directive is reported unused.
diff --git a/.changeset/4894-shared-registration-key-reader.md b/.changeset/4894-shared-registration-key-reader.md
deleted file mode 100644
index 1f8cca1445..0000000000
--- a/.changeset/4894-shared-registration-key-reader.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
----
-
-Test-and-tooling change only; no published behaviour changes. The four pins that read
-"which component keys does `packages/layout/src/index.ts` register?" now share one reader
-(`scripts/component-registrations.mjs`) instead of four copies of a regex that accepted a
-single-quoted key and nothing else — a double-quoted registration was legal, lint-clean
-and invisible to all four at once (objectui#4894).
diff --git a/.changeset/4905-inline-default-value-pin.md b/.changeset/4905-inline-default-value-pin.md
deleted file mode 100644
index 266fe1250d..0000000000
--- a/.changeset/4905-inline-default-value-pin.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-'@object-ui/app-shell': patch
-'@object-ui/plugin-detail': patch
----
-
-Inline `t(key, { defaultValue })` strings are now held to the one placeholder spelling a
-provider-less host can resolve, and five of them are pinned to the pack value for the first
-time (objectui#4905).
-
-`check:i18n-keys`' `default-value-drift` class pins an inline default byte-identical to its
-`en` row, and objectui#3512 holds `en` to the one spelling `createSafeTranslation`'s
-`fallbackT` interpolates — so most inline defaults were covered transitively. Re-measured
-on this tree, 66 of 1003 were not: three literal defaults on dynamic keys, and 63 written
-as a computed expression. A new `unresolvable-default-spelling` class in
-`scripts/check-i18n-call-site-keys.mjs` now judges the text every inline default carries —
-the folded sentence, or a template literal's static segments — so `{{ name }}`,
-`{{count, number}}`, `{{- name}}` and `$t(key)` are refused wherever they are written,
-rather than only inside a copy table.
-
-Four call sites gain a real pin because their default carries no placeholder at all: the
-record-form submit button now falls back to `Update`/`Create` (the pack's wording) instead
-of `Save`/`Create` via a nested `t('common.save')`, the context selector's package label
-and the approvals separator now state their literal. One more (`detail.showEmptyFields`)
-is behind a `createSafeTranslation` hook, whose fallback does interpolate, so it can safely
-say what the pack says.
-
-The other 61 are deliberately left computed, and the measurement behind that is the useful
-part: react-i18next's not-ready `t` returns `options.defaultValue` **verbatim, without
-interpolating it**. At a call site bound to a bare `useObjectTranslation()`, a default
-written as `` `Signed in as ${user.email}` `` is therefore the only form that renders
-correctly with no provider — rewriting it to `'Signed in as {{email}}'` would put literal
-braces in front of the user, which is the exact defect this family of cards exists to
-prevent. Those sites keep their template literals and are covered by the spelling class
-instead.
diff --git a/.changeset/4918-stale-strip-mode-prose.md b/.changeset/4918-stale-strip-mode-prose.md
deleted file mode 100644
index 5f16c6e8bb..0000000000
--- a/.changeset/4918-stale-strip-mode-prose.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
----
-
-Comment-only truthfulness fix in `@object-ui/plugin-detail`'s spec-parity tests. The
-`relationshipValueField` block in `recordRelatedListInputs.spec-parity.test.ts` and the
-`hideFields` block in `recordDetailsInputs.spec-parity.test.ts` each narrated strip mode
-as a present-tense fact about the installed `@objectstack/spec` — that an undeclared
-top-level key parses green and is silently dropped from `data`. The props schemas were
-closed upstream, so an undeclared key now draws a named `unrecognized_keys` refusal, and
-both comments read as current while being false against the installed pin. Both now state
-the pin-independent verdict (an undeclared top-level key is never authoring surface) and
-note that the contract expresses it two ways depending on the installed pin, pointing at
-`specRefusesUnknownTopLevelKeys` in the sibling `recordHighlightsInputs.spec-parity.test.ts`
-as the behavioural probe. This also settles `recordDetailsInputs` disagreeing with itself,
-its section-key block having already taken the pin-aware disposition. No assertion changed
-and no published behaviour changes.
diff --git a/.changeset/4919-retire-mobile-overrides.md b/.changeset/4919-retire-mobile-overrides.md
deleted file mode 100644
index 2e0d9a4457..0000000000
--- a/.changeset/4919-retire-mobile-overrides.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-'@object-ui/types': minor
-'@object-ui/mobile': minor
----
-
-Retire the `MobileOverrides` type and its `mobileOverrides` mount point (objectui#4919,
-maintainer ruling 2026-08-19, ADR-0049 enforce-or-remove).
-
-`MobileOverrides` published a six-key mobile override surface — `layout`, `columns`,
-`useBottomSheet`, `fullScreen`, `touchTarget` and a three-value `navigation` vocabulary
-(`'bottom-tabs' | 'hamburger' | 'drawer'`) — from `@object-ui/types` and, re-exported,
-from `@object-ui/mobile`. Nothing read any of it. Measured on current `main`: the type had
-exactly four mentions repo-wide — its own declaration, the single
-`MobileComponentConfig.mobileOverrides` mount point, and the two barrel re-exports — and
-the lower-case property name (the spelling a renderer would actually read) appeared only
-in that declaration. No renderer, hook or adapter resolved it, and a sweep of the example
-apps and the `objectstack` sibling checkout found zero authors. The three `navigation`
-values were three spellings of the same no-op.
-
-The declared surface is removed rather than narrowed. The #3985 lineage's rule is "narrow
-to the implemented values"; here the implemented set is empty, so that rule terminates in
-deletion — a config that type-checks, builds and silently does nothing is the
-declare-without-enforce shape the platform doctrine forbids.
-
-Removal rather than a `?: never` tombstone follows this package's own discriminator. A
-tombstone exists to steer authors to a named live replacement — `crud.ts` `confirm` →
-`confirmText` (objectui#4314), `data-display.ts` `hoverable` / `striped` → `data-table`
-(objectui#5474) — or to keep a key loud that the docs had actively taught as working.
-Neither applies: there is no replacement key to steer to, no documentation ever described
-the surface, and there is no successor spelling. That is the same zero-pull, no-successor
-shape as the retired `AccordionItem.icon` (objectui#4652) and `ToggleGroupItem.icon`
-(objectui#4632), both of which were removed outright rather than tombstoned.
-
-**Breaking for TypeScript authors of `MobileOverrides` / `mobileOverrides` only** (marked
-`minor` per this repo's version-alignment rule, which reserves `major` for following
-`@objectstack` across a major — see AGENTS.md's 版本号策略, and the identical
-classification used for `AccordionItem.icon`). Runtime behaviour is unchanged: an authored
-`mobileOverrides` did nothing before and does nothing now. What changes is that the
-contract no longer claims otherwise, so the mistake surfaces at authoring time — importing
-the type is now a "has no exported member" error, and authoring the key on a
-`MobileComponentConfig` object literal is an excess-property error, instead of a silent
-no-op that type-checks and builds.
-
-If real mobile-override renderer work is ever wanted it re-enters deliberately, as designed
-product surface on its own card, with the renderer landing in the same change as the
-declaration — not by resurrecting this declaration.
diff --git a/.changeset/4929-plugin-published-stylesheets.md b/.changeset/4929-plugin-published-stylesheets.md
deleted file mode 100644
index b2cb6e0b03..0000000000
--- a/.changeset/4929-plugin-published-stylesheets.md
+++ /dev/null
@@ -1,52 +0,0 @@
----
-'@object-ui/plugin-grid': patch
-'@object-ui/plugin-kanban': patch
----
-
-`@object-ui/plugin-grid` and `@object-ui/plugin-kanban` now publish a stylesheet —
-`"./style.css"`, mapped to `dist/index.css` and compiled at build time from the package's
-own sources (objectui#4929, maintainer ruling 2026-08-17, Direction 1).
-
-**What was broken.** Only `@object-ui/components` and `@object-ui/fields` shipped CSS, and
-each scans its own `src` only, so a class used exclusively by a plugin could not appear in
-either sheet BY CONSTRUCTION. A published-state Vite app that installed one of these two
-plugins and followed the quick-start rendered the grid or the board with **25 themed
-utilities that had no source anywhere in the world** — `bg-muted/10`, `bg-card/60`,
-`text-muted-foreground/60`, `ring-primary/40` and friends, ordinary appearance classes —
-plus ~103 plain ones. Re-measured on the merged tree: the 21 the card listed all still hold,
-and four more (`[&>h3]:text-foreground/80`, `border-l-primary/40`, `border-primary/30`,
-`hover:text-primary`) that its literal-grep method could not see.
-
-The plain utilities a consumer could in principle regenerate by pointing `@source` at the
-package's `dist`. The themed ones they cannot, at all: they resolve `@theme` tokens declared
-in `packages/components/src/index.css`, which that package does not publish. A build inside
-this monorepo is their only possible producer — which is why the fix is a stylesheet we
-ship, not documentation teaching consumers to hand-declare the theme and scan
-`node_modules` (the advice objectui#4858 had just retired from the guides).
-
-**The shape**, inherited from `@object-ui/fields` (objectui#4059): each package gains
-`src/index.css` that `@reference`s the components entry — theme tokens, the class-based
-`dark` variant and the animate plugin become available for resolution while emitting
-nothing — plus `scripts/build-css.mjs`, which subtracts every rule components' published
-sheet already ships. So these are **supplements, imported after** the components sheet, and
-they are 16.30 kB and 11.41 kB rather than another ~170 kB each:
-
-```css
-@import 'tailwindcss';
-@import '@object-ui/components/style.css';
-@import '@object-ui/fields/style.css';
-@import '@object-ui/plugin-grid/style.css';
-@import '@object-ui/plugin-kanban/style.css';
-```
-
-Add a line only for the plugins you install; no other `@object-ui/plugin-*` package
-publishes a stylesheet yet. The build step is shared
-(`scripts/build-plugin-stylesheet.mjs`) so it is the pattern the next one inherits rather
-than a file to copy, and it refuses to write a sheet that fails any of four assertions — no
-rule may vanish, the subtraction must have removed something, the class count may not pass
-a leak ceiling, and named themed utilities only this build can produce must still be
-present.
-
-Nothing is removed and no existing import changes: a consumer who does not import the new
-sheets is exactly where they were, and the guides' "do not scan `node_modules`" advice
-stays correct — it is now correct for plugins too.
diff --git a/.changeset/4935-element-filter-comment-residue.md b/.changeset/4935-element-filter-comment-residue.md
deleted file mode 100644
index caebf8b3b5..0000000000
--- a/.changeset/4935-element-filter-comment-residue.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
----
-
-Comment-only cleanup in `@object-ui/components`: the `elements.tsx` header note no
-longer lists `element:filter` among the heavier interactive elements said to live in
-their owning plugins. No such file ever existed for it, and the element was retired at
-element grain upstream (ADR-0049), so the type is gone from `PageComponentType`
-entirely. No published behaviour changes.
diff --git a/.changeset/4938-timeline-dead-example-link.md b/.changeset/4938-timeline-dead-example-link.md
deleted file mode 100644
index f000f50e64..0000000000
--- a/.changeset/4938-timeline-dead-example-link.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
----
-
-Doc-only fix in `@object-ui/components`: `packages/components/src/renderers/complex/TIMELINE.md`
-linked `../../examples/prototype/src/App.tsx` for "comprehensive examples of all
-three timeline variants in action" — that example app was deleted whole in
-`3aa84cee0` with no successor at the same path, and no gate had ever opened this
-file, so the link sat dead with nothing to notice (objectui#4938). Repointed at
-the interactive demo the docs site now serves for the same three variants
-(`https://www.objectui.org/docs/plugins/plugin-timeline`).
-
-No source or behaviour change; text only.
diff --git a/.changeset/4947-tombstone-judge-convergence.md b/.changeset/4947-tombstone-judge-convergence.md
deleted file mode 100644
index 7f6937b240..0000000000
--- a/.changeset/4947-tombstone-judge-convergence.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
----
-
-Test-infrastructure convergence, no shipped code touched: the last two local copies of
-the ADR-0087 D2 tombstone criterion — in `packages/plugin-detail`'s
-`recordDetailsInputs` spec-parity test and `packages/app-shell`'s `block-config`
-preview test — now import `@object-ui/test-support`'s shared judge instead of
-spelling out `unwrap()._def.type === 'never'` by hand. Both copies carried the
-structural channel alone; the shared judge OR-s it with the `[REMOVED]` description
-channel, so neither channel can go quietly permissive on its own, and every
-tombstone-aware gate in the repo now moves together when the criterion changes.
diff --git a/.changeset/4971-declared-arm-subset-gate.md b/.changeset/4971-declared-arm-subset-gate.md
deleted file mode 100644
index 1d3b39bc39..0000000000
--- a/.changeset/4971-declared-arm-subset-gate.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
----
-
-Test-only: `registry-inputs-spec-parity.test.ts` gains a THIRD direction — every coarse
-arm a block declares on a key must be one `@objectstack/spec` accepts there (objectui#4971).
-
-objectui#3832 gave `ComponentInput.type` the array form so a union key can declare its real
-arms, and in doing so created a second way to disagree with the contract. The two are not
-symmetric: declaring FEWER arms than the spec accepts produces NOISE (the manifest gate warns
-on a legal write — audible), while declaring an arm the spec REJECTS is SILENT — `checkType`
-clears a value the contract refuses, the manifest and the generated `.d.ts` publish it as
-legal, and `declared = enforced` inverts with nothing to announce it. Measured on #3832's own
-branch: a fake `'object'` arm on `element:text_input.defaultValue` reddened that block's
-per-block test, while a fake `'number'` arm on `page:card.title` left all 856 tests green —
-the property held by per-block discipline, not by a gate. It is one-directional for that
-reason.
-
-An arm names a value's KIND, never its domain (`ComponentInput.type`, maintainer ruling
-2026-08-17), so the gate refutes an arm only when the contract refuses the KIND — read off the
-parse ISSUES rather than a boolean, scoped to the key so a required sibling cannot speak for
-it, and recursing through a union's branches. A refusal of the VALUE leaves the arm standing,
-which is what keeps a correct `'string'` arm on a spec-enum key from reading as invented; the
-same rule still refutes a `'number'` arm there, and both halves are pinned by name. An `enum`
-arm is judged exactly instead — every declared member must be a value the spec accepts.
-
-Two red-on-arrival findings, reported rather than declared away: `element:number.filter`
-(objectui#6206) and `object-grid.data` (objectui#6207), both carried as reasoned, issue-backed
-exemptions that a stale-exemption test deletes the moment either side moves.
diff --git a/.changeset/4991-lucide-pin-range-consistency.md b/.changeset/4991-lucide-pin-range-consistency.md
deleted file mode 100644
index 9982eb31c2..0000000000
--- a/.changeset/4991-lucide-pin-range-consistency.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
----
-
-Test-only change to `packages/cli/src/__tests__/app-generator.test.ts`: the
-`lucide-react` manifest pin, and the pre-fix reverse-verification's drift
-check, no longer read an arbitrary member off `inRepoRangesOf(...)` without
-first asserting the repo's in-repo declarations for that dependency actually
-agree. No published behaviour changes.
diff --git a/.changeset/5034-navigateonsuccess-url-contract.md b/.changeset/5034-navigateonsuccess-url-contract.md
deleted file mode 100644
index 567b1f9cf8..0000000000
--- a/.changeset/5034-navigateonsuccess-url-contract.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-"@object-ui/plugin-form": minor
-"@object-ui/types": minor
----
-
-`navigateOnSuccess` is relative-only, escapes the interpolated id, and is deprecated in favour of `submitBehavior`
-
-The url contract for this key was undeclared: it was same-origin-guarded (so a same-origin
-ABSOLUTE value was accepted), it interpolated `{id}` / `{recordId}` without escaping the
-substituted value, and nothing said which of those was intended. The maintainer ruled it on
-2026-08-17: `navigateOnSuccess` is the pre-ruling ancestor of the `submitBehavior` family
-rather than a second dialect, so as a compat alias it runs under the semantics
-objectstack#7496 ruled for that family.
-
-**Relative paths only.** A same-origin absolute such as `https://own-host/record/{id}` is
-now refused like any other out-of-contract value, rather than accepted and navigated at
-browser level. The destination is authored metadata, which is exactly where an address
-somebody else chose gets copied in. Cross-origin and protocol-relative values were already
-refused and still are; every relative shape that worked before still works.
-
-**The interpolated id is URL-escaped.** `/r/{id}` with an id of `a/b c` resolved to
-`/r/a/b c`, silently growing a path segment, and a template of `{id}` let the id become the
-whole destination. The substituted value now goes through `encodeURIComponent`, so a token
-is a value in the path and never a way to add path structure. The template is the author's
-and is untouched — only the id, which is data read off the written record, is escaped.
-
-Both halves are needed and neither implies the other: relative-only is a rule about where a
-destination starts, so it cannot see structure injected further along; escaping runs only on
-the substituted value, so it cannot see an absolute the author wrote out.
-
-This can only narrow what is reachable. Every destination the key now accepts is a relative
-reference, and a relative reference cannot carry an authority, so it was already accepted by
-the same-origin guard this replaces — no value that was refused is now followed. With every
-accepted destination relative, the browser-level `window.location.assign` fallback at both
-call sites became unreachable and was removed; an accepted destination goes to the injected
-navigation seam, and the absent-seam fallback inside the shared hook is unchanged.
-
-**Deprecation.** `navigateOnSuccess` is marked `@deprecated` in favour of `submitBehavior`,
-which already takes precedence over it and carries the richer `{{record.field_name}}`
-interpolation. The `{id}` / `{recordId}` dialect keeps working for forms that already
-declare it — the ruling converges the documentation and the semantics, not the spelling.
diff --git a/.changeset/5106-doc-key-table-scan-surface.md b/.changeset/5106-doc-key-table-scan-surface.md
deleted file mode 100644
index 6dc86a21d0..0000000000
--- a/.changeset/5106-doc-key-table-scan-surface.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
----
-
-Tooling only, no published surface. `scripts/check-doc-component-types.mjs` now
-reads the plugin KEY TABLES in `content/docs/**` — the canonical
-`| Namespaced key | Bare-name fallback | Renderer behind it |` form the
-objectui#5002 family standardised on — and judges both halves of every row,
-including the namespaced one the gate never judged at all. Also fixes a floor
-that named a counter which never existed (`docFiles`), so the check that catches
-the docs walk finding nothing had been inert, and adds a guard that makes the
-same mis-key fail loudly instead of silently passing.
diff --git a/.changeset/5221-onsuccess-navigation.md b/.changeset/5221-onsuccess-navigation.md
deleted file mode 100644
index 709dc4aa88..0000000000
--- a/.changeset/5221-onsuccess-navigation.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-'@object-ui/core': minor
-'@object-ui/app-shell': minor
----
-
-Console half of `ActionSchema.onSuccess` post-success navigation.
-
-`@objectstack/spec` declares `onSuccess` as a closed strict object
-`{ navigate: string, openIn: 'self' | 'newTab' }`, refine-scoped to `type: 'api'` and
-`type: 'script'` — the two action types whose success event carries a server response.
-Nothing in this renderer read it, so an action declaring the hop navigated nowhere: the
-block fell into `ActionRunner`'s older `ActionDef.onSuccess` chained-callback channel,
-was dispatched as an action, and failed inside `executeNavigation` with "No URL provided
-for navigation action" — a red toast and no jump. The motivating report is a clone action
-that leaves the user sitting on the record they cloned from.
-
-`ActionRunner.handlePostExecution` now performs the declared hop through
-`navigationHandler` — the same SPA seam every other navigator in that file uses, which
-the console wires to react-router's `navigate`, so `openIn: 'self'` is a real in-place
-route hop rather than a full-page load. `interpolateTarget` gains a `${result.*}` scope
-alongside `${param.*}` and `${ctx.*}`, resolved against the handler's own return value
-(the level `readActionPayload` reads, one below the action envelope) and supplied only by
-this call site, so a target interpolated before its request still has no `result` to
-name. `openIn` is read as the one member that changes the branch and no default is
-written here — the spec materialises `.default('self')`, so parse output always carries a
-resolved member — and the two `openIn` spellings stay apart: this reads
-`onSuccess.openIn` (`'self' | 'newTab'`), never the top-level `type: 'url'` switch
-(`'self' | 'new-tab'`), each of which spec refuses in the other's position.
-
-The console's server-action wrapper gains the matching handler-return half: a handler may
-now return `openIn: 'self'` next to its `redirectUrl` to ask for the same-tab jump, while
-a `redirectUrl` **without** `openIn` keeps its shipped new-tab behaviour unchanged. When
-an action declares an `onSuccess` block, the wrapper defers to the runner and only tidies
-its pre-opened tab, so one navigation happens rather than two.
-
-The pre-existing `ActionDef.onSuccess` chained-callback channel is unchanged. It is told
-apart by the spec's own declaration — a non-array object whose `navigate` is a string —
-and keeps running for every other shape.
diff --git a/.changeset/5232-view-config-org-wide.md b/.changeset/5232-view-config-org-wide.md
deleted file mode 100644
index fe7e5b2452..0000000000
--- a/.changeset/5232-view-config-org-wide.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-'@object-ui/data-objectstack': minor
-'@object-ui/app-shell': minor
-'@object-ui/plugin-list': patch
-'@object-ui/i18n': patch
----
-
-**View configuration is explicitly org-wide, and its write path is now gated (objectstack#7494's
-ruling, maintainer 2026-08-12).** The `sort` / `hiddenFields` / `columnState` / `rowHeight` that a
-list toolbar persists were never per-user: they are one shared row on the view, so an ordinary user
-dragging a column or cycling density was re-styling that view for the entire organization. Nothing
-in the console said so, and nothing stopped it. A per-user scope stays parked (objectstack#7611,
-v18) and is deliberately not built here — which is precisely why the write has to be gated rather
-than narrowed: there is no second, private store for it to fall back to.
-
-`ObjectStackAdapter.updateViewConfig` now refuses when the session's **reported** ADR-0066 capability
-set does not contain `manage_metadata`, throwing the new `ViewConfigPermissionDeniedError`
-(`VIEW_CONFIG_PERMISSION_DENIED`, with `isViewConfigPermissionDeniedError` and the
-`VIEW_CONFIG_CAPABILITY` constant alongside it). The gate is the **first** statement in the method —
-before `connect()`, before the payload is assembled — so a refused call puts nothing on the wire.
-It is on the write rather than on the toolbar button on purpose: withholding the affordance would
-leave the method still accepting the call from anything else holding the adapter, whereas a gate on
-the write is inherited by every caller, present and future.
-
-`manage_metadata` is not a newly minted name. It is the capability this repo already treats as
-metadata-authoring authority — `HomePage`'s `AUTHORING_CAPABILITY`, the one the server itself
-refuses metadata writes without — and the gated write goes through `client.meta.saveItem`, the very
-same ADR-0005 metadata door, so this applies the authority the server is already applying instead of
-inventing a parallel one.
-
-**Unknown fails open, by doctrine.** A capability set that was never reported (a backend predating
-ADR-0066, or no permission provider mounted) is not a denial: the server enforces regardless, so a
-client-side refusal on missing data cannot protect anything and can only break a permitted user. A
-*reported* empty grant gates strictly. Hosts push the session's capabilities in with the new
-`setSystemCapabilities`; `ObjectView` wires it from `usePermissions()`.
-
-The refusal is also **said out loud**. `ObjectView`'s persist path previously swallowed every failure
-into `console.error`, which for a debounced toggle whose UI has already moved would have left the
-operator looking at a density they did not get; a denied write now raises a toast. And the "View
-settings" popover — where density and field visibility are actually changed — now states the scope
-before the operator acts: *"Grouping, color, density, and visible fields. Applies to everyone who
-uses this view."*, translated in all ten packs.
diff --git a/.changeset/5234-onnavigate-documented-exception.md b/.changeset/5234-onnavigate-documented-exception.md
deleted file mode 100644
index a0aabb6e02..0000000000
--- a/.changeset/5234-onnavigate-documented-exception.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
----
-
-Comment- and docs-only: `ObjectGridSchema.onNavigate` is now stated as the explicit,
-documented exception the maintainer ruled it on 2026-08-19 (objectui#5234, option C).
-Nothing is added to or removed from any accept set, and no published behaviour changes.
-
-`@object-ui/plugin-grid`'s `ObjectGrid` reads `schema.onNavigate` at the
-`useNavigationOverlay` call, while `GRID_QUERY_INPUTS` does not publish the key — so the
-manifest, the designer panel and the generated `sdui-intrinsics.d.ts` deny a key the
-renderer honours. That gap is now deliberate and said out loud rather than left to be
-re-discovered by the next census:
-
-- An exemption comment at the read site, in the shape objectui#5091 / PR #5241
-  established for `columnState`, `hideRowHeightToggle`, `maxInlineRowActions` and
-  `rowActionDefs` — with the one difference those four do not share: this key IS
-  declared in `@object-ui/types`, so the read is plain rather than a cast.
-- A programmatic-only note on the declaration in `@object-ui/types`
-  (`ObjectGridSchema.onNavigate`): it is a function value and a schema is a serialisable
-  document, so `(recordId, action) => void` cannot survive a metadata round-trip whatever
-  declares it, and programmatic callers should prefer `ObjectGridComponentProps` where its
-  nine sibling callbacks live.
-- `packages/plugin-grid/README.md` carried the un-narrowed universal claim that the grid
-  "never reads a callback off the schema", which `onNavigate` falsifies. Narrowed to match
-  `content/docs/plugins/plugin-grid.mdx`, which had already been narrowed to "any of these
-  nine"; both pages now also name the one callback that is read.
-- `gridNonAuthorKeys.test.tsx` extended, not rewritten: the four objectui#5091 keys keep
-  every assertion they had, and ten cases are added for this key — the ledger premises
-  plus two source-reading cases that pin the exemption prose itself, which is the only
-  part of a zero-behaviour-change ruling an ordinary assertion cannot see.
-
-The key is deliberately NOT removed (option A: a breaking public type change plus a
-deprecation cycle for zero measured harm) and deliberately NOT added to
-`GRID_QUERY_INPUTS` (option B: publishing to the designer a key no author can express).
diff --git a/.changeset/5293-view-sort-order-spelling.md b/.changeset/5293-view-sort-order-spelling.md
deleted file mode 100644
index 47728f24b6..0000000000
--- a/.changeset/5293-view-sort-order-spelling.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-'@object-ui/plugin-view': minor
----
-
-**Breaking (shipped as `minor` per AGENTS.md §版本号策略).** `ObjectViewProps.views[].sort`
-now spells its direction key **`order`**. The retired spelling is **`direction`** — named
-here so that a host still writing it can find this entry by searching the old key
-(objectui#5293).
-
-```diff
-  <ObjectView
-    views={[{
-      id: 'recent', label: 'Recent', type: 'grid',
--     sort: [{ field: 'created_at', direction: 'desc' }],
-+     sort: [{ field: 'created_at', order: 'desc' }],
-    }]}
-  />
-```
-
-**Nothing that worked stops working on this surface, because on the `views` prop
-`direction` never worked.** All three consumers of the resolved `activeView.sort` read
-`order`: the non-grid fetch lowers it through the shared sink `convertSortToQueryParams`,
-whose `entry.order === 'desc'` is false for a missing key; the grid path forwards it to
-`ObjectGridSchema.sort`, where `ObjectGrid` builds the wire string `` `${s.field} ${s.order}` ``
-— literally `"created_at undefined"` — and `parseSchemaSort` reads a missing `order` as
-ascending, so the column header even drew an ascending arrow; `mergedSort` hands the same
-value to the delegated list view.
-
-So a host writing the exact shape the prop declared got an **ascending** list with no
-failure signal anywhere: the declaration said the value was well-formed, and the direction
-was dropped at three independent readers rather than rejected at one. This rename does not
-take away a feature — it converts a silent wrong answer into a loud type error at the one
-place that can still be fixed cheaply.
-
-**Scope — one published export still accepts `direction`, and this release does not retire
-it.** `toSortItems` (`packages/plugin-view/src/config/view-config-utils.ts`, re-exported
-from the package root and listed in the README) folds `s.order || s.direction || 'asc'`.
-It serves a different surface — the studio inspector-draft that feeds `SortBuilder` — and
-it is not reachable from the `views` prop, so it neither affects nor is affected by this
-rename. If you migrate by searching for the old key, that is the other hit you will find:
-it is dormant (nothing in this repo calls it outside a test), and removing it would be a
-separate break on a separate public export, tracked as objectui#6011. It is not a partial
-retirement of this one.
-
-`order` is the spelling every other sort surface already uses (`SortConfig`,
-`NamedListView.sort`, `ObjectGridSchema.sort` / `.defaultSort`, and the shared
-`QuerySortEntry` sink), so the prop now has one spelling repo-wide and declared equals
-enforced.
-
-⛔ Deliberately **not** a tolerant dual-read (`direction ?? order`): that is the tolerance
-layer objectui#4869 ruled against, and admitting the old key as an alias would rebuild the
-drift this change removes. `SortUI` is untouched — it legitimately owns `direction` on its
-own `SortUISchema` and converts at its boundaries.
diff --git a/.changeset/5325-ineffective-dynamic-import-ledger.md b/.changeset/5325-ineffective-dynamic-import-ledger.md
deleted file mode 100644
index c1652b19e7..0000000000
--- a/.changeset/5325-ineffective-dynamic-import-ledger.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
----
-
-Build tooling only, no published package source changed.
-
-The console build emitted 43 `INEFFECTIVE_DYNAMIC_IMPORT` warnings on every run
-— every `import()` in `@object-ui/fields`' widget-loader map is defeated by a
-static edge to the same module. They are true, and they scroll past every build
-until nobody reads the log at all.
-
-They are now pinned to a ledger (`scripts/vite-ineffective-dynamic-imports.ts`)
-rather than filtered away: the pinned 43 are replaced by one summary line, an
-ineffective dynamic import the ledger does NOT know about keeps rolldown's
-original warning and fails the build, and a pinned entry that stops firing fails
-it too — so a build that dies before chunk assignment reports 43 named absences
-instead of a clean-looking zero.
-
-The module graph is deliberately unchanged; the ledger's header carries the
-measurement of why, and the eager-closure budget already governs the bytes.
diff --git a/.changeset/5397-release-pr-post-version-validation.md b/.changeset/5397-release-pr-post-version-validation.md
deleted file mode 100644
index 06dfedf041..0000000000
--- a/.changeset/5397-release-pr-post-version-validation.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
----
-
-CI-only: the changeset release workflow's refresh lane now renders the
-post-version tree, validates the surfaces `changeset version` can move
-(`QUICK_REFERENCE.md`, the generated `CHANGELOG.md` files, the manifest
-versions as the tooling suite reads them) and restores the tree before
-`changesets/action` opens or updates the version PR. No package changes.
diff --git a/.changeset/5422-coverage-lane-concurrency.md b/.changeset/5422-coverage-lane-concurrency.md
deleted file mode 100644
index 9a77ba1754..0000000000
--- a/.changeset/5422-coverage-lane-concurrency.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
----
-
-CI-only change: `ci.yml`'s workflow `concurrency` group now carries `github.sha` on
-the `push` trigger, so a merge to `main` no longer cancels the previous merge's
-still-running CI. The `pull_request` group (the PR number, `cancel-in-progress: true`)
-and the `merge_group` fallback to `github.ref` are both unchanged.
-
-The push lane is the only lane that runs the coverage gate, and the merged 4-shard
-report is what enforces `coverage.thresholds` for a commit. Measured over the 64
-completed push-lane runs on `main` between 2026-08-23T06:34Z and 2026-08-24T13:56Z,
-39 of them — 61% — lost that gate to cancellation rather than to a red suite.
-
-No published package changes.
diff --git a/.changeset/5458-unprefixed-query-params.md b/.changeset/5458-unprefixed-query-params.md
deleted file mode 100644
index 040a74bb72..0000000000
--- a/.changeset/5458-unprefixed-query-params.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-'@object-ui/app-shell': patch
-'@object-ui/plugin-dashboard': patch
-'@object-ui/console': patch
----
-
-Fix four `find()` calls that passed a query option without its `$`, and gate the shape.
-
-`QueryParams` declares every query option `$`-prefixed and `convertQueryParams` copies
-exactly those keys, so an unprefixed spelling reaches no branch and is dropped — no throw,
-no warning, and it type-checks because the type carries `[key: string]: any` for
-adapter-specific params. For a dropped cap the result is an **unbounded** read rather than
-a truncated one: the platform's GET list route has no default page size, so the query
-returns the whole match set and stays invisible until the object is large.
-
-- `app-shell` `ObjectView` fetched the footer's record count with `{ limit: 0 }`. This one
-  **inverted** rather than widened — `$top: 0` is honoured end to end as "no records", so
-  the dropped key turned "count only, fetch nothing" into "fetch every row in the object",
-  on every mount and every refresh of every list view. It now sends `$top: 0` and reads
-  the count off `total` only; the row-counting fallbacks are gone rather than repointed,
-  because once zero rows are requested an empty `data` means "you asked for none", not
-  "the object is empty", and counting it would assert a confident `0`. With no total the
-  footer line is omitted instead.
-- `app-shell` `AssignedUsersSection` looked a permission set up with `{ …, limit: 1 }`,
-  one line from three correct `$top` calls.
-- `plugin-dashboard` `DashboardFilterBar` passed `fields` **and** `top` in one literal, so
-  a filter's option list read every row and every column of its source object while its
-  own comment described it as capped at 200. The same call read `records.items`, which is
-  not a `QueryResult` member, so against a real adapter the fallback produced no options
-  at all.
-- `console` `sdui-workbench-preview` passed `{ top: 200 }` and read `.records` off the
-  result in its page-source metadata.
-
-A new `object-ui/no-unprefixed-query-params` ESLint rule rejects the shape at write time:
-a known query-option name missing its `$` in the second argument of a `find`/`findOne`
-call. It is narrow on purpose — a closed list of spellings, anchored to the call — because
-the index signature exists so adapters can take adapter-specific params, and a rule that
-flagged any unprefixed key would report the shape the type was written to allow. Its
-sibling `no-query-params-under-options` (the `{ options: { $top } }` half) is unchanged.
diff --git a/.changeset/5483-5439-dts-config-wiring.md b/.changeset/5483-5439-dts-config-wiring.md
deleted file mode 100644
index 02dff4f5b5..0000000000
--- a/.changeset/5483-5439-dts-config-wiring.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-'@object-ui/components': patch
-'@object-ui/fields': patch
-'@object-ui/plugin-ai': patch
-'@object-ui/plugin-calendar': patch
-'@object-ui/plugin-charts': patch
-'@object-ui/plugin-chatbot': patch
-'@object-ui/plugin-dashboard': patch
-'@object-ui/plugin-designer': patch
-'@object-ui/plugin-detail': patch
-'@object-ui/plugin-editor': patch
-'@object-ui/plugin-form': patch
-'@object-ui/plugin-gantt': patch
-'@object-ui/plugin-grid': patch
-'@object-ui/plugin-kanban': patch
-'@object-ui/plugin-list': patch
-'@object-ui/plugin-map': patch
-'@object-ui/plugin-markdown': patch
-'@object-ui/plugin-report': patch
-'@object-ui/plugin-timeline': patch
-'@object-ui/plugin-tree': patch
-'@object-ui/plugin-view': patch
----
-
-Published typings from every `vite-plugin-dts` package now carry an explicit extension on
-every relative specifier, and a type error in the declaration build now fails the build
-instead of being printed and ignored (objectui#5439, objectui#5483).
-
-**Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
-is the fix working.** These packages re-export mostly through NAMED re-exports —
-`export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
-extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
-`any`. Nothing errored; consumers simply got no types. With the extension emitted, the
-symbol carries its real type, and any call site that was relying on the `any` now type
-checks for the first time. This is the mode that produced the 21 residual `TS7006` on
-`@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
-unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
-immediately as `TS2305: has no exported member`.
-
-410 extensionless relative specifiers across 19 packages were emitted before this change;
-the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
-`@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
-is wired so it stays that way.
-
-The second half changes no emitted output today: 22/22 packages built green unmodified, so
-making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
-regression does — print and exit 0, versus fail the build.
diff --git a/.changeset/5490-per-chunk-eager-budgets.md b/.changeset/5490-per-chunk-eager-budgets.md
deleted file mode 100644
index f058a3687b..0000000000
--- a/.changeset/5490-per-chunk-eager-budgets.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
----
-
-Build tooling and CI only — `apps/console/vite.config.ts` (not published source:
-`@object-ui/console`'s `files` list carries `dist`, `plugin.*` and `README.md`),
-`scripts/check-eager-closure-budget.mjs` and its unit test. Nothing ships from
-this change.
-
-The console eager-closure budget weighed one total across 52 chunks. Inside its
-headroom a single chunk can absorb the whole allowance while the others shrink,
-and the total never moves — the shape of objectui#5266, whose 89 KiB landed
-entirely in `vendor-objectstack`. Per-chunk gzipped ceilings now sit on top of
-the aggregate for the three largest eager chunks, set at the measured current
-state plus ~2%, with each headroom narrower than the regression the gate exists
-to catch.
-
-The ceilings key on the chunk names the report itself carries (`files[].name`,
-new in report v2, taken from rolldown's own `chunk.name`) rather than on names
-this checker expects to exist. A budgeted chunk that is absent — renamed group,
-chunk gone — is therefore an error, not a skip: a ceiling with no subject weighs
-nothing and would be green forever.
diff --git a/.changeset/5522-runtime-telemetry-consumer.md b/.changeset/5522-runtime-telemetry-consumer.md
deleted file mode 100644
index 7e626d0bab..0000000000
--- a/.changeset/5522-runtime-telemetry-consumer.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-'@object-ui/app-shell': minor
-'@object-ui/console': minor
----
-
-Console telemetry can now be hard-disabled on an already-built artifact
-
-`/api/v1/runtime/config` gained `telemetry.allowClientErrorReporting`
-(objectstack#11382), and the Console now reads it. The Sentry decision becomes a
-conjunction of two independent grants — a DSN injected at **build** time AND a
-positive permission from the **runtime** — so the single pre-built SPA that both
-the hosted SaaS console and the on-premises / air-gapped EE images embed can be
-silenced by the deployment it lands in, with no rebuild and without editing files
-inside a published bundle. That was the half objectui#5522 could not close before:
-every other input to the gate is a Vite build-time variable frozen into the bundle
-as a literal, which is how an air-gapped EE Console came to send 14 Sentry
-envelopes per session to `sentry.io` carrying IP + User-Agent PII with no way for
-the customer to turn it off (objectstack-ai/cloud#1508).
-
-The permission fails **closed** in every direction: absent key, `telemetry` block
-absent, malformed payload, failed fetch, or a runtime predating the key all read as
-*do not send* — which is precisely the set of runtimes leaking today. It is a
-permission and never a source: the server supplies no DSN and cannot turn telemetry
-on for a build that carries none. Only a real boolean `true` grants; `'true'`, `1`
-and other truthy lookalikes do not.
-
-Behaviour change for deployments that already inject a DSN: reporting now also
-requires the runtime to grant permission, via
-`OS_TELEMETRY_CLIENT_ERROR_REPORTING_ENABLED` (or `RuntimeConfigPlugin`'s
-`allowClientErrorReporting`). A build that opted in but whose runtime says nothing
-will go quiet — deliberately, since that is the same artifact an air-gapped
-customer runs.
-
-`@object-ui/app-shell` additionally exports `isClientErrorReportingAllowed()` and
-the `RuntimeTelemetry` type, so consumers read the permission through the one
-fail-closed accessor instead of writing their own optional-chain against the
-payload.
diff --git a/.changeset/5631-ui-icon-icon-key-migration.md b/.changeset/5631-ui-icon-icon-key-migration.md
deleted file mode 100644
index fa31693dee..0000000000
--- a/.changeset/5631-ui-icon-icon-key-migration.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-'@object-ui/types': minor
-'@object-ui/components': minor
----
-
-**BREAKING (authoring): `ui:icon` names its glyph with `icon`, not `name`**
-
-`{ "type": "icon", "name": "check" }` no longer renders an icon. Write
-`{ "type": "icon", "icon": "check" }`. Stored metadata authored before this
-release needs converting — see the migration below.
-
-Marked `minor` per AGENTS.md §版本号策略 (this repo never publishes `major`
-outside an `@objectstack` major sync); the break is real and is stated here.
-
-**Why**
-
-`name` is the SDUI identity key every authored node carries, alongside `id` —
-it is not `ui:icon`'s private prop. So an ordinary node like
-`{ type: 'icon', id: 'save_icon', name: 'save_icon' }` asked lucide for a glyph
-called `SaveIcon`, missed, and rendered **nothing at all**: silent to a human,
-and clean to a DOM gate, because a renderer that renders nothing spreads no
-attributes to find. `action:*` already reads `icon`, so this is the vocabulary's
-existing answer, and it leaves no node type on which the identity key is
-unusable.
-
-**What changed**
-
-- `IconSchema` (types + its zod mirror) declares `icon: string` **required**,
-  exactly as `name` was required before it — a key rename at constant
-  strictness. `name` reverts to the optional identity inherited from
-  `BaseSchema`. The mirror previously *required* `name`, which is why the
-  renderer could not be migrated on its own: the published contract refused the
-  correct shape.
-- `ui:icon` resolves its glyph from `schema.icon`. There is deliberately **no**
-  `icon ?? name` fallback: a key meaning "identity" or "glyph" depending on
-  whether a lucide lookup happened to hit is the ambiguity being removed.
-- The registry's `inputs` entry and `content/docs/components/basic/icon.mdx`
-  moved in the same change as the resolver.
-- All 98 authored icon nodes in this repo are converted.
-
-**The break is loud in three places, never silent**
-
-1. `IconSchema` **refuses** a legacy node, with a message that names the rename
-   and points at the converter — not zod's default `expected string, received
-   undefined`.
-2. A legacy node that reaches the renderer unvalidated draws the visible
-   placeholder shipped in the previous release, and its `console.warn` now
-   carries the exact rename (`icon: "save_icon"`) plus the converter's name.
-   Its accessible name says so too, and it gains a
-   `data-objectui-icon-legacy-name-key` marker so a gate can tell
-   "unmigrated node" from "glyph that does not resolve".
-3. **Migration for stored metadata** — `migrateIconNodeKeys` from
-   `@object-ui/types`:
-
-   ```ts
-   import { migrateIconNodeKeys } from '@object-ui/types';
-
-   const { document, converted, warnings } = migrateIconNodeKeys(storedPage);
-   if (warnings.length) console.warn(warnings.map((w) => w.message).join('\n'));
-   if (document !== storedPage) await save(document);
-   ```
-
-   It walks the whole document and lifts `name` to `icon` on every icon node.
-   It is a one-shot conversion a deployer runs over stored documents — **not** a
-   read-path fallback; nothing calls it during rendering or parsing. It
-   **reports rather than guesses** for the two cases it will not touch: a node
-   already declaring both keys (`icon` wins, `name` stays the identity it is),
-   and a node naming no glyph at all.
diff --git a/.changeset/5631-ui-icon-visible-placeholder.md b/.changeset/5631-ui-icon-visible-placeholder.md
deleted file mode 100644
index 0e64171ad8..0000000000
--- a/.changeset/5631-ui-icon-visible-placeholder.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-'@object-ui/components': minor
----
-
-`ui:icon`: an unresolvable glyph now renders a visible placeholder instead of nothing
-
-An icon whose name does not resolve to a lucide glyph used to `return null`.
-That failed silently in two independent ways at once: invisible to a human (no
-gap, no error boundary — just an absent glyph), and clean-looking to a gate (a
-renderer that returns `null` spreads no attributes, so a DOM scan of it reports
-no findings).
-
-It now renders a dashed-square placeholder on the same SVG host, keeping the
-authored `className`, `size` and colour so the gap sits exactly where the icon
-would have been, with `role="img"`, an accessible name identifying the icon
-that failed, and a `data-objectui-icon-unresolved` marker. The `console.warn`
-stays and now names the cause.
-
-Also fixed: a node with no `name` at all reached `toPascalCase(undefined)` and
-threw, which the error boundary then swallowed — a third silent failure. It
-renders the placeholder too.
-
-Not included: `ui:icon` still reads the SDUI identity key `name` as its glyph
-name. Moving it to `schema.icon` is ruled but blocked on an authored-metadata
-migration — see objectui#5631.
diff --git a/.changeset/5676-layered-envelope-boundary-parse.md b/.changeset/5676-layered-envelope-boundary-parse.md
deleted file mode 100644
index 88c2a25333..0000000000
--- a/.changeset/5676-layered-envelope-boundary-parse.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-'@object-ui/data-objectstack': minor
----
-
-`MetadataClient.layered()` validates the ADR-0010 protection envelope against the
-producer's own schema at the boundary, instead of casting ten wire fields through
-unchecked (objectui#5676, triage adjudication 2026-08-22).
-
-The envelope arrived by ten `as` assertions over a raw `res.json()` body — no parse, no
-allowlist, no default. The consumer that reads it opens the metadata lock banner on
-`layered?.lock && layered.lock !== 'none'`, true for **any** non-`none` value, so a server
-sending a lock state this console had never heard of opened the amber box, drew the padlock
-and the border, and rendered an empty title. No fifth state ever had to be added to this
-repo for that to happen: a union types what this repo writes and constrains nothing about
-what a server sends.
-
-The boundary now runs `GetMetaItemLayeredResponseSchema.safeParse`. On the conforming path
-every value is the producer's schema output and the ten assertions are gone. `safeParse`
-and never `parse`: a metadata console that rejected every dialect it had not been compiled
-against would answer a newer server with a blank page, which is strictly worse than the
-wrong render being fixed. Values the schema rejects are still **forwarded** — dropping them
-would be that same refused rejection wearing different clothes — and are named in a new
-optional `MetadataLayered._unrecognized`, absent whenever everything parsed. This extends
-to the whole envelope the "pass through and label" treatment objectui#5672 chose for `lock`
-alone; the banner's existing unrecognised-token title is unchanged and needed no edit.
-
-The labelling is per field, which is the part that makes it a degrade rather than a subtler
-version of the same bug. Measured on the installed spec (17.2.0):
-`GetMetaItemLayeredResponseSchema.safeParse(body)` is all-or-nothing — one unknown `lock`
-returns `success: false` with `data` undefined — so the failure branch re-checks each key
-against that schema's own `shape[key]`, where only the offending field fails and the other
-six still arrive typed. Absence is never "unrecognised": the four resolved verdicts are
-required upstream on this path, so a pre-ADR-0010 backend takes the failure branch with
-nothing flagged and behaves exactly as before.
-
-One consequence of the same ruling, fixed alongside because it defeats it: a 200 answer
-whose body was a bare JSON string or number **rejected** the promise with a
-`TypeError: Cannot use 'in' operator`, from the envelope-detection guard's bare truthiness
-check. A malformed body must degrade, never throw.
diff --git a/.changeset/5700-shared-ref-namespaces.md b/.changeset/5700-shared-ref-namespaces.md
deleted file mode 100644
index ead20e9239..0000000000
--- a/.changeset/5700-shared-ref-namespaces.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
----
-
-Instruction-file only. `AGENTS.md` §9 多 agent 协作纪律 gains one bullet beside the
-existing `git stash` bullet, generalising it: a worktree isolates your checkout and
-exactly four ref namespaces (`HEAD`, `refs/bisect`, `refs/worktree`, `refs/rewritten`)
-and nothing else — not the object store, not the repo config, not any other ref. The
-existing stash rule is reframed as one case of that, because a reader who learns only
-the stash rule draws the opposite general conclusion.
-
-Two further instances that have cost work are stated: `refs/remotes/*` (a sibling
-agent's fetch advances *your* `origin/main`, so a path-scoped `git checkout origin/main`
-restores whatever that ref points at now — possibly newer than your branch base — and
-stages it), and `FETCH_HEAD` (last fetch in the checkout wins; the symptom is an empty
-diff that exits 0, which reads as "the change is not there" rather than as wrong
-content — a confidently wrong review conclusion about someone else's work).
-
-The `FETCH_HEAD` isolation boundary is stated as measured rather than extrapolated from
-`refs/stash`: on git 2.43 `git rev-parse --git-path FETCH_HEAD` resolves per-worktree in
-a linked worktree, so a sibling's fetch in *its* worktree does not move yours; the
-hazard is the shared primary checkout, where the same command resolves to the common
-`.git/FETCH_HEAD` and where every agent's first fetch lands before it creates a worktree.
-
-No hook is added — the safe forms are ordinary commands and the unsafe form is
-legitimate elsewhere, so a mechanical block would fire on correct usage. No published
-package changes.
diff --git a/.changeset/5729-column-sortability-signal.md b/.changeset/5729-column-sortability-signal.md
deleted file mode 100644
index d5f990d8e0..0000000000
--- a/.changeset/5729-column-sortability-signal.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-'@object-ui/core': minor
-'@object-ui/data-objectstack': patch
-'@object-ui/plugin-grid': patch
----
-
-Grid headers offer a sort click only on columns the PLATFORM says it will order by
-(objectui#5729 — the consumer leg of objectstack#10235, maintainer ruling A, 2026-08-23:
-the platform serves an explicit per-column sortability signal and the grid reads it,
-rather than re-deriving "virtual ⇒ unsortable" from field type).
-
-`GET /api/v1/meta/object/:name` now answers with a `sortability` projection on its
-ENVELOPE — `{ fields: { [name]: { sortable, reason?, caveat? } } }`, computed at serve
-time from the platform's own storage predicates, deliberately beside `item` rather than
-inside it so the key stays un-authorable. The signal was reaching the browser and being
-discarded one line before its only consumer: `ObjectStackAdapter.getObjectSchema` unwraps
-the envelope to `item`, so every UI reader saw a document with no signal on it. It now
-survives that unwrap, carried on the schema under a symbol key — invisible to
-`JSON.stringify`, to `Object.keys` and to a spread, so a schema handed back at a metadata
-write endpoint can never take it into a body the server parses strictly.
-
-`@object-ui/core` gains the one spelling of the consumer contract:
-`isPlatformSortableField(projection, name)` is `true` iff an entry EXISTS for the name and
-says `sortable: true`. Absence is a refusal — it is how the platform encodes an unknown
-name, a dotted path and an unprovisioned audit column, all three of which the runtime
-doors reject — so the `!== false` spelling every other optional flag in this repo uses
-would get exactly that family backwards. A projection that is absent ALTOGETHER is a
-different question with a different answer (`undefined`: no signal was served) and is
-typed apart from an empty one, so a deployment older than the upstream change keeps the
-behaviour it had rather than being told, falsely, that nothing on the object is sortable.
-
-Three things follow in the grid. The header click on a refused column ceases to exist, so
-neither the old silent-unordered result nor the `400 INVALID_SORT` that replaced it is
-reachable from it. A sort PERSISTED before the signal existed is filtered out of both what
-the grid renders and what it emits, so a restored personalization cannot ride back into
-the next `persistViewPatch({ sort })` — the half-fix where the affordance is gone and the
-PUT still fires. And the relational carve-out is untouched and deliberately not delegated
-to this signal: the platform answers `sortable: true` for a `lookup` (it has a stored
-foreign key and both runtime doors accept ordering by it), while the grid withholds that
-header for a different reason — a column of names ordered by an invisible id.
-
-Columns carrying `caveat: 'unprovisioned-anchor'` keep their click. The runtime accepts
-those sorts; refusing what the platform does not refuse would recreate declared-≠-enforced
-drift in mirror image.
diff --git a/.changeset/5733-changeset-presence-population.md b/.changeset/5733-changeset-presence-population.md
deleted file mode 100644
index a50347b9c0..0000000000
--- a/.changeset/5733-changeset-presence-population.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
----
-
-Tooling only; no published package behaviour changes.
-
-`scripts/check-changeset-presence.mjs` counted a changed file as a package's source
-only when it sat under `<pkg>/src/`. `apps/console/index.html` does not — it is the
-console's HTML entry, compiled into the published `dist/`, and it carries two inline
-classic scripts that run in every user's browser during parse. A pull request editing
-only that file changed shipped console behaviour while the gate reported
-`No source of a released package changed in this range` (objectui#5733).
-
-The population is now the package's published, executable source: `<pkg>/src/`, plus
-the bundler's HTML entry, plus whatever the package's own `package.json` `files` list
-publishes verbatim — minus documentation and licences, which ship but are not
-behaviour. On this tree the widening adds exactly three files
-(`apps/console/index.html`, `apps/console/plugin.ts`, `packages/runner/index.html`)
-and nothing else in any package directory.
diff --git a/.changeset/5753-providers-drop-spec-dep.md b/.changeset/5753-providers-drop-spec-dep.md
deleted file mode 100644
index eb0756fe59..0000000000
--- a/.changeset/5753-providers-drop-spec-dep.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-'@object-ui/providers': patch
----
-
-`@object-ui/providers` no longer declares `@objectstack/spec` as a dependency. Nothing
-in the package imports it, so consumers stop installing it on this package's account
-(objectui#5753).
-
-The edge was live for exactly one release cycle. It was promoted from `devDependencies`
-to `dependencies` when `ThemePreference` was derived from the spec's `ThemeMode` union,
-because the package's public `.d.ts` then referenced the spec. objectui#5716 re-pointed
-that derivation at `@object-ui/types` (`ThemeMode` / `THEME_MODES`), which removed the
-last three import sites — `src/types.ts` and the two retirement-era test files — and
-left the declaration behind with no reader.
-
-Re-measured on `origin/main` at `ad0f5f11f` before removal, with a positive control so
-the empty result is a real absence rather than a broken command: the import-shaped grep
-(`from` / `require(` / `import(` / `vi.mock(` against `@objectstack/spec`, bare name and
-every subpath) returns **0** hits under `packages/providers/` and **434** across
-`packages/` + `apps/` — same command, same invocation. The only surviving mentions in
-the package are the declaration itself, immutable `CHANGELOG.md` history, and a prose
-comment in `tsconfig.test.json` that this change corrects.
-
-No API change and no behaviour change: `dist/types.d.ts` imports only `react` and
-`@object-ui/types`, and no emitted file references a spec symbol. Consumers on an
-isolated `node_modules` (pnpm) never had supported access to the spec through this
-package, so nothing they could legitimately import goes away — the change is to the
-install graph only, which is why it is scored `patch` rather than `minor`.
diff --git a/.changeset/5754-ci-runs-hook-selftests.md b/.changeset/5754-ci-runs-hook-selftests.md
deleted file mode 100644
index ed261bbe01..0000000000
--- a/.changeset/5754-ci-runs-hook-selftests.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
----
-
-CI-only change: no published package's `src/` changed.
-
-Adds `.github/workflows/hook-selftests.yml`, a new PR/push gate over
-`.claude/hooks/*.selftest.sh` — the hermetic self-test matrices for the
-PreToolUse guards behind the worktree-first and never-`git stash` rules. Runs
-on any PR touching `.claude/hooks/**` or the workflow itself; fails the build
-the moment either matrix goes red. Does not modify the hooks or their
-self-tests. Paired writes: `content/docs/guide/ci-cd-pipeline.md` (workflow
-inventory) and `scripts/dependabot-merge-gate.mjs` (classifies the new check
-as `OPTIONAL_CONTEXTS`, following `Changeset Bump Policy`'s path-filtered
-shape).
diff --git a/.changeset/5775-lane-changeset-reader-mirror.md b/.changeset/5775-lane-changeset-reader-mirror.md
deleted file mode 100644
index 0a8e5a5070..0000000000
--- a/.changeset/5775-lane-changeset-reader-mirror.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
----
-
-CI-only change: the `lane` job in `.github/workflows/changeset-release.yml` now scans
-`.changeset/pre/*.md` as well as `.changeset/*.md`, and matches the reader's README
-exclusion case-insensitively (`/^README\.md$/i`) instead of comparing the one exact
-spelling. `scripts/__tests__/changeset-release-lane-mirror.test.ts` pins the step's
-script against the installed `@changesets/read`, executed rather than transcribed, so a
-dependency bump that changes the ignore list fails there instead of drifting.
-
-No published package changes, and no release behaviour changes: `pending_changesets`
-gates only the release job's clear step, and both edits make it count MORE, never less.
diff --git a/.changeset/5793-spec-range-floors.md b/.changeset/5793-spec-range-floors.md
deleted file mode 100644
index 74fd71c447..0000000000
--- a/.changeset/5793-spec-range-floors.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-'@object-ui/plugin-detail': patch
----
-
-`@object-ui/plugin-detail` now declares `"@objectstack/spec": "^17.1.0"` rather than
-`^17.0.0`, which is the lowest published spec that carries the symbol its own build
-output re-exports (objectui#5793).
-
-`dist/renderers/record-reference-rail.d.ts` reads
-`export type { ReferenceRailEntry } from '@objectstack/spec/ui'`, and
-`ReferenceRailEntry` first appears in `@objectstack/spec@17.1.0` — measured against the
-published tarballs, not the installed tree: the name is absent from 17.0.0's
-`dist/ui/index.d.mts` (425 exported names) and present in 17.1.0's (442). So the old
-range was a claim the package could not honour. Any consumer resolution that lands
-17.0.0 — a sibling pinning it exactly, an `overrides` entry, a mirror a minor behind —
-satisfied `^17.0.0` and got a dangling type re-export.
-
-Nothing a consumer installs today changes: normal resolution already picks the newest
-17.x, and `pnpm-lock.yaml` still resolves 17.2.0 on this edge after the bump. The change
-is to the declared floor only, which is why it is scored `patch` rather than `minor` —
-the same reasoning objectui#5753 used for the other direction on this dependency.
-
-The bump is one instance; the durable half is `scripts/check-spec-range-floors.mjs`, a
-gate that compares every published package's `dist` imports of `@objectstack/spec/*`
-against the export set of that package's own declared minimum. It runs on the publish
-path (`pnpm changeset:publish`) and nightly, and it names the symbol behind every range
-it asks for. No other package's floor is touched: the gate finds nothing else to justify
-one across the 19 packages that declare the spec in a consumer-facing field.
diff --git a/.changeset/5795-related-list-inherit-list-view-sort.md b/.changeset/5795-related-list-inherit-list-view-sort.md
deleted file mode 100644
index ba4b8789e3..0000000000
--- a/.changeset/5795-related-list-inherit-list-view-sort.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-'@object-ui/app-shell': minor
-'@object-ui/plugin-detail': minor
----
-
-An auto-derived related list now orders its rows by the CHILD object's default list view
-`sort`, instead of falling to the server's primary-key order (objectui#5795). A task
-version's "check items" tab whose child object declares `sort: [{ field: 'seq_no' }]`
-renders 10/20/30/40; before this it rendered whatever order the ids happened to give —
-20/30/10/40 in the reported case — while the child object's own list page obeyed the
-declaration.
-
-**Declared as user-visible, deliberately, even though no key was added.** The contract
-question ("where does a derived related list's sort declaration live?") was ruled on
-objectstack#11345 (maintainer, 2026-08-23) as **direction 1**: inherit the child's list
-view sort, and add **no** new spec key — the field-level `relatedListSort` the issue also
-proposed was explicitly not approved. So there is nothing new to author, and
-`record:related_list.sort` was already declared, parsed and consumed; this fills it. What a
-host observes is nonetheless new: a derived related-list descriptor gains a populated
-`sort` where it had none, and the query it issues gains an `$orderby`. An app whose child
-objects declare a default list order will see those tabs re-order on upgrade — which is the
-point of the change, and is why this is not a patch.
-
-Nothing is inherited where nothing was declared: a child object with no default list-view
-sort produces the same descriptor, the same node and the same `$orderby`-free query as
-before.
-
-The two `sort` surfaces declare the same union and mean different things by its string arm
-— a `ListView` string is the legacy space-separated `'seq_no desc'`, while the related
-list's own reader takes `'field'` / `'-field'` — so the inherited value is normalized to
-the array arm once, at the derivation, through `@object-ui/core`'s
-`convertSortToQueryParams` (the repo's single definition of both authored dialects). An
-un-normalized inherit would have ordered by a field literally named `seq_no desc`.
-
-Known and unchanged: `$orderby` is only assembled while the related list is in windowed
-(server-paged) mode, so a declared *or* inherited sort still disappears while the built-in
-client text filter is active. That hole pre-dates this change and affects the authored prop
-identically; it is now pinned as a recorded fact in
-`plugin-detail/src/__tests__/RelatedList.sortDroppedOutsideWindowed.test.tsx` rather than
-fixed here.
diff --git a/.changeset/5853-tablecolumn-type-canonical-union.md b/.changeset/5853-tablecolumn-type-canonical-union.md
deleted file mode 100644
index 47431dd506..0000000000
--- a/.changeset/5853-tablecolumn-type-canonical-union.md
+++ /dev/null
@@ -1,74 +0,0 @@
----
-'@object-ui/types': minor
-'@object-ui/components': patch
-'@object-ui/plugin-grid': patch
-'@object-ui/plugin-dashboard': patch
----
-
-`TableColumn.type` now has ONE canonical value set across all three ends that disagreed
-(objectui#5853, maintainer ruling 2026-08-25, Option B: the 8-literal interface union is
-canonical). The interface declared `'text' | 'number' | 'date' | 'datetime' | 'currency' |
-'percent' | 'boolean' | 'action'`; the zod mirror declared `z.string()` and accepted
-anything; the renderer branched on a third set and could only read the key through an
-`as any` cast.
-
-## ⚠️ Accept-set narrowing — these spellings stop validating
-
-`TableColumnSchema.type` was `z.string().optional()`. **Any string parsed green.** It is now
-`z.enum(TABLE_COLUMN_TYPES).optional()`, so a value outside the eight is refused at parse
-time with `type` named in the error path. Spellings that validated before and are **refused
-now**, grouped by why they were being written:
-
-- **Typos and invented names** — `'money'`, `'datetime2'`, `'string'`, `'int'`, `'integer'`,
-  `'float'`, `'double'`, `'datetime-local'`, and every other free-form string. `'money'` is
-  the card's headline case: it validated, matched no renderer branch, and the column fell
-  through to plain text rendering with nothing reported. That silent fall-through is the
-  lenient-validation face that lets AI-authored metadata errors through, and it is now a
-  loud parse failure.
-- **Object-schema field types written into a column slot** — `'select'`, `'lookup'`,
-  `'user'`, `'file'`, `'formula'`, `'textarea'`, `'email'` and the other 35 members of
-  `@objectstack/spec`'s `FieldType` that are not among the eight. These belong on the FIELD,
-  not on the column: a column gets its dedicated widget from the field definition behind its
-  `accessorKey`, never from `type`.
-
-**Authored metadata in this repo needs no migration.** Measured before tightening, across
-`examples/`, `content/`, `apps/`, `e2e/`, `docs/` and every package (591 JSON schema files
-plus the docs and playground sources): **zero** authored `TableColumn.type` values outside
-the eight, and zero occurrences of `int` / `integer` / `float` / `double` in a column
-position anywhere in the repository. If you author `type` on a table column, check it
-against the eight; if the value describes the FIELD rather than the column, remove it.
-
-## The renderer's undeclared vocabulary disappears instead of being declared
-
-`int` / `integer` / `float` / `double` were members of the data-table's `NUMERIC_EDIT_TYPES`
-and `datetime-local` had its own editor branch, none of them declared. They arrived because
-column-inference producers forwarded an object schema's field type **verbatim** into
-`TableColumn.type`. Rather than publishing that dialect, producers now fold their inferred
-value onto the declared vocabulary at their emit seam via the new
-`normalizeTableColumnType()`: `int`/`integer`/`float`/`double` → `number`,
-`datetime-local` → `datetime`, and **anything else drops the `type` annotation — never the
-column**. Two producers do this, not the one the card named: `ObjectGrid` (`@object-ui/plugin-grid`)
-and `ObjectDataTable` (`@object-ui/plugin-dashboard`), whose `buildFieldMeta` spread wrote
-the raw field type into the same slot.
-
-Dropping the annotation is behaviour-preserving at the only consumer that reads the key.
-`data-table`'s inline editor branches on `date`, `datetime` and the numeric set and
-otherwise falls through to a text input — which is exactly the `undefined` path. The
-dedicated widget a `select` or `lookup` column gets comes from the host's `renderCellEditor`,
-which resolves the field through `column.accessorKey` and never reads `type`.
-
-## New public API
-
-`@object-ui/types` exports `TABLE_COLUMN_TYPES` (the canonical tuple — the single
-declaration the zod mirror builds its enum from, so the two cannot drift), the
-`TableColumnType` union, and `normalizeTableColumnType()` for producers. The `as any` cast
-in `data-table.tsx` is deleted and the read is typed, so re-introducing an undeclared
-spelling is a tsc error rather than a silent widening.
-
-A value-level parity pin covers all three ends
-(`packages/types/src/__tests__/table-column-type-canonical.test.ts` and
-`packages/components/src/renderers/complex/__tests__/table-column-type-read-set.test.tsx`).
-objectui#5684's guard is key-set only and cannot see value drift — `type` was present on
-both sides the whole time — which is how this instance survived while its siblings were
-caught. A future inference value turning that pin red is by design; the note at the pin says
-so, and names the two correct repairs.
diff --git a/.changeset/5856-plugin-grid-catalog-entries.md b/.changeset/5856-plugin-grid-catalog-entries.md
deleted file mode 100644
index e44709e0e4..0000000000
--- a/.changeset/5856-plugin-grid-catalog-entries.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
----
-
-Docs and catalog fixtures only, no shipped code touched: the two `plugin-grid` catalog
-entries are now real `object-grid` nodes instead of hand-built static card layouts.
-`content/docs/plugins/plugin-grid.mdx` mounted `product-inventory-grid` and
-`team-members-grid` under `PluginLoader plugins={['grid']}` while both authored only
-`badge button card flex stack text` — pictures of a grid, not a grid. They are replaced
-by `object-grid-columns` (a `ListColumn` set with `sort`, `searchableFields` and
-`pagination`) and `object-grid-selection-summaries` (multi-row `selection`, named
-`rowActions` / `bulkActions`, per-column footer `summary` roll-ups), both querying the
-docs gallery's demo data source the same way the `plugin-view` entries have since
-objectui#5113.
-
-The two mock-ups are legitimate static layouts filed under the wrong plugin, so they are
-re-seated into `components-layout-card` as `inventory-table-card` and `team-roster-card`
-rather than deleted — deleting a catalog entry moves three corpus-wide counters
-(`NODE_CENSUS` in `layout-dom-leak-5574.test.tsx`, and the `className`-carrying layout
-node and `stack` node floors in `layout-props-conversion.test.tsx`), and a floor that
-moves because a fixture was deleted is indistinguishable later from one that moved
-because coverage regressed. All three are unchanged, with no floor edited.
-
-objectui#5113's pin in `catalog-gallery-render.test.tsx` is extended to cover
-`plugin-grid` through an explicit two-entry category/type map, keeping both of its halves
-— every entry authors the type its own package registers, and the rendered tile shows a
-record that exists only in the gallery's data source.
diff --git a/.changeset/5859-retire-orphaned-object-exports.md b/.changeset/5859-retire-orphaned-object-exports.md
deleted file mode 100644
index 7e460424ea..0000000000
--- a/.changeset/5859-retire-orphaned-object-exports.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-'@object-ui/types': minor
----
-
-`ObjectTrigger` and `ObjectRelationship` are removed from `@object-ui/types` — two
-hand-written interfaces orphaned by the `ObjectSchemaMetadata` derivation
-(objectui#5859, triage adjudication 2026-08-24; the derivation itself was
-objectui#5362).
-
-**Breaking for anyone importing either name.** The two symbols are, verbatim:
-
-- `ObjectTrigger` — the `{ name, when, on, condition?, action, config? }` trigger
-  configuration
-- `ObjectRelationship` — the `{ name, object, type, foreign_key?, cascade_delete? }`
-  relationship configuration
-
-Both existed solely to type members of the retired hand-written object-document mirror:
-`triggers?: ObjectTrigger[]` and `relationships?: ObjectRelationship[]`. objectui#5362
-replaced that mirror by deriving `ObjectSchemaMetadata` from `@objectstack/spec/data`'s
-`ServiceObject`, and the spec's object document declares neither member — so the two
-interfaces have had nothing to type since. objectui#5362 deliberately left them standing
-because cutting published exports is a separate decision from the ruled derivation; this
-is that decision.
-
-Measured before removing, on `main`: zero references in this repo outside the declaration
-and the `src/index.ts` re-export (`packages/`, `apps/`, `examples/`, `*.ts`/`*.tsx`,
-`node_modules` and `dist` excluded), and zero in the sibling `objectstack` checkout, which
-does import `@object-ui/types` in eleven files. Absence of a spec correspondence was
-verified at type level against the installed `@objectstack/spec` 17.2.0 rather than
-inherited from the card: neither `triggers` nor `relationships` is a key of
-`ServiceObject`. `DataModelDesigner`'s `relationships` state is its own local model and
-never referenced these types.
-
-**That measurement cannot see npm.** In-repo zero is not consumer zero — an external
-application importing either name from `@object-ui/types` will fail to compile after this
-release, and nothing in this repository can detect that. Both names are spelled out above
-so a host can search its own sources for them. If you were importing either, the shapes
-were client-side vocabulary with no runtime behaviour and no spec backing: copy the
-interface into your own code, or model the concept against `@objectstack/spec`, which owns
-the object document.
-
-Type-only change; nothing is emitted and no runtime behaviour moves. Ships `minor`, not
-`major`, per the version-alignment convention in AGENTS.md — objectui's major tracks
-`@objectstack`'s, and breaking changes of objectui's own carry `minor` with the semantics
-stated in the body.
diff --git a/.changeset/5867-layout-plaintext-fences-batch5.md b/.changeset/5867-layout-plaintext-fences-batch5.md
deleted file mode 100644
index 089856b3da..0000000000
--- a/.changeset/5867-layout-plaintext-fences-batch5.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
----
-
-Documentation only: re-fenced the 12 TypeScript blocks in `content/docs/layout/**` that were
-fenced `plaintext`, so `check-doc-snippet-types` compiles them, and fixed the four blocks it
-then reddened (a missing `AppShellBranding` import, three examples using components and values
-they never imported, and two `AppShell` examples that passed no children). Lowered
-`KNOWN_UNHIGHLIGHTED_TS_FENCES` by the three layout files in the same change. No published
-behaviour changes.
diff --git a/.changeset/5867-plaintext-fenced-ts-batch1.md b/.changeset/5867-plaintext-fenced-ts-batch1.md
deleted file mode 100644
index 80ee21ed4b..0000000000
--- a/.changeset/5867-plaintext-fenced-ts-batch1.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
----
-
-Docs only, publishes nothing: twenty-four TypeScript snippets across thirteen
-`content/docs/fields/*.mdx` reference pages were fenced ```plaintext, so
-`check-doc-snippet-types` — which reads only `ts` / `tsx` fences — never saw
-them (objectui#5867, batch 1 of N). Triage's classifier is the one applied: a
-plaintext block whose first line starts with `import` / `export` / `interface` /
-`type X =` / `const x: T` is code, and those fences are now `ts`; genuinely
-prose blocks on the same pages (a bare object literal, a comment-only
-illustration) are left alone. The gate's blocks-to-compile count rises from 157
-to 181 — exactly the batch — with diagnostics at 0, no new `FRAGMENT_MARKER`
-declarations, and the covered/ungated sets unmoved. The blocks also stop
-rendering as unstyled plaintext and pick up TypeScript highlighting, which is
-the reader-visible half.
diff --git a/.changeset/5867-plaintext-fenced-ts-batch2.md b/.changeset/5867-plaintext-fenced-ts-batch2.md
deleted file mode 100644
index 6c65b12f7c..0000000000
--- a/.changeset/5867-plaintext-fenced-ts-batch2.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
----
-
-Docs only, publishes nothing: twenty-one TypeScript snippets across three
-`content/docs/core/*.mdx` reference pages were fenced ```plaintext, so
-`check-doc-snippet-types` — which reads only `ts` / `tsx` fences — never saw
-them (objectui#5867, batch 2 of N). Triage's classifier is the one applied: a
-plaintext block whose first line starts with `import` / `export` / `interface` /
-`type X =` / `const x: T` is code, and those fences are now `ts` / `tsx`;
-genuinely prose blocks on the same pages are left alone. Compiling them found
-three real documentation defects, now fixed: `app-schema` documented an
-`AppSchema` type `@object-ui/types` has never exported (the shipped name is
-`AppComponentSchema`), and two `enhanced-actions` callbacks authored an
-`ActionCallback.dialog` object with no `type` key, which `SchemaNode` requires.
-Blocks that referenced ambient names are made self-contained with the import a
-reader copying them needs. The gate's blocks-to-compile count rises from 181 to
-202 — exactly the batch — with diagnostics at 0, no new `FRAGMENT_MARKER`
-declarations, and the covered/ungated sets unmoved. The blocks also stop
-rendering as unstyled plaintext and pick up TypeScript highlighting, which is
-the reader-visible half.
diff --git a/.changeset/5867-plaintext-fenced-ts-batch3.md b/.changeset/5867-plaintext-fenced-ts-batch3.md
deleted file mode 100644
index 523ebb6a4d..0000000000
--- a/.changeset/5867-plaintext-fenced-ts-batch3.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
----
-
-Docs only, publishes nothing: seventeen TypeScript snippets across ten
-`content/docs/fields/*.mdx` reference pages were fenced ```plaintext, so
-`check-doc-snippet-types` — which reads only `ts` / `tsx` fences — never saw
-them (objectui#5867, batch 3 of N). Triage's classifier is the one applied: a
-plaintext block whose first line starts with `import` / `export` / `interface` /
-`type X =` / `const x: T` is code, and those fences are now `ts`; genuinely
-prose blocks on the same pages are left alone. Compiling them found two real
-documentation defects, now fixed: `image` annotated `ImageFieldSchema.value`
-with `FileMetadata`, a name `@object-ui/types` does not export — it was
-deliberately renamed to `UploadedFileMetadata` (objectstack#4115) because the
-spec's same-named type is the storage layer's file record, a different shape —
-and `lookup` referenced `DataSource` without importing it. The gate's
-blocks-to-compile count rises from 206 to 223 — exactly the batch — with
-diagnostics at 0, no new `FRAGMENT_MARKER` declarations, and the
-covered/ungated sets unmoved. The blocks also stop rendering as unstyled
-plaintext and pick up TypeScript highlighting, which is reader-visible. Three
-further `fields` pages are excluded by measurement with blockers filed:
-`auto-number` (an ambient backend `db` handle), `object` (imports `ajv`, not a
-workspace dependency) and `location` (one fence welds a JSX element and a bare
-metadata object literal, so it parses as neither `ts` nor `tsx`).
diff --git a/.changeset/5867-plaintext-fenced-ts-batch4.md b/.changeset/5867-plaintext-fenced-ts-batch4.md
deleted file mode 100644
index 88d2a22e54..0000000000
--- a/.changeset/5867-plaintext-fenced-ts-batch4.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
----
-
-Docs only, publishes nothing: nineteen TypeScript snippets across
-`content/docs/blocks/block-schema.mdx` and six `content/docs/plugins/*.mdx`
-reference pages were fenced ```plaintext, so `check-doc-snippet-types` — which
-reads only `ts` / `tsx` fences — never saw them (objectui#5867, batch 4 of N).
-Triage's classifier is the one applied: a plaintext block whose first line
-starts with `import` / `export` / `interface` / `type X =` / `const x: T` is
-code, and those fences are now `ts`; genuinely prose blocks on the same pages
-are left alone. Compiling them found real documentation defects on
-`block-schema`, now fixed: the *Complete Example*, *Block Slots* and
-*Marketplace Example* blocks annotated `BlockSchema` / `SchemaNode` /
-`BlockLibrarySchema` without importing them, and three blocks referenced values
-defined in other blocks on the page. Resolving `BlockLibrarySchema` then
-un-masked a defect the unresolved name had been suppressing: both marketplace
-listings carried `schema: { /* block schema */ }`, an empty object that
-`BlockLibraryItem.schema` rejects because `BlockSchema` requires `type`. The
-gate's blocks-to-compile count rises from 206 to 225 — exactly the batch — with
-diagnostics at 0, no new `FRAGMENT_MARKER` declarations, and the
-covered/ungated sets unmoved. The blocks also stop rendering as unstyled
-plaintext and pick up TypeScript highlighting, which is the reader-visible half.
diff --git a/.changeset/5874-expandable-field-family-convergence.md b/.changeset/5874-expandable-field-family-convergence.md
deleted file mode 100644
index bcbee7fa1d..0000000000
--- a/.changeset/5874-expandable-field-family-convergence.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-'@object-ui/plugin-kanban': patch
-'@object-ui/plugin-detail': patch
-'@object-ui/app-shell': patch
----
-
-Four more private copies of the reference-bearing field family converge onto
-`@object-ui/core`'s `EXPANDABLE_FIELD_TYPES`, and the "fourth and last private copy" claim
-that `paramToField` still stated is corrected (objectui#5874, objectui#5875).
-
-Each copy diverged from the published family in BOTH directions, so this is a behaviour
-change on every face and not a refactor:
-
-- **`user` and `tree` are now treated as relations.** Both carry the same foreign-key
-  storage as `lookup` and resolve through the same expand path (objectui#2032), and each
-  face's own stated reason for special-casing `lookup` applied to them verbatim — so
-  gaining them restores the rule each face already meant. A `user` / `tree` field is now
-  read-only in the quick-look drawer (`RecordDetailDrawer`), where the drawer wires no
-  relation picker and a plain text input let a user overwrite the relation with a
-  free-form string; it gets the wide layout basis in the record header's highlights strip
-  (`HeaderHighlight`), whose inline editor is a record picker; and a field-backed action
-  param over one now inherits the picker config it needs (`resolveActionParams`).
-- **`master_detail` is now treated as a relation by `resolveActionParams` too** — it was
-  the only face missing that member as well, so a field-backed `master_detail` action param
-  inherited no `referenceTo` at all and degraded to the unexplained "paste a record id"
-  text input that objectui#3405 exists to prevent.
-- **The undeclarable `reference` spelling is gone from the three field-type faces.**
-  Measured against `@objectstack/spec`'s closed `FieldType` vocabulary with live controls
-  (`lookup` / `master_detail` / `user` / `tree`) and dead ones (the retired `owner`, plus a
-  nonsense spelling): `reference` is absent, so no spec-compliant object schema could
-  declare a field that reached those branches. It sat exactly where `owner` sat before
-  objectui#4814 retired it — dead weight that read as live capability.
-
-`resolveActionParams` keeps answering for `reference`, deliberately and by a different
-route: it is refused by the spec's `ActionParamSchema` too, but the dialog still accepts it
-from params already authored with it, and that acceptance belongs to the one alias table in
-`paramToField` rather than to a hand-copied membership test. This face now asks the shared
-family over the widget key that table produces — the same expression `paramToField`
-evaluates one step later, so the half that populates a param's picker config and the half
-that forwards it can no longer disagree.
-
-No face copies the set: each calls `.has()` on the object `@object-ui/core` exports, and
-each carries an identity pin (a spy on that `has`) so a member-identical private copy fails
-instead of quietly re-forking the table.
diff --git a/.changeset/5876-one-lookup-predicate.md b/.changeset/5876-one-lookup-predicate.md
deleted file mode 100644
index a774fa8767..0000000000
--- a/.changeset/5876-one-lookup-predicate.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-'@object-ui/plugin-dashboard': patch
----
-
-The dashboard package now holds ONE relation predicate instead of two that
-agreed only because a sweep had just aligned them (objectui#5876).
-
-`computeLookupExpand` in `ObjectDataTable.tsx` carried its own `isLookup`,
-byte-identical to the exported `isLookupType` in `recordFields.tsx` after
-objectui#5692 pointed both at `@object-ui/core`'s `EXPANDABLE_FIELD_TYPES`.
-Nothing kept them aligned: a future edit to either — a member added, the
-retirement gate moved — would have re-forked the `$expand` decision from the
-predicate whose docblock claims to drive it. `computeLookupExpand` now calls
-`isLookupType`, which gains its first production consumer, and the module no
-longer imports the shared family or the retirement gate at all.
-
-**No behaviour changes**, and that is measured rather than assumed:
-
-- The two bodies were identical, so every boolean answer — `tree` is expanded,
-  `reference` is not, ordinary relations are — is the same before and after.
-- The retired-spelling warning is not emitted a different number of times.
-  `reportRetiredFieldType` dedupes per SPELLING in one module-level set inside
-  `@object-ui/core`, which both bodies already shared, so routing two callers
-  through one function cannot change the count.
-
-Nothing published moves: `isLookupType` is not re-exported from
-`@object-ui/plugin-dashboard`'s entry, so this is internal shape only.
-
-Because a refactor with no observable delta cannot be pinned by a behavioural
-test — a byte-identical local copy satisfies every assertion you can write
-about `$expand` — the pin is identity, in
-`__tests__/expandableFamily.identity-5692.test.ts`: `computeLookupExpand` is
-observed CALLING `isLookupType`, and `ObjectDataTable.tsx` is read at source
-level to confirm no second body survives for it to call instead.
diff --git a/.changeset/5902-marked-refusal-drag-write-surfaces.md b/.changeset/5902-marked-refusal-drag-write-surfaces.md
deleted file mode 100644
index 831e3de14c..0000000000
--- a/.changeset/5902-marked-refusal-drag-write-surfaces.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-'@object-ui/plugin-kanban': patch
-'@object-ui/plugin-calendar': patch
-'@object-ui/plugin-form': patch
----
-
-Let a producer-marked refusal reach the drag-write surfaces (objectui#5902).
-
-The kanban card-move toast, the calendar drag-to-reschedule toast and the OCC
-conflict dialog each substituted a generic string for a refusal the producer had
-marked as user-facing (`userMessage`), so a user was told "Save failed" where the
-application author had written a sentence addressed to them. All three now read
-the marking through the shared `declaredUserMessage` reader, which covers both
-places the adapter boundary parks it — the typed member on
-`ConcurrentUpdateError` and the details bag on `DataApiValidationError`.
-
-Nothing unmarked changes: the reader answers `null` for it, so every existing
-generic substitution — including the localized "not authorized" message that
-keeps raw server diagnostics away from end users — still governs unmarked
-refusals exactly as before.
-
-The two toasts substitute; the conflict dialog augments. Its description also
-explains what the destructive "Overwrite" button does, which is affordance copy
-that surface owns rather than a refusal message, so the marking leads and that
-paragraph stays.
diff --git a/.changeset/5903-objectgantt-declared-keys.md b/.changeset/5903-objectgantt-declared-keys.md
deleted file mode 100644
index de0c6da6f5..0000000000
--- a/.changeset/5903-objectgantt-declared-keys.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-'@object-ui/types': minor
-'@object-ui/plugin-gantt': minor
----
-
-`ObjectGanttSchema` declares the ten gantt keys `ObjectGantt` actually reads
-(objectui#5903, triage 2026-08-24). Every one is a real, working, documented
-feature — `readOnly`, `mobileReadOnly`, `markers`, `navigation`, `skipWeekends`,
-`holidays`, `criticalPath`, `showBaselines`, `persistLayout`, `viewName` — and
-none of them was discoverable from the published type, because all ten were read
-as `(schema as any).K`. The cast was the load-bearing part: it kept the read
-invisible to `tsc`, to the zod mirror and to the designer's registry `inputs`.
-
-Both halves move together. The TS declaration (`packages/types/src/objectql.ts`)
-and its zod mirror (`src/zod/objectql.zod.ts`) gain the same ten keys at the same
-requiredness — all optional — so the `zod-mirror-parity` ratchet stays at zero
-drift for this pair and no `KnownDrift` entry is added. `navigation` is taken
-from `@objectstack/spec`'s `NavigationConfigSchema` by reference rather than
-restated, matching `ObjectGridSchema.navigation`.
-
-`ObjectGanttProps.schema` is retyped from `ObjectGridSchema` to
-`ObjectGanttSchema`. That is what makes the declaration load-bearing: the ten
-keys are not grid keys, so with the old prop type, dropping the casts would have
-left the reads landing on `BaseSchema`'s index signature — the same invisibility
-in different syntax. The grid-style `{ gantt: { … } }` block is unaffected;
-`getGanttConfig` reads it through that index signature exactly as before, and the
-registered renderer passes `schema: any`, so no runtime shape is turned away.
-
-Accept-set change, stated plainly: a **declared** key is now type-validated, so
-`readOnly: 'yes'` is refused where it used to parse green — the same narrowing
-objectui#5074 landed for `viewMode`. An **undeclared** key is still accepted:
-`BaseSchema` is `.passthrough()` and carries an index signature (objectui#5155's
-structural ceiling), so declaring these ten did not buy rejection of a
-misspelling. `packages/types/src/__tests__/gantt-declared-keys.test.ts` pins both
-halves so neither can be misread.
-
-The eleventh reported key, `label`, needed no declaration — `BaseSchema` already
-carries it — so only its cast was dropped.
diff --git a/.changeset/5916-record-path-stage-state-accessible-name.md b/.changeset/5916-record-path-stage-state-accessible-name.md
deleted file mode 100644
index 7b6bf579e1..0000000000
--- a/.changeset/5916-record-path-stage-state-accessible-name.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-'@object-ui/plugin-detail': patch
-'@object-ui/i18n': patch
----
-
-`record:path` now announces each stage's state, not just its label (WCAG 2.2 SC 1.4.1)
-
-The lifecycle path distinguished travelled, upcoming and lost-terminal stages with
-colour plus a `✓`/`✗` glyph, and both glyphs are `aria-hidden` decoration.
-`aria-current="step"` marked the current stage and nothing else, so a screen-reader
-user heard a run of identically-announced items — and a rejected stage announced
-exactly like an ordinary stage the record had not reached yet.
-
-Each stage now carries an accessible name composing its (already picklist-localized)
-label with its state, from five new `detail.pathStage*` keys translated in all ten
-locale packs. The glyphs stay decorative and the readout's `role="listitem"` /
-`aria-current` semantics are unchanged.
-
-The name is composed into `aria-label` rather than visually-hidden text because
-`listitem` takes its name from the author only: text placed inside a stage computes
-to an empty accessible name, so the visually-hidden shape would have looked right in
-the markup and delivered nothing to the accessibility tree.
diff --git a/.changeset/5924-live-headroom-invariant.md b/.changeset/5924-live-headroom-invariant.md
deleted file mode 100644
index 11faf78eb2..0000000000
--- a/.changeset/5924-live-headroom-invariant.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
----
-
-Build tooling and CI only — `scripts/check-eager-closure-budget.mjs`, its unit
-test, and a comment in `.github/workflows/performance-budget.yml`. Nothing ships
-from this change.
-
-The console eager-closure gate stated a binding constraint on its own
-sensitivity — the headroom above the measured payload must stay SMALLER than the
-89 KiB regression the gate exists to catch — and then checked it between two
-constants frozen in the same module. That assertion is an arithmetic fact about
-the file, true regardless of what the console weighs. The closure shrank 706,013
-gzipped bytes below the pinned baseline without the ceiling following it down,
-the live headroom reached 8.6x the regression size, and the check that was
-supposed to notice stayed green throughout: a demonstrated +158,006-byte eager
-regression, 1.7x the incident this gate was built for, passed with a green tick.
-
-`evaluateHeadroomSensitivity` now derives that headroom from the report the gate
-just read, for the aggregate ceiling and for each of the three per-chunk
-ceilings, and treats a ceiling that has drifted more than one regression above
-its own measurement as an ERROR (exit 2) rather than a size failure — it is a
-verdict about the gauge, the same asymmetry a budgeted chunk absent from the
-report already carried. The constant-vs-constant assertions stay as a secondary
-guard.
-
-The aggregate ceiling is re-baselined downward as the decision this records:
-`MAX_EAGER_CLOSURE_GZIP_BYTES` 4,086,000 to 3,345,000 over a `BASELINE` moving
-4,005,911 (`4c1623c0c`) to 3,299,898 (`48e53814e`). Headroom goes from 8.63x the
-regression size to 0.49x. Lowering a ceiling toward reality is a tightening: no
-build that passed before and measures under the new line fails after it. The
-floor is unchanged — a ceiling is never put below a measured figure.
diff --git a/.changeset/5926-empty-action-visible-when.md b/.changeset/5926-empty-action-visible-when.md
deleted file mode 100644
index 4599bf9b70..0000000000
--- a/.changeset/5926-empty-action-visible-when.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-'@object-ui/components': minor
----
-
-Route a `data-table`'s `emptyAction` node through `SchemaRenderer`, so a `visibleWhen`
-authored on it is actually evaluated (objectui#5926 gap 1).
-
-`visibleWhen` is not a per-block concern in this platform. It is enforced **once,
-generically**, in `packages/react/src/SchemaRenderer.tsx`: `shouldHide` tests `visibleWhen`
-ahead of the hoisted `visible` (objectui#5454), sets `_hidden`, and the `_hidden` early
-return fires **before** the registry dispatches. A block renderer cannot ignore the gate,
-because it never sees the node.
-
-`emptyAction` was the one authored-node exception in the tree. The empty-state CTA slot
-resolved the registry **directly** — `ComponentRegistry.get(node.type)` — and mounted the
-result itself, so the node never passed through `SchemaRenderer` and its `visibleWhen` was
-**never evaluated**. `@objectstack/spec` accepts the key (`SchemaNodeSchema` carries
-`visibleWhen`, and `data-display.zod.ts` types `emptyAction` as a `SchemaNode`), so an
-author wrote a gate, the platform took it, and nothing enforced it — declared-not-enforced,
-the same class objectui#5401 / #5505 closed for `record:alert`, one level down.
-
-Measured on the branch point, mounting a `data-table` with no rows so the empty state is
-actually reached: an `emptyAction` carrying
-`visibleWhen: { dialect: 'cel', source: 'features.can_create == true' }` under an ambient
-scope of `features.can_create = false` **rendered**, and so did the bare-string spelling of
-the same predicate. Both now render nothing. The three must-show cases were pinned in the
-same file and were green before and after — an `emptyAction` whose predicate resolves
-**true**, one declaring **no** `visibleWhen`, and one whose predicate names an unbound root
-(the central gate fails soft to visible, and this slot now gives the same answer as every
-other node rather than a private one).
-
-The fix is a **route**, not a new check: no `visibleWhen` test was added to `data-table.tsx`.
-A local check on this slot would have been a fourth evaluator, which is the drift
-`page:tabs`' item-level predicate already records on this card. The slot now mounts its
-authored node exactly the way the `empty` renderer's `action` slot always has.
-
-**Behaviour change worth declaring, beyond the gate itself.** No declaration moves and no
-new key is accepted, but two host-observable answers change on this slot:
-
-- An `emptyAction` whose `visibleWhen` resolves false stops rendering. That is the fix.
-- An `emptyAction` whose `type` is missing or names an unregistered component now gets the
-  platform's uniform "unknown component type" report instead of rendering as silent
-  nothing. Malformed metadata gets one answer across the tree rather than a private one
-  here — but a page that shipped a typo'd `emptyAction` type went from invisible to visibly
-  reported.
diff --git a/.changeset/5927-zod-mirror-group-a-widenings.md b/.changeset/5927-zod-mirror-group-a-widenings.md
deleted file mode 100644
index aae2128dd3..0000000000
--- a/.changeset/5927-zod-mirror-group-a-widenings.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-'@object-ui/types': minor
----
-
-**`@object-ui/types/zod` now accepts seven spellings its own TypeScript declarations already declared**
-
-Seven keys across five hand-written zod mirrors refused values the published TS
-types invite and the renderer implements — `declared !== enforced` on a published
-validator. The mirrors are widened to their declarations. Nothing is narrowed and
-nothing previously accepted is rejected, so this is additive for every author and
-every host: schemas that parsed before still parse.
-
-The newly-accepted spellings, so a host can search for them:
-
-| schema (`@object-ui/types/zod`) | key | now also accepts |
-|---|---|---|
-| `ButtonGroupSchema` | `variant` | `secondary`, `destructive`, `ghost`, `link` |
-| `ButtonGroupSchema` | `size` | `icon` |
-| `ObjectChartSchema` | `chartType` | `column`, `horizontal-bar`, `donut` |
-| `FormSchema` | `validationMode` | `onTouched`, `all` |
-| `SelectSchema` | `defaultValue`, `value` | `boolean` |
-| `DataTableSchema` | `selectable` | `'single'`, `'multiple'` (alongside `boolean`) |
-| `ViewSwitcherSchema` / `ViewTypeSchema` | `defaultView`, `activeView`, `views[].type` | `chart` |
-
-**Each one was decided by measuring the renderer, not by matching the declaration.**
-Widening a mirror to its declaration is only correct where the running code
-implements the missing spelling; where a spelling is dead, the right fix is to
-withdraw it from the declaration (ADR-0049 enforce-or-remove), not to teach the
-validator to accept something that renders nothing. The read sites:
-`buttonVariants`' `cva` map (`components/src/ui/button.tsx`) carries all six
-variants and all four sizes; `AdvancedChartImpl` normalizes `column` to `bar`,
-maps `horizontal-bar` to a real `BarChart` layout and gives `donut` its own inner
-radius; `useForm({ mode })` hands `validationMode` straight to react-hook-form,
-whose `isOnTouch` / `isOnAll` branches implement `onTouched` and `all`;
-`toControlValue` / `matchOptionValue` (#3090) round-trip a boolean option value
-with its type intact; `resolveSelectionMode` implements `'single'` as
-replace-on-select with no select-all header, distinct from `'multiple'`; and
-`chart` is a rendered view type with its own `case` in both `ListView` and
-`ObjectView`.
-
-Consumer-visible type effect: `z.infer` of these schemas widens accordingly.
-Widening an input contract cannot break a caller that was already passing a
-narrower value, but code that exhaustively switches on the inferred union — e.g.
-a `switch` over `chartType` with no `default` — will want the new arms.
-
-Refs objectui#5927 (group A of the 17 measured mirror drifts). The remaining
-classes are rulings rather than edits and stay in the `KnownDrift` ledger.
diff --git a/.changeset/5940-detail-collection-decline-to-fetch.md b/.changeset/5940-detail-collection-decline-to-fetch.md
deleted file mode 100644
index 2703d95554..0000000000
--- a/.changeset/5940-detail-collection-decline-to-fetch.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-"@object-ui/plugin-form": patch
----
-
-`object-master-detail-form` declines to fetch a detail collection whose child object it never resolved, instead of calling `getObjectSchema(undefined)`.
-
-`childObject` is REQUIRED on `MasterDetailDetailConfig` and is what every downstream read is keyed
-on — `deriveDetail(d.childObject, …)`, the child-schema cache, and the FK scope of each child
-fetch. But a detail entry reaches the renderer straight off an authored schema, so a malformed one
-arrives with the key `undefined`, and the resolve effect asked the data layer for it anyway.
-Measured: mounting the block with a detail entry that carries no `childObject` issued
-`getObjectSchema(undefined)` — a real backend receives a query for an object literally named
-`undefined`, and whatever it returns becomes the console's problem.
-
-The resolve effect now skips such an entry and warns, leaving it in place so the grid card shows
-its config hint and the row-state array stays index-matched. This is the choice `RelatedList`
-already makes for the same class of missing key (*"has no referenceField/parentId — refusing to
-fetch all rows"*), and the sibling child-schema-cache effect in this same component already spelled
-it `.filter(Boolean)`; the three now agree. A detail collection that names its child object fetches
-exactly as before.
diff --git a/.changeset/5944-preview-page-source-query-params.md b/.changeset/5944-preview-page-source-query-params.md
deleted file mode 100644
index 287a5f7a82..0000000000
--- a/.changeset/5944-preview-page-source-query-params.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
----
-
-Test-only change: the ADR-0080 preview harnesses' page sources are now held to
-`object-ui/no-unprefixed-query-params` by that rule itself, run over the source
-strings ESLint structurally cannot reach inside a template literal
-(objectui#5944). No published behaviour changes — the new file is a test under
-`apps/console/src/__tests__/`, and `eslint-rules/` is a repo-local plugin
-directory rather than a workspace package.
diff --git a/.changeset/5956-5957-record-path-a11y-residue.md b/.changeset/5956-5957-record-path-a11y-residue.md
deleted file mode 100644
index d57e248f10..0000000000
--- a/.changeset/5956-5957-record-path-a11y-residue.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-'@object-ui/plugin-detail': patch
-'@object-ui/i18n': patch
----
-
-`record:path` finishes localizing and de-colouring its accessible names — the two residues
-objectui#5916 named and deliberately left behind (objectui#5956, objectui#5957).
-
-**The list's own label was English on a localized surface, and the other one named nothing.**
-Both the desktop and the mobile `role="list"` row did
-`aria-label={schema.aria?.label || 'Record path'}`, so a zh/ja/ar session heard `Record path`
-for the list while every stage inside it announced in the session locale — one control
-speaking two languages at once. The fallback is now `detail.pathLabel`, translated in all ten
-packs; the `schema.aria.label` author override still wins ahead of it.
-
-The lost-terminal alt group was a different defect wearing the same clothes: its
-`aria-label="Alternative terminal stages"` sat on a bare `div`, which has the `generic` role,
-and browsers expose no accessible name on a generic element. That string reached nobody —
-inert, not merely untranslated — so translating it would have shipped copy to ten packs that
-no user can hear. It is removed rather than given a role that takes a name, on three
-measurements: nothing is lost (it was never announced), it would be redundant (every stage
-inside already announces `closed lost` in the session locale after objectui#5916, in the one
-place `role="list"` can carry it), and it would fork the two rows (the mobile row renders one
-flat list with no alt group, so a named group would make one control expose two structures by
-viewport).
-
-**An unreached goal terminus was distinguished by hue alone.** `railClass` paints it
-`bg-emerald-500/30` where a plain upcoming stage gets `bg-muted` — the renderer's own note
-calls this "a faint emerald so the goal is legible" — while both announced the identical
-`{{stage}}, upcoming`. Two stages ahead of the record painted differently and read the same:
-the WCAG 2.2 SC 1.4.1 class objectui#5916 closed, on the one distinction it left behind, and
-reachable without authors opting in because `classify()` finds `won` through the `WON_TOKENS`
-heuristic as well as an explicit `terminal: 'won'`. New key `detail.pathStageWonUpcoming`
-(`{{stage}}, goal stage, not reached`), translated in all ten packs.
-
-Scoped to the UNREACHED goal, which is a measurement of the stylesheet rather than a
-preference: a reached goal terminus paints `bg-primary` when current and `bg-emerald-500` when
-completed, byte-identical to any other current or completed stage. Naming it apart would hand
-a screen reader a distinction the screen does not make — the mirror image of the defect — so
-it is one new key, not a pair, and a test pins that decision so it cannot drift into a fourth
-state unnoticed.
-
-Both new keys also land in `DETAIL_DEFAULT_TRANSLATIONS`, which
-`defaults-maps-mirror-en-pack` compares against the `en` pack key by key, so neither can fork
-between a provider-mounted console and a provider-less embed. No existing `en` value changes,
-so no pack is asked to follow an edit.
diff --git a/.changeset/5965-vscode-summary-codeql-claim.md b/.changeset/5965-vscode-summary-codeql-claim.md
deleted file mode 100644
index 8af3fbd59a..0000000000
--- a/.changeset/5965-vscode-summary-codeql-claim.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
----
-
-Doc-only removal in the (private, unpublished) `object-ui` VSCode extension package:
-`packages/vscode-extension/SUMMARY.md` is deleted. The file asserted a security-scan
-outcome that nothing ever produced — "CodeQL扫描通过 / 无安全漏洞 / 无已知问题"
-("CodeQL scan passed / no security vulnerabilities / no known issues") — while this
-repository has never had a CodeQL workflow, default-setup or otherwise. `CONTRIBUTING.md`
-already states the opposite as the repo's canonical fact: it "does **not** run
-static-analysis security scanning of its own source code (CodeQL or equivalent)".
-
-The claim was not one line. It recurred as a release-checklist tick (`- [x] 安全扫描通过`)
-and twice in the conclusion, alongside a matching `- [x] 单元测试通过` in a package that
-carries zero test files — the document was a frozen one-off session status report
-("代码完成度: 100%", "扩展已准备好发布到VSCode Marketplace"), not living documentation.
-Nothing in the repository referenced it and it never shipped: the package is
-`private: true`, and `.vscodeignore` excludes `*.md` except `README.md`, so it was absent
-from the VSIX. Its durable reference content (commands, snippets, configuration, project
-structure) is already carried by `README.md`, `DESIGN.md`, and `PUBLISHING.md`.
-
-Also lowers two `objectui#4938` population floors in `scripts/__tests__/check-doc-links.test.ts`
-by exactly this one deletion (packages/* 12→11, combined 15→14), so they keep failing if
-the link scanner stops walking the tree.
-
-No published source, behaviour, or shipped artifact changes.
diff --git a/.changeset/5993-button-shared-icon-resolver.md b/.changeset/5993-button-shared-icon-resolver.md
deleted file mode 100644
index 3d17aa1e88..0000000000
--- a/.changeset/5993-button-shared-icon-resolver.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-'@object-ui/components': patch
----
-
-`ui:button` resolves its authored `icon` through the shared `resolveIcon` instead of a
-byte-equivalent copy of it (objectui#5993).
-
-`renderers/form/button.tsx` carried its own `toPascalCase`, its own `iconNameMap` holding
-the single `Home -> House` entry, and its own index into lucide's runtime `icons` record —
-the same algorithm as `renderers/action/resolve-icon.ts`, but not the same function. The
-`action:*` family, `complex/data-table.tsx` and both menu renderers already import the
-shared one. The hazard was drift, not rendering: an alias added to `resolve-icon.ts` to
-absorb a lucide retirement (the objectui#5586 / #5622 mechanism) reached every one of those
-sites and silently missed `ui:button`, which would have gone on resolving the retired
-spelling to nothing while the rest of the repo resolved it correctly.
-
-**No behaviour changes, and that is measured rather than asserted.** The two
-implementations were compared over 3547 names — every one of lucide's 1767 record keys in
-both spellings, plus kebab-case probes (`arrow-right`, `dollar-sign`, `user-plus`), the
-`Home` alias, retired spellings and `undefined`: 3539 identical by object identity, 8
-differing only in the nullish flavour returned for a miss (the copy indexed the record and
-got `undefined`; the shared resolver `?? null`s it), zero genuine forks. That one
-difference cannot reach the DOM — `Icon` is consumed at exactly two sites, both
-`{!isLoading && Icon && <Icon .../>}` truthiness tests, and React renders nothing for
-`null` and `undefined` alike. Icon identity, `h-4 w-4` sizing, `iconPosition`, the loading
-state and the `Loader2` spinner are unchanged, and are pinned by
-`renderers/form/__tests__/button-shared-icon-resolver.test.tsx`.
-
-Because behaviour is unchanged, the usual red-before ablation does not exist for this
-change and none was manufactured. The one row in that suite that discriminates is
-structural: it spies on the shared module and fails when the glyph does not come out of it,
-which is red on the copy and green on the import.
-
-`scripts/check-lucide-icon-record-names.mjs` drops `form/button.tsx` from
-`DECLARED_RECORD_READERS` in the same commit — that gate rediscovers record readers from
-source on every run and fails on drift in both directions, so the removal is verified by
-the gate rather than declared. It is also what now guards the dedupe: a re-inlined copy
-would be discovered as an undeclared record reader and fail. The census entry for the
-`button` *type* stays, its resolver re-pointed at `resolve-icon.ts`, so `ui:button`'s
-authored icon names are still judged against the live record.
-
-`renderers/basic/icon.tsx` keeps its own copy deliberately and is untouched: `ui:icon`
-draws a `SquareDashed` placeholder and warns on an unresolvable name (objectui#5631), which
-the shared resolver does not do.
diff --git a/.changeset/5996-eager-closure-missing-chunk.md b/.changeset/5996-eager-closure-missing-chunk.md
deleted file mode 100644
index 922af1c22b..0000000000
--- a/.changeset/5996-eager-closure-missing-chunk.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
----
-
-Build tooling only — `apps/console/vite.config.ts`, which is not published
-source (`@object-ui/console`'s `files` list carries `dist`, `plugin.*` and
-`README.md`), so nothing ships from this change.
-
-`emit-eager-closure-report`'s `writeBundle` hook read every member of the eager
-closure off disk with an unguarded `fs.readFileSync`. The closure walk seeds
-itself from `chunk.imports`, and rolldown lists a chunk's EXTERNAL imports in
-that array beside the file names of real chunks — so a bare specifier vite could
-not resolve joins the closure under its own name and is then read as a path. The
-result was a bare `ENOENT` from `node:fs`, several frames from the cause, naming
-neither the plugin nor the unresolved import.
-
-The read is now guarded by an existence check that `this.error()`s with the
-missing name, the chunk that imports it, and the diagnosis. The failure stays
-loud — that direction is correct, and the two counter-probes above it exist to
-keep it that way; only its message changes.
diff --git a/.changeset/5998-record-path-one-classification.md b/.changeset/5998-record-path-one-classification.md
deleted file mode 100644
index 0f17f158a1..0000000000
--- a/.changeset/5998-record-path-one-classification.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-'@object-ui/plugin-detail': patch
----
-
-`record:path` now derives ONE stage classification and hands it to both of its rows, so a
-stage can no longer paint and announce two different ways depending on viewport width
-(objectui#5998).
-
-The renderer draws a desktop row (`hidden sm:flex`) and a mobile row (`flex sm:hidden`) from
-the same `stages[]`, and each used to compute its own `terminal` from that array.
-`renderStage` passes the same `terminal` to `railClass` and — since objectui#5957 — to
-`stageAriaLabel`, so any disagreement surfaced in the colour and in the accessible name at
-once. The rows disagreed on two axes:
-
-Mid-path goal. `WON_TOKENS` matches `完成`, an ordinary word rather than a Salesforce-style
-`closed_won` value, so a path like `草稿 → 完成 → 已归档` classified index 1 as `won`.
-Desktop declined it, because only the last forward stage can be the goal terminus; mobile
-marked it `bg-emerald-500/30` and announced `goal stage, not reached`.
-
-The lost slice. Desktop renders `stages.slice(firstLostIdx)` as a visually separated alt
-group and hardcoded `terminal: 'lost'` on every member of that positionally-defined group,
-while mobile classified each stage on its own. A plain stage after a `lost` one
-(`草稿 → 失败 → 已归档`) therefore painted destructive and announced `closed lost` on
-desktop and plain on mobile; a `won`-classified stage in the same position drew `'lost'`
-from one row and `'won'` from the other.
-
-Both rows now index a single `stageTerminals` array: `lost` is a property of the stage
-itself, `won` is the goal terminus and so is the last forward stage or nothing, and the
-positional grouping is a layout concern that no longer overrides what a stage is. Behaviour
-is narrowed on both axes and never widened — no stage gains a `terminal` on either row that
-it did not already carry there, and a goal terminus that really is last keeps its faint
-emerald rail and its `goal stage, not reached` name on both rows.
diff --git a/.changeset/6004-grid-column-emit-boundary.md b/.changeset/6004-grid-column-emit-boundary.md
deleted file mode 100644
index c714459cc1..0000000000
--- a/.changeset/6004-grid-column-emit-boundary.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-'@object-ui/plugin-grid': minor
----
-
-fix(plugin-grid): type ObjectGrid's column emit against the `TableColumn[]` slot it fills
-
-`generateColumns()` had no return annotation and all four of its call sites cast
-to `any`, so nothing checked what this producer wrote into
-`DataTableSchema.columns: TableColumn[]`.
-
-Annotating it is not enough, and that is the substance of the change. Measured on
-this program: `generateColumns(): TableColumn[]` raises **zero** diagnostics — the
-emit literals reach the annotation through `.map()`, which strips the freshness
-that excess-property checking depends on, so even an undeclared key written out
-longhand is accepted. Underneath that sits the reason the annotation could not
-bite at all: `objectSchema` is `useState<any>`, and an `any` spread into an object
-literal collapses the **entire** literal to `any`.
-
-So the fix has three parts: name the four inference locals so `any` stops at the
-boundary, carry ADR-0049 `?: never` tombstones **derived** from
-`keyof ListColumn` (never hand-listed, so a future spec key is refused by
-default), and drop the `any` at every call site — including a fourth the card's
-census missed and a fifth (`const generatedColumns: any[]`) inside the producer.
-
-Key verdicts: `headerIcon`, `pinned` and `wrap` are HELD and now declared at the
-seam; `options` is RETIRED — nothing on either side of the seam read it, and
-every value it carried still reaches its consumer through the field metadata the
-cell closure captures and the object schema the inline editor reads. `type` stays
-objectui#5853's and `name` is not emitted here at all.
-
-No rendering change.
diff --git a/.changeset/6011-tosortitems-order-spelling.md b/.changeset/6011-tosortitems-order-spelling.md
deleted file mode 100644
index 246ac6fe48..0000000000
--- a/.changeset/6011-tosortitems-order-spelling.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-'@object-ui/plugin-view': minor
----
-
-**Breaking (shipped as `minor` per AGENTS.md §版本号策略).** The published `toSortItems`
-export now reads its sort direction from **`order`** only. The retired spelling is
-**`direction`** — named here so that a host still writing it can find this entry by
-searching the old key (objectui#6011).
-
-```diff
-  import { toSortItems } from '@object-ui/plugin-view';
-
-- toSortItems([{ field: 'created_at', direction: 'desc' }]);
-+ toSortItems([{ field: 'created_at', order: 'desc' }]);
-```
-
-**What changed, exactly.** `toSortItems` folded `s.order || s.direction || 'asc'`: two
-spellings for one key, silently preferring the canonical one. It now folds
-`s.order || 'asc'`. Everything else about the helper is unchanged — `id` is still
-preserved when present and minted with `crypto.randomUUID()` otherwise, `field` still
-defaults to `''`, and a non-array draft still yields `[]`.
-
-**The failure mode if you do not migrate is silent.** A draft entry spelled
-`{ field: 'created_at', direction: 'desc' }` used to produce
-`{ field: 'created_at', order: 'desc' }`; it now produces
-`{ field: 'created_at', order: 'asc' }` — the documented default for an entry that names
-no direction. Nothing throws and nothing warns: the `SortBuilder` row renders, and it
-renders **ascending**. If you have a studio inspector draft, a persisted view body, or any
-other producer that still writes `direction`, grep for the key and re-spell it to `order`.
-
-**Why the tolerant read went rather than staying.** objectui#4869 ruled that a spelling the
-sink does not recognise gets ruled into the contract or rejected at the producer, never
-absorbed by a tolerance layer. objectui#5293 retired the same word on
-`ObjectViewProps.views[].sort` and shipped it as a `minor`; this entry finishes the job on
-the sort family's public surface, so `order` is now the one spelling repo-wide and declared
-equals enforced. The scope note in the objectui#5293 entry — that this export was *not*
-retired by that change — described that release's scope correctly and is superseded here.
-
-`SortUI` is untouched. Its own file-local `toSortItems` is a different symbol, and
-`direction` is the key `SortUISchema` legitimately declares.
diff --git a/.changeset/6014-tree-grid-field-formatting.md b/.changeset/6014-tree-grid-field-formatting.md
deleted file mode 100644
index 94d9c492ed..0000000000
--- a/.changeset/6014-tree-grid-field-formatting.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-'@object-ui/plugin-tree': patch
----
-
-`ObjectTree` formats its cells the way the flat table does: a lookup column renders the
-referenced record's display name and a select column renders its translated option label,
-instead of a raw record id and the raw stored value (objectui#6014).
-
-Reported against the built-in 业务单元 (`sys_business_unit`) page, whose 「组织架构」 tree tab
-showed the manager column as a bare user id and the type column as `department`, while the
-flat-table tab on the same page — over the same expanded records — showed the user's name
-and 「部门」.
-
-The card carried its own control, and it pointed at the fetch rather than the formatter. The
-tree treated "the host passed inline `data`" as "I do not need the object schema" and skipped
-`getObjectSchema`, but its record-fetch branch prefers a live object dataSource over any
-inline data. On the one mount shape `ListView` actually uses — `objectName` + a dataSource +
-its own pre-fetched `data` — the tree therefore issued its OWN query with
-`buildExpandFields(undefined)` → `[]` → no `$expand` at all, and had no field definitions to
-format cells from. Both reported symptoms fall out of that single gap, which is why the flat
-tab was unaffected and why the tree's existing tests (inline data, no dataSource — a path
-that never runs the tree's own fetch) could not see it.
-
-Three changes, all inside `packages/plugin-tree`:
-
-- The object schema is fetched whenever the dataSource can serve one, not only when no host
-  passed inline data. The guard inside the fetch already no-ops without a dataSource, so the
-  pure inline/static path is unaffected.
-- Records are no longer fetched until that schema has settled — settled, not necessarily
-  successful, so a rejected or inapplicable schema fetch can never block the tree. This also
-  removes a wasted first query whose lookup columns came back as bare ids and were painted
-  for a moment before the real query landed.
-- Cell values route through a field-aware formatter that delegates both decisions rather than
-  re-deciding them: option labels through the `translateOptions` seam `ObjectGrid` already
-  uses for the flat tab (so both tabs read one `fieldOptions.*` i18n key, with the same
-  exact-then-case-insensitive match and `humanizeLabel` fallback as `SelectCellRenderer`), and
-  expanded references through `getRecordDisplayName`, the unified display-name resolver
-  (ADR-0079), with the family judged by `isExpandableFieldType` — the same predicate that
-  decided what to put in `$expand`.
-
-No new exports and no new package dependencies: both resolvers were already published from
-`@object-ui/core`, and `translateOptions` was already reachable through the `useSafeFieldLabel`
-hook this component calls for its column headers.
-
-One visible consequence beyond the report: an expanded record that comes back with no name-ish
-field now reads as ADR-0079's `Record #<id>` floor — the string every other surface shows for
-it — rather than as the bare id.
diff --git a/.changeset/6023-recent-item-type-keys.md b/.changeset/6023-recent-item-type-keys.md
deleted file mode 100644
index f65580588d..0000000000
--- a/.changeset/6023-recent-item-type-keys.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-'@object-ui/i18n': patch
----
-
-All ten locale packs now define `home.recentApps.itemType.report` and
-`home.recentApps.itemType.metadata` (objectui#6023). `RecentItem['type']` is a six-member
-union and `useTrackRouteAsRecent` writes both of these at runtime — `metadata` on any
-`/metadata/<type>/<name>` route visit, `report` on any `/report/<name>` visit — but the
-packs defined only four of the six, so the Recently Accessed and Starred cards labelled
-those two items from the call sites' inline `defaultValue` instead of from the pack.
-
-Ten packs missing the same member is full parity, so no pack-vs-pack gate could see it,
-and the prefix rule only ever asked whether `home.recentApps.itemType` resolved, which it
-did. What made it quiet rather than loud is the `defaultValue`: English readers saw a
-plausible `Report` / `Metadata` (lowercase in the rail) rather than a raw key, and the
-other nine locales saw those English words — objectui#3517's mechanism for hiding a
-missing key for months.
-
-The nine translations were taken from each pack's own existing rendering of the same word
-rather than composed: the singular `Report` that `appDesigner.navReport`,
-`appDesigner.navTypeReport` and `search.badgeReport` already carry (ar `تقرير`, de
-`Bericht`, es `Informe`, fr `Rapport`, ja `レポート`, ko `보고서`, pt `Relatório`, ru
-`Отчёт`, zh `报表`), and the `Metadata` that `layout.metadata.label` already carries (ar
-`البيانات الوصفية`, de `Metadaten`, es `Metadatos`, fr `Métadonnées`, ja `メタデータ`, ko
-`메타데이터`, pt `Metadados`, ru `Метаданные`, zh `元数据`). No new vocabulary was invented
-for any locale.
-
-The two matching entries in `scripts/i18n-call-site-key-baseline.json`'s `missingMembers`
-are cleared, since that list is a ratchet: a baselined entry whose defect is gone fails the
-build too. The union itself is untouched — narrowing `RecentItem['type']` is the other
-resolution the gate accepts, and it would have been a lie about data both call sites
-demonstrably write.
diff --git a/.changeset/6024-catalog-own-plugin-pin-generalized.md b/.changeset/6024-catalog-own-plugin-pin-generalized.md
deleted file mode 100644
index 3d85725589..0000000000
--- a/.changeset/6024-catalog-own-plugin-pin-generalized.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
----
-
-Tests and test-config only, no shipped code touched: the catalog "entries use their own
-plugin" pin in `examples/schema-catalog/test/catalog-gallery-render.test.tsx` is
-generalized from the two hand-enumerated categories objectui#5113 and objectui#5856 left
-it at (`plugin-view`, `plugin-grid`) to all thirteen `plugin-*` catalog categories.
-
-The `category -> type` map is now DERIVED from the `register()` calls, by reusing
-`deriveRegistryKeys` from `scripts/check-doc-component-types.mjs` and joining its
-registration sites on the `packages/<dir>` that owns them — the same derivation
-`scripts/regenerate-known-schema-types.mjs` already consumes. The value is a SET, which
-`plugin-charts` requires (its entries author `chart` and `bar-chart`), and the rule stays
-per entry rather than per category.
-
-objectui#5113's RENDER half (a record that exists only in the gallery data source reaches
-the screen) does not transfer to the eleven categories that author their data inline, so
-it is replaced for them by a MOUNT half rather than degraded to the STRUCTURE half:
-substituting every own-plugin node with an inert probe must put the probe's marker on
-screen, which a stray node, a `type` that is not a node, and a node behind a satisfied
-`hidden` cannot do. Data provenance is kept, unweakened, for the entries that bind to an
-object the gallery fixture serves — derived per entry from `objectName`, not declared. The
-gate states its own coverage split so breadth cannot be read as depth: 5 entries carry
-structure + mount + data, 34 carry structure + mount, and `plugin-editor` / `plugin-map`
-lose nothing to their `EXCLUSIONS` because the probe replaces the renderer that needs
-Monaco and WebGL2.
-
-The derivation earned its keep on its first run: the filing's hand-written table read
-`plugin-form  form`, and `form` is registered by `packages/components`, not by
-`@object-ui/plugin-form`. Both `plugin-form` entries are the third instance of
-objectui#5113's class, ledgered against objectui#6167 with a case asserting they still
-fail, so the ledger cannot rot green.
-
-`examples/schema-catalog/tsconfig.test.json` gains `allowJs` (with `checkJs` off) and a
-repo-root `rootDir`, the same answer `tsconfig.scripts.json` reached in objectui#3494 for
-importing a plain-JS CI helper into a typed pin test.
diff --git a/.changeset/6025-declare-plugin-grid-in-gallery-host.md b/.changeset/6025-declare-plugin-grid-in-gallery-host.md
deleted file mode 100644
index abfbccde32..0000000000
--- a/.changeset/6025-declare-plugin-grid-in-gallery-host.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
----
-
-Docs-site host and catalog test only: `apps/site/app/components/registerCatalogBlocks.ts`
-now declares `@object-ui/plugin-grid` instead of inheriting `object-grid` from
-`@object-ui/plugin-view`'s `import { ObjectGrid }` (`ObjectView.tsx:37`). Nothing renders
-differently — measured: with exactly the eleven packages the host used to carry,
-`object-grid` and every `@object-ui/plugin-form` key already resolved — which is the point.
-A component import in another package was the only reason two catalog tiles could draw, and
-a refactor of `object-view` that stopped it from drawing a grid itself would have turned
-them into OBJUI-001 panels with the cause several files from the symptom.
-
-`catalog-gallery-render.test.tsx` gains the judge that can tell the two apart: every
-`plugin-*` category with catalog entries must be loaded BY NAME in the host's import list,
-derived from the categories rather than enumerated, and leaning on the existing parity case
-that ties `HOST_PACKAGES` to the host file's literal imports. `ComponentRegistry.get()`
-cannot judge this — it is truthy in both worlds.
diff --git a/.changeset/6027-sidebar-tailwind-v4-spelling-guard.md b/.changeset/6027-sidebar-tailwind-v4-spelling-guard.md
deleted file mode 100644
index 069e67899a..0000000000
--- a/.changeset/6027-sidebar-tailwind-v4-spelling-guard.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
----
-
-Tests only; no published behaviour changes.
-
-Adds an offline assertion that the shipped
-`packages/components/src/ui/sidebar.tsx` contains no Tailwind **v3**
-`[--var]` arbitrary values, wired into the existing
-`scripts/__tests__/shadcn-local-patches.test.ts` suite (no new workflow).
-
-The Tailwind v4 custom-property migration (`925051db6`) is an *undeclared*
-local edit — prose in `shadcn-components.json` (`localEdits`), with nothing in
-`scripts/shadcn-local-patches.mjs` re-applying it — so a `--force` sync drops
-it. It is the only one of `sheet`/`sidebar`'s four undeclared edits that no
-gate catches: the v3 spelling compiles, renders, and emits invalid CSS that
-browsers silently discard. The assertion closes that silence from the cheap
-side rather than declaring ~20 class-string anchors.
-
-Asserted against the file the repo **ships**, not a vendored fixture — the
-regression being guarded is "a forced sync overwrote the shipped file", which a
-fixture-based check would pass straight through. The block also guards the
-inverse (the correct v4 `(--var)` spellings must not trip it) and pins the
-tolerated/refused counts, and its docblock records the other three undeclared
-edits with the gate that catches each.
diff --git a/.changeset/6038-production-predicate-fault-warning.md b/.changeset/6038-production-predicate-fault-warning.md
deleted file mode 100644
index 8110de9e00..0000000000
--- a/.changeset/6038-production-predicate-fault-warning.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-'@object-ui/core': patch
-'@object-ui/react': patch
-'@object-ui/components': patch
----
-
-A node-gate visibility predicate that FAULTS now says so in a production build, once per
-distinct predicate source (objectui#6038, maintainer ruling 2026-08-25, option B: "the
-silence is no longer an accepted property"). Observability only — no verdict moves.
-
-`SchemaRenderer`'s visibility chain is fail-open: a predicate that cannot be evaluated
-resolves to the same answer as one that said yes, so a gate that stops biting looks
-exactly like a gate the author got right. The diagnostic that names it (objectui#5454 /
-objectui#5687) sat behind a `__DEV__` short-circuit, because the only fault-detection
-channel available was `throwOnError`, and on the CEL branch `evaluateCelCondition`
-implements that by evaluating **twice** — too expensive to ship for every predicate of
-every node.
-
-**What production actually printed before, measured per dialect on the built evaluator**
-— the card's premise held for one dialect of three, and the other two failed in opposite
-directions:
-
-| dialect | production console, before |
-|---|---|
-| bare string | **nothing** |
-| `{ dialect: 'cel' }` envelope | one generic line, deduped per source |
-| `${…}` template | one generic line **per evaluation**, never deduped |
-
-So the dialect objectstack#11254 measured a live gate breaking on was the silent one,
-while the template dialect was the console flood the ruling's rate-limit clause exists to
-prevent.
-
-**The fix reports the fault the evaluator already detected, at the same number of engine
-calls.** `EvaluationOptions.onFault` is a new passback on `@object-ui/core`'s
-`ExpressionEvaluator`: every fault site is already inside a `catch`, or already holds the
-canonical engine's failure reason, so nothing is evaluated twice. It mirrors, one layer
-up, the seam `FieldPredicateDiagnostic` already documents (`warn: false` plus a reason
-passback), and supplying it transfers reporting to the caller so one fault stays one
-line. Pinned: the CEL branch performs the same number of record reads with the passback
-as without it, and strictly fewer than the `throwOnError` probe.
-
-`SchemaRenderer` passes it in production and reports through the **same** reporter the dev
-branch uses — same message, same severity, same dedupe `Set`, same key. Development and
-production now print the identical line for the identical fault; the `__DEV__` gate no
-longer decides *whether* a fault is reported, only *how* it is detected.
-
-`page:tabs` item-level `visibleWhen` (`@object-ui/components`) is covered by the same
-reporter and the same rate limit. It swallowed the identical fault under a different
-helper, and it was the worse of the two: the node gate at least reported in development,
-while a faulting item predicate was silent in *both* builds on a gate whose false verdict
-removes an entire tab, header and panel.
-
-**Rate limit:** deduped per (node type, gate key, predicate source) — never per render and
-never per node instance. A two-hundred-row list of one broken predicate is one line; a
-second distinct predicate source still gets its own line. Both halves are pinned, because
-a test that asserts only "a warning was emitted" is equally green on an implementation
-that emitted fifty, and one that asserts only "exactly one" is equally green on an
-implementation that suppresses everything.
-
-**Not changed by this card, deliberately:** the fail-open semantics themselves; the
-objectui#5687 adapter-only `data.*` report, which stays development-only under its own
-2026-08-22 ruling (that path is not a fault — the predicate evaluated perfectly, against
-the wrong object); and the `/forms/:name` scope wiring of objectui#6262, which lands in
-its own PR.
-
-`reportUnresolvableVisibilityPredicate`, `formatUnresolvableVisibilityMessage`,
-`UNRESOLVABLE_VISIBILITY_PREFIX` and `__resetVisibilityPredicateWarnings` are now exported
-from `@object-ui/react` so every surface that evaluates a node `visibleWhen` shares one
-reporter and one rate limit — a second copy would mean a second dedupe `Set`, and one
-authored predicate would be entitled to one line per package instead of one line.
diff --git a/.changeset/6041-designer-reference-key.md b/.changeset/6041-designer-reference-key.md
deleted file mode 100644
index 803ca1328c..0000000000
--- a/.changeset/6041-designer-reference-key.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-'@object-ui/plugin-designer': patch
-'@object-ui/app-shell': patch
----
-
-The field designer now reads and writes a lookup field's relationship target under the
-spec's spelling `reference` (objectui#6041), in both directions.
-
-`referenceTo` is not in `FieldSchema`'s accept set. Measured against the installed
-`@objectstack/spec` 17.2.0, through the whole object document that
-`PUT /api/v1/meta/object/:name` validates:
-
-```
-ObjectSchema.safeParse({ …, fields: { rel: { type: 'lookup', label: 'Owner',
-                                            referenceTo: 'user' } } })
-  => success = false
-  => unrecognized_keys at ["fields","rel"] keys=["referenceTo"]
-     "Did you mean `referenceTo` -> `reference`?"
-```
-
-so authoring a lookup field through the designer returned a hard 422 `INVALID_METADATA`,
-and — because the key is then stored — blocked **every subsequent save** of that object,
-with nothing in the UI to say which key did it.
-
-The read direction was broken symmetrically and is the half that would have survived a
-write-only fix: `toDesignerField` read `raw.referenceTo` while a spec-parsed server sends
-`reference`, so every already-saved lookup field loaded into the designer with an **empty
-reference box**. Both wire-bound payload shapes move — `FieldMetadataPayload`
-(`MetadataService.toFieldPayload`) and `ServerFieldSchema`
-(`MetadataFieldsPage.fromDesignerField`).
-
-`referenceTo` also joins `RETIRED_FIELD_KEYS`. Renaming the emit sites alone does not
-unblock an object whose stored fields already carry the misspelling: `carryOver` spreads
-the previous server def verbatim, so the key would ride straight back out to the same 422.
-The designer's in-memory `DesignerFieldDefinition` keeps `referenceTo` — that is the
-internal prop name every other UI surface in this repo already uses (`LookupField`,
-`filter-builder`, `ObjectChart`, `ListView`, `UserFilters`), it reaches no wire-bound
-shape, and the parity gate classifies it as `uiOnly` rather than a violation.
-
-No behavioural change for a half-filled draft: the spec's prose calls `reference`
-"required for relationship types", but that is not enforced by the zod parse at 17.2.0 —
-`{ type: 'lookup', label: 'L' }` parses green at field level and through `ObjectSchema`,
-and `undefined` is dropped by `JSON.stringify` under either spelling, so the wire bytes
-are identical before and after.
diff --git a/.changeset/6043-retire-designer-formula-control.md b/.changeset/6043-retire-designer-formula-control.md
deleted file mode 100644
index 00f6f3a85e..0000000000
--- a/.changeset/6043-retire-designer-formula-control.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-'@object-ui/types': minor
-'@object-ui/plugin-designer': minor
-'@object-ui/app-shell': minor
----
-
-The Field Designer no longer offers a formula-expression textarea, and no designer write
-path emits a `formula` key (objectui#6043).
-
-**This is a behaviour change on an authoring surface: a control is removed.** A field's
-`type` may still be set to `formula` — that is a valid spec `FieldType` and stays in the
-palette — but the expression itself is no longer authored here. Authors write formula
-expressions in metadata-admin's field inspector, where they are checked.
-
-The control wrote `formula`, which is not in `FieldSchema`'s accept set. Measured against
-the installed `@objectstack/spec` 17.2.0:
-
-```
-FieldSchema.safeParse({ type:'formula', label:'Tax', formula:'price * quantity' })
-  => success = false
-  => unrecognized_keys ['formula']   "Did you mean `formula` -> `expression`?"
-```
-
-so `PUT /api/v1/meta/object/:name` returned a hard 422 `INVALID_METADATA` — and because
-the key was then stored, it blocked **every later save of that object**, not just the one
-that introduced it.
-
-**The key was deliberately NOT renamed to the spec's `expression`.** `FieldSchema` judges
-the key name and never the expression LANGUAGE — measured, it accepts
-`expression: 'price * quantity'` and even `expression: '!!!not cel at all!!!'`; only the
-empty string is refused. Spec `expression` is CEL rooted at `record`
-(`record.amount * 0.1`), whereas this control's own placeholder taught `price * quantity`
-— bare field refs, which under the scope formulas bind evaluate to null silently. A rename
-would therefore have converted a loud, immediate 422 into a formula that saves clean and
-then quietly computes nothing, which is strictly worse than the bug it appears to fix.
-
-Making refusals loud *in the control* would need CEL lint, autocomplete and `returnType`
-inference — that is `CelPredicateField`, which lives in `@object-ui/app-shell`, and
-app-shell depends on `@object-ui/plugin-designer`, so it cannot be imported back without a
-dependency cycle. Growing a second formula-authoring surface inside plugin-designer is a
-feature, not this fix. `returnType` is likewise not authored here: it is only derivable by
-inferring the CEL result type, and with no expression control there is nothing to infer
-from.
-
-`formula` joins the retired-key tombstone in `MetadataFieldsPage`, so an object already
-carrying the key is stripped clean on its next save instead of staying blocked forever —
-which matters more than usual here, because with the control gone an author would
-otherwise have no way left to clear it. It is dropped rather than migrated to `expression`,
-for the same reason the rename was refused. A `expression` authored in metadata-admin is
-**not** touched: it is a real `FieldSchema` key and rides through the designer's
-round-trip untouched.
-
-Also removes the now-unreachable `formula` read/write from
-`views/metadata-admin/previews/object-fields-bridge.ts`, which was a third emit site for
-the key that neither the card nor the parity gate named.
-
-The `formula` entry is removed from `check-designer-field-key-parity.mjs`'s
-`KNOWN_UNPARSEABLE_KEYS` ledger, which ratchets in both directions — a resolved key that
-left a stale entry behind would be as red as a new offender.
diff --git a/.changeset/6044-designer-system-key.md b/.changeset/6044-designer-system-key.md
deleted file mode 100644
index 09a3c92462..0000000000
--- a/.changeset/6044-designer-system-key.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-'@object-ui/plugin-designer': patch
----
-
-The field designer now reads the system-field marker under the spec's spelling `system`,
-and never hands `isSystem` back to the metadata API (objectui#6044).
-
-`isSystem` is not in `FieldSchema`'s accept set. Measured against the installed
-`@objectstack/spec` 17.2.0:
-
-```
-FieldSchema.safeParse({ type: 'text', label: 'L', isSystem: true })
-  => success = false
-  => unrecognized_keys keys=["isSystem"]  "Did you mean `isSystem` -> `system`?"
-```
-
-Two defects, one misspelling, and they are two different sites.
-
-**The read was dead** — the quieter and worse half. `toDesignerField` read `raw.isSystem`
-while a spec-parsed server sends `system`, so the flag was always `undefined`. Nothing went
-red, because the flag is optional and `undefined` is a valid "not a system field". But it is
-load-bearing: `FieldDesigner` refuses to delete a system field and disables its name and
-type inputs, so with the read dead `organization_id`, `created_at` and friends presented as
-ordinary editable, **deletable** business fields.
-
-**The write had no emit site at all.** `fromDesignerField` never names `isSystem`; its only
-route out is the verbatim `...carryOver(prev)` spread, so a stored misspelling round-tripped
-back to `PUT /api/v1/meta/object/:name` as a hard 422 `INVALID_METADATA` that blocks every
-later save. The repair is a `RETIRED_FIELD_KEYS` tombstone rather than a renamed line — and
-it is deliberately paired with the read fix, never a substitute for it: stripping alone would
-close the 422 and fossilize the dead detection. The spec spelling `system` is not stripped,
-so a server-injected flag rides through untouched and feeds the read.
-
-`app-shell`'s `FieldMetadataPayload` never declared the key, so `toFieldPayload` had nothing
-to fix. The designer's in-memory `DesignerFieldDefinition` keeps `isSystem`: it reaches no
-wire-bound shape and the parity gate classifies it as `uiOnly`.
diff --git a/.changeset/6045-field-payload-sort-order.md b/.changeset/6045-field-payload-sort-order.md
deleted file mode 100644
index c18dc4bd9b..0000000000
--- a/.changeset/6045-field-payload-sort-order.md
+++ /dev/null
@@ -1,56 +0,0 @@
----
-'@object-ui/app-shell': minor
-'@object-ui/types': minor
----
-
-The field metadata payload no longer emits `sortOrder`, the key `FieldSchema` refuses by
-name (objectui#6045). Field-level sibling of objectui#6223, same objectui#5761 family.
-
-Measured against the installed `@objectstack/spec` 17.2.0, whose `FieldSchema` accept set
-is 71 keys:
-
-```
-FieldSchema.safeParse({ type:'text', label:'L' })                  => success = true   (control)
-FieldSchema.safeParse({ type:'text', label:'L', sortOrder: 3 })    => unrecognized_keys ["sortOrder"]
-
-FieldSchema.safeParse({ type:'text', label:'L', sortable: true })  => success = true   (control)
-FieldSchema.safeParse({ type:'text', label:'L', sortable: 3 })     => success = false
-```
-
-The control is what makes that a key-by-key result rather than a schema refusing
-everything, and the `sortable` pair is what shows the near-spelling is a *different
-concept* — a boolean ("whether field is sortable in list views"), not this key's spec
-name.
-
-**The resolution was deletion, not a rename**, which is objectui#4687's shape rather than
-objectui#6041's. The spec has no field-level ordering key at all: it models field order by
-**declaration order** in the object's `fields` record, so a designer that wants explicit
-ordering reorders that record rather than carrying an index. There was nothing to map onto,
-and nothing was invented to map onto.
-
-**It was latent, and that is confirmed on today's tree.** Neither of the two sites that
-construct a `DesignerFieldDefinition` — `FieldDesigner`'s create/update handlers and
-`MetadataFieldsPage.toDesignerField` — ever named the key, so `toFieldPayload` emitted
-`sortOrder: undefined` and `JSON.stringify` dropped it. The key never reached the wire. It
-was one reorder feature away from doing so, which is the objectui#4644 shape: a hard 422
-`INVALID_METADATA` that blocks every subsequent save of the object, with nothing in the UI
-to say which key caused it.
-
-Removed in one go from the wire shape (`FieldMetadataPayload`), its writer
-(`toFieldPayload`) and the UI model (`DesignerFieldDefinition`), so no declaration is left
-behind that no writer fills and no schema accepts.
-
-**Breaking for TypeScript consumers**: `sortOrder` is gone from `DesignerFieldDefinition`
-(`@object-ui/types`) and from `FieldMetadataPayload` (app-shell), so code that set either
-stops compiling.
-
-Two keys share this spelling and are untouched, which is why the census was on the *shape*
-— a field-metadata payload key `FieldSchema` refuses — rather than on the identifier: the
-**object-level** `sortOrder` (`ObjectSchema`'s, removed from the object wire shape by
-objectui#6223 and deliberately kept on the `ObjectDefinition` UI model) and the
-**saved-view** `sortOrder` in `ObjectView`, which is per-view display order on a different
-document entirely.
-
-The `KNOWN_UNPARSEABLE_KEYS` entry in `scripts/check-designer-field-key-parity.mjs` goes
-with the fix — that ledger ratchets in both directions, so an entry left behind for a
-resolved key is as red as a missing one.
diff --git a/.changeset/6050-gantt-navigation-basepath.md b/.changeset/6050-gantt-navigation-basepath.md
deleted file mode 100644
index e7b6c13c0a..0000000000
--- a/.changeset/6050-gantt-navigation-basepath.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
-'@object-ui/plugin-gantt': patch
----
-
-The package README stops documenting a `navigation` key the spec refuses, and the corrected example is now parsed by the schema that validates it.
-
-`README.md`'s record-navigation override read
-`{ mode: 'page', basePath: '/console/apps/.../campaign' }`. `basePath` is not a
-member of the spec's `NavigationConfig`, and nothing consumes it:
-`useNavigationOverlay` — where a gantt's `navigation` lands — builds no URL out
-of the config, and `ObjectGantt` calls the hook with no `onNavigate`, so a
-page-mode click falls through to the host's `onRowClick`. The destination route
-is owned by the host and was never authorable through this key, under any
-spelling.
-
-That made the snippet worse than inert. `NavigationConfigSchema` is a strict
-object with no passthrough, so the undeclared key did not fall away quietly — it
-rejected the **whole** config with `unrecognized_keys`, taking down the
-`mode: 'page'` the sentence was actually teaching. An author who copied the
-documented snippet got a rejected navigation config and no page navigation, which
-is the copy-the-snippet-get-rejected shape objectui#5057 / #5012 named on other
-keys.
-
-The example is corrected to `{ "navigation": { "mode": "page" } }` — the shape
-the sentence demonstrates — and the prose now says who owns the destination route
-and points at `@objectstack/spec`'s `NavigationConfigSchema` for the member list
-instead of restating it, matching the derivation `ObjectGanttSchema.navigation`'s
-doc comment (objectui#5903) adopted for the same concept.
-
-`view` is **not** substituted for `basePath`. It is a declared member, but it
-names a form view (the spec: *"Name of the form view to use for details"*) and is
-forwarded to `onNavigate` as the action argument — it is not a route, so putting
-it where `basePath` stood would have replaced an invented key with a wrong one.
-It is documented for what it does.
-
-No gate in this repo could have caught the original defect, and that is why the
-fix ships with a measurement rather than a re-reading: `check-doc-snippet-types`
-compiles `ts`/`tsx` fences and `check-doc-component-types` reads `type` literals,
-and both are structurally blind to a metadata key in a README — the former's own
-header records schema-key validity as "a different question … left unruled on
-purpose". `src/readme-navigation-example.test.ts` closes that hole for this
-example by EXTRACTING the fence from the README on every run and parsing it
-against `NavigationConfigSchema`, with a control asserting the same parse still
-rejects an undeclared key by name, so the green cannot come from a schema that
-accepts everything.
-
-`tsconfig.test.json` names `node` in `types` for that test to compile, and its
-comment — which had recorded that no test in this package touches a Node global
-— is corrected rather than left standing.
diff --git a/.changeset/6051-gantt-flat-config-declared-keys.md b/.changeset/6051-gantt-flat-config-declared-keys.md
deleted file mode 100644
index 7aa10e1dc3..0000000000
--- a/.changeset/6051-gantt-flat-config-declared-keys.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-'@object-ui/types': minor
-'@object-ui/plugin-gantt': minor
----
-
-`ObjectGanttSchema` declares the flattened `GanttConfig` face `ObjectGantt`
-actually reads (objectui#6051). `getGanttConfig` has two branches: when
-`startDateField` and `endDateField` are both present at the TOP level it builds
-its config from top-level keys and returns early; otherwise it reads the `gantt`
-block. Everything the first branch reads was undeclared — and unlike
-objectui#5903's ten, none of it was hidden behind a cast. `BaseSchema` carries
-`[key: string]: any` (objectui#5155's structural ceiling) and the helper's
-parameter was `ObjectGridSchema | any`, so `schema.colorField` type-checked as
-`any` with no syntax anywhere to grep for. That is also why the census here is an
-AST enumeration and not a compile-and-observe: an index signature absorbs every
-literal name, so annotating the parameter compiles clean while enforcing nothing.
-
-**27 keys join the declared surface, each additive and each with a live read
-site.** 24 flattened `GanttConfig` members — `colorField`, `borderColorField`,
-`dependenciesField`, `parentField`, `typeField`, `lockField`, `objectField`,
-`summaryExtent`, `defaultCollapsedDepth`, `tooltipFields`, `baselineStartField`,
-`baselineEndField`, `groupByField`, `resourceView`, `assigneeField`,
-`effortField`, `capacity`, `quickFilters`, `autoZoomToFilter`, `timeSegments`,
-`interactions`, `exportFileName`, `timeZone`, `dependencyTypes` — plus the three
-query keys the fetch path reads, `staticData`, `filter` and `sort`. Nothing is
-declared that the renderer does not consume.
-
-**`GanttConfig` itself gains nine members and is a published type**, exported by
-name from `packages/types/src/index.ts`: `lockField`, `objectField`,
-`summaryExtent`, `defaultCollapsedDepth`, `borderColorField`, `dependencyTypes`,
-`timeZone`, `exportFileName`, `interactions`. The entry file's diff is empty only
-because the export list already named the type — the widening happened at the
-declaration.
-
-**The 28th measured key, `gantt` (the block face), is deliberately NOT declared**
-— see the closing section.
-
-The 24 are DERIVED from `GanttConfig` rather than restated, so the flat spelling
-cannot fork from the block spelling, and the invariant is pinned in the type
-system: every key of `GanttConfig` must be declared at the node's top level.
-Making that derivation possible moved nine members — `lockField`, `objectField`,
-`summaryExtent`, `defaultCollapsedDepth`, `borderColorField`, `dependencyTypes`,
-`timeZone`, `exportFileName`, `interactions` — out of `plugin-gantt`'s
-package-private `GanttConfigEx` and into `@object-ui/types`' `GanttConfig`. They
-are a MOVE, not new vocabulary: the `gantt` block already honoured all nine, and
-a type private to the plugin could be referenced by neither authoring face.
-
-Both halves move together, as in objectui#5903: the TS declaration and its zod
-mirror gain the same 27 keys at the same requiredness (all optional), the
-spec-modelled ones taken from `GanttConfigSchema.shape` by reference, so the
-`zod-mirror-parity` ratchet stays at zero drift for this pair and no `KnownDrift`
-or `UnmirroredDeclared` entry is added. The mirror builds the flat face and the
-`gantt` block from one field map, so they are one schema expressed twice.
-
-Accept-set change, stated plainly. All 27 keys are additive — every one is
-optional, and nothing previously legal loses its slot. What changes is that a
-**declared** key is now type-validated, so `capacity: 'one'` and
-`summaryExtent: 'parent'` are refused where they used to parse green. An
-**undeclared** key is still accepted — `BaseSchema` is `.passthrough()`, so this
-bought no rejection of misspellings. There is no narrowing anywhere in this
-change.
-
-**`gantt` is severed on purpose (objectui#6475), not overlooked.** It is the 28th
-key of the measured residue and a genuine read — `getGanttConfig`'s second branch
-honours it in full — but it is the one key whose declaration would NOT have been
-additive. It has no mirror entry today, so a block rides through `.passthrough()`
-unvalidated; declaring it as `GanttConfig` means it gets parsed against the spec's
-`GanttConfigSchema`, which REQUIRES `startDateField`, `endDateField` and
-`titleField`, and `ObjectGanttSchema` reaches the CLI's `validate` / `check`
-through `AnyComponentSchema`. A published CLI's refusal behaviour is decided on
-its own card, where reviewers can see what they are approving; objectui#6475
-carries the full measurement, including the case FOR enforcing it (the renderer
-already feeds that block to `GanttConfigSchema.safeParse` and warns, so enforcing
-restores declared = enforced rather than inventing a contract). Today's behaviour
-is pinned in the test file so the omission is a measured state, not a silent gap.
-`packages/types/src/__tests__/gantt-flat-config-declared-keys.test.ts` pins both
-halves so neither can be misread.
-
-Which face WINS is unchanged and was not decided here: the flat branch is checked
-first and returns early, so a node carrying both spellings still renders the flat
-one. (`plugin-map` had the opposite precedence ruled on in objectui#5018; no
-equivalent ruling exists for gantt.)
diff --git a/.changeset/6052-gantt-export-filename-i18nlabel.md b/.changeset/6052-gantt-export-filename-i18nlabel.md
deleted file mode 100644
index 5fffb4af6a..0000000000
--- a/.changeset/6052-gantt-export-filename-i18nlabel.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-'@object-ui/plugin-gantt': patch
----
-
-`ObjectGantt`'s export filename resolves a locale-map `label` instead of stringifying it
-(objectui#6052). A gantt authored as
-`{ "type": "object-gantt", "objectName": "task", "label": { "en": "Shift Plan", "zh-CN": "排班计划" } }`
-exported its PNG/PDF as `[object Object]-20260825-1030.png`.
-
-`BaseSchema.label` is `string | I18nLabel` since #4580's revised Q1-A ruling — `I18nLabel`
-being the spec's INLINE locale MAP — and the `exportFileName` chain handed that value
-straight to `String(...)`. It now goes through `resolveI18nLabel` from `@objectstack/spec/ui`,
-the producer's own resolver for that vocabulary, against the display locale the file already
-reads via `useDisplayLocale()`. A zh-CN audience gets `排班计划-<stamp>.png`, an en audience
-`Shift Plan-<stamp>.png`, and a plain-string label is unchanged.
-
-The next link in the same chain, `objectSchema?.label`, is deliberately left alone: that is
-the DATA object's label, declared `z.string().optional()` on the spec's `ObjectSchemaBase`,
-which is a `strictObject` — a locale map there is rejected by the producer rather than
-resolved by the consumer, and wrapping it would be accepting a second vocabulary at a read
-site. No filename sanitisation is added either; `GanttView` already strips
-filesystem-hostile characters downstream, and a resolved map entry goes through the same
-strip a plain string does.
diff --git a/.changeset/6058-zod-mirror-unmirrored-ledger.md b/.changeset/6058-zod-mirror-unmirrored-ledger.md
deleted file mode 100644
index ff4311f11e..0000000000
--- a/.changeset/6058-zod-mirror-unmirrored-ledger.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
----
-
-Test-only: `packages/types`' zod-mirror-parity guard now compares the UNION of the
-mirror's keys and the declaration's, and ledgers the newly visible half separately
-(objectui#6058; the stale prose counts objectui#6141 measured are corrected in the same
-file). No published type, mirror or runtime behaviour changes — nothing in `src/` outside
-`__tests__/` is touched, so there is nothing to release.
diff --git a/.changeset/6063-kanban-resolvedisplay-dead-guard.md b/.changeset/6063-kanban-resolvedisplay-dead-guard.md
deleted file mode 100644
index 56fc560050..0000000000
--- a/.changeset/6063-kanban-resolvedisplay-dead-guard.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-'@object-ui/plugin-kanban': patch
----
-
-`ObjectKanban`'s `resolveDisplay` drops an unreachable relation-type guard, and the rule
-that survives it is pinned (objectui#6063).
-
-The helper that builds card descriptions ended:
-
-```ts
-const isLookup = isExpandableFieldType(def);
-if (isLookup && isOpaqueId(raw)) return undefined;
-if (isOpaqueId(raw)) return undefined;
-return raw;
-```
-
-The second line subsumes the first for every input — same `raw` (a `const`, unmodified
-between the two lines), same predicate, and `OPAQUE_ID_RE` carries no `g`/`y` flag, so
-repeated `.test()` on it is stateless. `isLookup` was computed, branched on and discarded.
-
-**No behaviour changes on any board.** The card named a second reading — that the
-unconditional line was the mistake and only relation columns were meant to suppress
-id-shaped values — and it was rejected on evidence rather than by tidying first: the
-helper's own docblock declares both clauses, the same predicate is already applied with no
-type gate to the incoming `description` a few lines down, and `objectDef` is optional at
-that read, so a type gate would suppress nothing on exactly the boards whose object schema
-is thin or absent. That reading is now a red test, not a comment.
-
-Deleting the branch also deleted this path's read of `@object-ui/core`'s
-`EXPANDABLE_FIELD_TYPES`, so objectui#5874's identity pin for this face is re-anchored onto
-the read that is live — `buildExpandFields`, on every fetch — where the membership delta is
-observable on the wire (`$expand`) as well. That pairs the identity pin with the
-behavioural counter-probe #5874 had to record as missing.
diff --git a/.changeset/6067-component-meta-derive-from-canonical.md b/.changeset/6067-component-meta-derive-from-canonical.md
deleted file mode 100644
index d524f38c01..0000000000
--- a/.changeset/6067-component-meta-derive-from-canonical.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-'@object-ui/core': minor
----
-
-`ComponentMeta` at the registry is now DERIVED from the one declaration in
-`@object-ui/types` instead of restating it, and `tags` / `description` reach the
-registration surface (objectui#6067).
-
-## The convergence
-
-`packages/core/src/registry/Registry.ts` declared its own `ComponentMeta`: thirteen
-keys, of which nine were restated from `@object-ui/types`' `base.ts`, four were
-registry-only (`tier`, `namespace`, `skipFallback`, `labelling`), and `tags` /
-`description` were **absent** — although both are declared on the canonical type and on
-the `ComponentMetaSchema` zod mirror. Two of the three authorities agreed and the
-registration surface did not, so those two keys were unwritable at exactly the
-declaration most component registrations import. That is the same two-key delta
-objectui#5893 had just closed inside `@object-ui/types`, arriving a third time on a
-third declaration, and objectui#5671 had already made the identical move for the sibling
-type `ComponentInput` in this very file.
-
-It is now:
-
-```ts
-export type RegistryComponentMetaExtras = {
-  tier?: 'public' | 'internal';
-  namespace?: string;
-  skipFallback?: boolean;
-  labelling?: 'control' | 'group' | 'display';
-};
-
-export type ComponentMeta = CanonicalComponentMeta & RegistryComponentMetaExtras;
-```
-
-`RegistryComponentMetaExtras` is newly exported from `@object-ui/core`.
-
-**What changes for a consumer: `tags` and `description` become writable on the registry's
-`ComponentMeta`. Nothing narrows.** No key is removed, no key is renamed, and no key's
-type changes, so no existing registration stops compiling — verified by type-checking all
-37 workspace consumers of `@object-ui/core` (`pnpm --filter '...@object-ui/core'`), which
-is why this is a widening rather than the contract break a rename would have been. All
-four registry-only keys have live consumers, and they are still declared here.
-
-This is `minor` under this repository's policy that its own breaking changes never declare
-`major` (`scripts/check-changeset-no-major.mjs`); nothing here is breaking in any case.
-
-## Converge rather than rename, and why the four keys did not move
-
-The alternative dispositions were to rename the type so the name stops claiming a mirror,
-or to move the four registry keys onto `@object-ui/types`' `ComponentMeta` and re-export
-it outright the way objectui#5671 handled `ComponentInput`.
-
-Renaming was rejected because it cannot be done without a break: `@object-ui/core` is
-published, `ComponentMeta` is exported from it, and dropping the name would break every
-external consumer — while keeping it as an alias would leave the mirror claim standing
-under a second spelling, which fixes nothing.
-
-Moving the four keys was rejected because `skipFallback` and `namespace` are registration
-mechanics — they describe how the registry keys an entry, not what a component is — and
-`@object-ui/types`' `ComponentMeta` is the general, plugin-facing, AI-facing type. The
-extension keeps them where they are read, under their own named type, while the eleven
-shared members exist in exactly one place and can no longer drift.
-
-## Pinned by key set, not by assignability
-
-Every member of both shapes is optional, so `extends` is mutually **true** across the
-diverged pair — an assignability assertion is green on the defect and would not have
-caught it. Measured on the emitted `.d.ts` of both packages, before and after:
-
-| reading | before | after |
-|---|---|---|
-| `Core extends Canonical` | `true` | `true` |
-| `Canonical extends Core` | `true` | `true` |
-| `Exclude<keyof Canonical, keyof Core>` | `"tags" \| "description"` | `never` |
-| `Exclude<keyof Core, keyof Canonical>` | the four registry keys | the four registry keys |
-
-The new pin asserts the third row and names the fourth explicitly; the assignability pair
-is kept beside it, labelled, as the control that shows what it cannot see. A source-level
-assertion that the canonical members are not restated locally covers the remaining failure
-mode — a member-identical copy, which every `keyof` comparison stays green on and which is
-how the copy this replaces began.
diff --git a/.changeset/6074-check-ts-stale-migration-comment.md b/.changeset/6074-check-ts-stale-migration-comment.md
deleted file mode 100644
index 9789b66adb..0000000000
--- a/.changeset/6074-check-ts-stale-migration-comment.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
----
-
-Comment-only fix in `packages/cli/src/commands/check.ts`: the note beside the
-structural marker gate promised that "the corpus migration repays" the recall
-debt — the real schema files the checker skips because their root carries no
-structural key. No such migration exists and none can be written. The marker it
-would stamp is the `$schema` URL the 2026-08-20 ruling declined to mint, and
-`OBJECTUI_SCHEMA_URL` / `pointsAtObjectUi()` were deleted before objectui#5334
-merged. The same file already states, twenty lines earlier, that there is
-deliberately no `$schema` arm and no URL to declare — so the file contradicted
-itself.
-
-The note now says what is true: the recall debt is real and unpaid, the
-`$schema` route was ruled against, a corpus-wide `$schema` sweep is a measured
-no-op on the skipped-file count, and the arm can be added later without
-invalidating a single file because matching would be host-based. It points the
-next reader at the tracking card and its blocker instead of at a dead route.
-
-No behaviour change and nothing to release — `objectui check` judges, skips and
-prints exactly what it did before.
diff --git a/.changeset/6075-check-validity-recogniser-recall.md b/.changeset/6075-check-validity-recogniser-recall.md
deleted file mode 100644
index 7aeccd03d2..0000000000
--- a/.changeset/6075-check-validity-recogniser-recall.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-'@object-ui/cli': minor
----
-
-`objectui check` recognises a schema by validating it, and reports broken ObjectUI files instead of filing them as foreign ones.
-
-A file with a root `type` was judged only when its root carried an ObjectUI
-structural key (`children`, `body`, `className`, …). Leaf schemas carry only
-their own vocabulary, so nothing checked them: measured on this repository, 475
-files were eligible, 166 were judged and 309 were skipped.
-
-The command now has a second recogniser arm — the document validates as an
-ObjectUI component schema under `@object-ui/types`' own Zod union — which the
-maintainer's 2026-08-25 ruling selected over shipping a JSON Schema artifact to
-point a `$schema` URL at. It admits 209 of those 309 files. The structural arm
-still runs first, so recognition costs nothing for files that already had a
-marker, and `package.json` is still never judged: `"type": "module"` names no
-component the protocol models.
-
-Validity alone would have answered two different questions with one word.
-A broken ObjectUI schema fails validation exactly as a foreign file does, so a
-two-bucket report would have filed it as "not ObjectUI" — and the symptom of
-that is an absence: the file simply stops being mentioned. Measured, that bucket
-is not empty: 54 files land in it and 53 of them are real corpus content.
-
-So files the recogniser refuses are split. When the root `type` names a
-component this build registers, the file is **listed by name** as ObjectUI
-content that did not validate, pointing at `objectui validate <file>` for the
-reason — either the document is off-spec or its component type is not modelled
-by `@object-ui/types`. Everything else is counted as skipped, as before. The
-printed explanation now describes both arms, and only unreadable JSON still
-makes the command exit non-zero.
diff --git a/.changeset/6081-release-lane-drop-changeset-prediction.md b/.changeset/6081-release-lane-drop-changeset-prediction.md
deleted file mode 100644
index 3d99006fab..0000000000
--- a/.changeset/6081-release-lane-drop-changeset-prediction.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
----
-
-CI-only change: the `lane` job in `.github/workflows/changeset-release.yml` no longer
-predicts whether `changesets/action` will see a pending changeset. Its bash mirror of
-the action's file scan and the `pending_changesets` output it fed are deleted, and the
-release job's clear step now runs on every push run — `if: github.event_name == 'push'`.
-
-This supersedes the mirror that `5775-lane-changeset-reader-mirror.md` describes, and
-with it `scripts/__tests__/changeset-release-lane-mirror.test.ts`. The mirror could not
-be kept honest: `changesets/action` is used at a moving tag whose bundled
-`@changesets/read` is a different major from the installed one, and it is a minified
-chunk nothing here installs, so no test could execute it and no lockfile recorded it.
-The `changesets/action@v1` ref pin that lived in that test file is re-homed, not
-dropped — it now has its own file,
-`scripts/__tests__/changeset-release-action-ref-pin.test.ts`, and covers both `uses:`
-lines instead of one.
-
-No published package changes and no release behaviour changes: the clear step is
-idempotent and a measured no-op on a tree with nothing pending (`Removed 0`, exit 0,
-byte-identical tree), so running it unconditionally on the push lane does what the
-prediction was there to arrange. The `github.event_name == 'push'` test is retained
-deliberately — dropping it too would empty the tree on the refresh lane and fossilise
-the version PR silently.
diff --git a/.changeset/6089-hook-selftests-step-names-drop-counts.md b/.changeset/6089-hook-selftests-step-names-drop-counts.md
deleted file mode 100644
index d519e4ab50..0000000000
--- a/.changeset/6089-hook-selftests-step-names-drop-counts.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
----
-
-CI-only change: no published package's `src/` changed.
-
-Drops the hard-coded case counts from the two step names in
-`.github/workflows/hook-selftests.yml` (`guard-main-checkout-bash self-test
-(100 cases)` / `guard-shared-stash self-test (32 cases)` → the bare names).
-Nothing derived those numbers and nothing re-checked them, and a step name has
-no runtime behaviour, so a stale count could only ever show a wrong number on
-the checks page. Each run's own tail already prints `N passed, N failed`, and
-`guard-shared-stash.sh`'s header carries its count with the recipe to
-re-derive it. The `Cost` note keeps its counts, restated as a dated
-measurement (`2026-08-24` @ `53dc89db8`) — history, not a live claim — and a
-new header section records why the two are treated differently. What the
-workflow runs is unchanged: same job, same steps, same `run:` commands.
diff --git a/.changeset/6092-entry-guard-sweep.md b/.changeset/6092-entry-guard-sweep.md
deleted file mode 100644
index e63819ad6d..0000000000
--- a/.changeset/6092-entry-guard-sweep.md
+++ /dev/null
@@ -1,4 +0,0 @@
----
----
-
-Tooling only, no package released: every `scripts/**` entry guard now goes through one predicate. The 29 hand-typed guards `check-entry-guard.mjs` baselined (nine distinct spellings across 28 `.mjs` files, plus `shadcn-sync.js`) are converted to `isEntrypoint(import.meta.url)` and `KNOWN_HAND_TYPED_GUARDS` is empty. Twenty-eight of them were silently wrong: reached through a symlink they compared two different paths, answered `false`, and did nothing — exit 0 with no output, which a CI wrapper holding `result.status` reads as a pass (objectui#6092).
diff --git a/.changeset/6108-sort-axis-convergence.md b/.changeset/6108-sort-axis-convergence.md
deleted file mode 100644
index b031228521..0000000000
--- a/.changeset/6108-sort-axis-convergence.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-'@object-ui/plugin-list': patch
-'@object-ui/plugin-detail': patch
----
-
-The last three sort-axis consumers read the platform's per-column sortability signal instead
-of re-deriving it from the field's type (objectui#6108, inheriting objectstack#10235 ruling A
-through objectui#5729's landed contract). ListView's toolbar sort picker and both of
-RelatedList's sort entry points — the embedded table's column headers and the `data-list`
-sort-button row — now go through `isPlatformSortableField`, the same spelling the grid header
-adopted; their `UNMATERIALIZED_FIELD_TYPES` / `isUnmaterializedFieldType` re-derivations are
-deleted.
-
-The re-derivation was not wrong about `formula`: the platform computes its own projection from
-the same `@objectstack/spec` storage fact, which is why the drift went unnoticed across two
-cards. It parts company on everything the projection encodes as ABSENCE — an unknown name, a
-dotted path a caller can put in a related list's `columns`, an unprovisioned audit column —
-where a type read finds no field definition, answers "sortable", and offers a control the
-runtime meets with `400 INVALID_SORT`. It parts company again on any refusal that carries no
-`reason: virtual-type`, and it cannot follow the platform in the other direction either: a
-field the platform now DOES order by stays withheld forever on its type alone.
-
-Two behaviours are deliberately unchanged. The relational carve-out stays separate from the
-signal — the projection answers `sortable: true` for a `lookup` because the platform can order
-by the stored foreign key, while the UI withholds because that order means nothing beside a
-column of names — so a relational column does not get its sort back. And ListView's picker
-still lists a field the CURRENT sort already names, which is the only way to remove a sort the
-server refuses outright; that exception now covers platform-refused fields, not just formulas.
-
-A deployment that served no `sortability` key at all is a different case from "nothing is
-sortable": that branch keeps the type read as a compatibility floor, so behaviour on a backend
-older than objectstack#10235 (or an inline/mock data source) is byte-identical to before.
diff --git a/.changeset/6110-predicate-scope-unbound-evaluators.md b/.changeset/6110-predicate-scope-unbound-evaluators.md
deleted file mode 100644
index 4be26dce28..0000000000
--- a/.changeset/6110-predicate-scope-unbound-evaluators.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-'@object-ui/app-shell': minor
-'@object-ui/console': minor
-'@object-ui/plugin-form': minor
----
-
-⚠️ **Behaviour change: `current_user` predicates that have been doing nothing on
-the console form routes and in the wizard's submit gate now TAKE EFFECT.** Read
-this before upgrading if any of your form metadata gates on the session user.
-
-objectui#6010 bound the host predicate scope on the five authored-predicate call
-sites in the components form renderer, so `current_user` (plus the ADR-0068
-`user` / `ctx.user` / `os.user` aliases) resolves on `visibleWhen` / `visibleOn`
-there. Two other authored-predicate evaluators were still passing `undefined`
-for that argument, so the same authored text meant two different things
-depending on which surface opened the form (objectui#6110):
-
-- **`apps/console`'s form renderer**, on the authed internal route
-  `/forms/:name`. The internal route is a runtime record surface by ADR-0089
-  D1's own words (*"runtime record surfaces bind `record` + `current_user`"*),
-  and its `visibleWhen` metadata is the same `*.view.ts` FormView the
-  object-view chain renders — so a role gate authored once behaved differently
-  depending on which route opened the form.
-- **`WizardForm`'s submit-time required re-check** (`missingRequiredByStep`),
-  the gate that re-checks the whole declared field set at final submit because
-  `allowSkip` can jump past a step. Its docstring promises *"the same verdict
-  from all three rather than a second, divergent dialect"*, and since #6010 it
-  was the divergent one.
-
-**Why nobody noticed, and why the fix is felt as a change.** `visibleWhen` fails
-OPEN: a field on screen is what you get when the predicate resolves TRUE, when
-the scope was never bound so the predicate faulted, *and* when the predicate is
-broken. Those worlds were indistinguishable, so an app that authored a
-`current_user` gate saw the field render and had no way to tell the rule was
-inert. After this change the predicate is evaluated for real, and fields and
-sections that have always been visible will disappear for the users the rule
-excludes. `requiredWhen` fails the other way (CLOSED), so a `current_user`
-requiredWhen that has been silently not applying will now start holding submits.
-
-In the wizard the change is a fix in the user's favour as well: a required field
-the wizard HID from this user was still counted as visible by the submit gate,
-so the submit was refused on a control the submitter could neither see nor fill
-in.
-
-**Before upgrading**, audit any `visibleWhen` / `visibleOn` / `requiredWhen` in
-your form-view and object metadata that names `current_user`, and confirm each
-predicate says what you actually want evaluated against `record` +
-`current_user`.
-
-**The public anonymous form `/f/:slug` is deliberately unchanged.** It is
-mounted outside `ProtectedRoute` so an anonymous visitor can submit it, there is
-no authenticated principal, and no provider is mounted above it — so its scope
-is empty and a `current_user` predicate authored on a public form still faults
-and still fails open, exactly as before. Nothing new is declared to say so: the
-two routes are told apart by which component mounts them.
-
-`@object-ui/app-shell` exports `buildExpressionUser`, the `ExpressionProvider`
-user normalisation, so every console surface that mounts the provider publishes
-the same `current_user` shape rather than re-deriving it.
diff --git a/.changeset/6111-formsection-visiblewhen.md b/.changeset/6111-formsection-visiblewhen.md
deleted file mode 100644
index d17c7fa6e8..0000000000
--- a/.changeset/6111-formsection-visiblewhen.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
-'@object-ui/plugin-form': minor
-'@object-ui/types': minor
----
-
-⚠️ **Behaviour change: an authored `FormSection.visibleWhen` that has been doing nothing
-will now START HIDING SECTIONS.** Read this before upgrading if any of your metadata
-authors a section predicate.
-
-`@objectstack/spec` declares `FormSection.visibleWhen` and this repo's spec bridge maps it
-through, but every plugin-form layout renders a section header as a virtual
-`section-divider` pseudo-field and none of them copied the predicate onto it. On the
-object-view chain — the create/edit modal, the drawer, the split form, and the full-page
-record form — the key was declared, mapped, carried, and then dropped one hop before
-anything could evaluate it. The section rendered unconditionally, with no diagnostic
-(objectui#6111).
-
-**Why nobody noticed, and why the fix is felt as a regression.** `visibleWhen` fails OPEN:
-a section that renders is what you get when the predicate resolves TRUE, when the predicate
-never arrives, *and* when the predicate faults. Those three worlds were indistinguishable,
-so an app that authored a section predicate saw its section render and had no way to tell
-that the rule was inert. Every such app has been running with the rule switched off, and
-some will have been authored — or simply grown used to — that state. After this change the
-predicate is evaluated for real, and sections that have always been visible will disappear
-for the users the rule excludes.
-
-This is the intended ADR-0089 contract being delivered, not a new capability: the key was
-already declared, already documented, and already honoured by the console form renderer.
-The object-view chain was the one that silently ignored it.
-
-**Before upgrading**, audit any `sections[].visibleWhen` in your form-view metadata and
-confirm each predicate says what you actually want, evaluated against `record` +
-`current_user`. A predicate that was written speculatively, or left behind after a rework,
-now takes effect.
-
-**Measured scope of the hide.** The predicate gates the section's HEADER row. The renderer
-treats `section-divider` as presentational and holds no association between it and the
-fields that follow it, so a false predicate removes the heading and the section's fields
-keep rendering. The console renderer (`apps/console`) drops the whole `<section>`, fields
-included. That divergence is real, is pinned honestly by this change's tests rather than
-implied away, and is filed separately — it needs a renderer-side grouping contract, not
-another line in a layout.
-
-Two hops were dropping the key and both are repaired: `ObjectForm` rebuilds each section
-key by key when it delegates to Split/Drawer/Modal (and `ModalForm`'s own `groups` map does
-it again), so a key those maps did not copy never reached the layout at all; and the six
-`section-divider` synthesis sites across the four layout files.
-
-`@object-ui/types` gains the matching `ObjectFormSection.visibleWhen` declaration.
diff --git a/.changeset/6120-doc-snippet-dependency-resolution.md b/.changeset/6120-doc-snippet-dependency-resolution.md
deleted file mode 100644
index 01f3621a10..0000000000
--- a/.changeset/6120-doc-snippet-dependency-resolution.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
----
-
-Doc-snippet gate tooling only, no published package source changed.
-
-`check-doc-snippet-types` compiles every covered snippet as its own module at the
-repository ROOT. Workspace packages resolved there — it builds `paths` from each
-package's own `exports` — but a THIRD-PARTY specifier did not: under pnpm, a
-workspace package's own dependency is not hoisted to the root, so a snippet that
-imports `lucide-react` failed `TS2307` even though `@object-ui/layout` and
-`@object-ui/components` both declare it and any reader who installs those
-packages gets it. Five correct blocks across `content/docs/layout` were red on
-nothing but that, which blocked the whole group from being brought under the
-gate. The snippets were right; the resolution environment was the gap.
-
-The gate now derives `paths` for the specifiers each imported package DECLARES in
-its own `dependencies`, resolved from inside that package's directory — the
-environment a real consumer has. Deliberately narrow, and it fails closed:
-`dependencies` only (not peers, not devDependencies), only packages a covered
-document actually imports, only the bare specifier (no subpath wildcard), and a
-dependency shipping no types is left unresolvable rather than approximated. The
-repository's own manifests are untouched — declaring `lucide-react` at the root
-to buy a snippet its coverage would change what this repo claims to need in order
-to satisfy a checker.
-
-A fourth self-control (`undeclared`) now runs on every invocation and keeps that
-narrowness honest: a module importing `@floating-ui/react-dom` — installed here
-as a transitive of Radix's popper, declared by no package a covered document
-imports — MUST still produce `TS2307`. Widen resolution past the declarations and
-that control goes green, which is the only way to notice that the gate has become
-a rubber stamp no snippet can fail.
diff --git a/.changeset/6122-action-prop-renames.md b/.changeset/6122-action-prop-renames.md
deleted file mode 100644
index d99824e289..0000000000
--- a/.changeset/6122-action-prop-renames.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
----
-
-Docs only, publishes nothing: five `content/docs/components` reference pages
-annotated an event prop as `string | ActionConfig` — a type `@object-ui/types`
-has never exported. Each site was resolved individually against the freshly
-built `packages/types/dist/*.d.ts`, and in every case the shipped slot is a
-plain function callback that the page had also named wrongly:
-
-| page | documented | shipped slot | declaration |
-| --- | --- | --- | --- |
-| `form/command.mdx` | `onSelect` | `onChange?: (value: string) => void` | `form.d.ts:1376` |
-| `form/radio-group.mdx` | `onValueChange` | `onChange?: (value: string \| number) => void` | `form.d.ts:394` |
-| `form/date-picker.mdx` | `onDateChange` | `onChange?: (date: Date \| undefined) => void` | `form.d.ts:642` |
-| `form/combobox.mdx` | `onValueChange` | `onChange?: (value: string) => void` | `form.d.ts:1324` |
-| `feedback/toast.mdx` | `actionLabel` + `onAction` | `action?: { label: string; onClick: () => void }` | `feedback.d.ts:137` |
-
-The `string |` half of each annotation goes with the name, and that is the
-substance rather than a tidy-up: objectui#4453 narrowed the runtime to
-`typeof === 'function'`, so an authored string handler is **dropped**
-(`packages/plugin-calendar/src/calendar-view-renderer.tsx`). A reference page
-promising `string | Fn` is exactly what makes an AI author emit a handler that
-publishes, validates, and silently does nothing.
-
-No type was minted to make the prose true. Measured with a throwaway re-fence
-probe: `TS2304: Cannot find name 'ActionConfig'` **10 → 5** across the
-`components` group, and the 5 that remain are objectui#6132's, untouched here.
-
-Part of objectui#6122.
diff --git a/.changeset/6126-fields-unresolvable-imports.md b/.changeset/6126-fields-unresolvable-imports.md
deleted file mode 100644
index db0de73c8a..0000000000
--- a/.changeset/6126-fields-unresolvable-imports.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
----
-
-Docs only, publishes nothing: two `content/docs/fields` snippets referenced
-identifiers the snippet program cannot resolve, so both pages were held out of
-objectui#5867's batch 3 (objectui#6126). Neither is fixed by making the compiler
-happy — each was narrowed to what ObjectUI actually owns.
-
-`auto-number`'s Sequence Management block called `db.transaction` on a `db`
-declared nowhere in the workspace and exported by nothing (TS2304, plus TS7006
-on the `tx` that fell out of it). Declaring an ambient `db` would have had the
-renderer's documentation mint a backend contract it does not own, so the block
-is now the metadata the backend actually reads — a literal annotated with the
-exported `AutoNumberFieldMetadata`, carrying `format` and `starting_number` —
-and the transactional sketch is prose: one counter per object-and-field pair,
-incremented in the same transaction that inserts the record. The page now also
-says the thing it never said, which is that ObjectUI never allocates a value at
-all and renders a placeholder until the saved record comes back.
-
-`object`'s Backend Validation block opened `import Ajv from 'ajv'`, and `ajv` is
-declared by no `package.json` in this repository and resolves from nowhere
-(TS2307). Adding it as a dependency to satisfy a checker was refused, so the
-block keeps the ObjectUI half — an `ObjectFieldMetadata` literal whose `schema`
-is the JSON Schema a server validates against — and the Ajv call sequence, which
-was Ajv's documentation rather than ObjectUI's, is a prose sentence naming it as
-one option among any JSON Schema validator. The section now states the fact a
-reader most needs: `ObjectField` checks JSON syntax only and never enforces
-`schema`, so structural validation is the server's.
-
-Both pages join the compile population with the batch's own classifier: the four
-`plaintext`-fenced blocks whose first line starts with `import` or `interface`
-are now `ts`. The gate's blocks-to-compile count rises from 206 to 210 — exactly
-those four — with diagnostics at 0, no new `FRAGMENT_MARKER` declarations, and
-the covered/ungated and declared-fragment sets unmoved.
diff --git a/.changeset/6127-location-map-fence-split.md b/.changeset/6127-location-map-fence-split.md
deleted file mode 100644
index 49578b3076..0000000000
--- a/.changeset/6127-location-map-fence-split.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
----
-
-Docs only, publishes nothing: `content/docs/fields/location.mdx`'s *Integration
-with Maps* fence welded two different examples into one block — an import plus a
-JSX element (which needs `tsx`), immediately followed by a bare metadata object
-literal at statement position (which `tsx` reads as a labelled statement, then
-fails on the commas). Measured standalone with the repo's own TypeScript on
-`origin/main`: **2 syntactic diagnostics as `ts`, 5 as `tsx`** — it parsed under
-neither fence language, which is why `location.mdx` was excluded from objectui#5867
-batch 3 by measurement (objectui#6127). The fence is now **split in two**, each half
-fenced for what it actually is: a `tsx` block holding the widget example, made
-self-contained so it compiles (it renders `LocationField` with a typed
-`LocationFieldMetadata` and a state-held coordinate pair, instead of spreading an
-undeclared `props`), and a `jsonc` block holding the `object-map` metadata node —
-which is a schema-key question `check-doc-snippet-types` explicitly says it does
-not answer. Connecting prose numbers the two halves so the section still reads as
-one example. The page's *Field Schema* block, the other fence triage's classifier
-calls code, is re-fenced `plaintext` → `ts` in the same pass; the two genuinely
-prose fences (`{` and `// Valid coordinates`) are left alone.
-
-Accounting, stated because splitting a fence breaks the plain "blocks-to-compile
-rises by exactly the batch size" identity this card family has used across three
-batches: **1 block re-fenced, plus 1 fence split into 2 of which 1 half is
-TypeScript, so blocks-to-compile rises by 1 + 1 = 2** — measured 206 → 208, with
-diagnostics at 0, declared fragments unmoved at 111, and the covered/ungated sets
-unchanged. The page's fence count rises 4 → 5. Both blocks also stop rendering as
-unstyled plaintext and pick up TypeScript and JSON-with-comments highlighting,
-which is reader-visible.
diff --git a/.changeset/6131-sidebar-nav-navgroup-annotation.md b/.changeset/6131-sidebar-nav-navgroup-annotation.md
deleted file mode 100644
index bb475295e3..0000000000
--- a/.changeset/6131-sidebar-nav-navgroup-annotation.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
----
-
-Docs only, publishes nothing: the "Complete Example" block in
-`content/docs/layout/sidebar-nav.mdx` now annotates its grouped-navigation array as
-`NavGroup[]`, importing the type in the same block (objectui#6131).
-
-Without the annotation the array's `badgeVariant: 'destructive'` widens to `string`,
-and `SidebarNav`'s declared `badgeVariant?: 'default' | 'destructive' | 'outline'`
-does not accept it — so the whole array fails to assign to
-`items: NavItem[] | NavGroup[]`. TypeScript then reports the union's *other* branch,
-which is why the message reads "missing the following properties from type 'NavItem':
-title, href" and looks at first like a wrong data shape. The data shape was always
-right; the annotation was missing. A reader who copies this block into an annotated
-position, or assigns it anywhere typed under `strict`, hits the same TS2322.
-
-Measured on this branch against the built `dist/*.d.ts`, with the block temporarily
-re-fenced as `ts` under an `EXIT` trap so it joins the compile population (the fence
-itself belongs to objectui#5867's lane and is deliberately left as `plaintext` here):
-
-- before the annotation, `Semantic phase: 224 of 224 block(s) judged, 1 failed`, gate
-  exit 1, on `content/docs/layout/sidebar-nav.mdx:235:7  TS2322`;
-- after it, `Semantic phase: 224 of 224 block(s) judged, 0 failed`, gate exit 0.
-
-Removing the annotation again reproduces the identical TS2322, so it is load-bearing
-rather than decorative. Declared fragment count is unmoved at 111, no
-`FRAGMENT_MARKER` is added, and the covered/ungated sets are untouched.
-
-The annotation is written so that it **resolves**: the type is imported in the same
-block, because every block compiles in isolation. An annotation naming a type the
-block cannot see errors on the annotation itself, at which point TypeScript stops
-checking the literal underneath and the TS2322 disappears — the false-green shape
-already recorded for `guide/theming` in `scripts/check-doc-snippet-types.mjs`.
-
-This clears the last `content/docs/layout` block that stays red for a reason of its
-own, so the layout group is type-clean ahead of objectui#5867 re-fencing it.
diff --git a/.changeset/6138-fields-schema-block-parity-pr1.md b/.changeset/6138-fields-schema-block-parity-pr1.md
deleted file mode 100644
index ac0d7216fe..0000000000
--- a/.changeset/6138-fields-schema-block-parity-pr1.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
----
-
-Docs only, publishes nothing: the `Field Schema` block on every
-`content/docs/fields` page declared an interface of its own, so
-`check-doc-snippet-types` compiled it **vacuously** — a self-declared interface
-with no imports type-checks no matter what it says, because nothing in the block
-refers to anything the packages export (objectui#6138). The gate reported those
-pages green and structurally could not see whether the documented shape matched
-the shipped one. This is batch 1 of 2: the shared page plus four converted
-pages, proving the mechanism end to end before it is applied to the rest.
-
-Each converted `Field Schema` block is now a literal **annotated** with that
-field type's exported `*FieldMetadata`, so the sealed type's excess-property
-check judges every documented key. The page becomes structurally incapable of
-teaching a key the type does not have.
-
-Measured before converting: all 26 pages diverged from their exported type, and
-on 24 of them the divergence was **entirely** `FieldWidgetComponentProps`
-members — a real, exported, reader-facing surface filed under a heading that
-says "Field Schema". Deleting them would have deleted correct API, so the shapes
-are separated instead of one being dropped: a new `content/docs/fields/widget-props.mdx`
-documents `FieldWidgetComponentProps` once, with a gate-compiled example and the
-type named as the source of truth, and the field pages link to it. That page
-carries no hand-maintained key list — the type has 76 members and a prose
-restatement of a declared surface is the defect class objectui#6086 is open for.
-
-Three documentation defects the conversion forced out into the open, each a page
-teaching something no shipped type declares:
-
-- `date.mdx` documented the range bounds as `min` / `max`; `DateFieldMetadata`
-  declares `min_date` / `max_date`, and the sibling `datetime.mdx` already
-  documented that spelling. Two adjacent reference pages taught two spellings of
-  one concept and one of them did not exist. The docs are corrected; the type is
-  not touched.
-- `textarea.mdx` named `TextAreaFieldMetadata`; the export is
-  `TextareaFieldMetadata` (lowercase `a`). A name that must resolve, so it now
-  does.
-- `rich-text.mdx` named `RichTextFieldMetadata`, which does not exist at all. The
-  page's own block says `type: 'markdown' | 'html'`, so it resolves against the
-  existing `MarkdownFieldMetadata` / `HtmlFieldMetadata` pair rather than a
-  minted type. It also documented `toolbar`, `preview`, `minHeight` and
-  `maxHeight`, which `RichTextField` reads nowhere (`minHeight` / `maxHeight`
-  have zero occurrences in `packages/fields/src`), and `rows`, which it does read
-  through an `as any` while neither metadata type declares it — filed as
-  objectui#6140 with that measurement in it.
-
-The gate's blocks-to-compile count rises from 225 to 227 — the new page's two
-blocks, the conversions being one-block-for-one-block — with diagnostics at 0, no
-new `FRAGMENT_MARKER` declarations, and the declared-fragment count unmoved at 111.
diff --git a/.changeset/6138-fields-schema-block-parity-pr2.md b/.changeset/6138-fields-schema-block-parity-pr2.md
deleted file mode 100644
index 2bcd93ad29..0000000000
--- a/.changeset/6138-fields-schema-block-parity-pr2.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
----
-
-Docs only, publishes nothing: batch 2 of 2 for objectui#6138 — the remaining
-**22** `content/docs/fields` pages have their `Field Schema` block converted from
-a self-declared interface to a literal **annotated** against that field type's
-exported `*FieldMetadata`, each linking the shared
-`content/docs/fields/widget-props.mdx` page batch 1 added.
-
-A self-declared interface with no imports type-checks no matter what it says, so
-`check-doc-snippet-types` reported these pages green while being structurally
-unable to see whether the documented shape matched the shipped one. An annotated
-literal is judged by the compiler instead: the page becomes incapable of teaching
-a key the type does not have.
-
-That property depends on the annotated types being **sealed**, so it was measured
-rather than assumed. All 26 types this batch annotates against — the 22 field
-metadata types plus `SelectOptionMetadata`, `GridColumnDefinition`,
-`UploadedFileMetadata` and `LookupColumnDef` — carry no index signature, and a
-nonsense key on each produces `TS2353`. The same control run against the
-components lane's `BaseSchema` / `ButtonSchema` produces **zero** diagnostics,
-which is what an open type does and why that lane cannot use this mechanism
-(objectui#6143).
-
-Documentation defects the conversion forced out, each a page teaching something
-no shipped type declares:
-
-- `grid.mdx` documented a per-column `editable` flag and a string `width`.
-  `GridColumnDefinition` declares neither — `width` is a number of pixels — and
-  no widget reads a column-level `editable`. Both are corrected.
-- `formula.mdx` documented `return_type` as taking `currency`; the shipped union
-  is `'text' | 'number' | 'boolean' | 'date' | 'datetime'`.
-- `lookup.mdx` documented option keys `_id` and `name`; the widget matches
-  options by `value` and labels them by `label`, and those two keys are read off
-  **records**, not options.
-- `user.mdx` documented the value as a user object; the field stores the user's
-  id and the picker resolves the rest from `sys_user`.
-
-Two undeclared-but-consumed keys were found by checking each divergence against
-its renderer, and are filed rather than deleted or documented as metadata:
-`dependsOn` on select and `description` on a lookup's static options
-(objectui#6153, the same class as objectui#6140). The location field's stored
-`{ latitude, longitude }` value shape is declared by no exported type at all
-(objectui#6154), so that page describes it in prose and points at the card.
-
-The gate's blocks-to-compile count rises from 248 to 249 — 21 conversions are
-one-block-for-one-block and `lookup.mdx` becomes two blocks (data-source-backed
-and static-option) — with diagnostics at 0, no new `FRAGMENT_MARKER`
-declarations, and the declared-fragment count unmoved at 111.
diff --git a/.changeset/6143-components-schema-corrections.md b/.changeset/6143-components-schema-corrections.md
deleted file mode 100644
index c23ec20ba2..0000000000
--- a/.changeset/6143-components-schema-corrections.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
----
-
-Docs only, publishes nothing: four `content/docs/components` reference pages
-taught props the shipped types do not have. Each correction was resolved
-against a freshly built `packages/types/dist/*.d.ts` **and** against the zod
-schemas that are the ruled enforcement boundary, so both layers agree:
-
-| page | documented | shipped | declaration |
-| --- | --- | --- | --- |
-| `feedback/toast.mdx` | `variant?: 'default' \| 'destructive'` | `variant?: 'default' \| 'success' \| 'warning' \| 'error' \| 'info'` | `feedback.d.ts:123`, `zod/feedback.zod.js:59` |
-| `form/radio-group.mdx` | `direction` | `orientation?: 'horizontal' \| 'vertical'` | `form.d.ts:377`, `zod/form.zod.js:263` |
-| `form/combobox.mdx` | `searchPlaceholder`, `emptyText` | neither is declared | `form.d.ts:1283`, `zod/form.zod.js:378` |
-| `form/command.mdx` | `CommandItem.shortcut` | `CommandItem` declares only `value`, `label`, `icon` | `form.d.ts:1329`, `zod/form.zod.js:76` |
-
-`toast.mdx` is the one that mattered most: `'destructive'` is not a member of
-the union, it is the Shadcn vocabulary a reader arrives with, and it is the
-value most likely to be copied verbatim into an authored schema.
-
-Each removal was checked against the renderer before it was made, because a
-key a renderer genuinely reads is an undeclared capability rather than a doc
-error. None of these four is read: `renderers/form/combobox.tsx` contains
-neither `searchPlaceholder` nor `emptyText`, `renderers/form/command.tsx`
-contains no `shortcut`, and `renderers/feedback/toast.tsx` contains no
-`'destructive'`. The same sweep's genuinely-consumed keys went to
-objectui#6150 instead of being edited away.
-
-`emptyText` is removed from `ComboboxSchema` only. `CommandSchema` really does
-declare it (`form.d.ts:1368`), so `command.mdx` keeps it.
-
-No type, export or union member was minted, nothing was re-fenced, and no
-block changed shape — these blocks stay `plaintext` and stay outside the
-compile population. `check:doc-snippets` reports the same numbers before and
-after: 248 blocks to compile, 111 declared fragments, 178 covered / 44
-ungated. The import mechanism this card originally proposed is sequenced
-behind objectui#5155 and is deliberately not attempted here.
-
-Part of objectui#6143.
diff --git a/.changeset/6151-stack-schema-omit-collapse.md b/.changeset/6151-stack-schema-omit-collapse.md
deleted file mode 100644
index 92f2ab2c8a..0000000000
--- a/.changeset/6151-stack-schema-omit-collapse.md
+++ /dev/null
@@ -1,52 +0,0 @@
----
-'@object-ui/types': minor
----
-
-`StackSchema` now SHIPS the members it declares (objectui#6151). Its emitted declaration
-carried one property — `type` — where it was meant to carry twenty-five.
-
-The interface was written `extends Omit<FlexSchema, 'type'>`: "everything `FlexSchema` has,
-with a different `type`". That spelling erases every named member. `Omit` of a type over a
-key set is `Pick` over `Exclude` of `keyof` that type, and `keyof` a type carrying a string
-index signature is `string | number` — the literal member names are absorbed. `FlexSchema`
-inherits `BaseSchema`'s `[key: string]: any` (objectui#5155), so excluding `'type'` from
-`string | number` still leaves `string | number`, and the `Pick` rebuilt a type holding the
-index signature and none of the named members. Measured against the built `dist`:
-`FlexSchema` declared 25 properties, `StackSchema` declared 1.
-
-Nothing errored, which is why it survived four releases: the index signature keeps every
-absent key assignable and readable as `any`. The cost fell entirely on the tools that READ
-the declaration. Editor completion on a `stack` node offered `type` and nothing else — no
-`gap`, no `align`, no `justify`, no `children`. And a docs-versus-type sweep read
-`stack.mdx` as documenting keys that do not exist: objectui#6143 flagged `gap`, `children`
-and `className` there as divergences when the docs were right and the type was wrong.
-
-Fixed at the mechanism rather than by restating the members. The six flex/stack members now
-live in a new exported interface, `FlexLayoutProps`, which does NOT inherit `BaseSchema`,
-and `FlexSchema` and `StackSchema` each extend `BaseSchema` and `FlexLayoutProps`. No
-`Omit` crosses the index signature any more, and the members are declared once rather than
-duplicated. Extending `FlexSchema` directly was measured unavailable: an interface may
-narrow an inherited property only to a subtype, and `'stack'` is not a subtype of
-`FlexSchema`'s `type: 'flex'` (TS2430).
-
-`FlexSchema` is unchanged — its six member declarations moved byte-identically, and its
-emitted member set is the same 25 names before and after. The only declaration whose shape
-changes is `StackSchema`, which goes from 1 property to the same 25.
-
-**The one way this can newly error**, and why it ships as `minor`: keys on a `stack` node
-were previously answered by the index signature as `any`, so `gap: 'large'` type-checked.
-`gap` is now `number | undefined` and that line is a `tsc` error. Every value this newly
-rejects is one the renderer never honoured — `stack.tsx` feeds `gap` to a Tailwind numeric
-scale — so the change reports a defect that was already there rather than removing a
-capability. All three in-repo packages that name `StackSchema` or `FlexSchema`
-(`@object-ui/components`, `@object-ui/core`, the schema-catalog example) type-check green
-unchanged.
-
-Guarded by `packages/types/src/__tests__/stack-schema-emitted-members.test.ts`, which
-asserts against the EMITTED declaration rather than the source. That distinction is the
-whole point: a source-level assertion passes on the broken code, because the index
-signature answers for the missing key with `any`. The guard emits declarations with the
-package's own tsconfig and asserts (1) `StackSchema` declares exactly what `FlexSchema`
-declares, and (2) no member of the `LayoutSchema` union has lost any of `BaseSchema`'s
-named members — so the next heritage clause that collapses under the index signature reds
-for the whole class, not just for this one interface.
diff --git a/.changeset/6158-radio-group-orientation.md b/.changeset/6158-radio-group-orientation.md
deleted file mode 100644
index 51472aa062..0000000000
--- a/.changeset/6158-radio-group-orientation.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-'@object-ui/components': minor
----
-
-`radio-group` now renders the `orientation` its own type has always declared (objectui#6158).
-
-`RadioGroupSchema.orientation` was declared in two layers and read by none. The shipped TS
-type carries `orientation?: 'horizontal' | 'vertical'` with `@default 'vertical'`
-(`packages/types/src/form.ts:383`) and the zod mirror carries the matching
-`z.enum(['horizontal', 'vertical'])` (`packages/types/src/zod/form.zod.ts:282`), while
-`packages/components/src/renderers/form/radio-group.tsx` contained neither the string
-`orientation` nor `direction` and forwarded only `defaultValue`, `className`, the
-form-control DOM whitelist and the designer props.
-
-The consequence was measurable rather than cosmetic: every radiogroup root the library
-rendered came back byte-identical on that axis — no `data-orientation`, no
-`aria-orientation` — so the docs page's `## Layout Options` section demonstrated a
-distinction the product could not make, and its horizontal demo rendered vertically. An
-author reading the shipped type had every reason to write `orientation: 'horizontal'` and
-no way to discover it was inert.
-
-The key is now forwarded to the underlying Radix `RadioGroup`, which accepts it natively
-with the same two-value vocabulary and puts it on the root as `aria-orientation` and
-`data-orientation`; the layout utilities follow it so the visible difference the docs
-promise is real. This restores declared = enforced **without widening the acceptance
-set** — no new key is accepted, and no spelling outside the declared enum becomes legal.
-
-Two behaviour notes for anyone already shipping radio groups:
-
-- The declared `@default 'vertical'` is now actually applied instead of being left to
-  Radix's own `undefined`. A group that never authored the key keeps the vertical stack it
-  already rendered, and additionally announces `aria-orientation="vertical"` — the
-  announced orientation now agrees with the rendered one rather than being absent. Arrow
-  key roving focus narrows to Up/Down for those groups, which is the correct pairing for a
-  vertical stack.
-- Author `className` still wins: the orientation layout utilities compose first and the
-  authored class last, so tailwind-merge resolves every conflict in the author's favour.
-
-Registry meta `inputs` for `radio-group` gains `orientation` in the same change — it was
-the third surface that omitted the key, and leaving it out would have kept the designer
-palette disagreeing with the type.
diff --git a/.changeset/6165-home-item-type-label-parity.md b/.changeset/6165-home-item-type-label-parity.md
deleted file mode 100644
index ea059e0160..0000000000
--- a/.changeset/6165-home-item-type-label-parity.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-Home renders one agreed label for an item kind that has no translation key.
-
-The rail (`HomeContinue`), `RecentApps` and `StarredApps` all resolve the same
-`home.recentApps.itemType.*` label, and each spelled the lookup itself. They had
-drifted: the rail fell back to the bare kind (`report`) where both card surfaces
-fell back to the capitalised one (`Report`) — two spellings of the same word on
-one screen. All three now resolve through a single `recentItemTypeLabel` helper,
-so the fallback cannot drift apart again.
-
-User-visible: the rail's label for an unkeyed kind changes from `report` to
-`Report`. Every kind shipping today carries a key, so no label changes for them;
-this is about the next kind added, and any host passing a kind the locales do
-not carry.
diff --git a/.changeset/6166-zh-breadcrumb-reports.md b/.changeset/6166-zh-breadcrumb-reports.md
deleted file mode 100644
index 99da771680..0000000000
--- a/.changeset/6166-zh-breadcrumb-reports.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-'@object-ui/i18n': patch
----
-
-The zh pack's `console.breadcrumb.reports` renders 报表, the noun the rest of the pack
-already uses for the report feature (objectui#6166).
-
-**The authority for this edit is the maintainer ruling of 2026-08-25, not an occurrence
-count.** The card was filed explicitly as a native-speaker call and explicitly forbade
-resolving it by normalising to the majority: 报表 (a tabular/data report) and 报告 (a
-written/narrative report) are not interchangeable, so a pack that spells one key
-differently from its siblings is evidence of a majority and never, on its own, evidence of
-a mistake. The maintainer ruled that no deliberate narrative-report distinction was
-intended here and that the breadcrumb names the same report feature the rest of the pack
-calls 报表.
-
-The render context corroborates the ruling and closes the confidence gap triage recorded
-when it declined to decide this itself. `console.breadcrumb.reports` labels the
-`routeType === 'report'` **list** route in app-shell's `AppHeader` — a structural sibling
-of the `dashboards`, `pages` and `system` segments beside it — and drilling through it
-appends a metadata report definition, the same feature named by
-`console.commandPalette.reports`, `console.nav.navReport`, `search.typeReports`,
-`search.badgeReport` and `search.reportNotFound`. Nothing narrative renders beneath it.
-
-A comment at the key records that this was **ruled** rather than counted, and states the
-报表/报告 distinction it was ruled against, so the next reader measuring pack consistency
-neither re-files it nor quietly restores 报告 after reading the render context and
-disagreeing. That comment is half of the deliverable; the value change alone would leave
-the decision unrecorded, which is the failure mode the card was most concerned about.
-
-**Scope: one key, one pack.** This is not a licence to normalise vocabulary across the ten
-packs — the card names that hazard explicitly and says it would need its own ruling, and
-this ruling grants nothing beyond the single key it names. No `en` value changes, so no
-other pack is asked to follow, and no other pack was touched.
diff --git a/.changeset/6167-plugin-form-catalog-entries.md b/.changeset/6167-plugin-form-catalog-entries.md
deleted file mode 100644
index 0a31d99a68..0000000000
--- a/.changeset/6167-plugin-form-catalog-entries.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
----
-
-Docs and catalog fixtures only, no published package source touched: the two `plugin-form`
-catalog entries are now real `object-form` nodes instead of hand-built `form` schemas.
-`content/docs/plugins/plugin-form.mdx` mounted `basic-form` and `contact-form` under
-`PluginLoader plugins={['form']}` while both authored a root `type: "form"` with `input` /
-`select` / `checkbox` / `textarea` fields — every one of those registered by
-`@object-ui/components`, none of them by `@object-ui/plugin-form`, whose own keys are
-`object-form`, `embeddable-form`, `form-analytics`, `object-master-detail-form`,
-`record:line_items` and `view:form`. They are replaced by `object-form-record` (one `users`
-record, fields derived from the object's metadata, `fields` / `columns` shaping the grid)
-and `object-form-tabbed-sections` (the same record with `formType: 'tabbed'`, so the
-declared `sections` become tab panels of one form).
-
-The two hand-built forms are legitimate `@object-ui/components` examples filed under the
-wrong plugin, so they are re-seated into `components-form-form` as `basic-form` and
-`demo-request-form` rather than deleted — deleting a catalog entry moves corpus-wide
-counters (`NODE_CENSUS` in `layout-dom-leak-5574.test.tsx` and in
-`form-control-dom-leak-5632.test.tsx`, and the `className`-carrying layout node and `stack`
-node floors in `layout-props-conversion.test.tsx`), and a counter that moves because a
-fixture was deleted is indistinguishable later from one that moved because coverage
-regressed. All of them are unchanged, with no floor edited.
-
-`apps/site/app/components/registerCatalogBlocks.ts` now declares `@object-ui/plugin-form`,
-and its header no longer claims the import list is "exactly the packages that census
-resolves to". The two `OWN_PLUGIN_DEBT` lines in `catalog-gallery-render.test.tsx` are
-deleted, so both entries are held to the pin like every other one, and the pin's
-provenance instrument now reads the fixture record out of a form control's value as well as
-out of the tile's text — a form puts its record in `input.value`, where `textContent`
-cannot see it.
diff --git a/.changeset/6170-timeline-schema-declared-keys.md b/.changeset/6170-timeline-schema-declared-keys.md
deleted file mode 100644
index da89bd6eca..0000000000
--- a/.changeset/6170-timeline-schema-declared-keys.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-'@object-ui/plugin-timeline': minor
-'@object-ui/types': minor
----
-
-`TimelineSchema` now declares the presentational keys the timeline renderer actually reads
-(objectui#6170, maintainer ruling 2026-08-25 — the same family rule adopted on
-objectui#6172: the exported type aligns to the measured authored + read set).
-
-Before this, `TimelineSchema` declared `events` (required), `orientation` and `position`,
-and nothing else. `TimelineRenderer` is annotated `schema: TimelineSchema` and reads nine
-keys off that node — `variant`, `items`, `dateFormat`, `onItemClick`, `minDate`, `maxDate`,
-`rowLabel`, `scale`, `timeScale` — and **none** of the three that were declared. The docs
-property table and the registration's own designer `inputs` had agreed with the renderer
-all along; only the exported type disagreed. It was invisible to `tsc` because `BaseSchema`
-carries `[key: string]: any`, so every undeclared key resolved as `any` and the annotation
-constrained nothing.
-
-The most visible casualty was the docs page's own TypeScript example, which did not
-compile: `Property 'events' is missing in type '{ type: "timeline"; variant: string; items:
-… }' but required in type 'TimelineSchema'`. The page taught an authoring form its own
-published type refused.
-
-**Declared now** (TS interface and the `@object-ui/types/zod` mirror together): `variant`,
-`items`, `dateFormat`, `scale`, `timeScale`, `rowLabel`, `minDate`, `maxDate`. `onItemClick`
-is deliberately left undeclared — it is a runtime slot `ObjectTimeline` installs, and this
-package keeps callback-shaped keys off the authored surface.
-
-**`scale` is the canonical axis key.** It is `@objectstack/spec`'s `ui/TimelineConfig.json`
-spelling and the one `resolveTimelineScale` reads first (`scale ?? timeScale`). The designer
-now offers it, with all six buckets: `hour` / `quarter` / `year` have rendered correctly
-since objectui#2942 but were offered by neither the designer (which listed three) nor the
-exported type (which listed none), so they were authorable and undiscoverable. `timeScale`
-stays as a deprecated alias so stored JSON keeps working; retiring it is routed separately.
-
-**`events` is now optional.** It was required, which is why the documented authoring form
-did not type-check. That widening is the only non-additive change here — strictly more
-programs compile and strictly more input parses than before. `events`, `orientation` and
-`position` remain declared and remain read by nothing; a timeline authored with `events`
-still renders an empty rail. Their removal is a breaking narrowing of a published type and
-is routed through ADR-0049 enforce-or-remove as its own change, not smuggled into this one.
-
-Accept-set note for consumers: keys that previously resolved as `any` are now typed, so a
-value the renderer never implemented — `variant: 'diagonal'`, `dateFormat: 'medieval'`,
-`scale: 'fortnight'` — is a type error and a Zod rejection where it used to pass silently.
-Nothing that renders today stops rendering. `BaseSchema`'s index signature is untouched, so
-an undeclared key is still accepted by both halves (objectui#5155 / objectui#6269 own that
-ceiling).
diff --git a/.changeset/6175-column-state-persistence.md b/.changeset/6175-column-state-persistence.md
deleted file mode 100644
index ae287843cf..0000000000
--- a/.changeset/6175-column-state-persistence.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-'@object-ui/components': patch
-'@object-ui/plugin-grid': patch
----
-
-Column width and order that a user drags in `ObjectGrid` now actually persist
-(objectui#6175). Both halves of `saveColumnState`'s only two call sites were dead, so a
-drag was written nowhere — not to `localStorage`, not through `onColumnStateChange` to the
-host's `dataSource.updateViewConfig`. The saved state was read back correctly forever; it
-was simply never written.
-
-Two independent breaks, one per package:
-
-- **`@object-ui/components`** — `DataTableSchema` has declared
-  `onColumnResize?: (columnKey, width) => void` all along, and `data-table.tsx` invoked it
-  **nowhere**: the resize drag updated the table's local `columnWidths` state and stopped
-  there. It now reports the settled width once, at `mouseup`. Once, deliberately — the host
-  turns this callback into a write to shared view config, so a per-`mousemove` callback
-  would be a write storm.
-- **`@object-ui/plugin-grid`** — `ObjectGrid` emitted `onColumnReorder` (singular) while the
-  renderer invokes the near-duplicate `onColumnsReorder` (with the `s`), a different declared
-  key with a different signature. The producer now emits the spelling the renderer actually
-  invokes, mapping the reported `TableColumn[]` to the `accessorKey` order `columnState`
-  stores.
-
-**Nothing is retired.** Both spellings remain declared on `DataTableSchema`;
-`onColumnReorder` stays declared and stays unwired, exactly as the `RuntimeOnlyDeclared`
-ledger in `zod-mirror-parity.test.ts` records it. Which of the two survives is a
-declared-surface ruling that stays open and is deliberately not settled here.
-
-⚠️ Behavioural note for hosts: `onColumnStateChange` now fires where it previously never
-did, which means `dataSource.updateViewConfig` is now reached on a column drag. That call
-was unreachable by this path before, so any permission gate on that write now sees traffic
-it never saw.
-
-The renderer's resize/reorder gestures, the inbound seeding of `columnState`, and the
-declared surface are all unchanged.
diff --git a/.changeset/6178-detail-section-header-color.md b/.changeset/6178-detail-section-header-color.md
deleted file mode 100644
index 9a1a18887d..0000000000
--- a/.changeset/6178-detail-section-header-color.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-'@object-ui/plugin-detail': patch
----
-
-`DetailSection` now resolves `section.headerColor` through a lookup of complete
-Tailwind class literals instead of building `bg-` + the authored value as a
-template literal (objectui#6178).
-
-Tailwind v4 has no runtime — it builds the stylesheet by scanning source text
-for complete class tokens, and this workspace ships no `bg-*` safelist — so the
-old expression contributed nothing to the compiled CSS. Measured, not assumed:
-compiling `apps/console/src/index.css` with that expression deleted produced a
-byte-identical stylesheet (same sha256). An authored value styled the header
-only when some other source file happened to author the identical class
-literally, which is why both documented examples appeared to work: `bg-muted`
-occurs 691 times and `bg-primary/10` 63 times elsewhere in the workspace. That
-liveness was accidental and moved with unrelated edits in unrelated packages.
-
-The shape matches the sibling this repo already solved the same way —
-`useRowColor`'s `COLOR_TO_CLASS` in `@object-ui/plugin-grid`:
-
-- a lookup of literal, tint-only design-system classes: `muted`, `muted/50`,
-  `accent`, `primary/10`, `secondary/10`, `destructive/10`. Both values the
-  `@object-ui/types` mirror documents (`muted`, `primary/10`) are in it, so
-  nothing that rendered before renders differently now;
-- a value that is already a complete `bg-*` class is passed through untouched.
-  This is new — `headerColor: 'bg-muted'` previously produced the meaningless
-  `bg-bg-muted`;
-- anything else contributes no class at all, instead of a fabricated one.
-
-Behaviour change to be aware of: an undocumented bare suffix outside the
-vocabulary (say `headerColor: 'blue-100'`) no longer reaches the DOM as
-`bg-blue-100`. It rendered before only where another file happened to author
-that exact class; write it as the complete class (`headerColor: 'bg-blue-100'`)
-to keep it, on the same terms as any `className` a schema carries. No value is
-rejected and the declared type is unchanged.
-
-`headerColor` remains undeclared on the strict `@objectstack/spec`
-`record:details` section schema, which refuses it today on the strength of this
-defect (objectstack#11661). Declaring it, and with which vocabulary, is a
-separate spec decision.
diff --git a/.changeset/6188-line-items-child-object-decline.md b/.changeset/6188-line-items-child-object-decline.md
deleted file mode 100644
index 13a4a04f6c..0000000000
--- a/.changeset/6188-line-items-child-object-decline.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-"@object-ui/plugin-form": patch
----
-
-`record:line_items` declines to fetch the child schema of a panel whose child object it never resolved, instead of calling `getObjectSchema(undefined)`.
-
-`childObject` is declared `required: true` on the block's registry entry and typed `string` on
-`LineItemsPanelSchema`, but nothing enforces either — `inputs[].required` is designer metadata, and
-the block has no spec schema — so a node reaches the renderer straight off an authored schema with
-the key `undefined`, and the child-schema effect asked the data layer for it anyway. Measured:
-mounting the block through the registry with `childObject` unset issued
-`getObjectSchema(undefined)`, and a real backend receives a query for an object literally named
-`undefined`. The effect's `.catch` then turned the answer into a null child schema, so the visible
-outcome was a silently unsanitized child grid rather than an error.
-
-The effect now declines and warns, naming the key and what to set it to, and clears the cached child
-schema so a later save is never sanitized against a previous object's fields. This is the choice
-`RelatedList` already makes for the same class of missing key (*"has no referenceField/parentId —
-refusing to fetch all rows"*), and the one `object-master-detail-form` makes on this exact key. A
-panel that names its child object fetches exactly as before.
diff --git a/.changeset/6194-line-items-row-fetch-decline.md b/.changeset/6194-line-items-row-fetch-decline.md
deleted file mode 100644
index 312e431c29..0000000000
--- a/.changeset/6194-line-items-row-fetch-decline.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-"@object-ui/plugin-form": patch
----
-
-`record:line_items` declines to LOAD OR WRITE the rows of a panel whose child object it never resolved, instead of calling `find(undefined, …)` — the sibling site of the child-schema decline, in the same component.
-
-`LineItemsPanel` read `schema.childObject` at two sites. The first now declines; the row load still
-asked the data layer to `find` an object literally named `undefined`, scoped by
-`{ [relationshipField]: parentId }`. `load` guarded the *data source* and the *parent id* — the two
-things `RelatedList` calls "can I scope this query" — but not the *object being queried*.
-
-Declining that fetch is not enough on its own, and this is the part worth reading: `load` owns
-`loading`, and the panel branched `loading ? "Loading…" : !parentId ? "Save the record first…" :
-<grid>`. So the moment the fetch declined, an unresolvable panel with a parent id bound fell to the
-third branch and showed an **empty editable grid with an Add button, over an object that does not
-exist** — a worse outcome than the fetch it replaced. Measured on the pre-fix component: one
-keystroke in the grid's always-present ghost row materialised a row, which enabled Save, which
-reached `batchTransaction([{ object: undefined, action: 'create', data: { qty: 3, invoice: 'inv-1' } }])`.
-The bad *read* was one keystroke away from a bad *write*.
-
-An unresolvable panel therefore gets its own render branch — a config hint naming `childObject` and
-what to set it to, following the precedent `object-master-detail-form` set for this exact key and
-`AdvancedChartImpl`'s refusal placeholders. It is checked ahead of `loading`, because nothing is
-pending: the schema itself already says the panel can never resolve, so there is no honest moment at
-which "Loading…" is true. `save` takes the same one-line guard, for the one route the render branch
-cannot close — a schema edited to drop `childObject` while rows are already dirty.
-
-A panel that names its child object loads, renders and saves exactly as before.
diff --git a/.changeset/6213-core-adapters-readme-owns-its-directory.md b/.changeset/6213-core-adapters-readme-owns-its-directory.md
deleted file mode 100644
index 2f152e2974..0000000000
--- a/.changeset/6213-core-adapters-readme-owns-its-directory.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-'@object-ui/core': patch
-'@object-ui/data-objectstack': patch
----
-
-`packages/core/src/adapters/README.md` now documents the adapters that are actually in that
-directory, and the ObjectStack material it carried moved to the package that owns the behaviour
-(objectui#6213). Both files ship to consumers — `@object-ui/core` publishes its `src/`, and a
-README rides every tarball — so this was published documentation describing the wrong package.
-
-The page had been left behind when the ObjectStack adapter moved out to
-`@object-ui/data-objectstack`: its headings, feature list, filter-operator table and
-query-parameter table were all about that adapter, and its one-entry "Available Adapters" list
-told a reader Object UI has exactly one adapter and that it comes from `@object-ui/core`.
-`ApiDataSource`, `ValueDataSource`, `resolveDataSource`, `runBatchTransaction` and
-`emulateBatchTransaction` — the five exports that directory really ships — were named nowhere.
-
-- **`@object-ui/core`**: the page now opens with what the directory holds, gives each export a
-  usage snippet and a `provider` mapping, and points at `@object-ui/data-objectstack` for the
-  ObjectStack adapter. `## Creating Custom Adapters` is unchanged — it is the one section that was
-  always about this directory.
-- **`@object-ui/data-objectstack`**: gains a `## Query Translation` section carrying the
-  filter-operator and query-parameter mapping tables, the AST conversion example and the sorting
-  example. That material existed **only** in the `core` copy — this package's README documented
-  query translation as a single feature bullet — so it is ported, not dropped.
-
-No runtime behaviour changes; the duplicate copy of one package's documentation living under
-another package is what goes away.
diff --git a/.changeset/6223-object-payload-spec-keys.md b/.changeset/6223-object-payload-spec-keys.md
deleted file mode 100644
index e6b7eb8071..0000000000
--- a/.changeset/6223-object-payload-spec-keys.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-'@object-ui/plugin-designer': minor
-'@object-ui/app-shell': minor
----
-
-Object-level metadata payloads no longer emit the three keys `ObjectSchema` refuses by
-name — **group**, **sortOrder** and **relationships** (objectui#6223).
-
-Measured against the installed `@objectstack/spec` 17.2.0, whose `ObjectSchema` accept set
-is 42 keys:
-
-```
-const base = { name: 'account', label: 'Account', fields: { n: { type: 'text', label: 'N' } } };
-
-ObjectSchema.safeParse(base)                              => success = true    (control)
-ObjectSchema.safeParse({ ...base, isSystem: true })       => success = true    (control)
-ObjectSchema.safeParse({ ...base, pluralLabel: 'A' })     => success = true    (control)
-
-ObjectSchema.safeParse({ ...base, group: 'Sales' })       => unrecognized_keys ["group"]
-ObjectSchema.safeParse({ ...base, sortOrder: 3 })         => unrecognized_keys ["sortOrder"]
-ObjectSchema.safeParse({ ...base, relationships: [ … ] }) => unrecognized_keys ["relationships"]
-```
-
-The two controls are what make that a key-by-key result rather than a schema refusing
-everything. Each key was resolved on its own, as the objectui#5761 family ruling requires:
-
-- **group** — the Object Manager's grouping is a UI-only display category. The spec has no
-  object-level grouping key (`fieldGroups` groups the fields *inside* one object), so the
-  grouping control and its column stay, and the value is now DERIVED from the spec key that
-  is accepted (`isSystem`) instead of round-tripped. `MetadataObjectsPage` also strips a
-  `group` already stored by an earlier build, because its save-back spreads the server
-  document verbatim and would otherwise keep re-sending it forever.
-- **sortOrder** — what populated it was the array index the converter happened to be at,
-  i.e. the order the list was already in. The declaration is removed from the object
-  payload. The field-level `sortOrder` is a different key with a different card
-  (objectui#6045) and is untouched.
-- **relationships** — the spec models relationships on the FIELD (`reference` /
-  `master_detail`, plus object-level `indexes`). The object payload stops declaring and
-  sending an object-level relationship array; what the designer should author for a
-  relationship is a data-model question this change does not settle.
-
-**Breaking for TypeScript consumers of `ObjectMetadataPayload`** (exported from app-shell):
-the three properties are gone from the published type, so code that set them stops
-compiling. That is the point — setting any of them produced a payload the metadata route
-refuses. `ObjectDefinition` (the designer's UI model) is unchanged and still carries all
-three.
-
-The parity gate built for objectui#5761 now has a **second oracle**: every shape in
-`PAYLOAD_SHAPES` names the schema that judges it, `ObjectSchema` alongside `FieldSchema`,
-and reach is resolved within an oracle rather than across one — `group` is a legal
-`FieldSchema` key and a refused `ObjectSchema` key at the same time. That extension found a
-fourth object-level key (`enabled`, objectui#6238) and a value-level rejection the key-name
-check cannot see (`fields` sent as an array where the spec wants a map, objectui#6240);
-both are filed and ledgered rather than fixed here.
diff --git a/.changeset/6230-budget-comment-half-status.md b/.changeset/6230-budget-comment-half-status.md
deleted file mode 100644
index 3b79f6fff9..0000000000
--- a/.changeset/6230-budget-comment-half-status.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
----
-
-CI-only: the Bundle Analysis PR comment now names *which* eager-closure half
-objected, instead of reporting only that something did.
-
-`scripts/check-eager-closure-budget.mjs` evaluates three halves and publishes a
-verdict for each to `$GITHUB_OUTPUT` — `closure_status` (the aggregate ceiling),
-`closure_chunk_status` (the per-chunk ceilings) and `closure_headroom_status`
-(ceiling sensitivity). `.github/workflows/performance-budget.yml` passed only
-the first into the comment step, so the two others were published and never
-read. The step's exit code folds all three into one `budget_status`, which meant
-the comment could say a budget objected but not which half — a reader had to
-open the job log to learn whether the total grew, one chunk grew, or a ceiling
-had stopped measuring anything.
-
-- Both missing verdicts are now passed into the comment step and rendered.
-- The healthy comment is unchanged: the breakdown appears only when a half is
-  not `pass`, verified byte-for-byte against the previous renderer.
-- A drifted ceiling (exit 2) reads as a broken **gauge** rather than a size
-  failure, and no longer claims "nothing was measured" while showing two
-  ceilings that passed.
-- `render-budget-comment.test.ts` now fails if the checker publishes a
-  `closure_*` verdict the workflow does not wire through, so a fourth half
-  cannot repeat this.
-
-The exit-code mapping is untouched: exit 2 still maps to `budget_status=error`,
-any other non-zero to `fail`, and `error` still outranks `fail` across all three
-halves.
diff --git a/.changeset/6235-mergedsort-wrap.md b/.changeset/6235-mergedsort-wrap.md
deleted file mode 100644
index 7c90482826..0000000000
--- a/.changeset/6235-mergedsort-wrap.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-'@object-ui/plugin-view': patch
----
-
-`ObjectView` wraps `table.defaultSort` before handing it to a delegated list view, so a
-view whose only ordering is the deprecated key actually sorts (objectui#6235).
-
-`ObjectGridSchema.defaultSort` is declared a SINGLE `{ field, order }` object — the zod
-mirror agrees (`z.object({ field, order })`, not a union) — while the `list-view` node's
-`sort` slot is declared `string | SortConfig[]`, imported by reference from the spec's own
-`ListViewSchema`. `mergedSort`'s last branch forwarded the bare object into that slot
-unwrapped. The three branches ahead of it all produce an array or a string, so this was the
-one shape the slot never declared.
-
-Nothing crashed and nothing warned: every reader of that slot drops an unparseable sort
-silently. `ListView.parseSortConfig` and `ObjectGrid.parseSchemaSort` both open
-`typeof sort === 'string' ? [sort] : Array.isArray(sort) ? sort : []`, so a bare object
-yields `[]`; the shared sink `convertSortToQueryParams` returns `undefined` for it. Both
-in-tree hosts feed the slot straight into `ListView` (`app-shell`'s `fullSchema` and
-Studio's `renderStudioGridList`), so the symptom was an unsorted list with no error —
-while the SAME metadata sorted correctly as a grid, because `ObjectGrid` performs this
-lowering for the same pair.
-
-The wrap is verbatim the one the non-grid fetch path in this same file already applies
-(`|| (schema.table?.defaultSort ? [schema.table.defaultSort] : undefined)`), so all three
-consumers now agree and no fourth dialect is introduced. The shared sink is deliberately
-NOT widened to accept a bare `{ field, order }`: that is the widening the maintainer ruling
-of 2026-08-22 rejected on the merits, because the same slot legitimately carries
-`$orderby`'s own `Record<field, direction>` map, in which `{ field: 'desc' }` is a legal
-ordering by a column literally named `field`.
-
-Precedence is unchanged — a named view's sort still outranks `table.sort`, which still
-outranks `table.defaultSort`. Only the final branch changes shape.
-
-One behaviour note for hosts writing off-schema metadata: an ARRAY in `table.defaultSort`
-was previously forwarded verbatim by this path alone and is now lowered like every other
-resolver in the repo, which leaves it unreadable rather than rescuing it. That input is
-already refused by the zod mirror and already behaves this way on the fetch path and in
-`ObjectGrid`; the canonical slot for an array is `table.sort`.
diff --git a/.changeset/6238-object-payload-enabled.md b/.changeset/6238-object-payload-enabled.md
deleted file mode 100644
index fc618f3cd9..0000000000
--- a/.changeset/6238-object-payload-enabled.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-'@object-ui/app-shell': minor
----
-
-`MetadataService`'s two delete methods no longer PUT a hand-written tombstone. They call
-the metadata API's own delete door instead, and the latent `enabled?: boolean` on
-`ObjectMetadataPayload` is gone with it (objectui#6238). Object-level member of the
-objectui#5761 family, surfaced by the `ObjectSchema` oracle objectui#6223 added to
-`scripts/check-designer-field-key-parity.mjs`.
-
-**What the tombstone actually did.** `deleteObject` and `deleteMetadataItem` wrote
-`{ name, enabled: false, _deleted: true }` through `client.meta.saveItem`, i.e.
-`PUT /api/v1/meta/:type/:name`. Measured against the installed `@objectstack/spec` 17.2.0
-using `getMetadataTypeSchema` — the registry the framework's own `saveMetaItem` resolves a
-PUT's validator from — across all 26 registered overlay schemas:
-
-```
-ObjectSchema.safeParse({ name, label, fields })                        => success = true   (control)
-ObjectSchema.safeParse({ name, label, fields, isSystem: true })        => success = true   (control)
-ObjectSchema.safeParse({ name, enabled: false, _deleted: true })       => unrecognized_keys ["enabled","_deleted"]
-
-25 of 26 registered overlay schemas refuse `enabled` and/or `_deleted` BY NAME
- 1 of 26 (`view`) tolerates them; 4 kinds have no registered schema at all
- 0 of 26 strip them
-```
-
-So there were two failure modes, not one. Where the type has a strict schema — `object`
-among them — the delete was a hard `422 INVALID_METADATA`, so nothing was ever recorded.
-Where the schema is tolerant or absent, the framework stores the request item **verbatim**
-(it deliberately persists the body rather than `parsed.data`), and `_deleted` has no reader
-anywhere on the platform — so the "soft delete" was a silent no-op that left the item live
-carrying two junk keys. Neither outcome deleted or disabled anything.
-
-**The resolution is a mechanism change, not a rename**, and there was nothing to rename to.
-`ObjectSchema`'s 42-key accept set has no on/off flag; the near-spelling `enable` is
-`ObjectCapabilities`, a system-features *module object*, so `enabled: false` → `enable:
-false` fails on the value where it passes on the name. No wire key was invented: a metadata
-soft-delete convention would be a `@objectstack/spec` contract addition, and the platform
-does not have one.
-
-**Both sites now call `client.meta.deleteItem(type, name)`** — `DELETE
-/api/v1/meta/:type/:name`, the same request `MetadataClient.reset` issues, which is the
-mechanism `MetadataObjectsPage.handleObjectsChange` and `ResourceEditPage` already used for
-deletes. Two mechanisms for one operation had disagreed; now there is one. The delete route
-is generic over `:type` on the same route family and capability gate as the PUT, so this
-holds for every category the generic `deleteMetadataItem` serves, not just `object`. The
-doc comment claiming the API "exposes `saveItem` but no dedicated `deleteItem`" was stale:
-`@objectstack/client` 17.2.0 declares `meta.deleteItem` on the very client this service
-already holds.
-
-`reset` semantics are the overlay's, and that is the governed answer rather than a
-shortfall: it removes the customization row — which *is* deletion for an object the
-designer authored — and restores the artifact for one a package declares, an object you are
-not allowed to delete. Which of the two an item is, is what the API's own `deletable` /
-`resettable` verdicts report, not something a client-side flag should decide.
-
-**No published type changed.** `ObjectMetadataPayload` is exported from its module but that
-module is not re-exported by `packages/app-shell/src/index.ts`, the package's only entry, so
-the removed `enabled?: boolean` was never on the published surface and no `**/src/index.ts`
-is touched. What consumers *can* observe is behaviour: `MetadataService` is reachable
-through the published `useMetadataService()` hook, both method signatures are unchanged
-(`Promise<void>`), and the HTTP request they issue changes from a `PUT` with a body to a
-`DELETE`.
-
-The `KNOWN_UNPARSEABLE_KEYS` entry in `scripts/check-designer-field-key-parity.mjs` goes
-with the fix — that ledger ratchets in both directions, so an entry left behind for a
-resolved key is as red as a missing one. It is now empty for the first time, which is the
-ratchet arriving where it was pointed; the self-test's non-vacuity guard moved onto a
-fixture accordingly, so an empty ledger reads as success rather than as a demand that some
-key stay unresolved.
diff --git a/.changeset/6240-object-payload-fields-map.md b/.changeset/6240-object-payload-fields-map.md
deleted file mode 100644
index 8262d3150c..0000000000
--- a/.changeset/6240-object-payload-fields-map.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-`MetadataService`'s object writers PUT `fields` as the name-keyed MAP `ObjectSchema`
-requires, not an array (objectui#6240). Both of the designer's write paths were affected,
-and `saveFields` ran the conversion in the wrong direction outright: the server's own
-document arrives with `fields` as a map, and `fields.map(toFieldPayload)` turned it into an
-array on every field save.
-
-Measured against the installed `@objectstack/spec` 17.2.0 and against the framework's own
-write door. `ObjectSchema.fields` is a required record: an array — empty or not — is
-refused `invalid_type @ fields`, a map parses. `metadata-protocol`'s `saveMetaItem`
-resolves metadata type `object` to that same `ObjectSchema`, `safeParse`s the whole item
-and throws `422 INVALID_METADATA` **before** persisting, so the array was refused rather
-than stripped or stored: every designer object save and every designer field save that went
-through this service was a 422 that wrote nothing.
-
-This is the value-level half of the objectui#5761 parity family and is invisible to that
-family's key-name gate — `fields` sits in the accept set under either shape, which is the
-gate's own coverage note 4. The pins are runtime assertions on the captured request bytes.
-
-The conversion refuses, loudly, what it cannot key: a field with a missing or blank `name`
-throws instead of writing a `{ undefined: … }` entry (measured: the spec ACCEPTS that
-document, so nothing downstream would have caught it), and a duplicate name throws instead
-of letting the later field silently replace the earlier — a loss an array does not have.
-`saveFields` keeps preserving unknown keys of the fetched server document, which now
-actually reaches storage. `saveObject` with no `existingFields` still omits the key rather
-than writing `{}`: a PUT is an upsert, so `{}` would delete every field of an object on a
-save that only meant to rename it.
-
-`saveObject(obj, existingFields)` keeps its `FieldMetadataPayload[]` parameter type — the
-array is converted inside — so no caller's call site changes.
diff --git a/.changeset/6241-fieldgroups-section-heading-pin.md b/.changeset/6241-fieldgroups-section-heading-pin.md
deleted file mode 100644
index fce15362ee..0000000000
--- a/.changeset/6241-fieldgroups-section-heading-pin.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
----
-
-Tests only, no release: pin the synth → renderer seam for the default
-`fieldGroups` record detail page (objectui#6241).
-
-`buildDefaultPageSchema` synthesizes one detail section per declared
-`fieldGroups` entry and app-shell's `RecordDetailView` renders that output as
-the default record page for every object declaring `fieldGroups` with no
-assigned page — but nothing asserted end-to-end that those synthesized sections
-render their headings. The synthesizer's own suite asserts its return value and
-never renders; the `record:details` renderer suites render hand-authored
-section fixtures and never consume synthesizer output. Measured on `9ea4cdee3`:
-with the consumer's read of the emitted heading removed, all 109 files / 1031
-tests of `packages/plugin-detail/` still passed.
-
-The new file renders the real `buildDefaultPageSchema` output through the real
-registry into the DOM and asserts the declared heading TEXT, its declared
-order, and that a group's internal key never stands in for its label. It
-asserts no key spelling, so it stays independent of the `title` / `label`
-convergence open in objectui#6190 / objectstack#11661.
diff --git a/.changeset/6250-toast-demo-shapes.md b/.changeset/6250-toast-demo-shapes.md
deleted file mode 100644
index 88aa0717a3..0000000000
--- a/.changeset/6250-toast-demo-shapes.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
----
-
-Docs and fixtures only: the seven `components-feedback-toast/*` and seven
-`components-feedback-sonner/*` `SchemaExample` fixtures hung an action object off
-`onClick` (`{"type":"button", …, "onClick":{"action":"toast", …}}`) — a shape
-`ButtonSchema` declares as a FUNCTION and no dispatcher reads, so all fourteen were a
-RED `safeParse` on the envelope and clicking the rendered demo raised no toast
-(objectui#6250). They now author the registered spellings the engine already executes,
-`type: 'toast'` and `type: 'sonner'`, whose renderers draw their own trigger button and
-call sonner's `toast()` from it. `feedback/toast.mdx` and `feedback/sonner.mdx` follow,
-including two keys sonner's page taught that neither `SonnerSchema` declares nor its
-renderer reads (`duration`, `action`).
-
-No package source or behaviour change; fixtures, docs and pins only. Two things the
-fixture correction deliberately does NOT do, both left to the maintainer: declare an
-action union on `ButtonSchema.onClick` and build a dispatcher for it, and give the toast
-renderers the in-toast action button and promise form the removed demos implied.
diff --git a/.changeset/6269-objectview-slot-key-lists.md b/.changeset/6269-objectview-slot-key-lists.md
deleted file mode 100644
index 12c8d4b312..0000000000
--- a/.changeset/6269-objectview-slot-key-lists.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-'@object-ui/types': patch
----
-
-`ObjectViewSchema`'s `table` and `form` slots now ship the members they promise
-(objectui#6269). Both were declared by deriving from the schema they document — `table?:
-Partial<Omit<ObjectGridSchema, 'type' | 'objectName'>>`, `form?: Partial<Omit<ObjectFormSchema,
-'type' | 'objectName' | 'mode'>>` — and both derived types declared **zero** properties.
-
-`Omit<T, K>` is `Pick<T, Exclude<keyof T, K>>`, and `keyof T` on a type carrying a string index
-signature is `string | number` — the literal member names are absorbed. `ObjectGridSchema` and
-`ObjectFormSchema` both inherit `BaseSchema`'s `[key: string]: any` (objectui#5155), so each
-`Pick` rebuilt a type holding the index signature and none of the named members. Measured
-through the TypeScript checker: `ObjectGridSchema` 61 members, the `Omit` of it 0;
-`ObjectFormSchema` 67, the `Omit` of it 0. This is objectui#6151's collapse in *property*
-position — #6151's guard walks the `LayoutSchema` union and cannot see properties on
-`ObjectViewSchema`.
-
-Nothing errored, because the index signature answered every key as `any`. The visible costs
-were the ones only a reader of the declaration meets: `table: { colunms: 3 }` type-checked,
-`table: { pageSize: 'ten' }` type-checked, and editor completion inside `table: { … }` offered
-nothing at all for a slot documented as "inherits from ObjectGridSchema".
-
-Each `Omit` is now a `Partial<Pick<…>>` over an explicit key list — 59 keys for `table`, 64 for
-`form`, i.e. every declared member minus the identity keys the view itself fixes. `Pick` with
-literal keys never computes `keyof T`, so it cannot collapse the same way. The key lists are
-pinned against silent drift by `packages/types/src/__tests__/object-view-slot-key-lists.test.ts`,
-which recomputes each source schema's declared members through the TypeScript checker and
-requires set equality; a member added to `ObjectGridSchema` and not to the list turns it red.
-
-**Tightening, deliberately.** Restoring named members re-enables excess-property checks on
-object literals assigned into these two slots, so a misspelled key there is now an error
-instead of silently doing nothing. That is the intent of the fix. The slots' member *types* are
-unchanged — every key that resolved to a real declared type before still does.
-
-The `Pick` lists exist only because `BaseSchema` carries a root string index signature. When an
-objectui#5155 phase removes it, `Omit` stops collapsing and the lists (plus their pin) become
-removable; the pin's own comment records the condition, and one of its assertions is the
-tripwire that will notice.
diff --git a/.changeset/6271-kanban-fetch-gate.md b/.changeset/6271-kanban-fetch-gate.md
deleted file mode 100644
index dd74c6c0bb..0000000000
--- a/.changeset/6271-kanban-fetch-gate.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-'@object-ui/plugin-kanban': patch
----
-
-`ObjectKanban` no longer queries twice on mount (objectui#6271). A standalone board issued
-its first `find` before the object definition resolved — so `buildExpandFields` saw no
-fields and that query carried no `$expand` at all — then issued a second, expanded one once
-the definition landed:
-
-```
-['deal', { $top: 100 }]
-['deal', { $top: 100, $expand: ['owner'] }]
-```
-
-The definition now GATES the query instead of refining it afterwards: one query per mount,
-carrying the expansion the first time.
-
-Decided on measurement rather than on the two shapes' relative appeal. The first response
-never reached the screen in the regimes that matter: with the schema resolving no slower
-than the row query (profiles schema/find = 30/30, 30/60, 5/30 ms), the definition lands
-first, the effect re-runs, its cleanup flips `isMounted` false, and the unexpanded rows are
-discarded on arrival — a DOM probe polling every 2ms for a title only that response carried
-never fired once. What the gate costs is one schema resolution ahead of the query, and that
-read is cheap and shared: one small GET behind the same discovery call `find` already
-awaits, served thereafter from `MetadataCache` (5-minute TTL, concurrent readers coalesced
-onto one request). Measured against the real `ObjectStackAdapter` over loopback HTTP, 22
-reads of one object produced exactly one metadata request and every read after the first
-returned in 0.01ms. End to end the board is not slower for it — same harness, before →
-after, time to the fully populated board: 156.9 → 145.2ms (30/30), 119.8 → 110.6ms (30/60),
-54.7 → 52.4ms (5/30).
-
-The gate is on the definition read having **settled**, not on the definition being truthy:
-an adapter that exposes no `getObjectSchema`, and a read that throws, both settle with
-nothing to report and the board falls through to an unexpanded query rather than waiting
-forever. Boards fed rows by a parent (`data`, `bind`, inline `schema.data`) are untouched —
-they never ran this effect, and they still read the definition for lane titles and labels.
-
-The `isOpaqueId` suppression in the card-description path is unchanged and keeps its
-comment beside it: part of what it hid was this fetch ordering, but unexpanded rows still
-reach it from parents that pass rows they fetched without `$expand`, from author-supplied
-data, and from backends that decline an expansion.
diff --git a/.changeset/6278-context-menu-item-icon.md b/.changeset/6278-context-menu-item-icon.md
deleted file mode 100644
index 080e0bf78f..0000000000
--- a/.changeset/6278-context-menu-item-icon.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-"@object-ui/components": patch
----
-
-`ui:context-menu` now resolves a menu item's authored `icon` to a glyph. It previously never read the key at all.
-
-Both arms of `renderContextMenuItems` — the leaf `ContextMenuItem` and the `ContextMenuSubTrigger` — ignored `icon` entirely, so an item authored as `{ "label": "Copy", "icon": "copy" }` drew its label and nothing else. The name is now resolved through `resolveIcon`, the same lucide **record** surface `ui:button`, `ui:dropdown-menu` and the `action:*` family already resolve against: a live name draws its glyph, and an unknown or retired spelling draws nothing rather than degrading to a wrong glyph. This mirrors the repair `ui:dropdown-menu` received for the identical defect.
-
-The `components-overlay-context-menu/basic-context-menu` catalog fixture already declared four live names — `copy`, `scissors`, `clipboard`, `trash` — which drew nothing before this change and draw their glyphs now. Those names are also brought under `check:lucide-icon-record-names` by a new `context-menu` census entry, so a future retired spelling fails the gate instead of silently drawing nothing.
diff --git a/.changeset/6280-scan-surface-claims.md b/.changeset/6280-scan-surface-claims.md
deleted file mode 100644
index e4cdf7472e..0000000000
--- a/.changeset/6280-scan-surface-claims.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
----
-
-Doc-only fixes in `@object-ui/components` and the docs site: two stale claims about
-`scripts/check-doc-links.mjs`'s scan surface, both frozen at an earlier `SCAN_ROOTS`
-shape (objectui#6280).
-
-- `packages/components/src/__tests__/readme-shadcn-sync-categories.test.ts`'s
-  `## Scan surface` docblock said `README_SHADCN_SYNC.md` had "never been scanned by
-  anything" — false since objectui#4938, whose `packages/*` row excludes only the
-  basenames `README.md`/`CHANGELOG.md` and so does include this file. Rewritten to
-  argue from the current tree: the file IS scanned, but check-doc-links only inspects
-  `[text](href)` markdown-link syntax (never the backticked code spans this README
-  uses for every in-repo path) and has no notion of prose-vs-manifest consistency —
-  so the hand-rolled checks below survive regardless of scan surface, for reasons
-  unrelated to whether the surface reaches this file.
-- `content/docs/guide/ci-cd-pipeline.md` described the scan surface twice (prose and
-  the two-link-checkers table), both frozen at the objectui#3622 shape ("the internal
-  `docs/` tree and every package `README.md`"). Re-derived from the live `SCAN_ROOTS`
-  table (17 rows) and rewritten to include the app READMEs and root-level markdown
-  (objectui#4148), the rest of each package/app directory tree (objectui#4938), and
-  every nested `README.md` (objectui#6026).
-
-No source or behaviour change; text and a test docblock only.
diff --git a/.changeset/6285-capability-labels-derive-from-spec.md b/.changeset/6285-capability-labels-derive-from-spec.md
deleted file mode 100644
index 5c5c1affa0..0000000000
--- a/.changeset/6285-capability-labels-derive-from-spec.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-'@object-ui/fields': patch
-'@object-ui/i18n': patch
----
-
-The capability picker localizes `manage_sharing` (objectui#6285). Before this, "Manage
-Sharing" was the one platform capability in `sys_permission_set`'s picker that rendered in
-English in every locale, beside seven siblings that translated — a user-visible missing
-translation, in all ten packs at once.
-
-The cause was an unchecked copy. `CURATED_CAPABILITY_LABELS` in
-`CapabilityMultiSelectField.tsx` listed seven capability names under a doc comment claiming
-it mirrored `@objectstack/spec/security`'s `PLATFORM_CAPABILITIES`; the spec grew an eighth
-member and the list did not follow, so `manage_sharing` fell through to the English label
-the `sys_capability` registry serves. Nothing could catch it: the i18n gate reads that list
-as this key family's vocabulary and checks the members it names — all seven had keys — and
-no instrument compared the vocabulary to the array it was named after.
-
-`capability.label.manage_sharing` is now authored in all ten packs and in the field widgets'
-provider-less defaults map, the list carries the member, and the prose claim is replaced by
-a check: `CapabilityMultiSelectField.specParity-6285.test.tsx` imports `PLATFORM_CAPABILITIES`
-and fails on any difference in either direction, reading the declaration through the i18n
-gate's own source reader so what it pins is exactly what that gate consumes. `labelFor` also
-gains a `defaultValue`, so a capability that arrives in a future spec bump before its
-translation is authored degrades to the registry's English label rather than rendering a raw
-i18n key at the user.
diff --git a/.changeset/6286-explain-batch-cap-from-spec.md b/.changeset/6286-explain-batch-cap-from-spec.md
deleted file mode 100644
index 67e18ef880..0000000000
--- a/.changeset/6286-explain-batch-cap-from-spec.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-'@object-ui/plugin-grid': patch
----
-
-The batch-explain cap the row-verdict hook paginates under is now imported from
-`@objectstack/spec/security` instead of re-declared locally (objectui#6286).
-`useRecordCrudVerdicts` carried `const EXPLAIN_BATCH_MAX_RECORD_IDS = 200`, a hand copy of
-a SERVER contract constant, under a doc comment that named its own expiry condition: the
-pinned `@objectstack/spec@17.0.0-rc.6` predated the batch form, and the pin bump would
-supersede the declaration. It has.
-
-**No value changes and no behaviour changes.** The spec exports `200`, which is what the
-local copy said, verified by resolving the installed package and reading the export — both
-statically (`dist/security/index.d.mts`) and at runtime through the same specifier the
-source now uses. What changes is reference identity: if the server relaxes or tightens the
-cap and the spec follows, the client follows too, instead of paginating at the old boundary
-with no signal anywhere. The cap's whole point is that an over-cap request is refused with
-`400 VALIDATION_FAILED` rather than truncated, so a client that silently disagrees with it
-is exactly the drift `scripts/check-spec-symbol-derivation.mjs` argues about — and could
-not catch here, because both of its scanners skip non-exported declarations and this const
-was module-local (objectui#5899).
-
-The declared floor already carries the symbol, so no range moves: `@objectstack/spec@17.0.0`
-— the minimum `^17.0.0` admits — exports `EXPLAIN_BATCH_MAX_RECORD_IDS = 200` from
-`./security`. Measured against the published tarballs of `17.0.0-rc.6`, `17.0.0`, `17.1.0`
-and `17.2.0`: only the rc lacks it. The declaration was therefore expired one release
-earlier than the card that found it assumed.
-
-The half of the comment that explains *why* the cap exists and what the server does with an
-over-cap request is kept and now sits on the import; only the half explaining why it was
-declared LOCALLY is gone, since that is the part that stopped being true.
-
-Covered by a new reference-identity test rather than a value assertion. Every assertion on
-`200` passes on both sides of this change — a ghost — so
-`useRecordCrudVerdicts.batchCap.test.tsx` stands the spec module in at a cap no hand copy
-could produce and asserts the request chunking follows it, with a control case proving the
-stand-in installed and differs from the shipped value. The pre-existing cap assertion in
-`rowRecordCrudVerdict.test.tsx` now derives its fixture and its bound from the same export
-instead of re-typing `200`, which removes the last hand copy on this surface without
-pretending to be a two-world test.
diff --git a/.changeset/6287-flownode-description-key.md b/.changeset/6287-flownode-description-key.md
deleted file mode 100644
index e14fbd707d..0000000000
--- a/.changeset/6287-flownode-description-key.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-The flow designer's node inspector no longer offers a **Description** field, and strips a
-stored `description` off a node the first time an author edits it (objectui#6287).
-
-`FlowNodeSchema` is `.strict()` (objectstack#4001) and refuses that key by name — measured
-on the installed `@objectstack/spec@17.2.0`:
-
-```
-FlowNodeSchema.safeParse({ id, type, label, description, config })
-  -> unrecognized_keys: ["description"]
-```
-
-By this package's own reading of that mechanism, the cost is not untidiness but an
-unsavable draft: the key "surfaces as `unrecognized_keys` in the live client validation and
-as a 422 on save" (`flow-canvas-layout.withCanonicalGeometry`, on the identical retired `ui`
-case). So the field was not merely describing a shape the contract refuses — it was
-producing one, on every keystroke, and nothing anywhere read the value back. The spec's flow
-node has eleven keys and no note key of any spelling, so there was no reader to grow into.
-
-Stored flows heal on the author's first edit, the same migrate-on-write boundary the retired
-`ui` geometry gets, and for the same reason: with the field gone there would otherwise be no
-way left to clear a `description` an author had already saved.
-
-The three hand-written copies of the node and edge shapes that let this drift go unseen are
-now one declaration each — `FlowNodeInspector`'s node and edge types alias the canonical
-`FlowNodeLike` / `FlowDesignerEdge`, and `flow-decision-edges`' fourth edge copy aliases the
-same canvas edge instead of restating it with a `condition?: unknown` that had already
-outlived objectui#3202's narrowing by months.
diff --git a/.changeset/6293-conditionbuilder-reference-value.md b/.changeset/6293-conditionbuilder-reference-value.md
deleted file mode 100644
index 1bee446a33..0000000000
--- a/.changeset/6293-conditionbuilder-reference-value.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-`ConditionBuilder`'s row mode now compiles a value that is plainly a **reference** as one,
-instead of quoting it into a string literal (objectui#6293).
-
-`fmtValue` quoted anything that was not a number / `true` / `false` / `null`, and the value
-box is free text — so an author building "this field differs from its prior value", the idiom
-that *defines* a change-detection predicate, got `previous == 'previous.status'`. That is
-syntactically valid CEL, `previous` is a declared root, and a string literal's contents are
-deliberately not scanned for references by `flow-ref-check` or by the server-side validator.
-The predicate parsed, registered, evaluated — and was always false, with no author-time signal
-at any layer, at all five surfaces that mount this builder.
-
-A value matching a **declared root prefix** now emits as the reference: `record`, `previous`,
-`parent`, `user`, `current_user`, `org`. That set is this builder's own vocabulary — `record`
-/ `user` / `org` are exactly what its subject dropdown offers one control to the left,
-`previous` and `parent` are bound by `evalFieldPredicate` and by the server-side hook /
-validation evaluators, and `current_user` is the ADR-0068 spelling of the same identity object
-`user` names. Roots this builder never offers (`data`, `os`, `app`, `features`, `input`,
-`vars`, `page`) are deliberately excluded: `data.csv` is a plausible literal and `data` *is*
-bound, so capturing it would trade one silently-false predicate for another rather than for a
-loud one. Declaring which roots a mounting surface actually binds is caller-supplied
-vocabulary and belongs to objectui#6296.
-
-The test is "a dotted path under a declared root", not "contains a dot" — a version string
-(`1.2.3`), a filename, and a path under an unbound root all stay literal text. The literal and
-number controls are unchanged: `done` still compiles to `'done'`, `42` still to `42`.
-
-**Nothing already stored is rewritten.** A persisted `previous == 'previous.status'` no longer
-round-trips byte-for-byte, so the builder's existing safety rule hands it to the raw CEL editor
-rather than reinterpreting it — the author sees both readings and decides. In the other
-direction a hand-authored `record.status != previous.status` now round-trips *into* the row
-builder, which it could not before.
-
-The repair is at the authoring surface, where the ambiguity is: no consumer-side tolerance is
-added, and the emitted reference is now an identifier the existing reference checkers can see,
-where a string literal's contents were invisible to them.
diff --git a/.changeset/6301-packaged-automation-setup-page.md b/.changeset/6301-packaged-automation-setup-page.md
deleted file mode 100644
index f8b9ddb079..0000000000
--- a/.changeset/6301-packaged-automation-setup-page.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-'@object-ui/app-shell': minor
-'@object-ui/i18n': minor
----
-
-Setup gains a **Packaged automation** page — the operational surface for the flows an
-installed package ships (ADR-0126 §7.4, objectui#6301). Reached the way every other
-framework-contributed Setup surface is: the page registers the component-registry ref
-`automation:packaged`, so app navigation names the ref and `ComponentNavView` resolves it
-at `/apps/<app>/component/automation/packaged`. No bespoke route is added — a second way
-in would be a URL the app metadata does not know about.
-
-Per packaged flow the page does exactly two things:
-
-- **on/off for this scope** — reads the activation state the engine reports
-  (`GET /api/v1/automation/_status`, backed by the ADR-0126 §7.2 `sys_metadata_activation`
-  ledger) and flips it through `POST /api/v1/automation/<name>/toggle`;
-- **clone** — `POST /api/v1/automation/<name>/clone` with a mandatory new machine name and
-  label (§7.1). The carried-over definition is never offered as editable form fields; the
-  copy is edited in Studio like any other flow.
-
-Authoring stays in Studio. The list is scoped to packaged flows by the server's own
-three-clause provenance test (`isCodeArtifactBody`, ADR-0029 D9.6) rather than the
-`_packageId`-only shortcut, which classifies a tenant overlay bound to a package as
-packaged — the cloud#970 misread, and here it would put a tenant's own flow behind an
-install-wide switch.
-
-**Server refusals reach the operator verbatim** — no client-side softening or rewording.
-Three shapes are relayed as sent: the §5 posture gate (403 `PERMISSION_DENIED`, whose
-message names the tenancy posture *and* the sanctioned clone path), the §7.3 subflow guard
-(409 `DELETE_RESTRICTED`, which names the packaged callers that would break mid-run — a
-list nothing on the client could reconstruct), and the §7.1 clone name conflict (409).
-
-⛔ **No drift or ancestry surface** (§9): no diff-vs-base, no "customized" badge, no
-base-moved notice, no link from a clone back to its source. Cloned-without-disabled and
-disabled-without-clone are ordinary states, shown plainly. Tests pin the absence, including
-the case where a response carries a `clonedFrom` key anyway — the platform does not track
-that lineage, so a page that displayed it would be displaying something it invented.
-
-`@object-ui/i18n` gains the `packagedAutomation` key group — 24 keys in `en` and real
-translations in all nine other packs, matching each pack's existing vocabulary for "flow"
-and "package" (zh 流程/软件包, ja フロー/パッケージ, ko 플로우/패키지, de Flow/Paket,
-fr Flux/Package, es Flujo/Paquete, pt Fluxo/Pacote, ru Поток/Пакет, ar التدفق/الحزمة) and
-each one's quotation convention. The group deliberately carries no drift or ancestry
-wording, and no server refusal text: those arrive as server-authored prose and are
-rendered verbatim.
diff --git a/.changeset/6306-action-icon-type-resolution.md b/.changeset/6306-action-icon-type-resolution.md
deleted file mode 100644
index 741c32c49f..0000000000
--- a/.changeset/6306-action-icon-type-resolution.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-'@object-ui/components': patch
----
-
-An `action:icon` hosted by an `action:bar` now reaches its handler. It forwarded the
-COMPONENT id as the action type, so the click resolved nothing at all — no error, no
-toast, a button that silently did nothing (objectui#6306, the objectstack#2169 "Mark Done
-does nothing" shape).
-
-`action:bar` does not route members through `SchemaRenderer`. It pulls each member's
-renderer off the registry and RENAMES the declared type as it spreads it onto the child:
-`type` becomes the component id (`'action:icon'`) and the real declaration moves to
-`actionType`. `action:button` has always resolved that pair when it forwards
-(`schema.actionType || schema.type`); `action:icon` read `schema.type` alone and dropped
-`actionType` entirely. `ActionRunner.execute` resolves its handler from
-`action.type || action.actionType || action.name`, and `'action:icon'` binds no registered
-handler and no builtin — for a declaration carrying `target` rather than `endpoint` it does
-not reach the legacy `navigate`/`api` fallback either, so it fell through to
-`executeActionSchema` and the authored action never ran.
-
-**The bug was a function of the layout, not the declaration.** One authored action executed
-or did nothing depending on which `component` the host picked for it — the same asymmetry
-objectui#5493 fixed on this renderer for `onSuccess`, one key over.
-
-`check:action-forward-parity` could not have caught this and its green run was never
-evidence: `type` **is** in the forward whitelist, and that gate diffs key PRESENCE against
-the owed set. This is a wrong-VALUE defect behind a present key, a class the gate has no
-opinion on by construction. The existing icon coverage could not catch it either — it
-rendered `action:icon` bar members three times and asserted only `visible`/`enabled`, never
-that a click reached a handler, which is exactly how this shipped.
-
-Pinned by `action-bar-member-type-resolution.test.tsx`, which executes clicks rather than
-inspecting props. Every row that reads the icon member's zero renders a sibling
-`action:button` member of the SAME declaration in the SAME bar and reads its one first, so
-a zero cannot be "the harness never executed anything". One row registers a trap handler
-keyed on the component id, making the unfixed behaviour a positive artefact (the trap
-fires) rather than only a missing call. A standalone row stays green in both worlds on
-purpose: it refuses a "fix" written as `schema.actionType` alone, which would trade this
-defect for its mirror image on the surface where `type` IS the action type.
-
-Scope is this one renderer. `type: schema` appears in exactly two files under
-`renderers/action/` — `action-button.tsx` (already correct) and `action-icon.tsx`;
-`action:group` and `action:menu` compose their members differently and are untouched.
diff --git a/.changeset/6307-bold-version-literals.md b/.changeset/6307-bold-version-literals.md
deleted file mode 100644
index 9b3e4f62ca..0000000000
--- a/.changeset/6307-bold-version-literals.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
----
-
-Docs and gate change; no published surface.
-
-Two consumer-facing guides stated Node/pnpm floors this project neither declares nor
-tests: `content/docs/guide/quick-start.md` carried `**Node.js** 20+` / `**pnpm** 9+ or
-npm/yarn`, and `content/docs/guide/building-crud-app.md` the same pair on one line. Both
-pages address the reader's OWN project, so the root `engines` field never governed them,
-and no published package supplies a floor either — of the 46 workspace manifests, zero
-declare `engines.node` or `engines.pnpm` (the only `engines` block outside the root is
-`packages/vscode-extension`'s `engines.vscode`). The pages now state what is measurable
-instead: the packages are built and tested on Node 22.x with pnpm 10.x — 26 of the 27
-`node-version:` declarations in `.github/workflows` read `'22.x'` and the 27th reads
-`'22'`; the root `packageManager` field is `pnpm@10.31.0`, which is what `corepack enable`
-hands every CI job. Worded as what CI exercises, not as a requirement the project has not
-measured.
-
-The reason nothing objected: `scripts/__tests__/doc-version-claims.test.ts` scans
-`content/docs` for exactly this, and the `SEP` character class between a toolchain name
-and its version admitted backticks, quotes, whitespace, colons, commas, pipes and brackets
-— but not `*`. So `**Node.js** 20+` never matched `TOOLCHAIN + SEP + VERSION`, and the
-ratchet reported green over four literals it had never examined. `SEP` now admits `*` and
-`_`; measured over the 241 files the three scan roots resolve to, the corpus goes from 33
-matched literals to 37 — exactly those four, none lost. None of the four was ledgered:
-they were deleted, which is what the gate's own failure message asks for when a literal
-restates no manifest and no lane tests it, and the sentences replacing them are inventoried
-as `anchored` entries naming the anchor each can be re-measured against.
-
-A new fixture test keeps the widening measurable now that the repaired corpus carries no
-emphasised claim at all, and pins the one boundary it does not cross: `_Node.js_ 20+` stays
-invisible, because `_` is a word character and the `\b` on each side of the toolchain name
-therefore fires on neither side of it (measured: zero such spellings in the corpus today).
-
-objectui#6307.
diff --git a/.changeset/6308-living-workflow-example.md b/.changeset/6308-living-workflow-example.md
deleted file mode 100644
index 25ffccc64a..0000000000
--- a/.changeset/6308-living-workflow-example.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
----
-
-Docs change; no published surface.
-
-`content/docs/guide/ci-cd-pipeline.md`'s "Adding a New Workflow" section told a
-contributor to "follow the existing pattern for pnpm + Turbo setup" and then gave a copied
-YAML block in which every line had drifted: `actions/setup-node@v4` where every workflow
-in this repository now uses `@v7`, a hardcoded `node-version: 20` where every workflow
-declares `'22.x'` (and 20 sits below the floor the root `package.json`'s `engines` field
-now declares), and `pnpm/action-setup@v4`, which no workflow here has ever used — pnpm
-comes from `corepack enable` plus the root `packageManager` field instead. Re-measured on
-this change's own HEAD: `actions/setup-node@v7` — 28 occurrences, no other version;
-`node-version:` — 27 `'22.x'` and 1 `'22'`; `pnpm/action-setup` — 0.
-
-A copied block is a fossil by construction, so the section now points at
-`readme-exports.yml` as a living example instead of repeating one: it is short, runs on
-every pull request, and its setup is the complete pattern most new build/test/lint
-workflows need (checkout, `corepack enable`, `actions/setup-node` with pnpm's cache,
-`pnpm install --frozen-lockfile`, then a `turbo run build` step). Only the two steps that
-hold regardless of which Node or pnpm version the repository is on — the checkout step and
-`corepack enable` — stay quoted on the page; the reader copies the version-specific steps
-from the workflow itself. No new version literal was introduced, so no
-`doc-version-claims.test.ts` `KNOWN_CLAIMS` entry was needed.
-
-objectui#6308.
diff --git a/.changeset/6309-delete-object-fields-bridge.md b/.changeset/6309-delete-object-fields-bridge.md
deleted file mode 100644
index 18804b6669..0000000000
--- a/.changeset/6309-delete-object-fields-bridge.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-'@object-ui/app-shell': patch
-'@object-ui/types': patch
-'@object-ui/fields': patch
----
-
-Delete the dead `metadata-admin/previews/object-fields-bridge.ts` module, and the three
-prose references that still described it as wired.
-
-The module exported `bridgeFromDraft`, `commitToDraft` and `FieldsBridgeResult` and had
-**zero importers** — re-measured on the merged base, not inherited from the filing. Nothing
-in the repository could reach it either: `@object-ui/app-shell`'s `exports` map declares
-only `.` and `./styles.css`, so the file was not addressable as a deep import even from
-outside the workspace.
-
-Removing it is not the whole change. Three comments — in `types/src/designer.ts`, `types`'
-`designer-field-types.test.ts` (twice) and `fields`' `richtext-cell-renderer-5452.test.tsx`
-— cited the bridge as a live corroborating source. Left behind, they would have swapped
-dead code for false documentation: three in-repo pointers telling a future reader that this
-bridge mediates between the framework field record and `FieldDesigner`, and nothing telling
-them it is unreachable. The two that named it as the consumer deriving an editable-subset
-check from `DESIGNER_FIELD_TYPES` now name `MetadataFieldsPage`, which does exactly that
-with the same idiom and the same `objectui#3017` anchor. The third cited the bridge's
-`richtext` → `html` mapping as one of three corroborations that `richtext` stores HTML; the
-other two (the showcase seed and the field-type decision tree) are live and carry the point
-on their own, so that clause is dropped rather than repointed.
-
-No behaviour changes: nothing imported the module, so there is nothing to migrate.
diff --git a/.changeset/6310-designer-formula-key-retired.md b/.changeset/6310-designer-formula-key-retired.md
deleted file mode 100644
index 905322ab4c..0000000000
--- a/.changeset/6310-designer-formula-key-retired.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-'@object-ui/i18n': patch
-'@object-ui/plugin-designer': patch
----
-
-`appDesigner.fieldDesigner.formula` is retired — one row removed from each of the ten
-locale packs plus the designer defaults map, 11 lines, zero readers (objectui#6310).
-
-objectui#6043 retired the Field Designer's formula-expression textarea, which was the
-key's only call site (`FieldDesigner.tsx`, the `{ name: 'formula', label:
-t('appDesigner.fieldDesigner.formula') }` field descriptor). The value outlived it in
-eleven places: `DESIGNER_DEFAULT_TRANSLATIONS` in
-`packages/plugin-designer/src/hooks/useDesignerTranslation.ts`, and the `appDesigner >
-fieldDesigner > formula` leaf of `packages/i18n/src/locales/{en,de,es,fr,pt,ru,ja,ko,zh,ar}.ts`.
-
-Removed under objectui#4658's evidence standard, re-measured on this branch rather than
-inherited from the card: zero `t()`/`tt()` call sites, no dynamic template head that could
-reach it (`appDesigner.fieldDesigner.typeCategory.` is the namespace's only one), and its
-sole textual occurrence anywhere in the repo was the defaults-map row this change removes
-with it — so the key goes from NEEDS-REVIEW to no footprint at all.
-
-The map and all ten packs move in one commit, which is what keeps
-`defaults-maps-mirror-en-pack` green: that gate fails a map row whose key the `en` pack
-lacks, and `all-locales-key-parity` fails a pack left behind.
-
-Not touched: `designer.field.formula` (`'Formula (CEL)'`) in
-`packages/app-shell/src/views/metadata-admin/i18n.ts`, a different and live key belonging
-to metadata-admin's `ObjectFieldInspector` — the surface that still authors formula
-expressions.
-
-`packages/i18n/src/__tests__/appDesigner-fieldDesigner-formula-retired-6310.test.ts` pins the
-removal by name, following the four prior retirements (objectui#4145, objectui#4392,
-objectui#4730, objectui#5504). Every i18n gate here runs call site → key, so none of them can
-see a dead key come BACK into the packs: the reverse sweep that found this one is report-only
-by design, `all-locales-key-parity` is fully satisfied by ten packs agreeing on a dead key, and
-`check:i18n-drift` only fires when a value changes. Reverse-verified rather than asserted —
-reviving the row in all ten packs turns exactly that one case red, naming each pack, while the
-parity gate and the defaults-map mirror stay green.
diff --git a/.changeset/6313-quick-reference-node-floor.md b/.changeset/6313-quick-reference-node-floor.md
deleted file mode 100644
index c67eeeddbc..0000000000
--- a/.changeset/6313-quick-reference-node-floor.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
----
-
-Tooling-only fix (objectui#6313): `QUICK_REFERENCE.md`'s "Current Release" pin
-(`scripts/__tests__/quick-reference-current-release-4143.test.ts`) and the sync
-generator (`scripts/sync-quick-reference-release.mjs`) derived the Node/pnpm
-version floors with `match(/(\d+)/)?.[1]`, which keeps only the LEADING integer
-group. Against root `engines.node: ">=22.11"` (objectui#5306 / PR #6311) that
-produced a floor of `22`, silently discarding the `.11` — so a row reading
-exactly `≥ 22` passed a pin whose whole premise is disagreeing with its own
-cited anchor. Both derivations now strip the comparator and keep the WHOLE
-version string; `pnpm quick-reference:sync` regenerated the Node.js row to
-`≥ 22.11`. Added regression coverage pinning that a `≥ 22`-shaped row is now
-rejected and that a `≥ 220`-shaped row still is (objectui#4913), and corrected
-the test file's docblock, which had gone stale on the same anchor one decimal
-place up. No published package source changed.
diff --git a/.changeset/6316-docs-route-eager-closure-gate.md b/.changeset/6316-docs-route-eager-closure-gate.md
deleted file mode 100644
index d39e34ce12..0000000000
--- a/.changeset/6316-docs-route-eager-closure-gate.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
----
-
-Tooling-only change; no published behaviour changes. The docs route's eager closure now has
-an instrument. `check:eager-closure` reads `apps/console/dist/eager-closure.json` and weighs
-the console, so the budget objectui#4616 set over `/docs/[[...slug]]` — the route every one
-of the docs pages shares, and the one `apps/site/app/components/registerCatalogBlocks.ts`
-adds side-effect imports to — was governed by nothing, and its only measurement was
-reconstructed by hand, once. `pnpm check:docs-route-closure` weighs it structurally instead
-of in bytes (objectui#6316, triage ruling shape 2, so no docs-site build in CI): every
-package the registrar names must be already reachable from that route's static module graph
-— a declaration and no payload, which the gate proves for `@object-ui/plugin-form` and
-`@object-ui/plugin-grid` through `@object-ui/plugin-view` — or recorded in the script's
-`MEASURED_PAYLOAD` with what it is for. Anything else is a genuinely new graph, and it fails
-so that a human argues for it in review.
diff --git a/.changeset/6320-check-nested-dist-ignore.md b/.changeset/6320-check-nested-dist-ignore.md
deleted file mode 100644
index 9f99ca1fc5..0000000000
--- a/.changeset/6320-check-nested-dist-ignore.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-'@object-ui/cli': patch
----
-
-Fix `objectui check` scanning build output because its ignore list only excluded a
-root-level `dist/` / `node_modules/` (objectui#6320).
-
-`packages/cli/src/commands/check.ts` passed `ignore: ['node_modules/**', 'dist/**',
-'.git/**']` to `globSync`. `glob` matches `ignore` patterns against the path relative to
-`cwd`, so an unanchored `dist/**` / `node_modules/**` excludes only a directory of that
-name at the scan root — every nested `packages/<name>/dist/`, `examples/<name>/dist/`,
-`apps/<name>/dist/` (and their `node_modules/`) was still scanned. In a built workspace
-this means `objectui check` re-reads the author's own schemas a second time from build
-output, roughly doubling every count it reports (measured on this repository: 617 → 1047
-files globbed after a full build) with nothing in the output explaining why.
-
-The ignore patterns are now anchored at every depth (`'**/dist/**'`, `'**/node_modules/**'`),
-matching the fix's stated intent: exclude build output and installed dependencies wherever
-they live, not only at the project root. A root-level `dist/` / `node_modules/` remains
-excluded, unchanged.
-
-Confirmed before widening: no example, template, or docs fixture in this repository
-authors a schema under a directory literally named `dist` — the widened pattern excludes
-only generated content.
diff --git a/.changeset/6321-changeset-guard-self-coverage.md b/.changeset/6321-changeset-guard-self-coverage.md
deleted file mode 100644
index 25123a3f24..0000000000
--- a/.changeset/6321-changeset-guard-self-coverage.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
----
-
-Internal CI-only change: `changeset-guard.yml`'s `paths:` filter now includes its own
-YAML and `scripts/check-changeset-no-major.mjs`, so a change to the gate is exercised by
-the PR that makes it instead of by the next unrelated `.changeset/**` PR (objectui#6321).
-`content/docs/guide/ci-cd-pipeline.md` is updated to match. No published package changed.
diff --git a/.changeset/6329-actionparam-one-authority.md b/.changeset/6329-actionparam-one-authority.md
deleted file mode 100644
index ac3ed137ee..0000000000
--- a/.changeset/6329-actionparam-one-authority.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-`ActionParam` has one authority again (objectui#6329). The name was declared three times,
-not twice as the card counted: `@object-ui/types` publishes it — derived from the spec's
-`ActionParamSchema` input, with its own parity suite — and `ActionDefaultInspector.tsx` and
-`ActionPreview.tsx` each carried a module-local `interface` of the same name. app-shell
-already read the published one elsewhere (`utils/resolveActionParams.test.ts`), so both
-locals were shadows. They are deleted, not reconciled against each other, under the
-2026-08-25 family ruling 甲A1.
-
-Neither shadow needed a member the published type lacks, so nothing was added to the
-published surface. What the shadows got wrong was the DECLARATION, in the direction that
-lets wrong metadata compile:
-
-- The inspector's copy carried `[k: string]: unknown`. An index signature admits every key
-  at type `unknown`, so a commit of a key `ActionParamSchema` rejects by name — `.strict()`,
-  and `referenceTo` is listed in its alias map — type-checked here and failed on save. It
-  also made the two copies look compatible when they were describing different authoring
-  surfaces: `options` / `helpText` / `defaultValue` were declared outright on one side and
-  swallowed as `unknown` on the other.
-- The preview's copy declared `label?: string | { en?: string }`, admitting the `en` tag and
-  no other, while its own `localize` helper has always read `Object.values(o)[0]`. An inline
-  locale map keyed `fr-FR` rendered correctly and failed `tsc`. The published `I18nLabel`
-  admits both authorized forms, so the type now matches what the code already did — this
-  widens the declaration, not the runtime's acceptance.
-
-Two behaviour-visible consequences, both of them the local `type?: string` being withdrawn
-in favour of the published `ResolvableParamFieldType` (the spec's 49-member `FieldType` plus
-objectui's three declared param aliases):
-
-- `ActionPreview.renderFieldMock` no longer branches on `long_text` or `integer`. Neither is
-  in that vocabulary — `long_text` belongs to the console form-builder dialect and `integer`
-  to JSON Schema — so a param spelled either way is a parse rejection on the server and
-  could never have reached the preview. The two comparisons compiled only because the local
-  copy typed `type` as `string`.
-- The inspector's param-type dropdown narrows its commit through the runtime witnesses
-  `@object-ui/types` exports (`ACTION_PARAM_FIELD_TYPES` + `OBJECTUI_LOCAL_PARAM_FIELD_TYPES`)
-  rather than writing the raw DOM string. An unrecognised spelling clears the key instead of
-  being written into metadata the server would refuse; the eight offered spellings are
-  unaffected, and are now checked against the vocabulary at compile time.
diff --git a/.changeset/6332-explain-request-adoption.md b/.changeset/6332-explain-request-adoption.md
deleted file mode 100644
index b6952b279c..0000000000
--- a/.changeset/6332-explain-request-adoption.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
----
-
-Type-only: `useRecordCrudVerdicts` now builds its `POST /api/v1/security/explain`
-body against `@objectstack/spec/security`'s `ExplainRequest` instead of an
-untyped object literal, and `RecordCrudOperation` is now a *declared* subset of
-the spec's eight-verb `ExplainOperation` rather than a coincidental one.
-
-No release: `satisfies` and the subset wrapper are erased at compile time, the
-emitted JavaScript is unchanged, and `RecordCrudOperation` is not part of
-`@object-ui/plugin-grid`'s public `.d.ts` (verified — it does not appear in
-`dist/index.d.ts`).
-
-What it buys is a class of compile errors the untyped literal accepted:
-a renamed or mis-cased request key (`recordIDs`, `objectName`) and a verb the
-explain API does not accept are now `tsc` failures at the call site instead of
-a `400 VALIDATION_FAILED` — or, for a mis-cased `recordIds`, a request the
-server reads as "no ids at all". Pinned at compile time in
-`useRecordCrudVerdicts.explainRequest.test.ts`.
-
-The narrowing at the heart of the hook is deliberately preserved: the two kebab
-verbs stay written out locally, so an upstream release that adds a ninth verb
-cannot widen what this list asks about. Only the request side is adopted — the
-response stays `unknown` on purpose, because asserting the spec's entry type
-would make the hook's fail-open runtime guards look like dead code.
diff --git a/.changeset/6335-starred-apps-nav-exclusion.md b/.changeset/6335-starred-apps-nav-exclusion.md
deleted file mode 100644
index d56cbe2400..0000000000
--- a/.changeset/6335-starred-apps-nav-exclusion.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-`StarredApps` now filters out `nav`-type favorites before rendering (objectui#6335).
-
-`FavoritesProvider` has always documented `nav` favorites (sidebar entries pinned via
-the in-tree pin toggle) as "Excluded from Home/Starred and from the generic sidebar
-Favorites list so it doesn't render twice" — but `StarredApps` filtered nothing by type,
-so a `nav` favorite handed to it rendered anyway. `FavoriteItem['type']` also has no
-`nav` key under `home.recentApps.itemType.*` (only five of its six members do), so a
-`nav` card that reached `StarredApps` fell through to the raw `"nav"` label instead of a
-translated one.
-
-`StarredApps` now filters `items` to `type !== 'nav'` before rendering — the same
-exclusion already applied to the sidebar Favorites list in `AppSidebar.tsx` and
-`UnifiedSidebar.tsx` — restoring declared-equals-enforced behaviour and making the
-missing locale key correct by construction. No locale packs were touched, and the
-`FavoriteItem` / `RecentItem` union types are unchanged.
diff --git a/.changeset/6336-changeset-overwrite-guard.md b/.changeset/6336-changeset-overwrite-guard.md
deleted file mode 100644
index 4dd585854d..0000000000
--- a/.changeset/6336-changeset-overwrite-guard.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
----
-
-Internal CI-only change: a new report-only `Changeset Overwrite Report` job in
-`changeset-guard.yml` names any `.changeset/*.md` a change modified or deleted
-without having added it, and prints the release declaration that was there.
-
-No published package changes, so this releases nothing.
-
-objectui#6336 — a hand-picked `changesets`-style filename can land on one that
-already exists, and the overwrite is silent in both directions that should catch
-it: `git status` reports ` M` rather than `??`, and a deleted release declaration
-is flagged by nothing downstream. The cost lands on a third party — whichever
-earlier pull request's declaration disappears — and surfaces only when a package
-fails to bump.
-
-Report-only is measured, not cautious: across all 5281 first-parent commits on
-`main`, every one of the 19 modifications of a pre-existing changeset was
-legitimate, so a blocking gate would have failed all of them.
-`OS_CHANGESET_OVERWRITE_ENFORCE=1` flips it for whoever revisits that with a new
-measurement.
diff --git a/.changeset/6342-dead-migration-guide-pointers.md b/.changeset/6342-dead-migration-guide-pointers.md
deleted file mode 100644
index a4a89c9c2a..0000000000
--- a/.changeset/6342-dead-migration-guide-pointers.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-'@object-ui/core': patch
----
-
-Two deprecation warnings pointed at `MIGRATION_GUIDE.md`, a file deleted from the
-repository in `8c5d20455` (objectui#6342).
-
-`Registry.register()`'s missing-namespace warning now points at the live docs page
-that documents namespaced registration
-(`/docs/guide/plugin-development#namespaced-registration`) instead of the deleted
-guide. `ValidationEngine`'s function-based-condition warning drops its `See:` line
-entirely: the deleted guide covered component namespaces and lazy field
-registration and never documented conditions at all, so that pointer was
-misdirected as well as dead, and the warning already carries the complete
-before/after migration inline.
-
-Both are console messages shipped to application developers, so neither can use
-the immutable `git show <sha>^:<path>` provenance form objectui#6275 used for a
-docblock — a reader of the npm package has no repository to run it against.
diff --git a/.changeset/6353-timeline-bare-key-ownership.md b/.changeset/6353-timeline-bare-key-ownership.md
deleted file mode 100644
index 84d83034d6..0000000000
--- a/.changeset/6353-timeline-bare-key-ownership.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-'@object-ui/plugin-timeline': patch
----
-
-The bare `timeline` component key is now owned by DECLARATION rather than by
-module-evaluation order (objectui#6353).
-
-`packages/plugin-timeline` registers the same short name twice —
-`plugin-timeline:timeline` (`src/renderer.tsx`, the presentational renderer) and
-`view:timeline` (`src/index.tsx`, the object-bound `ObjectTimelineRenderer`). Neither
-passed `skipFallback`, so under `Registry.register` both also claimed the **bare**
-`timeline` key and the last module to evaluate won it. `src/index.tsx` re-exports
-`./renderer` (line 300) before its own `import` (line 307), so the presentational one
-registered first and the object-bound one overwrote it.
-
-The resolved outcome was the intended one and **does not change here**: `type:
-'timeline'` still renders `ObjectTimelineRenderer`, which delegates inward to the
-presentational renderer. What changes is that it is now decided rather than inherited.
-Reordering those two lines would previously have handed `type: 'timeline'` to the
-presentational renderer, which reads none of the object-bound keys (`object`, `filter`,
-`sort`, `limit`) — an authored timeline would have stopped fetching, with no error and
-no failing test. The registry's own collision guard names this remedy in its warning
-text; this applies it.
-
-`src/renderer.tsx` now registers with `skipFallback: true`, so only `view:timeline`
-claims the bare key, in any evaluation order. The presentational renderer stays
-reachable under its explicit `plugin-timeline:timeline` key, which is the lookup a
-presentational host already uses — no consumer-visible resolution changes.
-
-`src/__tests__/timeline-bare-key-ownership.test.ts` is the half that outlives the fix:
-it fails if the declaration is dropped, if a third registration starts claiming the bare
-key, or if resolution becomes order-dependent again. It reads both registrations' real
-declared metadata back out of the registry and replays them into a fresh `Registry` in
-**both** orders, so order-independence is a property under test rather than a property
-of the file the test happens to import.
diff --git a/.changeset/6360-master-detail-declined-detail-config-hint.md b/.changeset/6360-master-detail-declined-detail-config-hint.md
deleted file mode 100644
index e074fb8689..0000000000
--- a/.changeset/6360-master-detail-declined-detail-config-hint.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-'@object-ui/plugin-form': patch
----
-
-`object-master-detail-form` now renders a config hint naming `childObject` for a detail
-collection whose child object never resolved, instead of `Loading columns…` forever
-(objectui#6360).
-
-`MasterDetailForm` already declines to fetch the schema of such a detail (objectui#5940)
-and returns the entry unresolved, which is correct — asking the data layer for an object
-literally named `undefined` is what that guard removed. But the decline is precisely the
-guarantee that the entry's columns can never arrive, and the render branch it fell into
-read `!d.columns?.length ? <p>Loading columns…</p>`. The author was shown a
-spinner-shaped message that was permanently, unfixably wrong, and that never named the
-key they had to set.
-
-The `!d.childObject` case now takes its own branch, checked **before** the columns arm
-because nothing is pending — there is no first paint where "loading" is honest. The copy
-and structure are `LineItemsPanel`'s, which took the same branch for the same key in
-objectui#6194 / PR #6359; the two components had been disagreeing about what an author
-sees for the identical authoring mistake, and the weaker of the two was the one that read
-as the precedent. The hint carries its own `data-testid` (`md-detail-no-child-object`).
-
-Two source comments — at the decline itself and at the resolver's `catch` — asserted that
-"the grid card shows a config hint". They were false, and following them cost a reader a
-run of the component. The first is now true and says so. The second is **corrected rather
-than made true**: a detail whose schema fetch *threw* does name a child object, so it
-skips the new branch and still lands on `Loading columns…`. Distinguishing that from
-"still in flight" needs per-entry error state the resolver does not keep, so it is filed
-as objectui#6372 and the comment now points at it instead of promising a hint that is not
-rendered there.
-
-No spec or schema change: `childObject` is already REQUIRED on `MasterDetailDetailConfig`.
-This is renderer-side reporting of an authoring error that the type system cannot catch,
-because a detail entry reaches this renderer straight off an authored JSON schema.
diff --git a/.changeset/6361-spec-floor-17-2-0.md b/.changeset/6361-spec-floor-17-2-0.md
deleted file mode 100644
index c41aca32a7..0000000000
--- a/.changeset/6361-spec-floor-17-2-0.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-'@object-ui/core': patch
-'@object-ui/data-objectstack': patch
----
-
-`@object-ui/core` and `@object-ui/data-objectstack` now declare
-`"@objectstack/spec": "^17.2.0"` rather than `^17.0.0`, which is the lowest published
-spec that carries every symbol each package's own build output references
-(objectui#6361).
-
-`packages/core/dist/utils/column-sortability.d.ts` references
-`FIELD_SORTABLE_UNPROVISIONED_ANCHOR`, `FIELD_UNSORTABLE_VIRTUAL_TYPE`,
-`FieldSortability` and `ObjectSortability` from `@objectstack/spec/api`, and
-`packages/data-objectstack/dist/index.js` references the first two — none of which
-`@objectstack/spec@17.0.0` exports. Measured against the published tarballs rather than
-the installed tree, by `scripts/check-spec-range-floors.mjs`: six `floor-too-low`
-findings across the two packages, and `^17.2.0` is that gate's own computed answer for
-both. So the old range was a claim neither package could honour: any consumer
-resolution that lands 17.0.0 — a sibling pinning it exactly, an `overrides` entry, a
-mirror two minors behind — satisfied `^17.0.0` and got a dangling reference.
-
-Nothing a consumer installs today changes: normal resolution already picks the newest
-17.x, and `pnpm-lock.yaml` still resolves `17.2.0` on both edges after the bump — only
-the recorded `specifier:` moves. No source and no behaviour changes, which is why this
-is scored `patch`, on the reasoning objectui#5793 used for the same remediation on
-`@object-ui/plugin-detail`.
-
-The bump is release-blocking rather than cosmetic. `check:spec-floors` is deliberately
-not a `pull_request` job, so every PR stayed green while its blocking copy on the
-publish path — `pnpm changeset:publish` runs it before a single tarball reaches npm —
-would have cancelled the next release.
diff --git a/.changeset/6369-dead-lockfile-merge-driver.md b/.changeset/6369-dead-lockfile-merge-driver.md
deleted file mode 100644
index 958aaf5114..0000000000
--- a/.changeset/6369-dead-lockfile-merge-driver.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
----
-
-CI/doc-only: `.github/workflows/dependabot-auto-merge.yml` no longer configures the
-`pnpm-lock.yaml` merge driver, and the pinned "Lockfile Merge Driver" table in
-`content/docs/guide/ci-cd-pipeline.md` loses the row that named it (objectui#6369).
-
-A merge driver runs only when git has to merge the attributed path *on the runner*. The
-only merge that job performs is `gh pr merge --auto --squash`, which GitHub executes
-server-side in the merge queue — the runner's local git config takes no part in it, so
-the driver had no occasion to fire. Swept the whole file before removing: no `git
-merge`, `rebase`, `pull`, `cherry-pick`, `am`, `apply` or `revert` anywhere in it, the
-`git config` pair being the only `git` present; `actions/checkout` checks out the merge
-commit GitHub already computed rather than computing one; and the gate script imports
-`node:fs` only.
-
-Same no-occasion property objectui#6358 measured on `changelog.yml`, reached by a
-different route — that job never merged at all, this one merges only where local config
-cannot reach. With both dead copies gone the mechanism has one row left,
-`changeset-release.yml`.
-
-The guide sentence that produced both copies is narrowed in the same change: it now asks
-for a **local** merge, and records that neither a push nor a server-side merge is one.
-
-No source and no behaviour change; nothing a consumer installs is affected.
diff --git a/.changeset/6372-6371-master-detail-entry-identity.md b/.changeset/6372-6371-master-detail-entry-identity.md
deleted file mode 100644
index f9c66819da..0000000000
--- a/.changeset/6372-6371-master-detail-entry-identity.md
+++ /dev/null
@@ -1,57 +0,0 @@
----
-'@object-ui/plugin-form': patch
----
-
-`MasterDetailForm` gives every detail collection a per-entry record carrying its own
-identity and its own resolution status, closing two defects that both came from the same
-absence (objectui#6372, objectui#6371).
-
-`resolvedDetails` was a plain `MasterDetailDetailConfig[]` with no per-entry metadata, so
-both *what happened to this entry* and *which entry is this* were inferred from the
-entry's position in the array. One record answers both, which is why they land together —
-either one alone would have reshaped this structure and the second would then have
-rewritten the first.
-
-**objectui#6372 — a detail whose schema fetch threw sat on "Loading columns…" forever.**
-The resolver's `catch` returned the entry unchanged, and an entry with no `columns` is how
-*still in flight* is represented too, so the two states were indistinguishable and the
-render branch showed the same spinner-shaped message for both. For the failed one it never
-ended: the fetch is not retried, so nothing could ever replace it. Entries now carry a
-resolution status, and a failed one renders a refusal placeholder naming the child object
-whose schema could not be loaded (shaped on `AdvancedChartImpl`'s refusal placeholders —
-`role="status"`, because a refusal is a state, not an alert). Measured before the fix
-rather than read from source: a detail whose `getObjectSchema` rejects rendered
-`<p>Loading columns…</p>`.
-
-The thrown error is no longer discarded. The bare `catch` threw away the whole diagnosis,
-so whoever debugged this had neither a message nor a stack; the decline arm next to it has
-warned since objectui#5940, and this arm now matches it and passes the error object
-through.
-
-⭐ The fetch and the derive are caught **separately**, because they are different failures
-with different truths to tell. A schema that loads fine and then yields no relationship
-field is a configuration error, and calling it a load failure would be false. That arm's
-render is deliberately unchanged; only its error stops being swallowed.
-
-**objectui#6371 — a declined entry had no identity across a reorder.** There was no
-duplicate-key collision: the map index is unique among siblings by construction, so two
-declined details keyed as `undefined-0` and `undefined-1`, distinct. The real defect is
-that for a declined entry the data half of that key is `undefined`, leaving position as
-the entry's whole identity — and the row-state store was addressed the same way, seeded
-once at mount and never re-synced when the authored config changed. Reordering or removing
-an entry therefore handed a collection a different collection's rows.
-
-Entries now carry an id synthesized once from the incoming config: the child object for a
-named collection, and the authored position for a declined one, which has no other
-identity to offer. Row state is keyed by that id, so a collection can only ever read its
-own slot. Three reads were affected, not the one the report named:
-
-- the grid value, which showed the wrong collection's rows;
-- the document **subtotal** reducer, so a reorder did not merely mis-associate a grid, it
-  mis-computed the total;
-- the batch payload on save, which read
-  `details.filter(d => d.relationshipField).map((d, i) => state[i])` — after the filter `i`
-  indexed the filtered array while the row state was indexed against the full one, so a
-  declined entry above a real collection shifted every read below it by one and that
-  collection's rows were **silently dropped from the transaction**. Data loss on save, not
-  a display defect.
diff --git a/.changeset/6373-datatable-emit-boundary.md b/.changeset/6373-datatable-emit-boundary.md
deleted file mode 100644
index 5da8a51593..0000000000
--- a/.changeset/6373-datatable-emit-boundary.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-'@object-ui/plugin-dashboard': patch
----
-
-`ObjectDataTable` no longer writes six undeclared keys into the `data-table` columns slot
-(objectui#6373). `enrich()` returned `NormalizedColumn`, whose `[key: string]: any` accepts
-anything, so nothing checked the producer's output against
-`DataTableSchema.columns: TableColumn[]`: `{ ...col, ...fieldMeta }` spread `label`,
-`options`, `referenceTo`, `format`, `currency` and `decimals` onto every emitted column, and
-`TableColumn` declares none of them.
-
-The measured read set of the consumer (`data-table.tsx`, comments stripped) contains none of
-the six, so all six retire from the emit rather than being declared — declaring a key nothing
-reads is the same `declared != enforced` defect facing the other way. Rendering is unchanged
-because none of those keys was the live path for its own value: the `FieldMeta` the `cell`
-closure captures is what this widget's type-aware rendering has always read, and it is
-untouched. Authored spellings still pass through, so a column the author wrote as
-`{ format: '$0,0' }` keeps its `format` exactly as before.
-
-`type` is unchanged — objectui#5853's fold at this seam still applies. `name` is unchanged
-and still written: `data-table` reads `col.accessorKey || col.name` and objectui#5120 holds
-that alias while two published skill guides still teach a `{ name, label }` column. The hold
-is now declared at the seam instead of arriving anonymously inside a spread.
-
-The seam's emit type carries ADR-0049 `?: never` tombstones for the retired keys rather than
-being a bare `TableColumn` annotation. Measured before the shape was chosen: a bare annotation
-raises no error at all here, because TypeScript's excess-property check exempts properties
-that arrive through a spread — it would have type-checked the boundary without enforcing it.
diff --git a/.changeset/6375-concurrent-update-subsumed-guard.md b/.changeset/6375-concurrent-update-subsumed-guard.md
deleted file mode 100644
index d780ec58a6..0000000000
--- a/.changeset/6375-concurrent-update-subsumed-guard.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
----
-
-Internal only, no behaviour change: `@object-ui/data-objectstack`'s
-`normaliseClientError` carried two stacked `CONCURRENT_UPDATE` guards whose
-first could never decide an outcome — its condition
-(`code !== 'CONCURRENT_UPDATE' && httpStatus !== 409`) is strictly stronger
-than the line below it, so every input it would have returned was returned
-one line later anyway. Its `httpStatus !== 409` half advertised a second
-acceptance path (a bare 409 still being re-wrapped) that never existed, on the
-one function whose whole job is deciding which errors get re-wrapped. Deleted,
-with the effective rule — the wire `code` is the sole discriminator — written
-where the dead line used to be.
-
-Also aligned the doc comment above the exported `isConcurrentUpdateError` with
-the predicate underneath it: the doc named only the wire shape while the code
-accepts `name === 'ConcurrentUpdateError'` as well. The `name` limb is kept —
-it is the deliberate cross-realm discriminator that
-`isViewConfigPermissionDeniedError`'s doc already cites this function as its
-precedent for — and the doc now says so.
-
-Both accepted sets (the re-wrap's and the predicate's) are now pinned as an
-explicit truth table in `packages/data-objectstack/src/occ.test.ts`.
diff --git a/.changeset/6378-boot-redirect-splash.md b/.changeset/6378-boot-redirect-splash.md
deleted file mode 100644
index 739b8c31a9..0000000000
--- a/.changeset/6378-boot-redirect-splash.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-'@object-ui/app-shell': patch
-'@object-ui/console': patch
----
-
-The console boot no longer flashes a fully-white frame after the splash has painted
-(objectui#6378).
-
-Cause, established by measurement before any fix was written — the card named
-`LoadingScreen`'s unmount timing and `RouteFader` as suspects and both are exonerated.
-A CDP `Page.startScreencast` frame ledger (every frame classified with the card's own
-rule: white when no colour channel falls below 242) was correlated against a DOM-state
-ledger on the same clock (`performance.timeOrigin`), against the production
-`apps/console` bundle with the boot endpoints mocked. `RouteFader` never mounts on the
-boot path at all, and `LoadingScreen` unmounts exactly when its own gate says to. What
-is wrong is what REPLACES it: every readiness gate renders the splash while it waits and
-a bare `<Navigate>` the moment it decides. `<Navigate>` renders `null` and react-router
-runs the navigation as a transition, so the destination tree renders while the commit
-that already dropped the splash is what the compositor is showing — 41–147 ms during
-which `#root` holds no view and the viewport is the bare page background. The flash is
-intermittent only because it depends on a frame being swapped inside that window; the
-window itself was present on every measured boot.
-
-`RedirectWithSplash` (new, `@object-ui/app-shell`) pairs the same `<Navigate>` with the
-same `LoadingScreen` the gate one line above was already rendering, so the handoff
-changes no pixels and the transition runs underneath an unchanged screen. The console's
-three boot redirects use it: the auth gate's `/login` bounce, the `/` landing resolver,
-and the catch-all route. The nested organization `index` redirect deliberately does not —
-it fires under an already-painted layout, where covering the screen would be the
-regression.
-
-Acceptance campaign — same instrument on both sides, the two arms INTERLEAVED inside one
-process and one browser so drift in this shared container's load lands on both equally.
-102 paired boots per arm across five cells (signed-out `/`, signed-in `/`, an unmatched
-entry, and the card's two throttled network profiles). The empty-viewport window: 102/102
-pre-fix, 0/102 post-fix. The white frame itself, pooled over the three cells where the
-pre-fix build actually flashed: 67/87 (77%) pre-fix, 0/87 post-fix — 95% upper bound on
-the residual rate 3.4%, against a card-reported defect rate of ~1/3. The two throttled
-cells are reported but NOT pooled: the pre-fix build flashed 0 times there, so before and
-after agree and those cells prove nothing about the pixels (they still separate 15/15 vs
-0/15 on the DOM window).
-
-`e2e/console-boot-indicator.spec.ts` gains the deterministic half as a gate — after
-React's first commit the viewport centre must never stop being covered. That reading is
-what makes an intermittent defect gateable: the flash needs a frame to be swapped inside
-the window, but the window itself was present on every measured boot. Verified red-first,
-6/6 red on the pre-fix bundle and 6/6 green on this one.
diff --git a/.changeset/6391-lockfile-merge-driver-measurement.md b/.changeset/6391-lockfile-merge-driver-measurement.md
deleted file mode 100644
index d92c283548..0000000000
--- a/.changeset/6391-lockfile-merge-driver-measurement.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
----
-
-CI/doc-only: records the measurement of the last remaining "Lockfile Merge Driver" row
-(objectui#6391). No mechanism is added or removed.
-
-`changeset-release.yml` performs no local merge, so the driver it configures cannot fire in
-that job. Swept the whole file with a control term on every zero-hit — no `git merge`,
-`rebase`, `pull`, `cherry-pick`, `am`, `apply` or `revert`; every `git` in it is the two
-`git config` lines, `git status` twice, and the `git checkout -- .` / `git clean` pair that
-undoes the version step, `checkout -- .` being an index-restore rather than a merge. The
-deciding fact is in the marketplace action: read at `changesets/action` v1.9.0 (`a45c4d5`),
-`src/git.ts` and the shipped `dist/` agreeing, its entire git surface is `checkout`,
-`reset --hard`, `add .`, `commit -m`, `push --force` and `config user.*` — the version branch
-is updated by `reset --hard` plus a force-push, and a force-push resolves no merge.
-
-⭐ The `.gitattributes` line is NOT dead, which is why the row was not removed with the other
-two. `CONTRIBUTING.md` has contributors configure the same driver and then `git merge
-upstream/main` — a real local merge on the attributed path. Measured in a scratch repository
-with one variable changed: with the attribute the driver fires and the lockfile is
-regenerated; without it the identical merge ends in `CONFLICT (content)`. The CI half is dead
-and the repository-wide half is live, while `ci-cd-pipeline-doc.test.ts` binds them together,
-so the removal is a decision rather than a cleanup and is escalated instead of guessed.
-
-The row's stated reason ("version bumps rewrite the lockfile") was wrong and is corrected — a
-rewrite is not a merge — and the guide gains the third ⛔ note in the series that already
-records "pushing is not merging" and "a server-side merge is not a local one".
-
-No source and no behaviour change; nothing a consumer installs is affected.
diff --git a/.changeset/6392-vestigial-pnpm-steps.md b/.changeset/6392-vestigial-pnpm-steps.md
deleted file mode 100644
index 0c9cfc4f68..0000000000
--- a/.changeset/6392-vestigial-pnpm-steps.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
----
-
-CI-only change in `.github/workflows/dependabot-auto-merge.yml` (objectui#6392): removed the
-`corepack enable` + `pnpm --version` steps left behind once objectui#6389 removed the lockfile
-merge driver that had been their only consumer. Nothing in this job runs `pnpm install` or
-otherwise shells out to `pnpm`, so the two lines were a package manager enabled and
-version-printed for zero consumers. A comment in the workflow records the reasoning for the
-removal (and for not keeping `pnpm --version` alone as a fail-fast) so a future reader does not
-re-add it unexplained; the `cache: 'pnpm'` comment on the `Setup Node.js` step below was reworded
-to note that no pnpm setup happens in this job at all.
-
-No source or behaviour change outside the workflow file; no published package touched.
diff --git a/.changeset/6394-master-detail-underivable-detail-config-hint.md b/.changeset/6394-master-detail-underivable-detail-config-hint.md
deleted file mode 100644
index 52579e4076..0000000000
--- a/.changeset/6394-master-detail-underivable-detail-config-hint.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-'@object-ui/plugin-form': patch
----
-
-`MasterDetailForm` shows a config hint naming `relationshipField` for a detail collection
-whose child schema **loaded fine but could not be derived from**, instead of a permanent
-`Loading columns…` (objectui#6394).
-
-This is the third and last arm of the same resolver to be closed. `deriveDetail` throws
-when no lookup/`master_detail` field on the child object references the parent — a
-configuration error whose remedy is a key the author writes. The `catch` returned the
-entry unresolved, so it fell through to `!d.columns?.length ? <p>Loading columns…</p>`,
-and that message never ended: the derive is not retried, so those columns could never
-arrive. Same unbounded-wait-shown-as-a-spinner family as objectui#5940 / objectui#6188 /
-objectui#6194 / objectui#6360 / objectui#6372.
-
-The entry now carries `status: 'underivable'`, and the renderer gives it a branch of its
-own that names both ends of the relationship it could not find and the key to set:
-
-> Could not work out how `po_line` links to `purchase_order`: no lookup or master_detail
-> field on it references the parent. Set `relationshipField` on this collection to the
-> field that holds the parent record.
-
-⛔ Deliberately **not** objectui#6372's refusal placeholder, which states the schema could
-not be loaded — false for a schema that loaded fine. The two failures keep separate copy
-because they have different remedies: one is "check the object exists and reload", this one
-is "set this key". The thrown error is still logged with its stack (objectui#6372), since
-the placeholder shows the author the key rather than the raw message.
-
-Behaviour is unchanged for the other two arms and for a detail that is genuinely still
-fetching — that one keeps `Loading columns…`, where the message is true.
diff --git a/.changeset/6396-previous-values-dom-leak.md b/.changeset/6396-previous-values-dom-leak.md
deleted file mode 100644
index 7033c319c4..0000000000
--- a/.changeset/6396-previous-values-dom-leak.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-'@object-ui/components': patch
----
-
-The form renderer no longer leaks `FormSchema.previousValues` onto the `<form>` DOM node
-(objectui#6396).
-
-`previousValues` is a declared schema key with a real consumer: the renderer's
-`previousRecord` memo, which binds `previous` for field-rule CEL predicates and is the
-INSERT/UPDATE signal the read-only submit strip gates on (objectui#3484). That consumer
-reads it off `schema` and is unchanged. The defect was on the other channel —
-`SchemaRenderer` spreads every non-metadata top-level schema key as a React prop *in
-addition* to handing the node over as `schema`, so an edit-mode host (`ObjectForm`, which
-is what the `object-master-detail-form` header composes) delivered a second, top-level copy
-in `...props`. The renderer already consume-and-drops that whole family before its DOM
-spread — `objectName`, `onDirtyChange`, `defaultValues`, `fields`, `layout`, … —
-and `previousValues` was the one member missing from the list.
-
-Two things followed, on every edit-mode header render. React declined the prop and printed
-`React does not recognize the previousValues prop on a DOM element`, and — measured on
-React 19, and not recorded on the card — the persisted record was still stamped onto the
-element as `previousvalues="[object Object]"`. Consume-and-dropping the duplicate removes
-both.
-
-Scope is the runtime leak only. The declared key stays exactly as declared
-(`packages/types/src/form.ts`, `packages/types/src/zod/form.zod.ts` are untouched): it has
-a live consumer, so there is nothing here for the enforce-or-remove channel.
diff --git a/.changeset/6397-partial-schema-collapse-pin.md b/.changeset/6397-partial-schema-collapse-pin.md
deleted file mode 100644
index 244bf72b19..0000000000
--- a/.changeset/6397-partial-schema-collapse-pin.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-'@object-ui/types': patch
----
-
-`PartialSchema<T>` is pinned as collapsed, and its doc comment now says so
-(objectui#6397). Nothing about the type changes — the declaration is deliberately
-left exactly as written.
-
-The alias promises "all properties optional except the type" and does not deliver
-it. Every instantiation declares exactly ONE property, `type`, and carries a live
-`[key: string]: any`, so it accepts any key at `any`. Measured through the
-TypeScript checker against the emitted `index.d.ts` — the same instrument that
-produced objectui#6269's 61 -> 0 reading:
-
-    PartialSchema<ObjectGridSchema>  -> 1 declared property: type   (source: 61)
-    PartialSchema<ObjectFormSchema>  -> 1 declared property: type   (source: 67)
-    PartialSchema<ObjectViewSchema>  -> 1 declared property: type   (source: 42)
-    PartialSchema<ButtonSchema>      -> 1 declared property: type   (source: 27)
-
-`Omit<T, K>` is `Pick<T, Exclude<keyof T, K>>`, and `keyof T` on a type carrying a
-string index signature is `string | number` — the literal member names are
-absorbed. Every `T extends BaseSchema` inherits `BaseSchema`'s `[key: string]: any`
-(objectui#5155), so `Partial<Omit<T, 'type'>>` rebuilds a type holding the index
-signature and none of the named members. This is objectui#6151's collapse
-(heritage clause) and objectui#6269's (property position) in a third position: a
-generic mapped-type alias, which is why neither of their guards sees it — #6151's
-walks the `LayoutSchema` union, #6269's reads `ObjectViewSchema`'s two slots.
-
-**Why a pin and not a repair or a retirement.** Triage ruled on 2026-08-25 that
-retiring the alias is a removal of a published export of `@object-ui/types` — a
-breaking removal of published capability, which sits on the human floor — and that
-escalating it today would spend the maintainer's attention on a question
-objectui#5155 is expected to moot. Repair in place is unavailable: `T` is generic,
-so there is no literal key list to `Pick` the way #6269 could for its two concrete
-schemas, and every generic re-spelling collapses for the same `keyof T` reason.
-Once #5155 removes the root index signature, the alias starts working as written
-with no edit at all. What this ships is the removal of the one impermissible
-state — *declared, published, collapsed, and unpinned*.
-
-No runtime code, no type declaration and no accepted value changes; a consumer's
-`PartialSchema<X>` means exactly what it meant before. Declared `patch` rather
-than as a no-release so the doc-comment warning actually reaches the published
-`.d.ts` a consumer reads — that warning is the deliverable half of the card.
diff --git a/.changeset/6400-workflow-version-anchor.md b/.changeset/6400-workflow-version-anchor.md
deleted file mode 100644
index 05085edcaa..0000000000
--- a/.changeset/6400-workflow-version-anchor.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
----
-
-Test-only (objectui#6400): the version-claim ledger's `Node 22.x` entries no
-longer restate a hand-written count of `.github/workflows`, they are asserted
-against it.
-
-`scripts/__tests__/doc-version-claims.test.ts` gains a `workflowVersionKey`
-field on `KNOWN_CLAIMS` — the objectui#6400 counterpart to `skeletonDep`. It
-names the GitHub-Actions key (`node-version`) whose declarations across
-`.github/workflows` are a claim's anchor, and a new
-`describe('doc version claims - the workflow-version assertion')` reads those
-declarations on every run and demands the page state their major.
-
-The entry that motivated it was `anchored` and both halves of its reason had
-gone false: it named "the 14 `node-version: 22.x` declarations" against a tree
-holding 28 across 23 files, one of which is spelled `'22'` rather than `'22.x'`,
-and it credited `ci-cd-pipeline-doc.test.ts` with pinning the line when that
-file contains no `node-version` and no `22` at all. The claim itself stayed true
-throughout — what rotted is the sentence a reviewer re-measures it by, which is
-the entire load an `anchored` entry without a machine-checked field carries.
-
-Three entries carry the new field (`ci-cd-pipeline.md`, `building-crud-app.md`,
-`quick-start.md` — all three counts were stale), and none of their reasons
-states a count any more. The comparison is on the **major**, not the spelling,
-so the one lane declaring `'22'` is inside the anchor rather than a blind spot;
-a value the parser cannot read is reported rather than skipped, and the line
-parser is cross-checked against a counter that knows only the key.
-
-No package source changed and nothing is published by this.
diff --git a/.changeset/6405-fields-shared-stylesheet-builder.md b/.changeset/6405-fields-shared-stylesheet-builder.md
deleted file mode 100644
index 8ae7c7db09..0000000000
--- a/.changeset/6405-fields-shared-stylesheet-builder.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
----
-
-Build-tooling consolidation with no published bytes changed:
-`packages/fields/scripts/build-css.mjs` no longer carries its own copy of the
-components-sheet subtraction and now runs the shared
-`scripts/build-plugin-stylesheet.mjs` builder that `@object-ui/plugin-grid` and
-`@object-ui/plugin-kanban` already use (objectui#4929). One implementation of
-the subtraction now exists, so a fix to it reaches every package that ships a
-supplement stylesheet instead of only the one it was applied to.
-
-Declared as **no release** deliberately. `@object-ui/fields` ships
-`dist/index.css` to consumers, so the acceptance gate for this change was byte
-identity of that artifact, not equivalent-looking code — and it holds: the
-emitted sheet is `git hash-object f9cd6504a9e3a9603836230aea27c5a3a7e4e431`,
-22761 bytes, `167 rules kept (163 classes)`, both before and after the rewrite,
-and now from any working directory. Nothing a consumer installs changes, so
-there is no behaviour to release; bumping the fixed group of packages for a
-build script that emits identical bytes would put a version in the changelog
-that describes nothing.
-
-Fields keeps what is specific to it — its `MUST_SURVIVE` sentinels, its
-`CLASS_CEILING` of 600 and its stylesheet banner, the last through a documented
-`build({ header })` hook added to the shared module rather than a retained
-second copy of the builder.
diff --git a/.changeset/6409-keyed-version-recogniser.md b/.changeset/6409-keyed-version-recogniser.md
deleted file mode 100644
index 9961167d95..0000000000
--- a/.changeset/6409-keyed-version-recogniser.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
----
-
-The doc version-literal ledger can now see a version written behind a
-`<toolchain>-version:` key — `node-version: 20`, the shape every workflow example in
-these docs uses (objectui#6409). Test-only: `scripts/__tests__/doc-version-claims.test.ts`
-gains a second recogniser for that shape, plus the permanent fixture that rebuilds the
-pre-fix recogniser and asserts it fails on the same line the new one matches. No
-published package source changes.
diff --git a/.changeset/6412-packaged-actions-activation.md b/.changeset/6412-packaged-actions-activation.md
deleted file mode 100644
index cf50e3c65b..0000000000
--- a/.changeset/6412-packaged-actions-activation.md
+++ /dev/null
@@ -1,56 +0,0 @@
----
-'@object-ui/app-shell': minor
-'@object-ui/i18n': minor
----
-
-Setup › **Packaged automation** gains a packaged **actions** section beside its flows one —
-the surface half of ADR-0126 §8 item 2 (objectui#6412; the engine, ledger and both dispatch
-doors landed in objectstack#12348). The maintainer's pull, verbatim and untranslated:
-「动作 可能是需要开关的，因为有的 action 我不想启用。」
-
-Per packaged action the section does exactly **one** thing: **on/off for this scope**. That
-is all the `sys_metadata_activation` ledger knows about an action, and the section claims
-nothing more.
-
-- **State** comes from the ledger's `metadata_type: 'action'` rows, read through the generic
-  data API list the object itself sanctions for exactly this
-  (`apiMethods: ['get', 'list']` — *"Reads stay open so operability surfaces can answer
-  'what is disabled here?'"*). **Absence of a row means active**, so a stock boot shows
-  everything armed.
-- **Discovery** mirrors the runtime's own `collectActionDeclarations`: object-embedded
-  `actions[]` from `GET /meta/object` **plus** standalone items from `GET /meta/action`, with
-  the object-embedded declaration winning a `<object>:<action>` key clash. Listing only the
-  first source would leave an administrator with no off-switch for a packaged standalone
-  action.
-- **Flips** invoke the L6 write door `POST /actions/_activation/:object/:action` with exactly
-  the one key its body declares (`{ enabled }`); `global` is the object segment for an
-  object-less action, the same spelling both dispatch doors take.
-
-**⛔ No clone for actions.** The flows section keeps its own (§7.1); amendment ruling 3
-charters the *switch* for actions and nothing else, and §8 keeps the clone half pre-chartered
-until real pull appears. A clone control here would advertise machinery that does not exist —
-which is also why the server's §5 refusal for actions recommends the platform operator and an
-ordinary sibling action where the flow refusal recommends a clone.
-
-**⛔ No drift or ancestry surface** (§9): no "customized" badge, no diff-vs-base, no
-base-moved notice. The platform tracks no such lineage, so a surface showing it would be
-showing something it had to invent. The absence is pinned against a response that smuggles
-`clonedFrom` / `baseVersion` in, so it is enforced at the renderer and not merely by the wire.
-
-Server refusals reach the operator **verbatim** — no client-side softening, no retry loop.
-Three shapes are reachable in tests, each transcribed character-for-character from the
-runtime's own message builders: the §5 posture gate (403 `PERMISSION_DENIED`, naming the
-posture *and* the sanctioned path), the ambiguous-name refusal (409 `RESOURCE_CONFLICT`,
-naming the objects a machine name collides across — a list nothing on the client could
-reconstruct) and the no-ledger outage (503 `SERVICE_UNAVAILABLE`).
-
-One further refusal is the section's own and it points the same way: a `hasMore` on the
-ledger read is treated as a **load failure** rather than rendered. A dropped row reads as
-"active", so a partial ledger would show a switched-off action as armed — the one direction
-this section must not fail in.
-
-The flows section is unchanged in behaviour. It gains a heading beside the new one, and the
-page subtitle now says "Flows and actions" — that string moved in all ten packs together.
-Nine new `packagedAutomation.*` keys land in `en` **and in all nine other packs** as real
-translations; the two toggle-failure keys are artifact-neutral by wording and are reused
-rather than duplicated.
diff --git a/.changeset/6416-plugin-report-namespace.md b/.changeset/6416-plugin-report-namespace.md
deleted file mode 100644
index 41d0b87d0c..0000000000
--- a/.changeset/6416-plugin-report-namespace.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-'@object-ui/plugin-report': patch
-'@object-ui/cli': patch
----
-
-`@object-ui/plugin-report` now registers its three components under namespace
-**`plugin-report`**, the spelling its consumers already declare (objectui#6416).
-
-It used to register `report`, `spec-report` and `report-viewer` under namespace
-`report`, while `apps/console` declared the lazy stubs for the same three short
-names under `plugin-report` and the CLI's known-type whitelist shipped the
-`plugin-report:*` spellings as renderable. Two things followed from the
-disagreement:
-
-- **`plugin-report:report`, `plugin-report:report-viewer` and
-  `plugin-report:spec-report` could never be satisfied.** `Registry.register`
-  clears the lazy stub for the type IT registers, and that type was
-  `report:report`, so those three stubs were never cleared and no component was
-  ever stored under them: `get('report', 'plugin-report')` returned `undefined`
-  and `hasLazy('report', 'plugin-report')` stayed `true` forever. A schema
-  authored with any of the three whitelisted keys resolved to nothing — the
-  gate handed authors a green light for a key the runtime could not satisfy.
-- **The bare `report` key was claimed twice under two different namespaces.**
-  `Registry.register` and `Registry.registerLazy` share the
-  `meta?.namespace && !meta?.skipFallback` branch, so what bare `report`
-  *declared* depended on whether the plugin chunk had loaded yet — the
-  objectui#6353 shape.
-
-**No authored metadata changes.** The direction was chosen by measurement:
-nothing in this repository, and nothing in the sibling `objectstack` checkout,
-authors a `report:*` spelling (0 hits), while the bare spellings are authored in
-48 places. `type: 'report'`, `type: 'spec-report'` and `type: 'report-viewer'`
-resolve exactly as before; the three unreachable `report:*` keys are retired and
-the three `plugin-report:*` keys now name real components for the first time.
-
-`packages/cli/src/utils/known-schema-types.ts` is regenerated from the
-registrations, dropping `report:report`, `report:report-viewer` and
-`report:spec-report`.
-
-Two pins are the half that outlives the fix:
-`packages/plugin-report/src/__tests__/report-bare-key-ownership.test.ts` replays
-this package's real declared metadata and a console-shaped lazy stub into a
-fresh `Registry` in **both** registration orders, checking the bare key's
-declared namespace after every step, so order- and phase-independence are
-properties under test rather than properties of the file the test imports.
-`scripts/__tests__/report-namespace-agreement-6416.test.ts` re-derives both
-sites from source and fails if the plugin, the console stubs and the generated
-whitelist ever disagree again.
diff --git a/.changeset/6419-objectview-expand-gate.md b/.changeset/6419-objectview-expand-gate.md
deleted file mode 100644
index 8b53c9e1a0..0000000000
--- a/.changeset/6419-objectview-expand-gate.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-'@object-ui/plugin-view': patch
----
-
-`ObjectView`'s non-grid fetch now carries `$expand` (objectui#6419). The effect built its
-expand set from `objectSchemaRef.current` — a ref assigned in the render body, deliberately
-kept out of the effect's dependency list so the effect would run exactly once per mount. On
-that one run the ref was still `null`, so `buildExpandFields` saw no fields and the query
-went out as `{ $top: 100 }` with no `$expand` at all; because the effect never re-ran on the
-schema's arrival, it never went out with one either.
-
-`ObjectView` hands the rows it fetches to the child view as `data={data}`, which suppresses
-that child's own fetch. So every lookup / master_detail / user / tree field in the six
-non-grid views it hosts — kanban, calendar, gallery, timeline, gantt, map — rendered from
-raw foreign-key ids: blank on the kanban (its `resolveDisplay` suppresses opaque ids) and
-potentially the raw id on the other five.
-
-The object schema and the fact that its read has SETTLED are now one piece of state, keyed
-by object name, and the record query waits on it — the shape `ObjectKanban` adopted in
-objectui#6271. The gate is on the read having settled, **not** on a truthy schema: a view
-whose adapter exposes no `getObjectSchema`, or whose read threw, still queries (unexpanded)
-rather than waiting forever, and switching objects closes the gate in the same commit rather
-than sending the previous object's expand set.
-
-The trade was measured on this effect rather than inherited, because it has five more
-dependencies than the board's. With an instrumented adapter (schema and `find` both 30ms)
-across four host regimes: before, one query with no `$expand` and one raw delivery to the
-child; with `objectSchema` merely added to the dependency list, two queries and two
-deliveries — `raw` then `expanded`, a visible two-step paint, because here the raw rows
-settle into state *before* the re-run's cleanup rather than being discarded as they were on
-the board; gated, one query carrying `$expand` the first time and a single expanded
-delivery, with correct rows landing at the same wall clock as the dependency version.
diff --git a/.changeset/6421-concurrent-update-code-optional.md b/.changeset/6421-concurrent-update-code-optional.md
deleted file mode 100644
index bc5118a490..0000000000
--- a/.changeset/6421-concurrent-update-code-optional.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-'@object-ui/plugin-detail': minor
----
-
-`isConcurrentUpdateError` no longer promises a `code` its runtime check
-knowingly accepts values without.
-
-The exported predicate matches on two limbs — `code === 'CONCURRENT_UPDATE'`
-(the wire shape) **or** `name === 'ConcurrentUpdateError'` (the deliberate
-cross-realm discriminator, for a host that bundles the adapter twice so
-`instanceof` fails). Its narrowed type declared `code: 'CONCURRENT_UPDATE'` as
-a **required** literal, so for exactly the case the second limb exists to serve
-the predicate handed the caller a property the value does not have. `code` is
-now declared optional (`code?: 'CONCURRENT_UPDATE'`), stating only what both
-limbs guarantee.
-
-**Type-level only; zero runtime change.** The two-limb check is byte-identical
-— it is deliberate and documented, and the diff touches nothing but the return
-type and the comment above it. There was no runtime symptom to fix: the only
-consumer (`InlineEditSaveBar`'s conflict builder) reads just the optional
-`currentVersion` / `currentRecord` fields.
-
-**Breaking for TypeScript consumers that read the narrowed `code`.** After
-narrowing, `err.code` is now `'CONCURRENT_UPDATE' | undefined` instead of
-`'CONCURRENT_UPDATE'`, so code that assigned it to a non-optional `string` will
-newly fail to compile. That failure is the point: on a name-only error the
-value was already `undefined` at runtime, and the old declaration was the
-reason the compiler could not say so. Guard the read (`err.code ===
-'CONCURRENT_UPDATE'` still narrows fine) or branch on the predicate itself
-rather than on the field.
-
-Pinned by `ConcurrentUpdateDialog.narrowedCode-6421.test.tsx`, which asserts
-the invariant by assignability — the value the runtime accepts through the
-`name` limb must be assignable to the type the predicate returns — alongside
-runtime coverage of both limbs, which `plugin-detail` had none of.
diff --git a/.changeset/6425-objectdatatable-column-holds.md b/.changeset/6425-objectdatatable-column-holds.md
deleted file mode 100644
index d222901e91..0000000000
--- a/.changeset/6425-objectdatatable-column-holds.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
----
-
-No published behaviour changes, and nothing declared or retired.
-
-`ObjectDataTable.enrich()` read six field-meta overrides off the AUTHORED column — three
-through `(col as any)`, two more through the column bag's `[key: string]: any`, which
-answers `any` just as loudly without the tell (objectui#6425). Those reads now go through
-a local `AuthoredColumnOverrides` keyhole: every honoured key carries a written verdict
-and the card that owns it, and every other `FieldMeta` member is refused by a DERIVED
-`?: never` band, so a seventh one has to be adjudicated instead of admitted by silence.
-
-Type-only at the seam plus a new test file. `@object-ui/types`' `TableColumn` and its zod
-mirror are untouched: whether `format` / `options` / `referenceTo` / `currency` /
-`decimals` get declared on the published type or retired stays objectui#6425's open
-ruling, and this change is the per-key evidence that ruling needs, not the ruling.
diff --git a/.changeset/6426-dashboard-test-header-compiled.md b/.changeset/6426-dashboard-test-header-compiled.md
deleted file mode 100644
index 2e6e50ba75..0000000000
--- a/.changeset/6426-dashboard-test-header-compiled.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
----
-
-Comment-only fix: two headers in `@object-ui/plugin-dashboard` still said this
-package's tests are "compiled by nothing", a debt that has since been paid. The
-paragraphs did not merely describe the old state — they prescribed against
-writing a compile-time pin in this package, and nearly misrouted the legitimate
-one that objectui#6373 landed a few files away.
-
-- `src/__tests__/MetricWidget.domPassthrough.test.tsx` — the header claimed
-  `tsconfig.json` excludes the tests, that the package is "the sole remaining
-  `TEST_DEBT` entry", and that a `@ts-expect-error` written there "would be
-  especially dishonest".
-- `src/domPassthroughPins.ts` — the counterpart half of the same contract
-  carried the same premise (plus a stale "6 errors, objectui#4118" count), so
-  fixing only the test file would have left the two halves disagreeing.
-
-Both now state today's arrangement and name the config that does it:
-`tsconfig.test.json` type-checks this package's tests, chained from the
-package's `type-check` script (`tsc --noEmit && tsc -p tsconfig.test.json`).
-The `src/` placement of the pins is kept and re-framed as a preference rather
-than a constraint — they still belong next to the contract and still emit zero
-runtime bytes, but a pin in a test file is checked now too.
-
-Measured on this tree: `tsconfig.test.json --listFiles` includes 81 of this
-package's test files (both edited-adjacent files among them);
-`node scripts/check-type-check-coverage.mjs` reports `test type-check coverage:
-41/41 packages compile their tests, 0 declared debt`; and an `@ts-expect-error`
-injected into the test file guarding nothing is reported as
-`error TS2578: Unused '@ts-expect-error' directive`.
-
-No behaviour change, no public surface change.
diff --git a/.changeset/6431-param-dialog-close-parity.md b/.changeset/6431-param-dialog-close-parity.md
deleted file mode 100644
index 071f1fc0ef..0000000000
--- a/.changeset/6431-param-dialog-close-parity.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-`app-shell`'s two action runtimes now reset `ActionParamDialog` the same way when it closes
-(objectui#6431). `useConsoleActionRuntime` closed with `setParamState({ open: false, params: [] })` —
-replacing the whole state object, emptying `params` and dropping `title`, `description` and
-`resolve` — while `RecordDetailView`, which mounts a second runtime into the same dialog,
-closed with `setParamState(s => ({ ...s, open: false }))`. The console runtime moves onto the
-field-preserving shape.
-
-The user-visible effect is in the fade-out. `DialogContent` carries
-`duration-200 data-[state=closed]:animate-out`, so Radix keeps the content mounted through
-its exit animation and the dialog goes on rendering off `state` for the whole ~200ms. Under
-the blanking shape a params form the user had just filled in re-titled itself from the
-action's own label to the generic "Action parameters", swapped the action's description for
-the generic one, and dropped every param row — an empty, generically-labelled box fading out
-where a form had been. The confirm pair converged on the same shape for the same reason in
-objectui#6034; this is that ruling re-measured on this dialog rather than inherited, because
-`ParamDialogState` carries a form rather than display text and "blank it on close" could have
-been deliberate here.
-
-It was not, and nothing else changes for the user. The values a user types are not in
-`paramState` at all — they live in `ActionParamDialog`'s own `values` state, which its
-`useEffect` reseeds from the param defaults on every `state.open` false→true edge, so a
-reopened dialog starts blank under either reset shape. The retained `resolve` is inert: the
-dialog settles the promise before it asks for the close, and the open path replaces the whole
-state object.
diff --git a/.changeset/6442-catalog-blocks-claimant-list.md b/.changeset/6442-catalog-blocks-claimant-list.md
deleted file mode 100644
index 724ec3a477..0000000000
--- a/.changeset/6442-catalog-blocks-claimant-list.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
----
-
-Comment-only truthfulness fix in the docs-site gallery host,
-`apps/site/app/components/registerCatalogBlocks.ts`. Its `IMPORT ORDER IS CONTRACT`
-note justified the import order with a bare-keyword claimant list naming two packages
-that do not claim the key: it said bare `chart` is claimed by `plugin-charts`,
-`plugin-dashboard` and `plugin-report`. Re-derived with the repo's own
-`deriveRegistryKeys` (`scripts/check-doc-component-types.mjs`), bare `chart` has one
-package claimant, `plugin-charts` — `plugin-dashboard` registers `dashboard`,
-`dashboard-grid`, `metric`, `metric-card`, `object-data-table`, `object-metric`,
-`object-pivot` and `pivot`, `plugin-report` registers `report`, `spec-report` and
-`report-viewer`, and neither registers `chart` at all. The two `apps/console` sites
-that also hold the key are `registerLazy` stubs whose loader is `@object-ui/plugin-charts`
-itself, which `Registry.register` drops unconditionally once the real component arrives,
-so they are placeholders for that package rather than competing claimants of the keyword.
-
-The same re-derivation extends the correction to the `calendar` half the issue had not
-checked in depth: bare `calendar` likewise has one package claimant, `plugin-calendar`,
-because `@object-ui/components` registers the date-picker primitive as `ui:calendar`
-with `skipFallback: true` precisely so it does not take the bare keyword. The note
-therefore no longer opens by asserting that several packages register the same bare
-keyword — measured across the workspace, no bare key is claimed by two of the thirteen
-packages this file imports. The mechanism (last registration of a bare keyword wins) and
-the reason the order stays fixed are kept. No code, no imports and no assertions changed,
-and no published behaviour changes.
diff --git a/.changeset/6443-nav-visible-fault-diagnostic.md b/.changeset/6443-nav-visible-fault-diagnostic.md
deleted file mode 100644
index 516875ab35..0000000000
--- a/.changeset/6443-nav-visible-fault-diagnostic.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-A nav / area / field `visible` predicate that FAULTS now says so, in both builds, once per
-distinct predicate source (objectui#6443). Observability only — no verdict moves.
-
-`ExpressionProvider.evaluateVisibility` is the gate behind a navigation item's `visible`,
-an area's derived visibility, and the field list `RecordFormPage` renders. It is fail-open:
-a predicate that cannot be evaluated returns `true`, so a menu entry whose role gate has
-stopped working renders **for everyone — including the role it was written to exclude** and
-looks exactly like an entry the author meant to show.
-
-That fault was swallowed one layer down. `evaluateCondition` is fail-soft: it answers an
-unevaluable predicate with `true` from its own `catch` and does not throw, so this site's
-`try/catch` never saw a predicate fault at all. Measured per dialect at this site before the
-fix — the bare-string dialect, the one a live gate was measured breaking on, printed
-**nothing at all**:
-
-| dialect | console at this site, before | after |
-|---|---|---|
-| bare string | nothing | one named line |
-| `{ dialect: 'cel' }` envelope | one generic line | one named line (the generic one is *replaced*, not added to) |
-| `${…}` template | one generic line **per evaluation** | one named line, deduped |
-
-The fix wires `EvaluationOptions.onFault` (the seam objectui#6038 landed) to
-`reportUnresolvableVisibilityPredicate`, exported from `@object-ui/react` — the same
-reporter, message, severity, dedupe `Set` and rate limit the node gate and `page:tabs`
-already use, so one authored predicate is entitled to one line rather than one line per
-package. It costs no extra engine call: the evaluator hands back the reason at the point it
-already knows the predicate faulted, with no `throwOnError` double evaluation.
-
-A nav item is not a schema node, so the reporter's `type` slot — which, with the gate key
-and the predicate source, is the dedupe key — is the constant `app-shell:visible`. The rate
-limit is therefore **one line per distinct authored predicate source**, not one per menu
-entry: a broken role gate copy-pasted across eight entries is one authoring mistake, in one
-string, fixed in one edit.
-
-**Fail-open is unchanged.** The item still renders for everyone on a fault. Flipping that to
-fail-closed is a permission-boundary change, not a diagnostic, and is not this change's to
-make; the change makes the silence stop and nothing else.
diff --git a/.changeset/6444-evaluator-fault-warn-dedupe.md b/.changeset/6444-evaluator-fault-warn-dedupe.md
deleted file mode 100644
index afdf051590..0000000000
--- a/.changeset/6444-evaluator-fault-warn-dedupe.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-'@object-ui/core': patch
----
-
-`ExpressionEvaluator.evaluate` now reports a faulting `${…}` at most **once per authored
-source** instead of once per evaluation (objectui#6444). It is the hottest of the three
-predicate paths in this area — `SchemaRenderer` calls it for every `properties.*` value,
-every `props.*` value and `content`, for every node, on every render — so a single broken
-`${…}` prop in a 200-row list wrote 200 console lines per render, and 200 more on the next
-one. Measured on the built evaluator before the fix: three identical faulting
-`evaluateCondition` calls produced 3 lines where the `{ dialect: 'cel' }` envelope produced
-1; the 200-row list produced 200. After: 1 in every case.
-
-This is the one-per-source rate limit both sibling reporters already carry
-(`warnPredicateFailure` in `fieldRules.ts`, `visibilityDiagnostic.ts` in `@object-ui/react`),
-not a third mechanism. The dedupe key is the predicate's **authoring** identity — the fault
-site plus the source text, never the scope it ran against — which is both the siblings'
-precedent and the defect itself: the 200-row flood is one authored source evaluated against
-200 distinct scopes, so a scope-sensitive key would emit all 200 lines again.
-
-Nothing else moves. The two message texts are unchanged, a distinct broken source still gets
-its own line, `EvaluationOptions.onFault` still fires on every fault (objectui#6038's passback
-contract, so a caller doing its own warn-once bookkeeping keeps control of it), `throwOnError`
-still throws on every evaluation, and no symbol is added to the published surface.
diff --git a/.changeset/6445-disabled-gate-fault-diagnostic.md b/.changeset/6445-disabled-gate-fault-diagnostic.md
deleted file mode 100644
index ac2eff72dd..0000000000
--- a/.changeset/6445-disabled-gate-fault-diagnostic.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-'@object-ui/react': minor
----
-
-A `disabled` / `disabledOn` predicate that cannot be evaluated is now reported on the console, in development **and** in production — and the message says what this gate's fail-soft default actually did.
-
-`SchemaRenderer` routes six visibility legs (`visibleWhen`, `visible`, `visibleOn`, `visibility`, `hidden`, `hiddenOn`) through one reporter, and called `evaluateCondition` **bare** on the two enablement legs — the only uninstrumented predicate pair in the file. A faulting `disabled` predicate had therefore never been reported in any build, in any dialect that does not report on its own.
-
-It is also the pair whose fail-soft answer **bites**. `evaluateCondition` answers an unevaluable predicate with `true`; on the negated visibility legs that means SHOWN, here it means GREYED OUT. So the user got a control they could see and could not use, and the author got nothing to grep for.
-
-- **Wiring only, one engine call.** Both legs pass `EvaluationOptions.onFault` (objectui#6038's seam), which hands back the fault the evaluator has already caught. No `throwOnError`, no second evaluation, no `__DEV__` split — dev and production print identical bytes.
-- **No verdict moves.** The fail-soft `true` is preserved deliberately: a faulting `disabled` predicate still disables, exactly as before. Flipping that is a shipped-behaviour change and is not part of this.
-- **Its own copy, not the visibility reporter's.** The shipped line says the safe default meant the gate "did NOT bite", which is written about a gate that shows the node. This gate's line says the opposite, because the opposite is true: `[ObjectUI] An enablement predicate could not be evaluated`, then the node, the key, the source, the engine's reason, and that the node renders disabled — on screen, greyed out — with nothing else on screen to say a predicate failed. One reporter, one dedupe, one severity; a second message.
-- **Rate-limited exactly as the visibility gate is**, per `(node type, key, predicate source)`: two hundred rows of one broken predicate print one line, a second distinct source still prints, and the same source authored on `disabled` and on `visibleWhen` prints two — the gates cannot silence each other.
diff --git a/.changeset/6453-calendar-expand-gate.md b/.changeset/6453-calendar-expand-gate.md
deleted file mode 100644
index 4400c0ec3a..0000000000
--- a/.changeset/6453-calendar-expand-gate.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-'@object-ui/plugin-calendar': patch
----
-
-A standalone `object-calendar` bound to an object now queries WITH its `$expand`, so
-lookup / master_detail / user / tree fields render the related record instead of a raw
-foreign-key id (objectui#6453).
-
-`ObjectCalendar`'s fetch effect built its expand set from a ref assigned in the render body
-(`objectSchemaRef.current = objectSchema`) and left `objectSchema` out of its dependency
-list. That bought the effect exactly one run per mount and paid for it with the expansion,
-permanently: on that one run the ref was still `null`, `buildExpandFields` saw no fields,
-the query went out with no `$expand` at all, and nothing re-ran the effect when the schema
-landed. Only the standalone calendar reached this path — one hosted by `ObjectView` or
-`ListView` receives its rows as `data`, which objectui#6419 already covers.
-
-The ref is replaced by a settled-and-keyed resolution (`{ key, def } | null`) that GATES the
-record query, the third member of the family after objectui#6271 (`ObjectKanban`) and
-objectui#6419 (`ObjectView`). Measured on this component rather than inherited: gated, the
-calendar issues one query carrying `$expand` in every latency profile; the alternative of
-adding `objectSchema` to the dependency list issued two, and when the schema read was the
-slower of the two it painted raw ids, reverted to the "Loading calendar..." placeholder,
-then swapped — a three-step paint the correct rows do not arrive any later than.
-
-The gate is on the schema read having SETTLED, never on a truthy schema: an adapter that
-exposes no `getObjectSchema`, and a read that throws, both settle with nothing and the
-calendar still queries (unexpanded) rather than waiting forever. An inline `value` data set
-is deliberately not gated — it issues no metadata read, so there would be no resolution to
-wait for.
diff --git a/.changeset/6455-listview-sort-persist-leak.md b/.changeset/6455-listview-sort-persist-leak.md
deleted file mode 100644
index c082fcf6a1..0000000000
--- a/.changeset/6455-listview-sort-persist-leak.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-'@object-ui/plugin-list': patch
----
-
-`ListView`'s toolbar sort picker no longer persists a sort the platform refuses to order by.
-
-The picker keeps a platform-refused field listed while the CURRENT sort names it
-(#6108). That exception is deliberate and stays: it is the only way a user can
-REMOVE a sort the server answers `400 INVALID_SORT` for — withholding the option
-unconditionally renders a blank row nobody can delete, and drops the sort silently
-on the next edit.
-
-What was wrong is that the picker rendered and emitted from the same array. Editing
-anything ELSE in that popover — adding a second sort key, resetting to the view's
-default — re-emitted the whole array with the refused entry still in it, and the
-host's `onSortChange` turned that into `persistViewPatch({ sort })`: a
-personalization PUT storing a refused column, written by a user who never touched
-that row. A view stored before the sortability signal existed therefore kept
-re-persisting its refused `$orderby` indefinitely.
-
-Every `onSortChange` this component emits — the builder, the column-header sort and
-"reset to default" — now crosses one boundary that drops what the served projection
-refuses, while `currentSort` keeps the array whole. So what the picker LISTS and
-what it PERSISTS are separate: the refused entry stays visible and removable,
-removing it persists the removal, and no write carries it. This is the separation
-#5729 already made at the grid seam (`ObjectGrid`'s `manualSort` /
-`manualOnSortChange` pair); the picker was the second door onto the same stored
-view state.
-
-Only under a served sortability projection (objectstack#10235 ruling A). `undefined`
-means NO SIGNAL SERVED — an older deployment, an inline/mock data source — not
-"nothing is sortable", and that branch is byte-identical in behaviour to before.
diff --git a/.changeset/6460-objectview-fetch-view-identity.md b/.changeset/6460-objectview-fetch-view-identity.md
deleted file mode 100644
index 0b919f24c1..0000000000
--- a/.changeset/6460-objectview-fetch-view-identity.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-'@object-ui/plugin-view': patch
----
-
-`ObjectView`'s non-grid fetch no longer re-queries once per parent render when the host
-passes an inline `views` array (objectui#6460).
-
-The effect that fetches rows for the six non-grid view types (kanban, calendar, gallery,
-timeline, gantt, map) listed `activeView` — an **element of the `views` prop array** — among
-its dependencies. A host writing `views={[{ id: 'cal', type: 'calendar', label: … }]}`, which
-is how this component's own docs write it, produces a fresh element object on every one of
-its own renders, so the dependency changed identity every render and a new `find()` went out
-each time. Measured with an instrumented adapter and three parent re-renders: **4 queries
-where a hoisted array gives 1**. Because `ObjectView` hands its rows to the child view as
-`data={data}`, each extra query also re-delivered a fresh row array downstream — the
-"duplicate events in child views like the calendar" hazard, from the re-run direction.
-
-The effect now depends on the **values it reads** — the active view's `filter` and `sort`,
-plus its `id` — held at a steady reference while they are structurally unchanged, instead of
-on the view object's identity. Asking hosts to hoist the array was considered and rejected:
-that is a contract change on every caller of a published component, and it leaves the defect
-live for every host that does not comply.
-
-Nothing about precedence moves: a named `listViews` config's `filter`/`sort` still outrank
-the view's, which still outrank `table.filter`/`table.sort` and their deprecated aliases.
-Changing a view's filter, changing its sort, and switching the active view all still
-re-fetch. The comparison never serializes, so it stays correct for filter and sort values
-that have no faithful stringification — a `Date`, a function, a `Map`, `NaN`, or plain
-key-order instability — and every case it cannot model resolves to "changed", which costs a
-redundant query rather than withholding a needed one.
diff --git a/.changeset/6464-recall-submitter-gate.md b/.changeset/6464-recall-submitter-gate.md
deleted file mode 100644
index 541e31c934..0000000000
--- a/.changeset/6464-recall-submitter-gate.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-'@object-ui/react': minor
-'@object-ui/plugin-detail': patch
-'@object-ui/app-shell': patch
----
-
-The record page's approval band offers its **Recall** button to the approval's submitter
-only (objectui#6464).
-
-Field report on `@objectstack/*@17.2.0`: user A submits a record into a 4-level approval;
-user B — not the submitter, read access, not an admin — opens the record and the band still
-lights a clickable recall button. The click cannot succeed. The recall endpoint authorizes
-on submitter identity and refuses everyone else, so the only outcome available to that
-button was a failure toast. Record state was never at risk; this was purely a
-writability-feedback mismatch, the same family as objectui#3794.
-
-The button's only gate was `dataSource.cancelPendingApproval` — "can this adapter recall at
-all" — which is a question about the DataSource, not about the viewer. Identity now joins
-it, threaded the way every other signal on that band already travels: the HOST resolves it
-and passes it through `InlineEditProvider`, so the renderer stays DataSource-agnostic and
-never re-derives who submitted what.
-
-- `@object-ui/react` — `InlineEditProvider` accepts `approvalIsSubmitter`, surfaced on
-  `InlineEditContextValue`. Additive and optional; no existing prop changes.
-- `@object-ui/plugin-detail` — the band's recall button is withdrawn when that signal is a
-  resolved `false`.
-- `@object-ui/app-shell` — `RecordDetailView` resolves the verdict from its existing
-  approvals read and threads it.
-
-**The signal is tri-state, and the third state is the load-bearing one.** `true` offers
-recall, `false` withdraws it, and **`undefined` — a host that resolves no approval identity
-— renders exactly as it did before this release.** Omission preserving prior behaviour
-mirrors how `approvalPending` falls back to `locked`. Defaulting the unknown case to "hide"
-would have traded a cosmetic defect for a functional loss: every host whose band runs off
-the record's `approval_status` mirror alone would silently lose its submitter's only way to
-unlock their own record.
-
-**Withdrawn rather than disabled-with-reason.** The card offered either. For a
-non-submitter this control is never actionable on any pending record, so a permanently
-disabled button is standing clutter rather than a lesson; and the two sibling submitter
-levers already hide — the approvals panel's Remind button, and the declared
-`approval_recall` action's `visible` predicate. The band, its quorum tally and the
-approvals timeline still tell a non-submitter exactly what state the record is in. Only the
-lever they can never pull is gone.
-
-**This changes no permission.** Nothing about what the server allows moves, `canEdit` and
-the approval lock are untouched, and nothing downstream reads `approvalIsSubmitter` as an
-authorization verdict — the recall endpoint remains the sole authority, and it refused
-these callers before this change and refuses them after. There is deliberately **no admin
-carve-out** (the reporter ruled that case out, cf. objectstack#9464).
-
-The derivation itself is now one function, `isSubmitterOf` — server-resolved
-`viewer.is_submitter` first (framework#3310), an id comparison as the fallback for backends
-that predate it, joined with `??` so a server that resolved `false` is believed rather than
-re-litigated client-side. The approvals panel's Remind gate, which already carried that
-expression inline and whose behaviour is unchanged, now reads the same answer: two copies
-would have been two definitions of who submitted.
-
-The **untranslated refusal text** the reporter also saw ("No pending approval request found
-for this record", concatenated after a localized prefix) is a separate defect and is not
-addressed here; it is tracked on objectstack#11993.
diff --git a/.changeset/6465-stale-typecheck-headers.md b/.changeset/6465-stale-typecheck-headers.md
deleted file mode 100644
index 755b985bf4..0000000000
--- a/.changeset/6465-stale-typecheck-headers.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
----
-
-Comment-only fix: eleven test headers across `@object-ui/app-shell` and
-`@object-ui/core` still described a type-checking arrangement that no longer
-exists. Two distinct stale claims, both now corrected:
-
-1. **"this package's tests are compiled by nothing."** Both packages graduated
-   in objectui#4040; each `type-check` script is now
-   `tsc --noEmit && tsc -p tsconfig.test.json`, and `TEST_DEBT` in
-   `scripts/check-type-check-coverage.mjs` is literally `{}`.
-2. **Present-tense citations of `tsconfig.typetests.json`,** of which zero exist
-   repo-wide (objectui#4291 retired the last of them). Several headers told the
-   reader that a listing in such a project is what makes their assertions
-   load-bearing — a file the reader cannot find.
-
-Both matter beyond tidiness because several of these headers *prescribe*: one
-said a `@ts-expect-error` here "would be read by no compiler", another that "a
-new type-assertion test file is unchecked until it is added to that include
-list". Both instruct the next author away from assertions that are in fact
-checked, and away from the config that checks them. That is the same shape
-objectui#6426 was filed and fixed for in `@object-ui/plugin-dashboard`.
-
-Where a header is now positive ("this file IS compiled"), the claim was
-confirmed for **that file**, not inferred from the package-level coverage
-reading: `tsc -p tsconfig.test.json --listFiles` lists all 8 edited app-shell
-files (of 4455) and all 4 edited core files (of 634), and both projects exit 0.
-Surviving mentions of `TEST_DEBT` and `tsconfig.typetests.json` in these files
-are deliberate, and are now past-tense — they record why the header used to say
-otherwise.
-
-No behaviour change, no public surface change, no assertion or directive
-touched.
diff --git a/.changeset/6469-gantt-block-precedence.md b/.changeset/6469-gantt-block-precedence.md
deleted file mode 100644
index ffb8feea59..0000000000
--- a/.changeset/6469-gantt-block-precedence.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-'@object-ui/plugin-gantt': minor
-'@object-ui/types': minor
----
-
-**plugin-gantt: the `gantt` block now outranks the flat top-level spelling, and
-the losing face's keys are named instead of dropped.**
-
-`getGanttConfig` checked the flattened top-level spelling first and returned
-early, so a node carrying both spellings rendered the flat one and every key
-inside an authored `gantt` block was discarded with **no diagnostic** — not even
-the `GanttConfigSchema.safeParse` warning, which sat behind that early return.
-
-`plugin-map` had the identical two-faces shape ruled the other way (maintainer
-ruling on objectui#5018, 2026-08-17, landed in PR #5156): the block wins, with a
-dev-mode warning naming the ignored top-level keys. objectui#6469 inherits that
-ruling, so the two sibling view plugins now answer the same question the same
-way.
-
-What changes:
-
-- A node carrying **both** spellings now renders the **`gantt` block's** values.
-  The block is taken **whole** — the flat keys are not merged into it.
-- In dev, `[ObjectGantt] … these top-level keys are IGNORED: …` names every
-  shadowed flat key, once per distinct shadowing.
-- Nothing else moves. A node with only the flat spelling, or only a block, is
-  read exactly as before.
-
-**Producer-safe:** `ObjectView` (`case 'gantt'`) and `ListView` (`case 'gantt'`)
-both flatten `options.gantt` onto top-level keys and emit **no** `gantt` key, so
-every gantt reached through either view layer still takes the flat branch, and
-the new warning cannot fire on that path. This is the same producer check the
-`plugin-map` flip pinned, re-run on today's `main`.
-
-This **supersedes** the precedence sentence in the objectui#6051 changeset
-(`.changeset/6051-gantt-flat-config-declared-keys.md`), which recorded the flat
-branch winning — accurate for that change, which deliberately did not touch
-precedence, and reversed by this one.
diff --git a/.changeset/6471-ganttconfigex-restatement-pin.md b/.changeset/6471-ganttconfigex-restatement-pin.md
deleted file mode 100644
index f919b860f2..0000000000
--- a/.changeset/6471-ganttconfigex-restatement-pin.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
----
-
-Pin every member `plugin-gantt`'s `GanttConfigEx` restates on top of `GanttConfig`
-against its twin, so two declarations of one key can no longer drift apart in silence
-(objectui#6471).
-
-**No release.** Type-only and package-private: no runtime code changes, and the published
-surface is untouched on both sides. `packages/types` has zero changed files, so
-`GanttConfig`'s member list in the built `dist/index.d.ts` is byte-for-byte what it was;
-the new `GanttConfigRestated` alias is exported from `ObjectGantt.tsx` for the pin to
-import but is not re-exported by the package entry, and `plugin-gantt/dist/index.d.ts`
-carries zero occurrences of it after a real build (positive control: `QuickFilterDef`,
-which *is* re-exported, appears there).
-
-`GanttConfigEx` is `GanttConfig & { … }` and the intersection's second half re-declares
-keys the first half already declares — nine of them arriving from the spec's
-`GanttConfigSchema`, which declares 19 keys as of rc.6. The restatements are deliberate:
-their JSDoc is the only prose in this repo describing what the renderer does with each
-key, and the spec emits no per-member documentation, so deleting the members deletes the
-documentation. What was missing was any assertion that the two declarations still agree.
-
-The local half is now a named type, and that is the whole mechanism rather than a tidying
-step. An assertion phrased over `GanttConfigEx` cannot measure anything: `GanttConfigEx[K]`
-is already `GanttConfig[K] & local[K]`, so it is assignable to `GanttConfig[K]` by
-construction and stays green no matter how far the two declarations drift. Naming the
-local half gives the pin two independent operands.
-
-Measured, not assumed: **all twelve** restated members are mutually assignable with their
-`GanttConfig` twin today — including `quickFilters` and `timeSegments`, which the card and
-its triage both describe as load-bearing NARROWINGS. On current `main` they narrow
-nothing. objectui#6051/#6472 lifted `timeSegments` onto `GanttConfig` in the shape that is
-structurally `ShiftSegmentsConfig`, and rc.6's `GanttConfigSchema.quickFilters` already
-models `field` / `label` / `options` exactly as `QuickFilterDef` does. Both are kept and
-pinned as a measured state rather than deleted, so a future spec bump surfaces as a
-decision instead of a silent widening.
diff --git a/.changeset/6473-metadatatypeactions-param-dialog-close.md b/.changeset/6473-metadatatypeactions-param-dialog-close.md
deleted file mode 100644
index a1be13d209..0000000000
--- a/.changeset/6473-metadatatypeactions-param-dialog-close.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-The metadata-admin type-action param dialog no longer blanks itself while it closes
-(objectui#6473).
-
-`MetadataTypeActions` is the **third** consumer of `ActionParamDialog` in this package,
-after `useConsoleActionRuntime` and `RecordDetailView` — and it was the last one still
-writing `setParamState({ open: false, params: [] })` on close, replacing the whole state
-object. `DialogContent` carries `duration-200 data-[state=closed]:animate-out`, so Radix
-holds the content mounted through its exit animation and the dialog goes on rendering off
-`state` for the whole fade-out: a user who cancelled "Test connection" or a datasource
-sync watched the heading revert from the action's own label to the generic
-`actionDialog.title` and every param row disappear, for 200ms, on the way out. Close now
-flips `open` and keeps every other field, which is the shape objectui#6431 converged the
-other two consumers on.
-
-Not a user-data change: the values typed into the dialog never lived in `paramState` —
-they live in `ActionParamDialog`'s own `values`, reseeded from the param defaults on every
-open — so a reopen still starts from the defaults, pinned as a control.
-
-The pre-reset `paramState.resolve?.(null)` is dropped as well, on an enumeration rather
-than on "resolving twice is a no-op": `onOpenChange` is reachable from exactly three places,
-all inside `ActionParamDialog`, and every one settles the promise before asking for the
-close — `handleSubmit`, `handleCancel`, and the Radix root handler that delegates to
-`handleCancel` (the single route Escape, an overlay click and the header close button all
-take). All four routes are driven in the new test, with a census over
-`ActionParamDialog.tsx` so a later call site that skipped the settle is red there instead
-of leaving a promise pending forever.
diff --git a/.changeset/6477-buildconflict-narrowed-type.md b/.changeset/6477-buildconflict-narrowed-type.md
deleted file mode 100644
index 770cdc3fa7..0000000000
--- a/.changeset/6477-buildconflict-narrowed-type.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
----
-
-Type-only change in `@object-ui/plugin-detail`: `InlineEditSaveBar`'s internal
-`buildConflict` callback now takes the type `isConcurrentUpdateError` narrows to,
-instead of `any`, and the `as Record<string, unknown> | null` cast that the `any`
-made necessary is gone.
-
-Nothing releases. Measured, not assumed: building the package before and after
-the change and comparing all 52 emitted `.js` / `.cjs` / `.d.ts` artefacts leaves
-51 byte-identical, including `dist/index.js`, `dist/index.umd.cjs` and
-`dist/index.d.ts`. The single delta is `dist/InlineEditSaveBar.d.ts`, which gains
-the `BuildConflict` type its pin test reads; the package's `exports` map declares
-only `"."`, so that file is not resolvable by any consumer, and the published
-`dist/index.d.ts` does not mention the name. Published behaviour and published
-types are both unchanged.
diff --git a/.changeset/6480-strip-read-decorations.md b/.changeset/6480-strip-read-decorations.md
deleted file mode 100644
index 37be1ae602..0000000000
--- a/.changeset/6480-strip-read-decorations.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-`MetadataService.saveFields` no longer PUTs the framework's own read decorations back (objectui#6480).
-
-`saveFields` fetches the current object and spreads it verbatim (`...existingObject`) so that every key the service does not model survives a field save. That spread does not distinguish keys the **author** owns from keys the **framework** adds on the way out: `@objectstack/spec` declares `_diagnostics` and `_draft` as `METADATA_READ_DECORATIONS` — stamped onto served metadata documents by the read path — and `ObjectSchema` refuses both **by name**. A served document carrying either one was therefore spread straight back into the body of `PUT /api/v1/meta/object/:name`.
-
-The body now passes through the spec's own exported `stripReadDecorations` before it is sent, so the list of decorations stays the spec's rather than a local copy that goes stale the next time the framework adds one. This is the strip-on-write shape `MetadataObjectsPage.handleObjectsChange` already uses for `group`, applied where the spread is — simply not writing the key is not enough when the spread is verbatim.
-
-The strip is deliberately bounded to those two keys and is not a general "remove whatever the schema refuses" pass: an off-spec key the author owns still goes out and is still refused loudly, where someone can see it. Nothing is lost by dropping the decorations even though a PUT is an upsert — `_diagnostics` is the read-path validation verdict, recomputed on every read, and `_draft` reflects the row's `state` column and the `mode` parameter, never the body. The ADR-0010 protection envelope (`_lock`, `_provenance`, …) *is* write-path state the server merges back, and the spec deliberately keeps it out of the decoration list, so it is untouched.
diff --git a/.changeset/6487-visibility-advice-per-tier.md b/.changeset/6487-visibility-advice-per-tier.md
deleted file mode 100644
index 7750f26b92..0000000000
--- a/.changeset/6487-visibility-advice-per-tier.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-'@object-ui/react': minor
-'@object-ui/app-shell': minor
-'@object-ui/components': minor
----
-
-**The unresolvable-visibility-predicate report now names the roots of the tier the
-predicate was actually evaluated against** (objectui#6487). An app-shell author
-whose nav, area or field `visible` faulted was told to check `record` and
-`page.<var>` — two roots that tier does not bind at all.
-
-`formatUnresolvableVisibilityMessage` and `reportUnresolvableVisibilityPredicate`
-(both exported from `@object-ui/react`) take a new **optional sixth argument**, a
-`PredicateScopeTier` — also exported — selecting the closing advice paragraph.
-Everything above that paragraph is unchanged on every surface, and so is every
-verdict: this is diagnostics copy only.
-
-**The published signature grew; nothing existing breaks.** The argument defaults
-to `'page-component'`, so a five-argument call keeps printing the bytes it
-printed before. All three in-repo call sites pass their tier explicitly rather
-than lean on that default.
-
-Each tier's root set was derived from the code that builds the bag, not from the
-prose that described it:
-
-- **`'page-component'`** — `SchemaRenderer`'s node gate and `page:tabs` item
-  predicates. Both bind `record`, `current_user` and `page.<var>` (the roots
-  `@objectstack/spec`'s `ui/page.zod.ts` declares for the tier). Its paragraph is
-  byte-for-byte what it was.
-- **`'app-shell'`** — the chrome gate `ExpressionProvider.evaluateVisibility`
-  runs, wired onto this reporter by objectui#6443. Its evaluator is built from
-  `{ current_user, user, ctx: { user }, os: { user }, app, data, features }`, so
-  the line now names `current_user` with its three ADR-0068 alias spellings,
-  `app`, and `features` — the deployment-flag root that provider documents for
-  exactly this kind of predicate — and states outright that `record` and
-  `page.<var>` do not exist there.
-
-**Why not generalise the copy instead.** Dropping the concrete root names would
-have made one paragraph true everywhere at the cost of making it useful nowhere:
-an author who mistyped a root needs to know which roots exist *at their tier*,
-which is the whole reason the paragraph is read.
-
-`data` is bound at the app-shell tier but is deliberately not advertised there —
-every mount of `ExpressionProvider` in this repo passes `data={{}}` or omits it,
-so naming it would point an author at a root that answers nothing.
diff --git a/.changeset/6488-carry-over-field-keys.md b/.changeset/6488-carry-over-field-keys.md
deleted file mode 100644
index 619f637a0f..0000000000
--- a/.changeset/6488-carry-over-field-keys.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-`MetadataService.saveFields` carries the server's per-FIELD keys through a field save
-instead of rebuilding every entry from the designer model (objectui#6488).
-
-The method preserved unknown keys of the OBJECT document by spreading it, but that spread
-is object-level and said nothing about keys INSIDE a field. Every entry was rebuilt by
-`toFieldPayload`, so every key the server sent inside a field that the designer does not
-model was dropped on every field save: `expression` (a formula authored in metadata-admin),
-`precision`, `scale`, `system`, `sortable`, and anything a plugin registered. Measured
-against the installed `@objectstack/spec` 17.2.0, `FieldSchema` accepts all five — the
-designer's model is a subset of what a field may hold, and the difference was being
-deleted.
-
-The loss is not new but was UNREACHABLE. While `fields` went out as an array the whole
-body was refused `422 INVALID_METADATA` before persistence, so nothing `saveFields`
-dropped ever reached storage; objectui#6240 made the body parse, and a PUT is an upsert,
-so from that fix onward the drop lands.
-
-`toFieldPayload` now merges onto the previous SERVER entry, read from the document
-`saveFields` already fetches for the object-level spread — the form
-`MetadataFieldsPage.fromDesignerField` has used one writer over all along, and no extra
-request.
-
-Two properties keep the fix from becoming its own mirror image, both pinned in
-`MetadataService.fieldKeyCarryOver.test.ts`:
-
-- **A property the author CLEARED stays cleared.** Every modelled key is still written
-  unconditionally, so a cleared property arrives as an explicit `undefined` that overrides
-  the carried value and is dropped by `JSON.stringify` — absent from the body, which on an
-  upsert is the deletion. A conditional merge would leave the server's old value standing
-  and fail the author's deletion silently.
-- **Retired designer keys do not ride back out.** `indexed`, `referenceTo`, `formula`,
-  `isSystem` and `sortOrder` are refused BY NAME by `FieldSchema`; a stored document can
-  still carry them, and echoing one back is a hard 422 that blocks every later save of the
-  object with no UI path to clear it. Everything else the server sent still survives — the
-  strip is keyed to those tombstones, not a blanket unknown-key purge.
diff --git a/.changeset/6489-designer-fields-map-keying.md b/.changeset/6489-designer-fields-map-keying.md
deleted file mode 100644
index 2af37a0ed1..0000000000
--- a/.changeset/6489-designer-fields-map-keying.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-'@object-ui/plugin-designer': patch
----
-
-The Field Designer builds an object's `fields` map by defining own properties and refuses
-the three field lists a name-keyed map cannot carry (objectui#6489). `MetadataFieldsPage`
-keyed the map by blind assignment — `nextFields[f.name] = fromDesignerField(…)` inside a
-bare `for` loop — which failed silently in three directions, all measured on the installed
-`@objectstack/spec` 17.2.0:
-
-- **A field named `__proto__` never reached the wire.** `map['__proto__'] = def` invokes the
-  prototype setter instead of creating a key, so the field vanished from the serialised PUT
-  body. `__proto__` matches `ObjectSchema.fields`' key rule `/^[a-z_][a-z0-9_]*$/`, so the
-  spec stood ready to accept the field the client had thrown away. The map is now built
-  through `Object.fromEntries`, which defines an own property.
-- **A nameless field was stored under the literal key `"undefined"`.** Measured:
-  `ObjectSchema.safeParse` with `fields: { undefined: … }` returns `success = true`, so the
-  document parsed, persisted, and had no reader anywhere. It is now refused before the
-  request.
-- **Two fields sharing a name collapsed into one entry.** A designer list carrying two
-  `amount` fields PUT a single entry, the later silently replacing the earlier. Also refused
-  before the request.
-
-Both refusals raise before `client.save`, so a refused list issues no PUT at all, and the
-message lands in the page's existing error surface naming the offending index — the caller
-is fire-and-forget (`void handleFieldsChange(next)`), so throwing past it would show the
-author nothing.
-
-This is the plugin-designer port of the refusals objectui#6240 landed in the sibling object
-writer (app-shell's `MetadataService.toFieldsMap`), down to the wording, so the two writers
-of the objectui#5761 parity family cannot drift. `fromDesignerField`'s carry-over semantics
-are untouched.
diff --git a/.changeset/6493-bind-field-visibility-evaluators.md b/.changeset/6493-bind-field-visibility-evaluators.md
deleted file mode 100644
index aa20d7da0e..0000000000
--- a/.changeset/6493-bind-field-visibility-evaluators.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
-'@object-ui/app-shell': minor
----
-
-⚠️ **Behaviour change: `current_user` and `features` gates on an object field's
-`visible` that have been doing nothing on the record form page and in the
-console's record modal now TAKE EFFECT.** Read this before upgrading if any of
-your object metadata gates a field on the session user or on a deployment flag.
-
-objectui#6010 and objectui#6110 bound the host predicate scope on the form
-renderer and on the console form routes. `evaluateVisibility` was still being
-reached with a THIRD and FOURTH evaluator that neither of those touched:
-`RecordFormPage` and `AppContent` each built a private
-`new ExpressionEvaluator({ user, app, data })` for the field-visibility filter,
-beside — not from — the `ExpressionProvider` each of them mounts. Those bags
-bound `user`, but not the canonical `current_user` nor the ADR-0068 `ctx.user` /
-`os.user` spellings of that same object, and not `features` at all. So one
-authored predicate meant two different things depending on which evaluator
-reached it: `current_user` resolved on a nav item and was unbound on a field.
-Both sites now build their scope with the same `buildExpressionScope` the
-provider uses, which is the only declaration of what an app-shell predicate may
-name.
-
-**Why nobody noticed, and why the fix is felt as a change.** A field `visible`
-predicate fails OPEN: a field on screen is what you get when the predicate says
-TRUE, when the root was never bound so the predicate faulted, *and* when the
-predicate has a typo. Those worlds are indistinguishable, so an app that
-authored a `current_user` gate saw the field render and had no way to tell the
-rule was inert. After this change the predicate is evaluated for real, and
-**fields that have always been visible will disappear for the users the rule
-excludes** — and a `features` gate whose flag is off will hide its field once
-`/api/v1/auth/config` resolves.
-
-`AppContent`'s bag also hand-rolled its user as `{ name, email, role }`, without
-`positions`. It now uses the same `buildExpressionUser` normaliser every other
-console surface publishes, so `'sales' in current_user.positions` — the gate the
-server enforces on write — reaches the same verdict client-side instead of
-faulting open.
-
-**Before upgrading**, audit any `visible` predicate in your object metadata that
-names `current_user` (or `user` / `ctx.user` / `os.user`) or `features`, and
-confirm each says what you actually want evaluated. Measured on the metadata
-shipped in this repo and in the framework at the time of the change: **nothing
-in it authors such a gate**, so no shipped surface changes behaviour today —
-the audit is for your own object metadata, which this cannot see.
-
-**The error path is deliberately unchanged.** A predicate that throws still
-fails open, exactly as objectui#6443 / objectui#6487 left it. This change is
-about which roots are BOUND, not about what happens when evaluation fails.
diff --git a/.changeset/6496-toast-button-keys.md b/.changeset/6496-toast-button-keys.md
deleted file mode 100644
index a5281eb24d..0000000000
--- a/.changeset/6496-toast-button-keys.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-'@object-ui/types': minor
----
-
-`ToastSchema` now declares the two trigger-button keys the `toast` renderer actually reads
-(objectui#6496, triage scope cut 2026-08-26 — the same declare-what-runs family as
-objectui#6170).
-
-`renderers/feedback/toast.tsx` renders a `<Button>` that raises the toast, and reads two
-keys off the node to do it: `variant={schema.buttonVariant}` and
-`{schema.buttonLabel || 'Show Toast'}`. `ToastSchema` declared **neither**, on the TS face
-or in the `@object-ui/types/zod` mirror. The registration's own designer `inputs` offered
-`buttonLabel` (with `defaultValue: 'Show Toast'`), so the designer shipped a control for a
-key the published type did not have; `buttonVariant` was read by the renderer and named by
-nothing at all. `SonnerSchema` — the sibling with the identical trigger mechanism —
-declared both all along, so only one of the two components was expressible.
-
-The visible cost was on objectui#6250: with `buttonLabel` undeclared, its seven corrected
-toast demos could not author a per-demo trigger label the way the corrected sonner demos
-could, and all seven render the default `Show Toast`. Those demos are unblocked by this.
-
-**`buttonVariant` is declared as the six Button variants, on both faces.** The model this
-card was told to copy disagrees with itself: `SonnerSchema` spells the key `z.string()` in
-the zod mirror and `'default' | 'secondary' | 'destructive' | 'outline' | 'ghost' | 'link'`
-in TS. Matching by symmetry picks nothing, so the shape was taken from what the value
-*reaches* — the renderer passes it straight into `<Button variant={…}>`, whose prop type is
-`VariantProps<typeof buttonVariants>['variant']`, exactly those six. The TS face is the
-correct one and both faces here carry it.
-
-An open `string` is not merely under-validation. Measured on `cva` 0.7.1: an unrecognised
-variant key contributes **no** variant class, and `defaultVariants` applies only when the
-value is *absent* — so `buttonVariant: 'primary'` renders a button with no background and
-no text colour, silently, while `buttonVariant: undefined` renders the default look
-correctly. `primary` is the likeliest wrong spelling precisely because the default
-variant's own class is `bg-primary`. And `buttonVariant: ''` is silently resolved to
-`default` by the same falsy fallback — the one wrong value that does not *look* wrong,
-which an open `string` would accept and never signal. That the declared six are the Button's own vocabulary
-is pinned in both directions in `components/src/__tests__/toast-button-variant-parity.test.ts`
-— `@object-ui/types` has zero deps and cannot import the Button, so the list there is
-necessarily hand-copied, and that file is what stops it being a copy that can drift.
-
-**`SonnerSchema`'s own two faces are left disagreeing.** Its mirror stays `z.string()`.
-That is a real defect on a published surface, and it is filed as objectui#6541 rather than
-fixed here —
-this card's face is `ToastSchema`, and narrowing a second published key is its own
-accept-set change with its own consumers to measure.
-
-**Direction 2 of the finding is untouched.** `action` and `onDismiss` are declared on
-`ToastSchema` and read by no renderer; they sit immediately adjacent to this edit and are
-byte-identical after it. They are enforce-or-remove on a published type and belong to the
-objectui#6124 unsatisfiable-mirror census feeding the objectui#6182 handler-dialect
-decision; they are deliberately not pinned here either, so that family's ruling lands
-without a test of this card's to negotiate with.
-
-Accept-set note for consumers: both keys are **optional** and materialise no default, so
-nothing that renders today stops rendering and no stored toast JSON becomes invalid. Two
-keys that previously resolved as `any` through `BaseSchema`'s index signature are now
-typed, so `buttonLabel: 42` and a `buttonVariant` outside the six are a type error and a
-Zod rejection where they used to pass silently — values that never rendered correctly in
-the first place. `BaseSchema` is untouched, so an *undeclared* key is still accepted by
-both halves (objectui#5155 / objectui#6269 own that ceiling); declaring these two bought
-validation of the declared keys, not rejection of misspellings.
diff --git a/.changeset/6503-concealment-gate-copy.md b/.changeset/6503-concealment-gate-copy.md
deleted file mode 100644
index 642f7aaa9c..0000000000
--- a/.changeset/6503-concealment-gate-copy.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-'@object-ui/react': minor
----
-
-The unresolvable-predicate diagnostic tells `hidden` / `hiddenOn` authors what actually
-happened to their node (objectui#6503). Those two legs are the only ones in
-`SchemaRenderer`'s visibility chain whose verdict is NOT negated: `evaluateCondition`
-answers an unevaluable predicate with `true` on every path, the four negated legs turn that
-into SHOWN, and these two return it as-is, so the same `true` sets `_hidden` and the
-component returns `null`. Both were handed the consequence paragraph written for the negated
-legs — "the gate did NOT bite - a predicate that cannot be evaluated reads on screen exactly
-like one that said yes" — which is the opposite of what an author whose block VANISHED is
-looking at. That line exists to name their predicate, and instead it sent them to hunt a
-rendering bug that does not exist.
-
-The two legs now print their own paragraph: the safe default is the one that BITES here, the
-node was REMOVED and is not on the page at all, an absent node is indistinguishable from
-metadata that meant to hide it, and nothing is wrong with the renderer.
-
-Copy only — no verdict moved. The node still vanishes, which is the shipped fail-soft the
-neighbouring family (objectui#3862 / #3955 / #6443 / #6487 / #6445) preserved deliberately,
-and every case in the new suite pins the verdict beside the sentence.
-
-`PredicateGateKind` — re-exported from `@object-ui/react`'s entry — gains a third member,
-`'concealment'`, joining `'visibility'` and `'enablement'`. The opening line is deliberately
-UNCHANGED (`UNRESOLVABLE_VISIBILITY_PREFIX`): these are visibility predicates, and an app or
-a test filtering the console by that constant must go on catching them. Consumers that
-switch EXHAUSTIVELY over the union, or key a `Record` by it, gain a third case to answer;
-no runtime signature moved and every value accepted before still is.
diff --git a/.changeset/6505-predicate-valued-gate-rules.md b/.changeset/6505-predicate-valued-gate-rules.md
deleted file mode 100644
index 67f1d4c700..0000000000
--- a/.changeset/6505-predicate-valued-gate-rules.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-'@object-ui/core': patch
----
-
-Dev-mode `validateSchema` no longer reports every expression-valued `visible` / `disabled`
-gate as an invalid schema (objectui#6505). `BASE_SCHEMA_RULES` declared both keys
-`typeof value === 'boolean'`, so the exact authoring form the docs teach —
-`{ "type": "button", "disabled": "${record.stage == 'closed'}" }` — printed
-`disabled must be a boolean` and its host element got `data-obj-schema-invalid`, the cue
-apps are told to hang a red outline off.
-
-**The accept set widens to what the protocol already declares and the runtime already
-accepts, not beyond it.** `AGENTS.md` §4 declares both keys as expressions, `SchemaRenderer`
-evaluates them through `hasDeclaredPredicate` + `evaluateCondition`, `@objectstack/spec`
-normalizes every authored predicate into a `{ dialect, source }` envelope, and the
-objectui#3862 / objectui#3955 rulings are entirely about which expression spellings count
-as declared. This table was the one place in the repo that disagreed, so this restores
-declared = enforced rather than changing a contract.
-
-**The rule still bites, and that half is pinned separately.** The two keys stay in
-`BASE_SCHEMA_RULES`: a number, `null`, `{}`, an array, `''`, whitespace-only predicate text
-and the empty / blank-`source` envelope (objectui#3960) are all still reported at their own
-path with `INVALID_TYPE`. Every one of those was reported before this change too — the
-accept set is a strict superset of the old one, so nothing that validated stops validating
-and nothing refused becomes accepted. The message now names both halves of the accept set
-instead of only the half that did not change.
-
-The verdict is delegated to `hasDeclaredPredicate` (`evaluator/declaredPredicate.ts`), the
-repo's single definition of "is a predicate gate declared on this value?"
-(objectui#3850's ruling), rather than answered a second time in the validator — a
-hand-rolled twin that agrees today and drifts tomorrow is the defect class this rule was
-already an instance of. `packages/core/src/validation/__tests__/predicate-valued-gate-rules.test.ts`
-pins the delegation behaviourally: the rule's verdict must equal
-`boolean || hasDeclaredPredicate(value)` across every probe in the file.
-
-The explicit boolean arm is kept even though `hasDeclaredPredicate` already subsumes it, so
-the superset relationship is provable locally: a future narrowing on the declaredness side
-cannot silently start reporting `disabled: false` — the most explicit gate an author can
-write — as an invalid schema.
-
-The zod `safeValidateSchema` surface (`@object-ui/types/zod`, objectui#6318) is a different
-validator and is untouched.
diff --git a/.changeset/6507-boot-gate-redirect-splash.md b/.changeset/6507-boot-gate-redirect-splash.md
deleted file mode 100644
index a8f40444ac..0000000000
--- a/.changeset/6507-boot-gate-redirect-splash.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-Keep the boot splash painted across seven more console redirects (objectui#6507)
-
-Every readiness gate on the console boot path renders `LoadingScreen` while it
-waits and a bare `Navigate` the moment it decides. `Navigate` renders null and
-react-router runs the navigation as a transition, so the destination tree
-renders while the commit that already dropped the splash is what the compositor
-shows — measured at 41-147 ms of empty `#root` on the three sibling gates
-objectui#6506 fixed.
-
-Converted to `RedirectWithSplash`, which pairs the same navigation with the same
-`LoadingScreen` so the handoff changes no pixels:
-
-- `RequireOrganization` — both decisions (orgs exist but none active; no org at
-  all with multi-org enabled)
-- `RequireAiSurface` — a runtime that serves no agent
-- `AuthenticatedRoute` — the signed-out fallback (published for consumers;
-  `apps/console` converted its own `ProtectedRoute` copy under objectui#6506)
-- `RootRedirect` — byte-for-byte the shape that measured the widest window
-- `SetupRedirect` — the `/setup` deep link
-- `AppContent` — the no-accessible-app bounce, which returns above the single
-  `ConsoleLayout` mount
-
-`SystemRedirect` is deliberately left as a bare `Navigate`. It carries the same
-shape on a first navigation, but it is the only site in this set that also fires
-with the console already painted (`SettingsView` navigates to `/system/settings`
-from a button; `AppSidebar` links to `/system`), and a redirect firing under an
-already-painted layout must keep that layout rather than gain a splash. The five
-URL-rewrite redirects in `AppContent` are excluded for the same reason.
diff --git a/.changeset/6515-record-form-current-user-normaliser.md b/.changeset/6515-record-form-current-user-normaliser.md
deleted file mode 100644
index 759d69feeb..0000000000
--- a/.changeset/6515-record-form-current-user-normaliser.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-Field- and action-visibility gates on the full-screen record form page now see the same
-`current_user` every other console surface sees (objectui#6515). `RecordFormPage` built its
-own descriptor — `{ name, email, role, positions }` — instead of calling the shared
-`buildExpressionUser` normaliser, so `id` and `isPlatformAdmin` were simply absent from the
-predicate scope that page publishes.
-
-An absent key is not `false`. A predicate naming one of them FAULTS, and a faulting
-visibility predicate fails OPEN, so the gate silently did not bite: a field gated on
-`ctx.user.isPlatformAdmin == true` (the shape `sys_environment`'s "Change Plan (admin)"
-action uses) rendered for every user on this page, and an id comparison against
-`ctx.user.id` (the shape `sys_user`'s own gates use throughout `platform-objects`) did the
-same. Nothing on screen distinguished that from a gate that had said yes. The signed-out
-branch diverged on its own account too — it carried no `isPlatformAdmin` key at all, where
-`buildExpressionUser(null)` carries `false`.
-
-Fail-open on a genuine evaluation error is deliberately unchanged (objectui#6443 / #6487 /
-#6445); what changed is that these predicates no longer fault in the first place.
-
-The normaliser moved from `console/AppContent.tsx` to `providers/expressionUser.ts`, beside
-the `ExpressionProvider` it feeds. That move is what made the fix available: `RecordFormPage`
-is `lazy()`-loaded BY `AppContent`, so importing the normaliser from its old home would have
-put a static edge from the split chunk back into the module it was split out of. Both
-`console/AppContent.js` and the package entry re-export the name, so `buildExpressionUser`
-is published exactly as before.
diff --git a/.changeset/6519-retired-field-key-strip.md b/.changeset/6519-retired-field-key-strip.md
deleted file mode 100644
index b4c449fd0a..0000000000
--- a/.changeset/6519-retired-field-key-strip.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-The object designer's field-IO read door now strips `referenceTo` and `isSystem` alongside
-`indexed`, so a draft authored before those controls were retired can be edited and saved
-again (objectui#6519).
-
-`previews/object-fields-io.ts` is the single read door for `draft.fields` across the whole
-object designer — inspector, form designer, design surface, settings / validations / API
-panels — and `writeFields` writes each def back verbatim. Its strip set named one key while
-`FieldSchema` refuses five by name, so a stored field carrying any of the others
-round-tripped straight back out to `PUT /api/v1/meta/object/:name`. Measured on the
-installed `@objectstack/spec` 17.2.0, through the whole document that endpoint validates:
-
-```
-ObjectSchema.safeParse({ name:'account', label:'Account',
-                         fields: { amount: { type:'number', label:'A', referenceTo: 1 } } })
-  => unrecognized_keys at ["fields","amount"]
-```
-
-which is the hard `422 INVALID_METADATA` that blocks EVERY later save of that object, with
-the control that wrote the key retired and no UI path left to clear it. This is the shape
-objectui#4644 closed in this same file for `indexed`, applied to the siblings that were
-left open.
-
-Both added keys were verified to be reachable rather than assumed: `referenceTo` was
-emitted by both designer writers until objectui#6041 (`MetadataService.toFieldPayload` and
-`MetadataFieldsPage.fromDesignerField`), and `isSystem` was a declared server-field key the
-designer read back until objectui#6044. Neither loses anything — the spec spellings
-`reference` and `system` are separate, accepted keys and ride through untouched.
-
-Two keys `FieldSchema` also refuses are deliberately NOT stripped, each for its own
-measured reason, and the tombstone on `RETIRED_FIELD_KEYS` carries both in full:
-
-- `formula` (objectui#6043) — `ObjectFieldInspector` seeds its linting CEL editor from
-  `def.expression ?? def.formula` and the first edit commits `expression` and clears the
-  alias. Stripping at the read door empties that editor and the authored source is gone on
-  the next save; objectui#6043 refused a blind rename precisely because that migration
-  surface exists. Dropping the text anyway is a maintainer call, raised on objectui#6519.
-- `sortOrder` (objectui#6045) — no writer on this tree ever populated a FIELD-level one, so
-  no draft this door reads can carry one; a strip would be dead code that reads like a
-  measurement.
-
-Unifying the three retired-key lists on this seam is deliberately not part of this change:
-it spans `plugin-designer/src/MetadataFieldsPage.tsx`, which objectui#6489 owns in flight.
diff --git a/.changeset/6522-objects-page-lookup-keying.md b/.changeset/6522-objects-page-lookup-keying.md
deleted file mode 100644
index cde18d07a2..0000000000
--- a/.changeset/6522-objects-page-lookup-keying.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-'@object-ui/plugin-designer': patch
----
-
-`MetadataObjectsPage` keys its object-name lookups as own entries, so deleting an object
-named `constructor` (or `__proto__`) from the Object Manager actually deletes it
-(objectui#6522).
-
-Both name lookups in the page were plain object literals filled by assignment, and the
-consequential one was a READ. The delete scan asked `!nextByName[name]`, which for an
-object named `constructor` answered out of `Object.prototype` with the `Object` function —
-truthy — so the deletion read as "still present" and `client.reset('object', …)` never
-fired. Not a refusal: the row disappeared from the manager, no error was shown, the save
-reported success, and the object was still there after the next reload. Measured against
-the installed `@objectstack/spec`, `ObjectSchema` pins object names to
-`/^[a-z_][a-z0-9_]*$/` and accepts both `constructor` and `__proto__` — those two are
-exactly the intersection with `Object.prototype`'s own names, so both are storable and
-neither was deletable.
-
-The second lookup, one function over, failed on the WRITE instead: `byName[item.name] =
-item` for an object named `__proto__` invoked the prototype setter rather than creating a
-key, so the object never became an own property, never reached the Object Manager at all,
-and left its payload on the lookup's prototype chain for later name lookups to answer out
-of. Both are now `Map`s — neither container is ever serialised, only its values are, so a
-`Map` fits where the sibling `MetadataFieldsPage` fields map (which IS the PUT body) needs
-`Object.fromEntries`.
-
-Keying only. Nameless and duplicate entries behave exactly as before: this page writes
-per-object, so the refusal semantics objectui#6489 added to the fields map are a separate
-question and are deliberately not ported here.
diff --git a/.changeset/6530-plugin-map-marker-title-precedence.md b/.changeset/6530-plugin-map-marker-title-precedence.md
deleted file mode 100644
index b3f4c12701..0000000000
--- a/.changeset/6530-plugin-map-marker-title-precedence.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-'@object-ui/plugin-map': patch
----
-
-The package README stops documenting a marker-title fallback that objectui#5953 replaced.
-
-`README.md`'s `map` block table described `titleField` as: "Omitted, markers are
-titled `Marker`." That was true of the pre-#5953 read site, which bound the
-marker title to a field name directly. objectui#5953 moved the marker title onto
-`@object-ui/core`'s `getRecordDisplayName`, and `'Marker'` is now passed only as
-that resolver's `fallback` option — a position the resolver reaches **only for a
-record carrying no id at all**. A record with an id and no resolvable name reads
-`Record #<id>`; a record whose object declares a `nameField` or a `titleFormat`,
-or which simply carries a name-ish key, reads that. So "omitted ⇒ `Marker`" was
-true in one narrow corner and false in the common case, and an author reading the
-row would either under-specify `titleField` for a reason that stopped being true
-or over-specify it to avoid a `Marker` that would never have appeared.
-
-The row now names the precedence an omitted `titleField` hands the decision to:
-the declared `nameField`, its deprecated `displayNameField` alias, the legacy
-`titleFormat` template, a type-aware pick from the object's fields, then
-name-ish keys read straight off the record — with `Record #<id>` as the floor and
-`Marker` reached only by an id-less record.
-
-Two details the row states deliberately:
-
-- It does **not** describe an object-level `objectDef.titleField` rung. The
-  resolver consulted one at step 0 as a second `??` leg, but objectui#6531 (PR
-  #6560) removes it — `@objectstack/spec`'s object schema is a `strictObject`
-  that rejects the key with `unrecognized_keys`, so no producer can ship it.
-  What survives is `options.titleField`, which is exactly what `map.titleField`
-  becomes at `ObjectMap`'s call site, so "a declared `titleField` wins" stays
-  true either way and the row does not go stale when that lands.
-- It names the record-key probe (the resolver's step 4b) as its own rung. That
-  is not a footnote for this component: `ObjectMap` fetches an object schema
-  only when `!hasInlineData && dataSource`, so for `staticData` or an inline
-  `data` array no object definition ever reaches the resolver and the record-key
-  probe is the only rung that can produce a title —
-  `ObjectMap.markerTitle.test.tsx` pins exactly that case.
-
-A second row falsified by the same commit goes with it. Two lines below the table,
-the field-name defaults paragraph listed what an unconfigured map falls back to as
-"`latitude` / `longitude` / `location` / `name` / `description`". objectui#5953 removed
-the title default: `getMapConfig`'s default branch returns coordinate keys and
-`descriptionField` only, under a comment that spells out why — "Deliberately NO
-`titleField` (objectui#5953)… `getRecordDisplayName` resolves it from the object
-definition, and it does so better than any literal here could". The paragraph now
-lists the four defaults that exist and says where an unconfigured marker's title
-actually comes from. Left alone in the same sentence: `map: { titleField: 'name' }`
-still names no coordinate field and still renders an empty map, which is accurate.
-
-Prose only: no behaviour changes, and the placeholders were already pinned in
-order by `ObjectMap.markerTitle.test.tsx`.
diff --git a/.changeset/6541-sonner-button-variant-enum.md b/.changeset/6541-sonner-button-variant-enum.md
deleted file mode 100644
index c3396d7e46..0000000000
--- a/.changeset/6541-sonner-button-variant-enum.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-'@object-ui/types': minor
----
-
-**Accept-set NARROWING on a published surface.** `SonnerSchema.buttonVariant` in the zod
-mirror (`@object-ui/types/zod`) was `z.string()`; it is now
-`z.enum(['default', 'secondary', 'destructive', 'outline', 'ghost', 'link'])`. Values
-outside those six — `'primary'`, `'danger'`, `'Default'`, `''` — used to validate and now
-fail. Stated as a narrowing rather than as a fix, because it removes values the published
-mirror accepted (objectui#6541).
-
-**What was wrong.** The same key on the same component shipped as two disagreeing published
-faces: an open string to anyone validating (`@object-ui/types/zod`), and a closed
-six-member union to anyone type-checking (`@object-ui/types`, `SonnerSchema.buttonVariant`
-in `feedback.ts`). The TS face was already correct — only the mirror is changed here, so
-this is the mirror being made to agree with a declaration that sat beside it all along.
-
-**Why the wide face was wrong and not merely wide.** `renderers/feedback/sonner.tsx` passes
-the value straight into `<Button variant={…}>`, whose vocabulary is exactly those six keys
-of `buttonVariants`. Measured on `cva` 0.7.1, an unrecognised key contributes **no** variant
-class, and `defaultVariants` applies only when the value is absent *or falsy*:
-
-```
-buttonVariants({ variant: undefined }) -> "… bg-primary text-primary-foreground …"  default look
-buttonVariants({ variant: 'ghost'   }) -> "… hover:bg-accent …"                     real variant
-buttonVariants({ variant: 'primary' }) -> "…"                                       NO colour at all
-buttonVariants({ variant: ''        }) -> "… bg-primary …"                          silently 'default'
-```
-
-So the mirror was validating values the renderer visibly breaks on: `'primary'` — the
-likeliest wrong spelling, since the default variant's own class is `bg-primary` — rendered a
-button with no background and no text colour, and `''` was silently reinterpreted as
-`default`. Nothing that renders correctly today stops validating.
-
-**Blast radius, measured.** The key stays optional, so every published `sonner` node that
-omits it keeps parsing. The two fixtures in the repo that set it
-(`examples/schema-catalog/src/schemas/components-feedback-sonner/{error,promise-based-toast}.json`)
-use `destructive` and `outline` — both inside the six. No consumer was found relying on a
-seventh spelling.
-
-**Model inherited, not invented.** objectui#6496 landed exactly this spelling on
-`ToastSchema` for the same trigger mechanism, matched to `ButtonProps['variant']` as ground
-truth. This card applies the settled shape to the sibling that still disagreed with itself.
diff --git a/.changeset/6547-flat-gantt-face-pointers.md b/.changeset/6547-flat-gantt-face-pointers.md
deleted file mode 100644
index aa716d2662..0000000000
--- a/.changeset/6547-flat-gantt-face-pointers.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-'@object-ui/types': patch
----
-
-`ObjectGanttSchema`'s flattened gantt face documents `colorField`, `parentField`,
-`tooltipFields` and `quickFilters` in its own words, instead of pointing at a type that
-says nothing about them (objectui#6547).
-
-Those four members carried a bare `See {@link GanttConfig}.` pointer. `GanttConfig` is
-`SpecGanttConfig & { … }`, and all four arrive from the **spec** half: the local half of
-that intersection declares exactly ten top-level members (`timeSegments`, `lockField`,
-`objectField`, `summaryExtent`, `defaultCollapsedDepth`, `borderColorField`,
-`dependencyTypes`, `timeZone`, `exportFileName`, `interactions`) and none of these four is
-among them. `SpecGanttConfig` is `z.input<typeof GanttConfigSchema>`, and the spec's
-emitted `.d.ts` carries no per-member JSDoc — its 19 members are bare `z.ZodOptional`
-entries under one type-level "Gantt Settings" docblock. So the pointer was not merely
-unhelpful, it was misdirecting: a reader who followed it landed on a type documenting
-nothing about the key and concluded the key was undocumented.
-
-Verified on the built artifact rather than the source: all four bare pointers were present
-in `dist/objectql.d.ts` before this change and none is after, so the defect was on the
-published surface and the repair reaches it.
-
-**Prose only — the published shape is unchanged, and that is the point.** The natural
-repair, writing the prose onto `GanttConfig`, means re-declaring these members inside the
-intersection; PR objectui#6546 measured that as a widened published surface on the built
-`dist/index.d.ts` and it was rejected there. So the shape was measured, not asserted:
-`ObjectGanttSchema`'s 45 members and their checker-resolved types are byte-identical
-before and after, and the built face's 51 declaration lines diff clean with comments
-stripped. Only comment bytes moved.
-
-The seven **member-qualified** pointers (`See {@link GanttConfig.borderColorField}`,
-`.lockField`, `.summaryExtent`, `.defaultCollapsedDepth`, `.timeSegments`,
-`.interactions`, `.exportFileName`) name members of that ten-member local half, resolve to
-real prose, and are deliberately left alone — the defect is the bare form, and a substring
-search for `{@link GanttConfig` hits both.
-
-The prose is taken from the renderer's live read sites in `plugin-gantt`, not invented:
-`colorField`'s status/state/priority/severity fallback chain and the platform default
-blue, `parentField`'s unknown-id-renders-as-root rule, `tooltipFields`' drop-empty-rows
-behaviour (which is what lets a mixed-object tree list the union of every level's fields)
-and its replacement of the default date · duration · progress tooltip line, and
-`quickFilters`' schema-resolved option domains. No behaviour change, no runtime code.
diff --git a/.changeset/6548-stale-test-name.md b/.changeset/6548-stale-test-name.md
deleted file mode 100644
index 50ccd2cc9c..0000000000
--- a/.changeset/6548-stale-test-name.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
----
-
-Test-only change in `@object-ui/core`: renamed one `it()` in
-`actionDef-closed-surface.test.ts` so its reported name cites `tsconfig.test.json`,
-the project that actually compiles the file, instead of the retired
-`tsconfig.typetests.json` (objectui#4040). No assertion, source file or published
-behaviour changes — only the string the runner prints.
diff --git a/.changeset/6551-signedin-user-id-required.md b/.changeset/6551-signedin-user-id-required.md
deleted file mode 100644
index 236bd0641c..0000000000
--- a/.changeset/6551-signedin-user-id-required.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-`buildExpressionUser`'s signed-in cast declares `id`, `name` and `email` REQUIRED, so it is
-no longer wider than the contract it mirrors (objectui#6551).
-
-The normaliser reads its input through a cast, and that cast wrote all three keys optional
-(`{ id?: string; name?: string; email?: string; … }`) while the signed-in branch forwards
-exactly those three RAW. So the declaration said `buildExpressionUser({ name: 'B', email:
-'b@c.d' })` was a legitimate input, and the code answered `{ id: undefined, … }` for it —
-present-and-always-`undefined`, which is the shape objectui#5424 removed `roles` from this
-same object for ("the shape that teaches the wrong thing") and the one objectui#6534
-refused for the anonymous branch, one key over. The three keys BELOW them already defended
-with `??`; the asymmetry sat inside one object literal.
-
-The contract disagreed with the cast. Every production input is `useAuth().user`, typed as
-`@object-ui/auth`'s `AuthUser`, which extends the spec's `AuthUser`
-(`@objectstack/spec/contracts`): `id: string; email: string; name: string`, with only
-`positions` and `tenantId` optional. `name` and `email` are narrowed alongside `id` because
-that same interface declares them required too — the same answer from the same authority,
-not a widened scope. `role` stays optional (it is `@object-ui/auth`'s display-only
-addition, not a spec key), and the index signature stays (better-auth projects an app's
-custom user columns onto this object, and it is how `isPlatformAdmin` / `positions` are
-read).
-
-NOTHING REACHABLE CHANGES, and deliberately so. The only production producer is a
-better-auth principal that always carries `id`, which is why this was graded a latent shape
-hazard rather than a bug, and why the fix moved a declaration and no runtime behaviour: the
-defect was that the cast LIED about the contract. `id: u.id ?? null` was the rejected shape
-(triage, 2026-08-26) — a lenient default in the consumer is what AGENTS.md #0.1 forbids and
-what objectui#6534 shipped a scope fence against, and it silently equates "signed in, no
-id" with "signed out". A producer without an `id` is wrong at the producer.
-
-Because `id?: string` and `id: string` produce byte-identical output for every input a
-producer can supply, no runtime assertion can pin this; the new
-`expressionUser.sessionContract.types.test.ts` drives `tsc` itself over the real
-declarations and carries its own discrimination leg — the same cases compiled a second time
-against the pre-fix optionality, with the five that flip named by index.
-
-No fault-handling path moved. Fail-open on a predicate that DOES fault stays deliberate
-policy (objectui#6443 / #6487 / #6445).
diff --git a/.changeset/6557-objectview-titlefield-middle-leg.md b/.changeset/6557-objectview-titlefield-middle-leg.md
deleted file mode 100644
index 13424aa2ac..0000000000
--- a/.changeset/6557-objectview-titlefield-middle-leg.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-'@object-ui/app-shell': patch
-'@object-ui/react': patch
----
-
-Drop the undeclared object-level `titleField` from the object page's five
-remaining view-config seams, and from the record-search memo key
-
-`ObjectView` resolves a title field for seven view kinds. Two of them —
-calendar and gantt — already read `viewDef.<kind>?.titleField || 'name'`. The
-other five (timeline, kanban, map, gallery, tree) carried a three-rung chain
-with `objectDef.titleField` in the middle, so one file answered the same
-question two different ways. This converges the five on the shape the two
-siblings already had; it is a convergence, not a removal.
-
-The middle rung could never fire for legal metadata. `@objectstack/spec`'s
-object schema is a `strictObject`, so
-`ObjectSchema.safeParse({ …, titleField: 'x' })` is rejected with
-`unrecognized_keys` — the same issue code a nonsense key gets — while
-`nameField`, `displayNameField` and `titleFormat` all parse (measured against
-`@objectstack/spec@17.2.0`, the dist this repo installs). objectui#6531
-established that measurement and dropped the twin read inside
-`getRecordDisplayName`. Reading a key no producer can ship is the
-consumer-side alias AGENTS.md Commandment #0.1 bans.
-
-Behaviour for every legal config is unchanged, and both directions are pinned:
-a view that declares its own `titleField` still wins on every kind, a view that
-declares none still floors at `'name'`, and an object carrying the
-contract-rejected key is now honoured by no kind. Re-pointing the middle rung
-at the declared `nameField` was considered and rejected: it would have added a
-rung calendar and gantt do not have — increasing the divergence — and, unlike
-this change, it would have altered behaviour for legal configs.
-
-`useRecordSearch`'s candidate signature — the memo key that decides when the
-cross-object fanout re-runs — appended `o?.titleField ?? ''` to every entry.
-Because no legal object definition can carry the key, that half was permanently
-`''`: a constant suffix in a cache signature, and the last thing in the repo
-that read as evidence some producer supplies it. The signature is now the object
-name alone, which is the only field of an object definition the effect actually
-consumes. Change detection is unaffected — a changed candidate name still
-re-runs the fanout, and a new array with identical content still does not.
diff --git a/.changeset/6558-remove-dead-console-record-title-copy.md b/.changeset/6558-remove-dead-console-record-title-copy.md
deleted file mode 100644
index ccf03b9b1c..0000000000
--- a/.changeset/6558-remove-dead-console-record-title-copy.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
----
-
-Removed a dead pre-ADR-0079 `getRecordDisplayName` / `formatRecordTitle` copy from
-`apps/console/src/utils.ts`. Both were unexported-from-behaviour dead code with zero
-console importers (superseded by the unified `@object-ui/core#getRecordDisplayName`);
-no published behaviour changes.
diff --git a/.changeset/action-designer-param-vocabulary.md b/.changeset/action-designer-param-vocabulary.md
deleted file mode 100644
index 9b82c424a0..0000000000
--- a/.changeset/action-designer-param-vocabulary.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-"@object-ui/app-shell": patch
----
-
-fix(app-shell): the Action designer's preview draws what the runtime dialog will draw
-
-`ActionDefaultInspector` offers eight param `type` spellings; `ActionPreview`'s
-dialog mock switched on five of them over a private table, so three of the eight
-previewed as a control `ActionParamDialog` does not render — `datetime` and a
-targeted `lookup` as plain text boxes, and a `select` whose options were not
-authored yet as a text box as well. A `text` param that happened to carry
-`options` previewed as a select the runtime never draws, for the same reason in
-the other direction.
-
-The mock now resolves each param through `paramToField`'s
-`resolveParamWidgetType` / `paramDegradesWithoutTarget` — the same adapter the
-dialog itself renders through — so the two panes cannot disagree about a
-spelling again. `datetime` draws a date/time control, a `lookup` with a declared
-`reference` draws a record picker, a targetless one draws the record-id text box
-the dialog degrades to and says why, and a `select` always draws a picker.
-
-The per-param editor also gains an `options` control for `select` params. It had
-none, and `params` is hidden from the collapsed "More fields" form, so the panel
-that offered the type had nowhere to author the choices the type needs.
diff --git a/.changeset/action-keys-warning-text-5642.md b/.changeset/action-keys-warning-text-5642.md
deleted file mode 100644
index d4fdb94a12..0000000000
--- a/.changeset/action-keys-warning-text-5642.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-'@object-ui/core': patch
----
-
-The dev-mode unknown-key warning stops stating a fact that was retired, and
-sends the author to the file that actually declares the interface
-(objectui#5642).
-
-Both halves of the message's tail had outlived the change they described. It
-told the author the key was warned about rather than rejected because
-`ActionDef` "still carries `[key: string]: any`" — objectstack#4075 step 3
-deleted that index signature, and `actionKeys.pin.test.ts` pins the deletion in
-the opposite direction (`{ ActionDef: false, ActionContext: true }`), while
-`actionDef-closed-surface.test.ts` pins that `tsc` now rejects exactly such a
-key at the construction site. And it prescribed promoting the key to an explicit
-field on `ActionDef` "(packages/core/src/actions/actionKeys.ts)" — that file
-holds the INVENTORY (`ACTION_DEF_KEYS`); the interface is in `ActionRunner.ts`.
-The wrong pointer had teeth: an author who followed it edited the inventory
-alone, which is precisely the half-change the pin test reddens on, since it
-re-derives the inventory from the interface's AST.
-
-The tail now carries the reason the module's own header already gives for why
-this warning survived step 3 — the two mechanisms cover disjoint populations.
-`tsc` sees action literals authored in code; the warning sees actions that
-arrive as data, from stored rows that are rehydrated unparsed and that no
-compiler ever looked at (objectstack#3903). The prescription names
-`ActionRunner.ts` for the field and `ACTION_DEF_KEYS` as the same-commit second
-edit, saying why.
-
-No behaviour change: the classification logic, the key inventory and its
-derivation are untouched, and the warning fires on exactly the same actions as
-before. Two comments in the same file and two in the pin test that described the
-pre-step-3 world were refreshed in the same pass, and the message text is now
-pinned — the printed interface path is resolved off the message and read, so a
-move or rename reddens by name instead of shipping a second dead prescription.
diff --git a/.changeset/action-onsuccess-forward-5493.md b/.changeset/action-onsuccess-forward-5493.md
deleted file mode 100644
index b74a69cef5..0000000000
--- a/.changeset/action-onsuccess-forward-5493.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-'@object-ui/components': patch
----
-
-`action:button`, `action:icon`, `action:group` and `action:menu` now forward the
-declared `onSuccess` block, so the post-success navigation an author writes in metadata
-actually happens on those four surfaces (objectui#5493).
-
-`onSuccess` — spec's closed strict `{ navigate, openIn }` object — became authorable on
-`ActionSchema` with the `@objectstack/spec` 17.1.0 pin bump (objectui#5328), and the
-runner has read it off the **forwarded** def since objectui#5221:
-`ActionRunner.handlePostExecution` → `readOnSuccessNavigation` → `navigateOnSuccess`,
-which hops through the app's own `navigationHandler` (a real SPA route change, immune to
-popup blocking). Between those two halves sat these four forward whitelists, which never
-carried the key. The action succeeded, the toast said so, and the declared hop silently
-did not happen — the same "shipped green while dropped one hop before the runner" class
-as `bodyExtra` (objectstack#6837), `bodyShape` (objectstack#6938) and `resultDialog`
-(objectui#3646).
-
-Reachability before this change was a function of which host rendered the action: the
-full-def-spread hosts (`DeclaredActionsBar`, `ObjectGrid.onActionDef`,
-`RelatedRecordActionsBridge`, `useNavActionDispatch`) already carried it through, so the
-same declaration hopped there and did nothing here — and on an `action:bar`, whether an
-action lands inline (`action:button`) or in the overflow (`action:menu`) is decided by
-`maxVisible`, 3 desktop / 1 mobile. The declared navigation therefore depended on
-viewport width.
-
-Pinned end to end in
-`packages/components/src/renderers/action/__tests__/action-onSuccess-forward.test.tsx`:
-one row per surface drives the real renderer through the real runner and asserts the
-`${result.*}`-interpolated url reaches `onNavigate`, with `openIn` exercised on both
-branches. Each row asserts the action executed first, so a zero-navigation reading
-cannot be a harness that did nothing.
-
-The four matching `KNOWN_GAPS` entries in `scripts/check-action-forward-parity.mjs` are
-deleted — that ledger is ratcheted, so a stale entry excusing a key that is now
-forwarded fails the gate. `element:button` is untouched and stays correct: `onSuccess`
-is not on spec's `InlineActionSchema` pick list, so that surface never owed it.
diff --git a/.changeset/action-param-degrade-predicate-5654.md b/.changeset/action-param-degrade-predicate-5654.md
deleted file mode 100644
index 2fc5978fe4..0000000000
--- a/.changeset/action-param-degrade-predicate-5654.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-**Behaviour change:** a `master_detail` action param with no reference target now
-receives the same "paste a record id" placeholder and help text a targetless
-`lookup` param has had since objectui#3405. Previously it degraded to a plain
-text input exactly like `lookup` did, but silently — the user was shown an
-unexplained empty box that wanted a bare record id.
-
-The cause was two hand-maintained answers to one question. `paramToField()`
-performs the degradation over RESOLVED widget keys (`lookup`, `master_detail`),
-while `ActionParamDialog` decided who gets the hints with its own literal over
-RAW param spellings (`'lookup' || 'reference'`). Neither set contained the
-other: `master_detail` degraded with no hints, and `reference` was a copy of an
-alias-table row the adapter folds to `lookup` before it tests membership.
-
-`paramToField` now exports `paramDegradesWithoutTarget(param)` and both the
-adapter's own fallback branch and the dialog's two hint readers ask it, so "who
-degrades" and "who gets hints after degrading" are one member set answered once
-(objectui#5654; same convergence shape as objectui#4770 / #4790 / #4815).
-
-Params that already had the hints keep them, including the `reference` spelling;
-a param that renders as text without having degraded (an unknown type) still
-gets no picker hints.
diff --git a/.changeset/action-runtime-same-origin-only-5702.md b/.changeset/action-runtime-same-origin-only-5702.md
deleted file mode 100644
index 1340b71436..0000000000
--- a/.changeset/action-runtime-same-origin-only-5702.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-**Behaviour change:** the console action runtime (`useConsoleActionRuntime`) now
-builds its authenticated fetch with `sameOriginOnly: true`, matching the
-`provider: 'api'` data-source lane (`ConsoleShell`). A metadata `type: 'api'`
-action whose resolved target is a different origin than the page is fetched
-through the bare global fetch: the platform Bearer token, `X-Tenant-ID`, and
-`Accept-Language` are no longer attached (objectui#5702, maintainer ruling
-2026-08-22). Previously the Bearer rode to any off-origin target whose URL
-contained `/api/`, and `X-Tenant-ID` rode to every off-origin target
-unconditionally.
-
-Same-origin actions — including every relative target in a same-origin
-deployment — are unchanged, and off-origin requests still execute (pass-through,
-not a refusal). An off-origin integration that legitimately needs the platform
-bearer declares itself explicitly or proxies same-origin.
-
-Note for split-host setups: `apiHandler` prefixes relative action targets with
-`VITE_SERVER_URL`. When that is set to an origin different from the page's,
-those action requests are off-origin and no longer carry credentials. The
-committed dev and starter configurations are unaffected: since objectui#5745
-they ship `VITE_SERVER_URL` empty and reach a split-host backend through the
-Vite `/api` dev proxy, so their action requests are same-origin.
diff --git a/.changeset/active-org-clear-removal-failure-5731.md b/.changeset/active-org-clear-removal-failure-5731.md
deleted file mode 100644
index aacb03bc76..0000000000
--- a/.changeset/active-org-clear-removal-failure-5731.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-'@object-ui/auth': patch
----
-
-`ActiveOrganizationStorage.clear()` now verifies that the persisted key is actually
-gone and, when it is not, both reports the failure and stops `get()` answering from
-the surviving value — instead of swallowing the failed removal (objectui#5731).
-
-`clear()` nulled `_memoryValue` and then removed the persisted key inside a
-`try`/`catch` that discarded any failure. Since objectui#5703 `get()` prefers a
-NON-NULL `localStorage` read and only falls through to `_memoryValue`, so the two
-halves of `clear()` were not equally strong: nulling memory always sticks, while a
-removal that did not stick left the key readable and the read order preferred it.
-Sign-out is one of `clear()`'s five callers, so the failure mode was "sign-out does
-not stick", and it was silent — the cleared organization went back on the wire as
-`X-Tenant-ID` on every subsequent request.
-
-The removal is now judged by a READ-BACK rather than by catching the throw, which is
-both narrower and wider in the right directions. Wider: a wrapped or proxied
-`localStorage` whose `removeItem` is a silent no-op never throws and leaves identical
-residue, and is now covered. Narrower: SSR and the partitioned-iframe browser where
-every operation throws have nothing readable to resurrect, were already safe, and are
-not reported as failures.
-
-A key whose removal could not be verified is quarantined in memory for the rest of the
-page-load: `get()` skips the persisted branch for it and answers from `_memoryValue`,
-which `clear()` has just nulled and which a later `set()` refills with the value that
-write was meant to persist. The quarantine is released as soon as a removal on that key
-sticks. An unstamped `X-Tenant-ID` is a documented state of the edge contract
-(objectui#5279); a re-stamped signed-out organization is not.
-
-The failure is not thrown and not returned. All five call sites — sign-out's
-`purgeSignedOutClientCaches`, `switchOrganization`, `deleteOrganization`,
-`leaveOrganization`, and the session-user purge that runs on the SIGN-IN path — arrive
-after the transition they follow up on has already happened, and none can act on a
-storage failure; a `boolean` every caller ignores would read as handled when it is not.
-So the invariant is restored inside `clear()` and the failure is reported to the
-console.
-
-A working `localStorage` behaves exactly as before: the removal sticks, nothing is
-quarantined, nothing is reported, and a non-null persisted read is still authoritative.
-`set()`'s swallowed write failure is deliberately untouched — that swallow is
-objectui#5703's memory fallback, and it is the correct kind, because the memory copy
-upholds `set()`'s postcondition where nulling memory could not uphold `clear()`'s.
diff --git a/.changeset/active-org-storage-memory-fallback-5703.md b/.changeset/active-org-storage-memory-fallback-5703.md
deleted file mode 100644
index eef9655d93..0000000000
--- a/.changeset/active-org-storage-memory-fallback-5703.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-'@object-ui/auth': patch
----
-
-`ActiveOrganizationStorage.get()` now prefers a non-null `localStorage` read and falls
-back to the in-memory value otherwise, instead of returning the `localStorage` read
-unconditionally — so the fallback is reachable in the browser state it was written for
-(objectui#5703).
-
-`set()` already swallowed a failed `localStorage.setItem` into `_memoryValue`, but
-`get()` only consulted `_memoryValue` when the READ itself threw. There is a real
-browser state where the read does not throw and the fallback is nonetheless the only
-copy: `localStorage` present and readable but rejecting writes — Safari private
-browsing, and any quota-exhausted origin, where `setItem` throws `QuotaExceededError`.
-In that state the active org was stored and could not be read back, measured as
-`_memoryValue = org-42` alongside `get() = null`.
-
-The cost was silent and lasted the whole session rather than the documented first-boot
-window: `createAuthenticatedFetch` reads `get()`, so `X-Tenant-ID` was never stamped on
-any request. Per the edge contract documented on objectui#5279 that header is a routing
-hint a reader falls through on — the framework scopes from the session — so no row
-visibility rode on this; what was missing is the tenant-routing input, on every request.
-`switchOrganization` also appeared to succeed while the client-side stamp never
-followed.
-
-Sign-out is unaffected, and that is the half worth stating: the new fallback fires
-exactly when the `localStorage` read is null, which is the state `clear()` leaves
-behind. It answers `null` there because `clear()` nulls `_memoryValue` too. That
-property is now pinned by test rather than relied upon, so a future `clear()` that only
-removed the persisted key fails a test instead of quietly re-stamping a cleared org.
-
-A non-null persisted read still wins over the memory value, so a working `localStorage`
-behaves exactly as before.
diff --git a/.changeset/activity-map-single-reading-5878.md b/.changeset/activity-map-single-reading-5878.md
deleted file mode 100644
index b04790a791..0000000000
--- a/.changeset/activity-map-single-reading-5878.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-'@object-ui/app-shell': minor
-'@object-ui/plugin-detail': minor
----
-
-The console record page and the `record:activity` block read ONE `sys_activity`
-type table, so a scheduled meeting no longer appears on one and vanishes on the
-other.
-
-`RecordDetailView`'s `sys_activity` merge carried a hand-written copy of the
-table that `record:activity` exports as `ACTIVITY_TYPE_TO_FEED_TYPE`. Neither
-file imported the other and nothing compared them, so the two could drift
-silently — and they had. objectui#5840 added `scheduled` -> `event` to the
-exported table, because a shipped producer (HotCRM's `schedule_meeting`) writes
-that value and the row was being dropped before any filter ran. The copy here
-was left untouched, so the same row rendered on a hand-authored record page and
-was dropped on the console record page: same record, same row, two answers.
-
-`RecordDetailView` now imports the exported table, and the copy is gone. The
-table is re-exported from `@object-ui/plugin-detail`'s entry point, which is
-what makes a single reading possible at all — it was previously reachable only
-from inside the plugin. No module enters the eager closure: the module holding
-it was already pulled in by the renderer beside it.
-
-Adding an activity type is now one edit, in one place, that both surfaces see.
-A re-fork is caught rather than merely discouraged: the new pins spy on the
-shared object and inject a member into it at runtime, so a private copy holding
-today's members exactly — the failure this change removes — fails, where a
-value comparison would pass on the defect.
-
-Only the table converges. The row-to-`FeedItem` construction around it is still
-written twice, so an unmapped activity type is still dropped silently on the
-console surface where the block warns once; that mirror is filed separately.
diff --git a/.changeset/adapter-meta-type-singular-4940.md b/.changeset/adapter-meta-type-singular-4940.md
deleted file mode 100644
index a96ab64517..0000000000
--- a/.changeset/adapter-meta-type-singular-4940.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-'@object-ui/data-objectstack': patch
----
-
-`ObjectStackAdapter.getApp` and `getPage` now address the `app` / `page` metadata
-types in the singular, matching the other twelve `client.meta.*` call sites in this
-file (objectui#4940).
-
-`getApp` (`getItem('apps', …)`) and `probeAppAccess` (`getItem('app', …)`) addressed
-the same metadata type sixty lines apart, and only `probeAppAccess`'s comment argued
-its singular spelling was deliberate — the plural site was silent. Both plural sites
-resolved today only because the server folds plural → singular
-(`RestServer.metaTypeSingular` via `PLURAL_TO_SINGULAR` from `@objectstack/spec/shared`,
-confirmed by reading both the mapping and the by-name route handler that calls it), so
-this is consistency restoration rather than a behavior change — nothing a user hits was
-broken, and nothing a user hits changes.
-
-`appAccessProbe.test.ts` (objectui#4252's local pin for this same spelling) is extended
-with two new cases asserting `getApp`/`getPage` pass the singular type to
-`client.meta.getItem`, so a future revert to the plural spelling fails a test instead of
-depending on the server-side fold staying in place.
diff --git a/.changeset/adr-0057-d10-citation-attribution-5202.md b/.changeset/adr-0057-d10-citation-attribution-5202.md
deleted file mode 100644
index e30834a070..0000000000
--- a/.changeset/adr-0057-d10-citation-attribution-5202.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
----
-
-Traceability only — this publishes nothing, declared explicitly with an empty frontmatter
-rather than left undeclared. The change is comment text at seven live source sites; no
-executable line moves, and `git diff -U0` carries zero non-comment added or removed lines.
-
-`server enforces, client is courtesy` was cited at those seven sites as a bare
-**`ADR-0057 D10`**. The substantive claim is correct and is unchanged here; what was missing
-is the **framework qualifier**. In this repository the bare string resolves to
-`docs/adr/0057-console-ai-chat-one-conversation-docked.md` — a document about console AI chat
-docking, which contains no `D10` at all and is the one a reader greps first. The intended
-anchor is the *framework's* ADR-0057, whose D10 decides *"Setup-nav surfacing follows the
-capability (ADR-0029 K2); the object stays open"*.
-
-Each site now carries the disambiguation already shipped by the two authorities in this
-repository — `docs/adr/0036-field-conditional-rules.md:91` and
-`packages/core/src/evaluator/fieldRules.ts:38` — rather than a third phrasing:
-`the framework's ADR-0057 D10 — framework numbering; this repo's own ADR-0057 is an
-unrelated document`.
-
-Three sites are deliberately left byte-untouched, all three already correct:
-`packages/data-objectstack/src/appAccessProbe.test.ts:25` (a verbatim quotation of the
-objectstack#8013 ruling, and about the capability/nav gate — the one family D10 really does
-decide), plus the two authorities above.
diff --git a/.changeset/ai-chat-public-share-base-4482.md b/.changeset/ai-chat-public-share-base-4482.md
deleted file mode 100644
index 3ad06d0251..0000000000
--- a/.changeset/ai-chat-public-share-base-4482.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-`AiChatPage`'s public share-link base now resolves through the one console-mount
-resolver instead of a private copy of it (objectui#4482).
-
-The page built `publicShareBase` itself — read the injected `<base href>`, take its
-pathname, trim trailing slashes, concatenate `${origin}${base}/s` — which was the third
-independent implementation of the mount resolution `resolveConsoleUrl` centralizes.
-objectui#4472 had just deleted the other two on that rule; this was the surviving
-sibling. Its output was correct, so nothing a user hits was broken and nothing a user
-hits changes: measured over the base-href matrix, the deleted builder and
-`resolveConsoleUrl('s')` return identical URLs for every shape the console is served in
-— `/_console/` (the only href the framework CLI injects), `/` root mounts, `./` portable
-builds, nested mounts, and no `<base>` at all.
-
-The `/s` resolution now lives beside its three siblings as `resolvePublicShareBase()`,
-which keeps the one thing a bare `resolveConsoleUrl('s')` call would drop: with no DOM
-it returns `undefined` rather than a URL built from an origin that does not exist, so
-`ShareDialog` applies its own fallback. It deliberately takes no `baseURI` argument —
-the mount is only ever carried by the injected `<base href>`, and a resolver with no
-other input cannot be pinned by a test that steers something production never reads.
-
-`resolvePublicShareBase.browser.test.tsx` pins the resolved base against a real injected
-`<base>` element for each deployment shape, plus a structural case asserting no other
-app-shell file reads the `<base>` tag — so a fourth copy fails a test rather than
-waiting for mount semantics to change under it.
diff --git a/.changeset/ai-quota-ledger-vocabulary-3804.md b/.changeset/ai-quota-ledger-vocabulary-3804.md
deleted file mode 100644
index 61ec9e5047..0000000000
--- a/.changeset/ai-quota-ledger-vocabulary-3804.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-'@object-ui/plugin-chatbot': patch
----
-
-Recognize the landed AI quota ledger vocabulary in the chat error path
-
-`parseAiQuotaError` now accepts the three SCREAMING_SNAKE ledger codes the cloud
-token guardrail emits (`AI_ALLOWANCE_EXHAUSTED`, `AI_DESIGN_QUOTA_EXHAUSTED`,
-`AI_DATA_CHAT_TRIAL_EXHAUSTED`) alongside the legacy lowercase trio, which stays
-readable for producers that have not converged yet. The companion fields
-(`messageEn` / `upgrade` / `topUp` / `resetsTonight`) are now read from the
-declared envelope's `error.details` as well as their legacy top-level position,
-with the declared position winning.
-
-A quota-exhausted user gets the upgrade / top-up CTA again instead of the
-generic "Response failed" banner. The per-turn message cap's generic
-`QUOTA_EXCEEDED` deliberately keeps its existing rate-limit path — it has no
-upgrade or top-up next step.
diff --git a/.changeset/ai-studio-accessor-5577.md b/.changeset/ai-studio-accessor-5577.md
deleted file mode 100644
index dca9479328..0000000000
--- a/.changeset/ai-studio-accessor-5577.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-`features.aiStudio` is now read through one `isAiStudioEnabled()` accessor instead
-of being spelled inline at two call sites (objectui#5577).
-
-`features.marketplace` already had a documented accessor whose docblock is where the
-fail-open doctrine is written down — *"Fails OPEN (`!== false`): a runtime predating
-`/api/v1/runtime/config`, or one whose config fetch failed, keeps the default `true`"*,
-plus the "never infer this from the shape of a failure" warning. `features.aiStudio`
-had no such sibling: `ChatDock` read `getRuntimeConfig().features.aiStudio !== false`
-and `HomePage` read `getRuntimeConfig().features?.aiStudio !== false`, so one doctrine
-had two spellings and neither reader could cite it.
-
-The two spellings were not equivalent. `ChatDock`'s omitted the optional chain, and
-against a runtime-config snapshot whose `features` is absent that read is a TypeError
-rather than a fail-open — the exact shape that crashed 29 tests across four suites in
-PR #5575 before it was corrected. Measured here: no live path can currently deliver
-such a snapshot to `ChatDock` (the module's singleton constructs `features` on every
-write and exports no setter, and no suite mounts the dock's default body under a
-partial stand-in), so this closes a reachable-by-construction crash rather than a live
-one — and it closes it at the source by leaving no inline read to get wrong.
-
-`isAiStudioEnabled()` is an internal module export, matching `isMarketplaceEnabled()`:
-neither is re-exported from `src/index.ts`, so the package's published `exports` surface
-is unchanged.
diff --git a/.changeset/alias-closure-relative-miss-5386.md b/.changeset/alias-closure-relative-miss-5386.md
deleted file mode 100644
index f67ab4d329..0000000000
--- a/.changeset/alias-closure-relative-miss-5386.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
----
-
-Tests only — this publishes nothing, declared explicitly with an empty frontmatter
-rather than left undeclared. No package `src/` is touched; the only file changed is
-`examples/console-starter/test/vite-alias-closure.test.ts`, and that example is private.
-
-Makes the alias-closure walker record an unresolvable **relative** import instead of
-dropping it.
-
-`computeClosure()` walks two kinds of specifier. The bare-specifier branch pushed a miss
-onto `unresolvable`; the relative branch dropped one with no record at all. So
-`expect(closure.unresolvable).toEqual([])` was not a weak assertion for relative imports
-— it was a structurally empty one. It could not fail no matter how many relative
-specifiers the walk failed to follow, and the `filesWalked` floor was the only signal
-that anything had gone wrong.
-
-That is how two earlier conversions to explicit extensions (objectui#4538, objectui#5214)
-each truncated this walk while landing green: the floor had enough slack to absorb both,
-and only went red once app-shell — the largest package — converted and took the count
-under 500. The direct symptom was being swallowed one branch away the whole time.
-
-Measured on `main` at the time of this change, with the resolver ablated to its
-pre-objectui#5357 behaviour to reproduce that regression class: 275 relative specifiers
-dropped, `filesWalked` 1245 to 402, packages reached 29 to 22 — and `unresolvable` still
-reporting `[]`. With this change the same ablation fails the suite with all 275 named,
-each alongside the file that imports it.
-
-The miss is recorded only for specifiers that are *meant* to be modules — no extension,
-or one of the JS/TS emitted extensions. `ts.preProcessFile` also reports `./styles.css`,
-`./data.json` and `./logo.svg`, which `resolveModule` cannot resolve by design, so
-recording those identically would fail the suite for a reason that is not a defect.
-Assets and Vite resource specifiers (`?raw`, `?url`, `?inline`) are skipped into a
-separate `nonModuleSkipped` list — explicitly, and observably, rather than by accident.
-
-Four fixtures pin the class against the real walker so a future edit cannot silently
-re-blind the branch: `./Foo.js` resolving through to the `Foo.tsx` on disk, planted
-unresolvable modules of both spellings being named, assets staying out of `unresolvable`
-while still being accounted for, and the classifier's boundary cases.
diff --git a/.changeset/analytics-error-branch-mapping-5663.md b/.changeset/analytics-error-branch-mapping-5663.md
deleted file mode 100644
index e0809a7683..0000000000
--- a/.changeset/analytics-error-branch-mapping-5663.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-'@object-ui/data-objectstack': patch
----
-
-`ObjectStackAdapter.queryDataset` now maps a failed dataset query by the server's
-ADR-0112 error `code`, not by the HTTP status, so an unknown dataset and an
-unauthenticated session stop being reported as a missing analytics capability
-(objectui#5663).
-
-Two unrelated conditions answer **404** on `POST /api/v1/analytics/dataset/query`:
-the runtime dispatcher's `ROUTE_NOT_FOUND` when the route was never mounted, and
-the route's own `NOT_FOUND` when `body.datasetName` matches no saved dataset. The
-mapping tested `res.status === 501 || res.status === 404` and called all of it
-"the analytics capability is not installed", so every unknown dataset produced a
-banner telling the operator to install `@objectstack/service-analytics` and mount
-`AnalyticsServicePlugin`. Measured live on a prod tenant, that banner was shown on
-four HotCRM Executive Overview widgets while the analytics service was installed
-and answering — the real condition was an installed `app.objectstack.hotcrm` at
-1.3.0 whose datasets ship in 2.2.2, i.e. a package upgrade, the opposite corner of
-the system from the remedy the banner named.
-
-Three conditions now get three answers, each keyed on the code the framework
-declares for it:
-
-- `NOT_IMPLEMENTED` (501, route mounted with no analytics service) and
-  `ROUTE_NOT_FOUND` (404, route not mounted) keep the existing
-  `AnalyticsNotInstalledError` and its copy — one remedy, one message.
-- `NOT_FOUND` (404, unknown `datasetName`) throws the new
-  `AnalyticsDatasetNotFoundError` (`ANALYTICS_DATASET_NOT_FOUND`), naming the
-  dataset and pointing at the installed app's version rather than at the server.
-- `UNAUTHENTICATED` (401, `enforceAuth`) throws the new
-  `AnalyticsUnauthenticatedError` (`ANALYTICS_UNAUTHENTICATED`), which says the
-  request was refused before it ran and therefore says nothing about the
-  capability.
-
-The banner also used to print the server's own message in a parenthetical while
-contradicting it in the headline — it quoted `Dataset "opportunity_metrics" not
-found.` under a headline claiming a missing capability. That is now structurally
-impossible rather than merely fixed: the headline is a pure function of `code` and
-the parenthetical is a verbatim quote of `message`, both read off the same
-response, and a test walks every branch asserting each message carries its own
-headline and none of the others'.
-
-Additive only. `AnalyticsNotInstalledError` keeps its `code`, its copy and its
-constructor signature (it gains an optional third `serverCode` argument and a
-`serverCode` field), so consumers matching `ANALYTICS_NOT_INSTALLED` — including
-the metadata-admin dataset preview — are unaffected. A 404 carrying a code this
-client does not recognise, such as the analytics cube gate's `CUBE_NOT_FOUND`, now
-keeps its server detail instead of being relabelled as a missing capability; a 404
-or 501 carrying no code at all is still read as the capability being absent, since
-the route's own `NOT_FOUND` always ships a code.
diff --git a/.changeset/analytics-failure-code-first.md b/.changeset/analytics-failure-code-first.md
deleted file mode 100644
index 8b9043df2c..0000000000
--- a/.changeset/analytics-failure-code-first.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-'@object-ui/data-objectstack': minor
----
-
-Classify `/analytics/query` failures by their ADR-0112 `code` rather than their HTTP status, so a chart is no longer answered from a different code path behind the wrong explanation.
-
-`classifyAnalyticsFailure` tested `status === 404 || status === 501` before the code operands on the same line, so the status short-circuited every one of them: any 404 on this face was classified "the analytics capability is not installed" whatever code it carried, and `NOT_IMPLEMENTED` / `ROUTE_NOT_FOUND` were unreachable for the conditions they name. Three unrelated conditions answer 404 on this url, so the status cannot tell them apart — the `code` is the contract.
-
-Two conditions change behaviour:
-
-- **404 `CUBE_NOT_FOUND`** (a misspelled or unregistered cube — an authoring mistake) now **throws** the server's own error verbatim, keeping `code` and the producer's repair instructions. It previously warned "install `@objectstack/service-analytics`" and silently degraded to `find()` + client-side aggregation — which cannot answer it anyway, because the fallback re-reads the same name through `/data`, where an unregistered object is a 404 `OBJECT_NOT_FOUND`.
-- **401 `UNAUTHENTICATED`** (an anonymous or lapsed session) now **throws** `AnalyticsUnauthenticatedError` instead of degrading silently behind a `find()` that is about to be refused the same way.
-
-Unchanged: `NOT_IMPLEMENTED` / `ROUTE_NOT_FOUND` and code-less 404/501 answers still degrade loudly to the client-side fallback, 400 `VALIDATION_FAILED` still throws, and 5xx / network failures still degrade silently.
diff --git a/.changeset/anon-seed-scope-pin-5828.md b/.changeset/anon-seed-scope-pin-5828.md
deleted file mode 100644
index 12f0afa2b7..0000000000
--- a/.changeset/anon-seed-scope-pin-5828.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
----
-
-Test-only: lands the objectui#5746 enumeration harness as a regression pin under
-objectui#5828. It mounts the real console boot path (real `AuthProvider`, real
-`ConnectedShell` session gate, real `MetadataProvider`; only the auth and
-metadata servers are doubled) and asserts what is true today — including that
-the guest and `previewMode` boots write `objectui:metadata:app:@none:@anon`,
-which is the open observation objectui#5828 carries, not a change made here. The
-pin that can fail is S6: it goes red if objectui#5198's principal-scoped cache
-key stops discriminating principals. No published behaviour changes.
diff --git a/.changeset/anonymous-expression-user-id-6534.md b/.changeset/anonymous-expression-user-id-6534.md
deleted file mode 100644
index c3c8459aae..0000000000
--- a/.changeset/anonymous-expression-user-id-6534.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-The predicate identity bound for a signed-out visitor now carries `id: null`, so a
-`ctx.user.id` visibility gate BITES instead of failing open (objectui#6534).
-
-`buildExpressionUser` has two branches, and only the signed-in one carried `id`.
-So `'id' in buildExpressionUser(null)` was `false`, and an absent key is not
-`false`: a CEL predicate naming `ctx.user.id` / `current_user.id` / `os.user.id`
-hit an unbound key for a signed-out visitor and FAULTED. A faulting visibility
-predicate fails OPEN (`evaluateVisibility`), so the gated field or action rendered
-for exactly the principal it was written to exclude, with nothing on screen to say
-the gate had not bitten — silently, for every signed-out visitor.
-
-Because the defect was in the shared normaliser rather than at a mount site, it
-reached EVERY mount site, including `AppContent` and the console's
-`InternalFormRoute`, both of which have always called the normaliser correctly.
-This is the same fault-open mechanism objectui#6515 fixed one level up, where
-`RecordFormPage` hand-rolled a descriptor missing `id` and `isPlatformAdmin`.
-
-`null` rather than `undefined`, and rather than leaving the key absent, is settled
-by precedent on this exact object rather than chosen here. objectui#5424 removed
-`roles` from it because a present-and-always-`undefined` key "is the shape that
-teaches the wrong thing" — the context answers rather than being plainly absent,
-and the answer is silently wrong; `undefined` here would reproduce that defect one
-key over. Leaving it absent IS the defect. `null` is a VALUE a CEL author can
-compare against, so `ctx.user.id == '…'` resolves to a clean FALSE. Measured, not
-assumed: at a real mount site with `authState.user = null` and a field gated on
-`ctx.user.id == 'u_admin'`, the field is now filtered OUT of the schema handed to
-`ObjectForm`, where before it was present.
-
-This also closes the last asymmetry between the two branches. Both now advertise
-the same six keys, which is the symmetry objectui#5424 was closing when it removed
-`roles` — and the shape pin now asserts the key sets are equal, so a future edit
-that adds a key to one branch and forgets the other fails whichever branch it
-forgets.
-
-NOT CHANGED, deliberately: fail-open on a predicate that DOES fault. That is
-shipped permission-boundary policy (objectui#6443 / #6487 / #6445) and remains
-exactly as it was — an unevaluable `visible` still renders. This change removes a
-REASON to fault; it does not touch what happens once a predicate has. No accept set
-is widened, no gate is relaxed and no fallback is added: the only behavioural
-movement is that an id-gated surface which used to render for anonymous visitors
-now hides from them.
diff --git a/.changeset/app-shell-nodenext-pin-5440.md b/.changeset/app-shell-nodenext-pin-5440.md
deleted file mode 100644
index f6674a1eb9..0000000000
--- a/.changeset/app-shell-nodenext-pin-5440.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-Pin `module` / `moduleResolution` to `nodenext` in `@object-ui/app-shell`'s build config, matching the pins `@object-ui/react`, `@object-ui/fields` and five other packages already carry. This package builds with a bare `tsc`, which never rewrites import specifiers, so what the source writes is exactly what `dist` ships; under `nodenext` a missing relative extension is a compile error, so the extensionless-specifier defect that made published entries unloadable under plain Node cannot come back silently here.
-
-The lazy `@monaco-editor/react` imports in the metadata designer's source editors now read the package's named `Editor` export instead of its default. `@monaco-editor/react@4.7.0` is CommonJS and ships no `exports` map, so under `nodenext` the default resolves to the module namespace rather than to the component. The two names are one declaration in that package's own typings and the same object at runtime in both its CommonJS and ESM builds, so the editor that renders is unchanged.
diff --git a/.changeset/app-shell-page-header-subtitle-4761.md b/.changeset/app-shell-page-header-subtitle-4761.md
deleted file mode 100644
index 01333ab79c..0000000000
--- a/.changeset/app-shell-page-header-subtitle-4761.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-The console's `<PageHeader>` spells its secondary line `subtitle`, the same key the other `PageHeader` in this repo uses (objectui#4761).
-
-This repository has two components named `PageHeader`. `@object-ui/layout`'s is
-the renderer for the authored `page:header` / `page-header` node and converged
-on `subtitle` in objectui#3789, because `subtitle` is the key
-`@objectstack/spec/ui`'s `PageHeaderProps` declares. `@object-ui/app-shell`'s —
-the console's own title row, drawn by `ObjectView` and `ObjectDataPage` —
-spelled the very same concept `description` and had no `subtitle` at all. Both
-rendered correctly; the defect was one concept carrying two key names one
-package apart, the objectstack#4115 shape moved up a layer. An author reading
-one component to learn the other was being taught a key the contract does not
-have.
-
-**Not a breaking change, measured rather than assumed.** The convergence is a
-plain rename with no alias, because this component is not on the published
-surface:
-
-| gauge | result |
-|---|---|
-| exports of `dist/index.d.ts`, through the TypeScript checker | 226 symbols; `PageHeader` and `PageHeaderComponentProps` are not among them (controls: `AppShell` reachable, a nonsense name not) |
-| `exports` map | declares exactly `.` and `./styles.css` |
-| Node resolving `@object-ui/app-shell/layout`, `…/dist/layout/PageHeader.js`, `…/src/layout/PageHeader.js` | `ERR_PACKAGE_PATH_NOT_EXPORTED` for all three, while the declared entry resolves |
-| in-repo call sites | 2, both inside this package (`ObjectView.tsx`, `ObjectDataPage.tsx`) |
-| emitted declarations that change | `dist/layout/PageHeader.d.ts` only — `dist/index.d.ts` and `dist/layout/index.d.ts` are byte-identical across the change (`8c886251…`, `f9f4862b…`, both legs) |
-
-No supported specifier reaches the prop, so there was nothing to keep
-compatible, and a renderer-side `description` alias would have been exactly the
-second dialect AGENTS.md #0.1 forbids — the layout side had just finished
-retiring one. Out-of-repo consumers cannot be enumerated from this repository;
-what can be, and is, is the set of import paths through which one could have
-reached this component, which is empty.
-
-Rendered output is unchanged: same element, same classes, same position. The
-patch tier is a declaration that the tarball moved, not a claim that a consumer
-must act.
-
-`packages/app-shell/src/layout/__tests__/PageHeader.subtitle.test.tsx` is the
-pin the card asked for. It asserts the subtitle on the DOM a reader gets (a
-`<p>`, in the title block, after the `<h1>`), that `description` now draws
-nothing and is rejected by the compiler, and — the assertion that actually goes
-red if either side drifts again — that both packages' `PageHeaderComponentProps`
-declare `subtitle`.
diff --git a/.changeset/approvals-inbox-cell-remount-5348.md b/.changeset/approvals-inbox-cell-remount-5348.md
deleted file mode 100644
index 4a11753a5b..0000000000
--- a/.changeset/approvals-inbox-cell-remount-5348.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-'@object-ui/console': patch
----
-
-The Approvals Inbox stops remounting every row on every render.
-
-`ApprovalsInboxPage` declared `RequestCell`, `RecordCell` and `InlineActions`
-inside its own component body. React identifies a component by the identity of
-its function, so each render produced three brand-new component *types* and React
-unmounted and remounted every row's subtree instead of updating it — and the page
-holds its clock in state and ticks it every 60s, so this fired on a timer whether
-or not anyone was touching the page (objectui#5348).
-
-Two consequences were reproduced against `origin/main` before the fix, in
-`apps/console/src/pages/system/ApprovalsInboxPage.cellIdentity.test.tsx`:
-
-- **Transient subtree state is discarded.** Focus placed on a row's Approve
-  button moved to `<body>` on the next clock tick.
-- **Input is silently swallowed.** A pointer sequence that spans a re-render —
-  press, tick, release — left the confirmation dialog unopened: the captured node
-  had been replaced, so React's delegated listener never saw the click. This is
-  the failure objectui#5211 hit and worked around at its call site
-  (`Unable to find role="alertdialog"`).
-
-The three cells are now at module scope beside `StatusBadge`, which was moved
-there for the same reason and already carries the explanation. Everything they
-closed over is passed in: `RequestCell` and `InlineActions` take the page's
-scoped translator, and `RecordCell` takes `href: string | null` — one prop rather
-than two, so the objectui#5211 readable/unreadable decision and the URL cannot be
-handed in disagreeing with each other.
-
-The verification asserts the consequence, not the placement. A test that checks
-the three functions now sit at module scope stays green for a refactor that moves
-them and introduces a fourth inline component beside them; these cases compare
-DOM-node identity for all three cells across a clock tick, which no remount can
-pass, and re-drive the swallowed click.
-
-That guard is load-bearing because lint cannot supply one here.
-`react-hooks/static-components` exists for exactly this class and is `error` in
-this repo via the plugin's recommended set, yet it reports nothing on this page:
-measured on `origin/main`, an arrow-form inner component injected into
-`ApprovalsInboxPage` and used in JSX produced **zero** reports, while the same
-shape in a ten-line file produced two. The rule's analysis bails out on this
-component, which is how three of them shipped.
diff --git a/.changeset/approvals-queue-hidden-amount-6020.md b/.changeset/approvals-queue-hidden-amount-6020.md
deleted file mode 100644
index 3c0b81e920..0000000000
--- a/.changeset/approvals-queue-hidden-amount-6020.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-"@object-ui/console": patch
----
-
-Approvals inbox: the queue rows and the amount sort now honour each request
-object's own `hidden: true` field declaration (objectui#6020).
-
-The `hidden: true` trim added for the drawer summary card reached only the
-drawer — the desktop queue row, the mobile card and the amount comparator
-still read the field, so an amount an app author declared hidden rendered
-inline in the queue and ordered the list, which leaked its relative magnitude
-even to a viewer who never saw the figure.
-
-The queue spans many objects, so the trim is a per-object lookup and every row
-is answered about its own object; a row left with no renderable amount now
-sorts with the other amount-less rows. `hidden` stays a UI contract
-(objectstack#10749) and the filter still fails open: an unanswered or failed
-metadata read renders today's figure.
diff --git a/.changeset/approvals-raw-payload-gate-5553.md b/.changeset/approvals-raw-payload-gate-5553.md
deleted file mode 100644
index 3cd1ed2642..0000000000
--- a/.changeset/approvals-raw-payload-gate-5553.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-'@object-ui/console': patch
----
-
-The Approvals Inbox no longer shows a business approver the submitted record's raw
-row JSON.
-
-The detail drawer's "Raw data (JSON)" panel rendered on `payload != null` alone — no
-principal check of any kind — so every approver could expand (and one-click copy) the
-complete raw snapshot: `id`, `created_by`, `updated_by`, `owner_id`,
-`organization_id`, bare lookup ids, and **the fields the object's metadata declares
-`hidden: true`**. Reported from a live EHR deployment on 17.1.0
-(objectstack-ai/objectstack#10734), where that declaration is a patient-data control.
-The app author had no legitimate lever to remove the panel — field `hidden`, view
-columns, app navigation, permission sets and env vars are all ineffective against it —
-so the remedies available in the field were patching the shipped bundle or injecting
-CSS.
-
-The panel is now gated on `holdsStudioAccess`, reused verbatim from the console's
-`studioEntry` module: `studio.access` is a declared platform-scope capability that a
-tenant org owner does not hold by design, and it already reaches the browser in
-`systemPermissions[]` from `/api/v1/auth/me/permissions`. Nothing new is served,
-computed or made authorable — no new config key, no new i18n copy, and the panel is
-byte-for-byte unchanged for the platform operator it was written for. A business
-approver keeps the structured record summary, the approval chain, the activity feed
-and the decision actions; only the raw snapshot is gone.
-
-The gate reads the RAW `systemPermissions` signal and fails **CLOSED**, inverted from
-`usePermissions().hasCapabilities`. That hook fails open on purpose — hiding a
-holder's button while the server still refuses the write is the worse outcome for an
-action. This panel has the opposite stake, since the measured defect is a non-holder
-seeing it, so every not-a-reported-grant answer denies: no provider mounted, a backend
-predating ADR-0066 that omits the field, the resolver's `catch` path that answers `200`
-with no `systemPermissions` at all, and a reported empty array. A deployment whose
-permission layer just failed must not be the one that leaks the snapshot.
-
-`ApprovalsInboxPage.rawPayloadGate.test.tsx` pins all four verdicts. Because the
-acceptance condition is that something does *not* render — which an empty render
-reproduces perfectly — every denial case also asserts the drawer it denies inside, and
-the `studio.access` case drives the same fixture through the same helper and finds the
-panel. `created_by` and `organization_id` are the witnesses: both are in the page's
-`PAYLOAD_SYSTEM_KEYS`, so the summary card already drops them and their values can
-reach the DOM only through the raw panel. Ablating the gate (restoring the bare
-`payload != null` condition) turns the three denial cases red on exactly that
-assertion and leaves the holder case green.
-
-Out of scope, tracked separately: trimming the summary by object metadata, and the
-server-side residual that sends the unfiltered snapshot to the client at all.
diff --git a/.changeset/approvals-step-progress-vertical-5554.md b/.changeset/approvals-step-progress-vertical-5554.md
deleted file mode 100644
index 8bccea37ef..0000000000
--- a/.changeset/approvals-step-progress-vertical-5554.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-'@object-ui/console': patch
-'@object-ui/app-shell': patch
----
-
-The approval step progress bar is a vertical stepper, so long flows stop
-clipping their tail steps.
-
-Both occurrences were a single non-wrapping flex row whose steps were each
-`shrink-0`. A flex row's min-content width is the sum of its non-shrinkable
-items, so the bar's intrinsic width grew without bound with step count and
-label length. On a live 17.1.0 project a real 6-step flow with ordinary CJK
-step names measured **1070px inside a 527px container** (objectui#5554).
-
-The two hosts failed differently, and neither failure was recoverable by the
-reader:
-
-- **`ApprovalsInboxPage`** (the inbox detail drawer) — the bar itself was not
-  scrollable, so the nearest scroller was the drawer *panel*. Reaching steps
-  4-6 meant dragging the drawer's own horizontal scrollbar, which pushed the
-  record card, the activity timeline and the action buttons off-screen and left
-  a near-blank panel.
-- **`RecordApprovalsPanel`** (the record page's approvals panel) — this one
-  carried `overflow-x-auto`, so it scrolled itself rather than its container.
-  Better, but the tail steps still sat behind a scroll gesture with no visible
-  affordance.
-
-In both, readers took the clipped bar for the end of the data; the reporting
-customer acceptance tester said so verbatim. Widening the window does not help:
-the drawer is fixed-width, and clipping was identical at 1440x900 and 1920x1000.
-
-Both now render as a column: one row per step, a badge-and-rail gutter, and a
-label that may wrap. Width is capped by the container at every step count and
-every label length, which also suits both hosts' tall-and-narrow aspect. The
-rail segment below each step keeps the tint rule the horizontal connector used
-— it is coloured by the step it leads *into*.
-
-**Always vertical, with no step-count or measured-width threshold**, because
-the overflow is driven by intrinsic content width (labels x count), not by
-count alone: three 16-character CJK labels already crowd a 527px drawer, so any
-count threshold picks a cutoff that is wrong for some real flow, and a measured
-one reintroduces a viewport-dependent branch. The card's requirement is a fix
-that cannot break at an untested viewport or flow length, and a layout with no
-breakpoint and no measurement is the form that satisfies it. Horizontal-with-
-scroll was ruled out for both occurrences: it leaves steps behind a gesture.
-
-Pinned in `ApprovalsInboxPage.stepProgressVertical.test.tsx` and
-`RecordApprovalsPanel.stepProgressVertical.test.tsx`. "The stepper renders" is
-green against the broken code too — every step was always in the DOM, and the
-clipping was layout — so the suites assert the property the defect names
-instead: no row is `shrink-0`, every label is `min-w-0` and none is
-`whitespace-nowrap`, nothing in the subtree is an `overflow-x` scroller, and no
-axis, overflow or width-pinning class carries a breakpoint prefix (so there is
-no viewport with untested behaviour). The reported failing regime is exercised
-directly with the reporter's own six CJK labels, and a 2/5/6/12-step sweep pins
-that the layout classes are byte-identical across all four, so no count
-threshold can put some other flow length back on the old path.
-
-The two steppers are kept identical by hand rather than extracted to a shared
-component: they live in different packages, and deduplicating them is a
-refactor with its own surface. Filed separately.
diff --git a/.changeset/approver-display-name-5414.md b/.changeset/approver-display-name-5414.md
deleted file mode 100644
index f441983851..0000000000
--- a/.changeset/approver-display-name-5414.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-'@object-ui/app-shell': minor
-'@object-ui/i18n': minor
----
-
-The approval panel identifies the pending approver by name, not by a truncated raw id.
-
-A record waiting on a position rendered its approver as `positi…ager` — the
-engine reference `position:sales_manager`, 22 characters, past the identity
-formatter's 14-character truncation arm and middle-truncated to fit its chip. The
-step names beside it were human prose; the one line answering *who is holding
-this record* was an internal identifier, and not even a complete one. The same
-reference reached the admin-override confirm dialog un-truncated, so a paragraph
-of plain governance prose ended `— position:sales_manager` (objectui#5414).
-
-Both surfaces now resolve the reference before rendering, in three tiers, most
-authoritative first. The server's own `pending_approver_names` wins whenever it
-answers, and a backend that resolves its own slate costs the record page no extra
-request. Otherwise the console reads the directory row the spec's approver
-binding names — `sys_position.label` gives `Sales Manager` / `销售经理` — and,
-for a position, who fills the seat (`Sales Manager · Zhang Wei, Li Na`). With no
-adapter and no row, the machine name still prettifies into prose rather than
-truncating. The raw reference stays on hover, which is where an internal
-identifier belongs.
-
-An unstaffed position is surfaced rather than hidden: `销售经理（暂无在岗人员）`
-is actionable where `positi…ager` is not, and it is the motivating rescue case
-for the admin-override path. Staffing is deliberately tri-state — a
-`sys_user_position` read the viewer is not permitted to make leaves the seat's
-staffing UNKNOWN and says nothing, because "I could not look" is a different
-claim from "nobody holds it" and only one of them is safe to print on a
-governance surface.
-
-Two locale keys are added across all ten packs: `approvalsInbox.approverUnstaffed`
-and `approvalsInbox.approverNameSeparator`. The separator is a translated
-punctuation key rather than `Intl.ListFormat`, which was measured on this tree
-joining `['张伟','李娜']` into `张伟李娜` for `zh` — two names run together with
-no separator, reading as one person's name.
-
-The directory-backed kinds and their value columns are read from
-`@objectstack/spec`'s `APPROVER_VALUE_SOURCES` rather than restated, so a new
-approver type is covered the day the spec publishes it. Id-valued kinds
-(`user` / `team` / `department`) keep the existing middle-truncation: a row id
-has no prose to recover, and that arm is objectui#3461's answer, not this card's
-defect.
diff --git a/.changeset/approver-identities-read-positions-5424.md b/.changeset/approver-identities-read-positions-5424.md
deleted file mode 100644
index 2137b2b8c2..0000000000
--- a/.changeset/approver-identities-read-positions-5424.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-'@object-ui/app-shell': patch
-'@object-ui/console': patch
----
-
-fix(approvals): derive approver identities from `positions`, not the retired `user.roles` (objectui#5424)
-
-Framework ADR-0090 D3 renamed the session's `roles` key to `positions` with no
-deprecation window, and the protocol-17 session face emits no `roles` key at
-all. Three client sites still read it:
-
-- **`sharedUserFeeds.approverIdentities`** — the bell badge, the bell's
-  Approvals tab and Home's To-do card. It read nothing else, so it sent **no
-  `role:` identity at all**: an approval addressed to a position rather than to
-  a person matched nothing and vanished from all three surfaces, silently.
-- **`approvalsApi.buildApproverIdentities`** — "My Pending" and the
-  Approve/Reject enablement. It also splits the scalar `user.role`, so it
-  degraded rather than dying: it still yielded `role:user` while dropping every
-  business position name (`manager`, `finance_approver`, …).
-- **`AppContent`'s expression user** — forwarded a `roles` key that was always
-  `undefined` into every CEL predicate context. Removed; `positions` and
-  `isPlatformAdmin` were already forwarded correctly beside it.
-
-The retired spelling is **not** kept as a fallback — pairing the two is what
-ADR-0090 D3 forbids, and `packages/auth/src/types.ts` says so on the
-declaration.
-
-`AuthGuard`'s `requiredRoles` gate (the fourth surviving reader) is deliberately
-untouched: it is a semantics decision, not a rename, and is deferred to a
-maintainer ruling.
diff --git a/.changeset/appsidebar-deprecated-5720.md b/.changeset/appsidebar-deprecated-5720.md
deleted file mode 100644
index 404094e329..0000000000
--- a/.changeset/appsidebar-deprecated-5720.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-`AppSidebar` is now `@deprecated` — use `UnifiedSidebar` instead.
-
-A census (objectui#5720) found `AppSidebar` has no in-repo mount point
-(`ConsoleLayout` renders `UnifiedSidebar`, not this component) and no
-downstream consumer visible anywhere across this org's GitHub-visible
-repositories. It stays exported — from the package barrel and the published
-`dist/index.d.ts` — because `@object-ui/app-shell` is a public npm package
-(`publishConfig.access: "public"`) and an external consumer outside this org
-is structurally invisible to that census; that is why it is deprecated
-rather than deleted outright. No behavior change in this release — the
-component still renders exactly as before. Its admin nav cluster is a
-near-duplicate of `UnifiedSidebar`'s and has already drifted from it (it
-gates only `sys-marketplace` on the workspace-admin flag, where
-`UnifiedSidebar` gates the whole cluster); that divergence is not being
-reconciled, since the component is scheduled for removal rather than kept
-in parity — see objectui#5817 for the removal plan.
-
-Migration: replace any `AppSidebar` usage with `UnifiedSidebar` from the same
-package.
diff --git a/.changeset/authguard-positions-5424.md b/.changeset/authguard-positions-5424.md
deleted file mode 100644
index 438aa5d16a..0000000000
--- a/.changeset/authguard-positions-5424.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-"@object-ui/auth": minor
----
-
-`AuthGuard`'s `requiredRoles` now matches against `user.positions` — the one published spelling (framework ADR-0090 D3) — keeping the `user.role` scalar fallback only for sessions that carry no `positions` key at all (guest / legacy identities). This restores position-holder admission on protocol-17 deployments (where the retired `roles` key is never emitted) and closes the matching over-admission: a coarse scalar `role` no longer passes a gate whose position the server says the user lacks. Preview mode now emits `positions: [role]` instead of the retired `roles` key — it was the last producer — so preview identities are shaped like protocol-17 sessions for every `positions` consumer. The hand-copied `roles?: string[]` mirror key is removed from the client `AuthUser` type; breaking only for TypeScript consumers that compiled against `AuthUser['roles']` (read `positions` instead — no runtime payload ever carried `roles` at protocol 17). Maintainer ruling 2026-08-22 on objectui#5424.
diff --git a/.changeset/block-schema-docs-truth-4895.md b/.changeset/block-schema-docs-truth-4895.md
deleted file mode 100644
index 3019d9ed00..0000000000
--- a/.changeset/block-schema-docs-truth-4895.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
----
-
-Docs and a gate ledger only — this publishes nothing, declared explicitly with an empty
-frontmatter rather than left undeclared. No package `src/` is touched: the two files
-changed are `content/docs/blocks/block-schema.mdx` and
-`scripts/check-doc-component-types.mjs`.
-
-Corrects `content/docs/blocks/block-schema.mdx` to the vocabulary the repository actually
-declares, per the maintainer ruling recorded on objectui#4895 (Option B: docs-truth fix,
-the block family re-scoped as type-level).
-
-The page taught a `{ type: 'slot', name: 'content' }` node inside
-`BlockSchema.template`. `template` is typed `SchemaNode | SchemaNode[]`, so that snippet
-sat on the render path — and `slot` is registered nowhere. Measured against the
-`check-doc-component-types.mjs` derivation of the registered universe (659 keys), the only
-keys matching `/block|slot/` are `blockquote` and `ui:blockquote`. A reader who copied the
-snippet got the renderer's `OBJUI-001` "Unknown component type" panel. That node is
-deleted, and the page now teaches `slotContent`, the key `BlockSchema` and
-`BlockInstanceSchema` actually declare.
-
-**`slotContent` is documented as declared-but-not-yet-consumed, not as the working path**,
-because that is what it measures as. Outside `packages/types` — the interface, its Zod
-mirror, and that package's own parse test — nothing in the repository reads `slotContent`,
-`slots` or `template`. Rewriting one phantom into a second phantom is the failure this card
-exists to close, so the page states the status plainly instead of implying a runtime that
-does not exist. For the same reason the component-schema framing is dropped from
-`block-library` / `block-editor` / `block-instance`: none of them appears in `AnySchema`,
-the runtime node union in `packages/types/src/index.ts`.
-
-Two further measurements are written into the page because they are what a confused reader
-needs. The four `<SchemaExample>` demos it embeds are ordinary registered component trees
-(`card`, `flex`, `stack`, `text`, `icon`, `button`, `badge`) — none carries `type: 'block'`,
-`slots` or `slotContent`, so nothing on the page was ever exercising the block vocabulary.
-And the slot system that *is* wired end to end is a different family entirely: slotted
-record pages (`kind: "slotted"`, `page.slots`), consumed by `usePageAssignment`,
-`PageBlockCanvas` and `PageBlockInspector`. The page now links there rather than leaving the
-two `slots` spellings to be conflated.
-
-The `slot` entry in `DOC_TYPE_EXEMPTIONS` pointed at this card and is dropped, as the ruling
-requires. With the phantom node gone the entry would itself fail as `stale-exemption`, so it
-is deleted rather than re-pointed; the three terse family reasons are re-pointed at the
-ruling's framing in the same pass.
-
-Option A (build renderers for the family) is rejected on zero pull and Option C (retire the
-family) is deferred; neither is implemented here.
diff --git a/.changeset/built-moment-transition-5799.md b/.changeset/built-moment-transition-5799.md
deleted file mode 100644
index b429463265..0000000000
--- a/.changeset/built-moment-transition-5799.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-'@object-ui/app-shell': minor
----
-
-The built-moment transition (#5799): a build conversation that has produced a WHOLE-APP build auto-routes to `/studio/<pkg>/interfaces` — on live completion and on reopening the conversation — after idempotently re-keying the thread under the `app:<pkg>:build` cache key the Studio dock resolves, so the workbench's right rail continues the SAME conversation. Cold start keeps the full-page surface; the dock's 以完整页面打开 door carries a sticky per-conversation opt-out so the one sanctioned way back is never bounced straight to Studio.
diff --git a/.changeset/built-transition-published-5799.md b/.changeset/built-transition-published-5799.md
deleted file mode 100644
index 69bd9c0cfa..0000000000
--- a/.changeset/built-transition-published-5799.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-'@object-ui/plugin-chatbot': patch
-'@object-ui/app-shell': patch
----
-
-The built-moment transition (#5799) now fires on auto-publish environments too: `detectBuiltAppPackage` reads the raw build envelope (`status:'drafted'` OR `'published'`, packageId + an `app` item), because an auto-publish posture rewrites apply_blueprint's envelope to `published` and the drafted-only `draftReview` lift never fired there — measured live on staging, where reopening a built conversation stayed on the full page.
diff --git a/.changeset/calendar-explain-network-escape-5438.md b/.changeset/calendar-explain-network-escape-5438.md
deleted file mode 100644
index 18359f993f..0000000000
--- a/.changeset/calendar-explain-network-escape-5438.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
----
-
-Tests only — this publishes nothing, declared explicitly with an empty frontmatter
-rather than left undeclared. No package `src/` is touched; the only file changed is
-`packages/plugin-calendar/src/object-calendar-renderer.propsContract.test.tsx`.
-
-Stops `object-calendar-renderer.propsContract.test.tsx` from making four real outbound
-connections to `127.0.0.1:3000` while it stays green.
-
-`happy-dom`'s default document origin is `http://localhost:3000/`, so a relative-URL
-`fetch` that nothing intercepts resolves against that origin and leaves the process for
-real. The escaping request is `@object-ui/plugin-detail`'s record-level explain probe
-(`useRecordEditable`, `POST /api/v1/security/explain`): the file's one DEFAULT-navigation
-`onEventClick` case opens `ObjectCalendar`'s overlay drawer, which renders
-`RecordDetailDrawer` → `DetailView`, which gates its Edit/Delete CTAs on a per-record
-write verdict. With no `apiFetch` on the `SchemaRendererProvider` this file wraps every
-case in, the hook's `apiFetch ?? fetch` fallback reaches the bare global `fetch` — and the
-hook fails open on the resulting connection failure, so the escape was invisible to every
-existing assertion.
-
-Same defect class as objectui#3339 (`plugin-detail`, closed by PR #4105), objectui#5225
-(`plugin-report`) and objectui#5280 (`plugin-dashboard` `DatasetWidget`) — a new consumer
-of an already-diagnosed hook, not a new root cause. Fixed the way #4105 settled it:
-`installExplainDouble()` answers the probe from a recording double instead of the
-network, installed for every case in the file (not only the one that reaches it, since
-the probe is `DetailView`'s own wiring and invisible from this file's schema authoring).
-`visible: true` reproduces the pre-fix fail-open behaviour exactly, so no existing
-assertion changes meaning.
-
-A new pinned test — the file's counter-probe — opens the DEFAULT-navigation drawer and
-asserts the double is actually reached, twice (`update` and `delete`), with the expected
-URL and request body. Confirmed load-bearing by reverse verification: with the double
-temporarily disabled, the same case brings back all four `ECONNREFUSED` and fails that
-new assertion (`explainCalls` stays empty instead of reaching length 2).
diff --git a/.changeset/calendar-readme-schema-keys-5045.md b/.changeset/calendar-readme-schema-keys-5045.md
deleted file mode 100644
index eaf0ed0831..0000000000
--- a/.changeset/calendar-readme-schema-keys-5045.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-'@object-ui/plugin-calendar': patch
----
-
-`README.md`'s "Schema API / CalendarView" block described a `CalendarViewSchema`
-that does not exist. Measured against the interface itself
-(`packages/types/src/complex.ts`) and its zod mirror: `events` — the schema's
-only required key besides `type` — was published as `events?`, so a reader
-following the README omits it and TypeScript rejects the node; `defaultDate` was
-`string` where the schema says `string | Date`; and `onDateClick` was listed as a
-schema key when it is a `CalendarViewProps` **component** prop, sending readers
-to a different package's surface for a key `calendar-view` does not have (the
-schema's key is `onDateChange`). The block also listed 6 of the schema's 13 keys
-with nothing saying it was a summary (objectui#5045).
-
-The block now carries the requiredness the schema declares, names itself a
-partial summary of `CalendarViewSchema`, and adds the author-facing
-`defaultView` / `view` / `views` / `editable` / `date`. It also states plainly
-what the registered `calendar-view` renderer actually reads — it builds events
-from the node's `data` array and drops an authored `events` key (objectui#4433) —
-so the corrected requiredness does not itself become a new wrong instruction.
-
-This is a documentation fix to a file `plugin-calendar` publishes to npm, which
-is why it carries a version: the npm landing page only picks up the correction
-on a release. No behaviour, export, type, or `dist` byte changes. The pin test
-added alongside it publishes nothing.
diff --git a/.changeset/calendar-view-event-rename-5044.md b/.changeset/calendar-view-event-rename-5044.md
deleted file mode 100644
index 0ba8d30bf3..0000000000
--- a/.changeset/calendar-view-event-rename-5044.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-'@object-ui/plugin-calendar': patch
----
-
-`@object-ui/plugin-calendar` now exports the `CalendarView` component's runtime event
-type as **`CalendarViewEvent`**, and keeps `CalendarEvent` as a **`@deprecated` alias**
-of it. **Non-breaking:** the alias is a working re-export denoting the same type, so
-code importing `CalendarEvent` from this package keeps compiling unchanged — nothing is
-removed and no behaviour changes.
-
-Why: `@object-ui/types` exports its own `CalendarEvent`, the AUTHORING event
-(`id: string`, `start` / `end` accept ISO strings with `end` required, plus
-`description`), while this package's was the runtime event (`id: string | number`,
-`start: Date`, `end?: Date`). Neither is assignable to the other, and IDE auto-import
-chose between the two identical names essentially at random — the wrong pick surfaced as
-a remote `TS2322` about `Date` rather than as a wrong import, which is how this package's
-own README example stayed uncompilable through an earlier import-path fix. The authoring
-type keeps the canonical `CalendarEvent` name; the runtime type gets the self-describing
-one (objectui#5044, following the `ObjectCalendarProps` -> `ObjectCalendarComponentProps`
-rename in objectui#4650).
-
-Write `CalendarViewEvent` in new code.
diff --git a/.changeset/calendar-view-mode-agenda-retired-5740.md b/.changeset/calendar-view-mode-agenda-retired-5740.md
deleted file mode 100644
index f50f849b41..0000000000
--- a/.changeset/calendar-view-mode-agenda-retired-5740.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-'@object-ui/types': minor
----
-
-`'agenda'` leaves `CalendarViewMode` and the zod `CalendarViewModeSchema`
-(objectui#5740 — the value-level residue of objectui#5667's key-level
-convergence of `CalendarViewSchema` on the registered `calendar-view`
-renderer's measured read set; ADR-0049 enforce-or-remove).
-
-The union declared a value nothing enforced: the registered renderer's `view`
-input declares `enum: ['month','week','day']`, `resolveAuthoredView` resolves
-any off-enum value — `'agenda'` included — to `undefined` (the component's
-`'month'` default), and `CalendarView` renders no agenda view. An author
-writing the type-legal, zod-valid `view: 'agenda'` got a month calendar with
-no error or warning. No in-repo, example, or catalog app authors
-`view: 'agenda'` (measured during objectui#5667's sweep and re-measured for
-this change, including the objectstack tree).
-
-**This narrows the accept set — unlike #5667's key retirements, which created
-no new rejections.** `view` is a declared key, and declared keys are validated
-even under `.passthrough()`, so `view: 'agenda'` is now a **validation error
-that previously parsed green** (an `invalid_value` issue on the `view` path,
-offering `month`/`week`/`day`). Undeclared keys still pass through unchanged.
-Breaking on the published zod surface; ships as `minor` per this repo's
-version-alignment policy (majors track `@objectstack`).
-
-The runtime boundary is unchanged: an off-union `view` in raw metadata still
-falls back to the component's `'month'` default at the renderer, and the
-registry input already declared the three-value enum. Docblocks, the schema
-reference table, and the zod `describe` no longer teach an `'agenda'`
-fallback.
diff --git a/.changeset/calendar-view-schema-converge.md b/.changeset/calendar-view-schema-converge.md
deleted file mode 100644
index 61f9a3c1d7..0000000000
--- a/.changeset/calendar-view-schema-converge.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-'@object-ui/types': minor
-'@object-ui/plugin-calendar': patch
----
-
-`CalendarViewSchema` (TS interface and zod mirror) converges on the registered
-`calendar-view` renderer's measured read set (objectui#5667, maintainer ruling
-option A — the renderer is authoritative).
-
-**Breaking for consumers of the published type** (deliberate; per-repo policy
-breaking changes ship as `minor` — the fixed group's `major` tracks
-`@objectstack`):
-
-- Nine inert keys are retired: `events` (the interface's only required key,
-  which the renderer deliberately drops — objectui#4433), `defaultView`,
-  `defaultDate`, `date`, `views`, `editable`, `onEventCreate`,
-  `onEventUpdate`, `onDateChange`. None had a read site on the authored-node
-  path and no measured app authors them (ADR-0049 enforce-or-remove).
-- The type now declares what the renderer actually reads: `data`, `titleField`,
-  `startDateField`, `endDateField`, `allDayField`, `colorField`, `view`,
-  `currentDate`, `allowCreate`, `className`, plus the two host-only function
-  hatches it forwards (`onEventClick`, `onViewChange`).
-- Practical radius, measured: `BaseSchema` carries an index signature and the
-  zod `BaseSchema` is `.passthrough()`, so nodes still authoring retired keys
-  neither fail to compile nor get rejected at validation — they are simply no
-  longer declared, documented, or type-checked. The material accept change is
-  that zod no longer **requires** `events`: a `{ "type": "calendar-view" }`
-  node without it now validates (previously the one key validation demanded
-  was the one key guaranteed to do nothing).
-
-Runtime renderer behaviour is unchanged. `@object-ui/plugin-calendar`'s README
-and `content/docs/api/schema-reference.md` are repaired to the converged
-surface in the same change, so no copy of the old contradiction survives.
diff --git a/.changeset/canvas-design-run-5800.md b/.changeset/canvas-design-run-5800.md
deleted file mode 100644
index 18e7c49388..0000000000
--- a/.changeset/canvas-design-run-5800.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-'@object-ui/app-shell': minor
----
-
-设计⇄运行 on the Interfaces canvas (#5800): a two-state switch in the canvas header flips the SAME renderer between design (selection + inspector + design overlays) and an interactive runtime (click 新建, enter records) — ADR-0080's design=run pivot made visible; selection context survives the round trip. The topbar's 打开应用 teleport is retired (run mode is the in-workbench way to try the app), and the topbar's app detection now matches the pillar's (draft-app fallback, re-resolved on draft saves and the metadata-refresh pulse) so a deep-link to /access can no longer claim the package has no app while /data shows one.
diff --git a/.changeset/catalog-layout-props-sweep-4891-4890.md b/.changeset/catalog-layout-props-sweep-4891-4890.md
deleted file mode 100644
index 92f13f1872..0000000000
--- a/.changeset/catalog-layout-props-sweep-4891-4890.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-'@object-ui/components': minor
----
-
-`stack` now reads its spacing from `gap` and nothing else — the undeclared
-`spacing` key it also accepted is gone (objectui#4890).
-
-`StackSchema extends Omit<FlexSchema, 'type'>`, whose spacing key is `gap`.
-`spacing` was declared by nothing: not the TypeScript interface, not the zod
-mirror, not the renderer's own `inputs` registration. `stack.tsx` read it anyway,
-as `schema.gap ?? (schema as any).spacing ?? 2` — and the `as any` is the whole
-story, since it existed to get past the type system saying the key was not there.
-A lenient consumer leg does not stay in the consumer: it becomes a second
-de-facto contract that producers write to, and 135 nodes across 39 files of the
-shipped schema catalog did exactly that. Every one of them rendered correctly, so
-nothing ever pointed at it, while the examples went on teaching the key to every
-author who copied them.
-
-The trap it was one edit away from springing: `flex` — semantically a `stack`
-with a `direction` — never read `spacing`, so re-typing any of those nodes would
-have dropped the spacing to the default silently. Fixed at the producer
-(AGENTS.md #0.1): those nodes now author `gap`, carrying the same value, and the
-alias is deleted rather than legalised into `StackSchema`, where it would only
-have been a second name for `gap`.
-
-**If you author `spacing` on a `stack`**, rename it to `gap`; the value and the
-rendering are unchanged. A `stack` still carrying `spacing` now renders the
-default gap, exactly as a `flex` always did.
-
-Also in the same sweep, and visible only in the published example catalog rather
-than in any package API: 140 catalog nodes that were already `flex` / `stack` /
-`container` stopped hand-writing their own declared props in `className`
-(`items-center` → `align`, `justify-between` → `justify`, `gap-2` → `gap`,
-`flex-wrap` → `wrap`, `p-4` → a container's `padding`) — 231 tokens in all
-(objectui#4891). Breakpoint-prefixed overrides and everything decorative stay in
-`className`, because the props are not responsive. Both facts are ratcheted in
-`examples/schema-catalog/test/layout-props-conversion.test.tsx`.
diff --git a/.changeset/chart-height-chain-5451.md b/.changeset/chart-height-chain-5451.md
deleted file mode 100644
index 3ab5836770..0000000000
--- a/.changeset/chart-height-chain-5451.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-'@object-ui/plugin-charts': patch
----
-
-`ObjectChart`'s wrapper div now carries `h-full`, keeping the height chain intact from a dashboard grid cell's declared height down to the element Recharts measures. Previously the chain died at the plain auto-height wrapper: `height: 100%` on the chart container computed to `auto`, Recharts measured a permanent zero, and only the `CHART_MIN_HEIGHT` floor (#5503) kept dashboard charts visible — at a fixed floor height instead of filling the cell (#5451). Under auto-height parents `h-full` resolves to `auto`, so non-dashboard hosts are unchanged.
diff --git a/.changeset/chat-transport-memo-4187.md b/.changeset/chat-transport-memo-4187.md
deleted file mode 100644
index 93978f70c6..0000000000
--- a/.changeset/chat-transport-memo-4187.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-'@object-ui/plugin-chatbot': patch
----
-
-`useObjectChat` no longer rebuilds its `DefaultChatTransport` on every render
-(objectui#4187).
-
-The transport `useMemo` listed the caller's `body` and `headers` in its dep list.
-Both are object props and every caller passes a fresh literal each render — the AI
-page's chat pane builds its `body.context` inline — so the memo never hit and a
-transport was constructed on every render of every chat surface, which during a
-streaming turn is once per token batch.
-
-`body` and `headers` are now read through refs inside
-`prepareSendMessagesRequest`, the idiom this hook already uses for the live model
-(`modelRef`) and the handoff conversation id (`parentConvRef`), and they are gone
-from the dep list. Unlike memoizing at each call site, a future caller cannot
-undo it.
-
-No user-visible behaviour changes: `@ai-sdk/react` keeps the transport in a ref
-and re-keys its `Chat` only on `chat`/`id` (verified against the installed
-4.0.68), which `useObjectChat` passes neither of, so the message thread was never
-at risk — the rebuild was pure waste. The one real difference is *when* the two
-values are sampled: a send now reads them at send time, so it observes the values
-of the most recent render instead of those of the last render that happened to
-rebuild the transport. That is never staler than before, and it is pinned by
-`useObjectChat.transportIdentity.test.tsx`.
diff --git a/.changeset/check-schema-positive-marker-and-skip-count.md b/.changeset/check-schema-positive-marker-and-skip-count.md
deleted file mode 100644
index 84f3ac9f6b..0000000000
--- a/.changeset/check-schema-positive-marker-and-skip-count.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-'@object-ui/cli': minor
----
-
-`objectui check` judges a file's `type` only when the file is recognisable as an ObjectUI schema, and reports how many it declined to judge.
-
-A root `type` was treated as a component key wherever it appeared. `type` heads at
-least seven unrelated JSON vocabularies, and the most common of them is
-`package.json`'s `"type": "module"` — so the first line a user saw running
-`objectui check` in their own project was a warning about their own package
-manifest. Measured at this repository's root: 46 warnings, 45 of them
-`package.json` (objectui#5127).
-
-A file now enters type judgement only when its root carries a structural key
-declared on `BaseSchema` — `children`, `body`, `className`, `placeholder`,
-`style`, the `visible`/`hidden`/`disabled` predicate family, `testId`,
-`ariaLabel`. Every other root-`type` vocabulary — JSON Schema's `"array"`, an
-`.eslintrc.json`'s `"commonjs"`, a package manifest's `"module"` — is simply
-never judged. The key set is read out of the node contract rather than invented,
-and it is closed: it grows only when `BaseSchema` grows.
-
-A list of filenames to exclude was the alternative and was rejected: it is a
-second hand-maintained list of the shape objectui#5115 had just finished
-deleting, and it can only ever enumerate the foreign vocabularies someone already
-thought of. This is a positive marker instead.
-
-Because the marker narrows what is checked, the command now also reports the
-count of files that had a root `type` and no marker, together with the marker
-keys that opt one back in. That number is the coverage this gate gives up until
-schema files are recognisable, and printing it is what keeps the loss visible
-rather than silent. The `.yaml`/`.yml` half of the scan is unchanged — it was
-never type-judged, before this change or after it. Exit codes are untouched: a
-JSON parse failure remains the only thing that fails the run.
-
-No public `$schema` URL is introduced. An earlier revision also admitted a file
-whose root `$schema` had an `objectui.org` host; the maintainer ruled against
-minting that identifier (2026-08-20, objectui#5127), so the structural key is the
-only marker. Because the matching was host-based rather than literal, that arm
-can be added later without invalidating a single file.
diff --git a/.changeset/chilled-donkeys-shave.md b/.changeset/chilled-donkeys-shave.md
deleted file mode 100644
index 745cbf50eb..0000000000
--- a/.changeset/chilled-donkeys-shave.md
+++ /dev/null
@@ -1,4 +0,0 @@
----
----
-
-Test-only change to the console's public-block binding-reach probe: its `sections` fixture sample is now spec-valid (an array of section objects, not a bare string), its `formType` sample is a real form variant, and the crash guard runs ahead of the branch split so it covers every candidate. No published behaviour changes — the renderers are untouched.
diff --git a/.changeset/cli-validate-field-widget-namespace-5449.md b/.changeset/cli-validate-field-widget-namespace-5449.md
deleted file mode 100644
index 2984a2ef41..0000000000
--- a/.changeset/cli-validate-field-widget-namespace-5449.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-'@object-ui/types': patch
-'@object-ui/cli': patch
----
-
-`objectui validate` now refuses a form field whose widget id names a namespace
-other than `field:`, matching the verdict `@object-ui/core`'s `validateSchema`
-has given since objectui#5375 (objectui#5449).
-
-The CLI reaches `FormFieldSchema` through `safeValidateSchema`, and that schema
-declared `type` and `widget` as bare optional strings — so a field typed
-`ui:password` validated clean while the runtime validator rejected the same
-document with `UNRESOLVABLE_FIELD_WIDGET_NAMESPACE`. The CLI is the surface an
-author actually runs before shipping, so it was the one handing out the false
-green: an author did exactly the diligence objectui#5375 asks for and still
-shipped metadata that renders a secret into a plain text box.
-
-A `superRefine` on `FormFieldSchema` now states the rule, mirroring core's
-precedence (`widget` before `type`), the key it blames, its error code and its
-message verbatim, so the two entry points cannot describe one defect two ways.
-
-**This rejects documents that previously validated.** Only colon-qualified
-field widget ids outside the `field:` namespace are affected — `field:`-prefixed
-ids and bare names such as `password` still pass, registered or not. A field
-carrying, say, `type: 'ui:password'` must be rewritten as `password` or
-`field:password`; it never rendered as a password box in any case.
-
-Which of the repo's authoring-time validators is canonical remains open
-(objectui#4631) — this states the rule on the zod side rather than unifying
-them.
diff --git a/.changeset/closure-claims-bounded-or-derivable.md b/.changeset/closure-claims-bounded-or-derivable.md
deleted file mode 100644
index ccf0743e1b..0000000000
--- a/.changeset/closure-claims-bounded-or-derivable.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
----
-
-Documentation and gate-only change (objectui#6186). The `thresholds` closure claim
-carried by `@object-ui/sdui-parser`'s unconsumed-widget-option census was written
-twice — in the census header and in the plugin-dashboard docs page — and is now
-single-sourced onto the census header, with a new gate re-deriving it from source
-on every test run. The block-schema page's whole-tree negative is bounded to the
-block family's own keys.
-
-The only edit to published source is the census module's comment header: no
-exported symbol, runtime behaviour or emitted diagnostic changes, so this releases
-nothing.
diff --git a/.changeset/cloud-connection-bind-failure-i18n-5054.md b/.changeset/cloud-connection-bind-failure-i18n-5054.md
deleted file mode 100644
index 68a88aac2c..0000000000
--- a/.changeset/cloud-connection-bind-failure-i18n-5054.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-'@object-ui/app-shell': patch
-'@object-ui/i18n': patch
----
-
-A cloud-connection bind failure now reads in the user's language whichever clock
-noticed it (objectui#5054).
-
-One abandoned device approval could be noticed by either of two clocks, and the
-Cloud Connection panel had a different answer for each. When the panel's own
-`expires_in` deadline fired first it rendered `cloudConnection.errors.expired` —
-translated in all ten packs. When the SERVER noticed first, `/bind/poll` answered
-HTTP 400 with `message: 'Device authorization failed: expired_token'`; `getJson`
-threw a bare `Error` carrying only that sentence, and the catch rendered it
-verbatim. Same user, same failure, two languages, decided by which clock got
-there first — visible on a zh console as the same abandoned approval reading
-Chinese or English depending on whether the tab sat open past `expires_in`.
-
-`getJson` now carries the envelope's `declaredCode` and `code` across its throw,
-and a single closed map turns the two RFC 8628 outcomes a user can actually cause
-into console copy: `expired_token` → the existing `cloudConnection.errors.expired`,
-`access_denied` → a new `cloudConnection.errors.accessDenied` added to all ten
-locale packs. `declaredCode` is read first, because ADR-0112 keeps the upstream
-spelling there — `code` is `DEVICE_CODE_FAILED` for both.
-
-Every other code is unchanged: `invalid_grant`, and anything upstream invents
-next, still render the wire `message`, which stays the single source of truth for
-failures this console has no copy for. No API, export or resolver was widened.
diff --git a/.changeset/clusterradius-unit-doc-5020.md b/.changeset/clusterradius-unit-doc-5020.md
deleted file mode 100644
index 00f5731ef8..0000000000
--- a/.changeset/clusterradius-unit-doc-5020.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-'@object-ui/plugin-map': patch
----
-
-`ObjectMapProps.clusterRadius`'s JSDoc said "in pixels"; `clusterMarkers` has
-always used it as a coordinate-degree grid cell edge (`radius / 2 ** zoom`,
-divided into the marker's `[lng, lat]` degrees), not a screen-space radius —
-a host tuning clustering granularity by the documented unit would get a
-completely different result than intended (objectui#5020).
-
-No behavior, default, or name changes: clustering, the >100-visible-marker
-auto-threshold, and tap-through zoom are unaffected, and `clusterRadius` has
-no call sites outside `plugin-map/src` today (re-confirmed repo-wide,
-including `apps/`, `examples/`, and the `objectstack` spec/server repo — the
-default of `50` is what runs everywhere). This is a doc-comment correction
-only, bringing the JSDoc in line with the README's already-correct wording
-(post objectui#5002).
-
-The latitude-anisotropy trade-off (a degree grid distorts east-west as
-latitude rises) is a known design trade-off, not part of this fix.
diff --git a/.changeset/component-meta-converge-and-deprecate-alias-5893.md b/.changeset/component-meta-converge-and-deprecate-alias-5893.md
deleted file mode 100644
index 657412bdca..0000000000
--- a/.changeset/component-meta-converge-and-deprecate-alias-5893.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-'@object-ui/types': minor
----
-
-`ComponentMeta` is now declared once and re-exported, and `PluginComponentMeta` is
-deprecated in favour of `ComponentMeta` (objectui#5893).
-
-## The convergence
-
-`@object-ui/types` published `ComponentMeta` twice, from two different declarations:
-`base.ts` and `plugin-scope.ts` (the latter published as `PluginComponentMeta`). They
-were structural copies, not an alias pair. `plugin-scope.ts`' `ComponentMeta` is now
-`export type { ComponentMeta } from './base.js'` — the disposition objectui#4580 ruled
-for the identical shape, *a structural copy would reproduce the defect the moment either
-side moved*, and the same move objectui#5671 made for the sibling type `ComponentInput`
-in the same file.
-
-Either side had already moved. `base.ts` declared eleven keys; the plugin-scoped copy
-declared nine — the same nine, **minus `tags` and `description`**. So a plugin author
-typing against the plugin-facing declaration could not write two keys the main surface
-advertises, and which the runtime validator already accepted: `ComponentMetaSchema` in
-`zod/base.zod.ts` declares all eleven, so two of the three authorities agreed and the
-plugin-facing one did not. `resizeConstraints`' six members were identical in both, so
-the delta was exactly those two keys.
-
-What changes for a consumer: `tags` and `description` become writable on the
-plugin-facing type. Nothing narrows — no key is removed and no key's type changes, so no
-existing registration stops compiling. The convergence buys **acceptance** of two keys;
-it buys no rejection of anything. `ComponentMetaSchema` is a plain `z.object` with no
-`.strict()`, so it strips unknown keys rather than refusing them, and that is unchanged
-here.
-
-## The alias deprecation, sequenced after it
-
-`PluginComponentMeta` — the published alias for the plugin-scoped declaration — is now
-`@deprecated` in favour of `ComponentMeta`. **`PluginComponentMeta` is the name to search
-for** if you import it; replace it with `ComponentMeta` from the same entry point.
-
-This is stage 1 of objectui#5674's two-stage retirement (maintainer ruling, 2026-08-22:
-deprecate for a release, then remove). Nothing is removed here — the export still exists
-and still names the same type.
-
-The ordering is deliberate and is why the two halves ship together. Until the convergence
-above, the alias named a genuinely different nine-key interface; deprecating it then
-would have warned consumers about a name that was still about to change meaning. It is
-deprecated now, at its final meaning.
-
-**Why a deprecation window rather than a deletion.** The measurement that licenses
-deleting an export from a published package is *"no importer"*, and what can be measured
-from inside this repository is only *"no importer here"*. In-repo, `PluginComponentMeta`
-has exactly one occurrence — its own export line — searched across every root
-(`packages/`, `apps/`, `content/`, `docs/`, `skills/`, `examples/`, `e2e/`, `scripts/`,
-`eslint-rules/`, `public/`, `.changeset/` and the root docs) plus the sibling
-`objectstack` framework checkout, with controls searched identically so a broken search
-could not read as a clean one. What no search here can see is a consumer on npm. **That
-external caveat is unchanged from objectui#5674 and is not being dropped:** the window
-converts a silent break into a warned one before stage 2 lands. Stage 2 removes the alias
-and the now-dead re-export in `plugin-scope.ts` that exists only to feed it, and ships as
-a `minor` under this repo's policy that its own breaking changes never declare `major`.
-
-## Pinned by identity, not by member set
-
-A new test asserts that `plugin-scope.ts` re-exports the declaration and declares no
-`ComponentMeta` of its own. A member-set assertion cannot do this job: TypeScript is
-structurally typed, so a local re-declaration carrying the same eleven keys is mutually
-assignable with the imported one and passes every type-level check. A member-identical
-structural copy is exactly what objectui#4580 predicted would drift and exactly the state
-this card recorded — this copy started identical and acquired its two-key delta later.
-The member-set checks are kept alongside the identity pin, labelled as the control that
-shows what it cannot see.
diff --git a/.changeset/componentinput-reexport-4972.md b/.changeset/componentinput-reexport-4972.md
deleted file mode 100644
index 910e0a7348..0000000000
--- a/.changeset/componentinput-reexport-4972.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-'@object-ui/core': minor
-'@object-ui/types': minor
----
-
-`ComponentInput` is now declared once and re-exported, instead of restated in three
-places (objectui#4972).
-
-`@object-ui/core`'s `ComponentInput` (`registry/Registry.ts`) and `@object-ui/types`'
-plugin-scoped `ComponentInput` (`plugin-scope.ts`, published as `PluginComponentInput`)
-were structural copies of the interface in `@object-ui/types`' `base.ts`. Both are now
-re-exports of that one declaration, which is the disposition objectui#4580 ruled for the
-identical shape — *a structural copy would reproduce the defect the moment either side
-moved* — and the way `core/src/types/index.ts` already handles `SchemaNode`.
-
-Either side had already moved. `base.ts` declared thirteen keys; both copies declared
-nine, so `min` / `max` / `step` / `placeholder` were missing from **the copy every
-component registration actually imports**. Those four keys were unwritable at any real
-registration — a plain TypeScript error at the call site — while `ComponentInputSchema`
-(the zod schema) and `ComponentMeta.inputs` both accepted them. The publication face
-advertised four keys the authoring face rejected. Measured over the repository, no
-registration had tried to write one yet, so nothing a user hits was broken today; what
-changes is that the four keys become writable, and there is no longer a second
-declaration for the next widening to miss.
-
-`ComponentInput`'s arm vocabulary (`ComponentInputControlType`) was already a single
-declaration imported by all three sites (objectui#3832); this converges the rest of the
-interface.
-
-Measured, not assumed: `@object-ui/core`'s published entry `dist/index.d.ts` is
-byte-identical across the change (sha256 `f6494f80…`, both legs). That gauge is reported
-here only with its control — a probe that added a *required* key to `ComponentInput` left
-the same file byte-identical, because `dist/index.d.ts` is a 63-line barrel of
-`export *` lines that names `ComponentInput` zero times. The gauge that can actually fail
-is the emitted declaration file: `dist/registry/Registry.d.ts` changes, as does
-`@object-ui/types`' `dist/plugin-scope.d.ts`, and those two files are the *only* emitted
-declarations that change in either package.
-
-`WidgetInput`'s union-arm capability is deliberately untouched — a different gate path
-and a separate judgment.
diff --git a/.changeset/componentrendererprops-reexport-4594.md b/.changeset/componentrendererprops-reexport-4594.md
deleted file mode 100644
index 52cad5745a..0000000000
--- a/.changeset/componentrendererprops-reexport-4594.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-'@object-ui/core': minor
----
-
-`ComponentRendererProps` is now declared once and re-exported, instead of
-hand-declared a second time in `@object-ui/core` (objectui#4594).
-
-`@object-ui/core`'s `ComponentRendererProps` (`src/types/index.ts`) was a
-non-generic interface typing `schema` as `SchemaNode`, while
-`@object-ui/types`' declaration of the same name is generic —
-`ComponentRendererProps< TSchema extends BaseSchema = BaseSchema >` with
-`schema: TSchema`. Same name, both exported from their package entry, from two
-packages the same consumers import together: which declaration a call site got
-depended on which package it reached for, and the two disagree about whether a
-primitive node is admissible. Core's is now a re-export of types', which is the
-disposition objectui#4580 ruled for `SchemaNode` two lines above it in the same
-file, and objectui#4972 for `ComponentInput` — *a structural copy would
-reproduce the defect the moment either side moved*.
-
-**Published-surface effect, and the reason it is not neutral.** Resolved
-through the TypeScript checker from `core/dist/index.d.ts` over a clean rebuild
-of both legs, `ComponentRendererProps` as reached through `@object-ui/core`
-moves from non-generic with
-`schema: BaseSchema | string | number | boolean | null | undefined` to
-`ComponentRendererProps<TSchema>` with `schema: TSchema`, defaulting to
-`BaseSchema`. `schema` therefore **narrows** back to the object form — core's
-copy had silently widened when objectui#4608 made core's `SchemaNode` a
-re-export of types' union — and the type gains a parameter. **Nothing imported
-it**, on either side, re-verified repo-wide on the merged ref, so no call site
-can observe either move; the narrowing is recorded here because it is a change
-to a published type, not because a consumer is affected.
-
-A compile-time pin now holds the reconciliation from
-`@object-ui/react` — the only position that resolves both packages through
-`node_modules` — alongside the existing `SchemaNode` one. It is a test-only
-addition and emits nothing, so `@object-ui/react` takes no bump of its own.
diff --git a/.changeset/components-react-page-published-dts-text-5666.md b/.changeset/components-react-page-published-dts-text-5666.md
deleted file mode 100644
index 6b021a41f0..0000000000
--- a/.changeset/components-react-page-published-dts-text-5666.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-'@object-ui/components': patch
----
-
-Published declaration text for the react page renderer changed: `kind:'react'` page `source` styling is now stated in the shipped `.d.ts`
-
-`dist/renderers/layout/react-page.d.ts` is in this package's npm tarball, and the
-declaration emitter reproduces that module's file-header documentation into it
-verbatim. Two things a consumer reads — on hover over `ReactKindPage` in an editor,
-or straight out of the tarball — now say something different:
-
-- The injected-scope note no longer tells authors that layout is left to "plain
-  HTML + Tailwind". It says plain HTML.
-- A new paragraph states the styling contract for `kind:'react'` page `source`:
-  `source` is runtime metadata, not build input. Style with inline `style` objects
-  using `hsl(var(--token))` theme colors, and render overlays through `ObjectForm`
-  with `formType` `"drawer"` or `"modal"` rather than a hand-rolled `fixed inset-0`
-  backdrop. Do **not** author Tailwind utility classes in page `source`: the
-  console's Tailwind is compiled at build time by scanning the console's own `src`
-  and there is no safelist, so an authored utility class silently produces no CSS
-  and no error anywhere. `os validate` reports it as
-  `page-source-className-tailwind`. (ADR-0065; ADR-0080's 2026-06-30 amendment;
-  see `content/docs/guide/react-pages.md`.)
-
-That is guidance an author can act on, and it contradicts what this package's
-declarations previously told them, so it is a change to the published surface
-rather than an internal edit. No runtime behaviour changed and no export moved.
-
-This entry is corrective. The text landed under objectui#5461 with a changeset that
-declared only `@object-ui/types`, on the stated grounds that the edits "do not
-project into any `.d.ts`". Rebuilding the package shows that they do — the reasoning
-and the measurement are recorded in `scripts/check-changeset-presence.mjs`'s header,
-where the next author will meet them.
diff --git a/.changeset/confirm-card-terminal-5695.md b/.changeset/confirm-card-terminal-5695.md
deleted file mode 100644
index 7d3d67a83e..0000000000
--- a/.changeset/confirm-card-terminal-5695.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-'@object-ui/plugin-chatbot': minor
-'@object-ui/app-shell': patch
-'@object-ui/i18n': patch
----
-
-The 确认修改 (confirm changes) card now carries a UI-owned terminal state after approval (#5695): `detectReplayOutcome` lifts the confirm-replay envelope (`replay_*` tool results) into 应用中 / 已生效 / 已暂存为草稿（含内联发布）/ 未生效（含 publishError 首行）, rendered on the original card across the live, hydration/share, and localStorage-cache converters. A failed in-turn publish no longer rehydrates as an ordinary draft card with a live Publish button — the UI-rendered refusal is the layer a model cannot narrate over. New `console.ai.changesApplying/Applied/Drafted/Failed` keys in all ten locale packs.
diff --git a/.changeset/confirm-handler-published-type-5835.md b/.changeset/confirm-handler-published-type-5835.md
deleted file mode 100644
index d141b7648e..0000000000
--- a/.changeset/confirm-handler-published-type-5835.md
+++ /dev/null
@@ -1,4 +0,0 @@
----
----
-
-Type `RecordDetailView`'s confirm handler as the published `ConfirmationHandler` instead of an inline re-spelling of the same shape, and pin that both of `app-shell`'s confirm runtimes hand `ActionConfirmDialog` the same field set. Releases nothing: the annotation is erased at build time (the emitted JS for `RecordDetailView.tsx` is byte-identical before and after), the handler is not exported, and no published surface changes.
diff --git a/.changeset/confirm-runtime-close-parity-6034.md b/.changeset/confirm-runtime-close-parity-6034.md
deleted file mode 100644
index 94766b7b4a..0000000000
--- a/.changeset/confirm-runtime-close-parity-6034.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-Console action runtime: closing an action confirm dialog now keeps the dialog's
-text instead of blanking it mid-fade.
-
-`useConsoleActionRuntime` reset its confirm state by replacing the whole object
-(`{ open: false, message: '' }`), which cleared `message` and dropped `options`.
-Radix keeps `AlertDialogContent` mounted through its exit animation, so the
-dialog's description went blank and its title and button labels reverted to
-their defaults while it was still fading out. It now flips only `open` and keeps
-every field, matching `RecordDetailView`'s second confirm runtime, which already
-closed this way. Both runtimes feed one `ActionConfirmDialog`; the parity pin now
-covers the close path as well as the open path.
diff --git a/.changeset/console-action-dispatch-envelope-5611.md b/.changeset/console-action-dispatch-envelope-5611.md
deleted file mode 100644
index a7e8555f25..0000000000
--- a/.changeset/console-action-dispatch-envelope-5611.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
----
-
-Internal: the console's admin-override notice now travels on a declared dispatch
-type instead of a cast (objectui#5611). No published API and no runtime
-behaviour changes, so this changeset declares "no release" rather than a bump —
-`@object-ui/app-shell` source moved, nothing it exports did.
-
-`overrideNotice` is the safety copy shown once, ahead of a privileged admin
-override that finalises an approval step over approvers who have not acted. Its
-producer (`DeclaredActionsBar`) reached its reader (`useConsoleActionRuntime`'s
-param-collection dialog) through a `dispatch as ActionDef` cast on one side and
-`action?: any` on the other, so nothing declared the key anywhere and the two
-could drift apart in silence — rename it on either side and the notice stops
-appearing with every test still green, because each side's suite spells the key
-itself.
-
-Both ends now share one declaration: `ConsoleActionDispatch`
-(`ActionDef & { overrideNotice?: string }`), a HOST-composed envelope that lives
-at the seam, in the one package where producer and reader both live. The cast is
-gone and both param-collection handlers narrow off `any` — which is what puts
-those functions under the compiler at all.
-
-The published `ActionDef` deliberately does NOT declare the key (maintainer
-ruling 2026-08-22): it is the authored-metadata mirror, and `overrideNotice` is
-the first key no author supplies, so declaring it there would make an unenforced
-key legally writable in metadata. That prohibition still holds exactly as
-written — `ActionDef` and `ACTION_DEF_KEYS` are unchanged.
-
-`@object-ui/core` is NOT untouched, and the reason is a separate declaration:
-the same ruling's item 4 adds `HOST_DISPATCH_ACTION_KEYS` to the key inventory
-so the dev-mode warning stops calling the host-composed key unknown. That change
-carries its own changeset (`host-dispatch-action-keys-5611.md`) and its own
-patch bump; this one remains the app-shell half, which publishes nothing.
diff --git a/.changeset/console-boot-request-dedup-5544.md b/.changeset/console-boot-request-dedup-5544.md
deleted file mode 100644
index 44270d6e83..0000000000
--- a/.changeset/console-boot-request-dedup-5544.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-'@object-ui/types': patch
-'@object-ui/app-shell': patch
-'@object-ui/console': patch
----
-
-The console's cold load no longer asks `/api/v1/runtime/config` or
-`/auth/me/localization` twice (objectui#5544).
-
-Two pairs of boot callers were racing each other for the same URL, with no shared
-provider between them, so no guard inside either component could see the other:
-
-- `GET /api/v1/runtime/config` — the pre-React branding script inlined in
-  `apps/console/index.html` (it runs during HTML parse so the tab title and
-  favicon are the operator's before the bundle is fetched) and
-  `initRuntimeConfig()`. Measured ×2 on prod and on staging. This is the
-  expensive one: the console `await`s `initRuntimeConfig()` before
-  `createRoot().render()`, so the duplicate sat on the critical path to first
-  paint, and at the control plane's ~0.5–1.4 s for this endpoint it also pushed
-  boot concurrency further past the server's pool knee.
-- `GET /api/v1/auth/me/localization` — `seedTenantLanguage()` on a device's true
-  first visit and `LocalizationFetchProvider` on every boot. The seed keeps
-  running past its 500 ms race by design and the provider mounts the moment that
-  race resolves, so on a first visit the two overlap. Measured ×2 on staging.
-
-`@object-ui/types` gains `sharedGetJson()`: callers that ask for the same GET
-while one is already in flight join that request instead of starting another. It
-shares the in-flight promise and nothing else — the entry is deleted the instant
-the request settles, so there is no cache, no TTL and no stale window, and a
-caller arriving after settle fetches fresh exactly as before. Rejections fan out
-to every sharer with the status intact (`LocalizationFetchProvider`'s retry
-policy still sees its own 503), each caller receives its own copy of the parsed
-body, and only GETs are eligible — a non-GET is refused rather than quietly
-rewritten.
-
-Requests that differ in credentials mode or headers keep separate identities, so
-the console's two deliberate `auth/get-session` calls — one Bearer-only with the
-cookie omitted to detect a stale token, then one through the cookie — stay two
-requests. Collapsing those would have destroyed the signal the first one exists
-to read.
-
-No component receives anything different: same payloads, same errors, one fewer
-round trip.
diff --git a/.changeset/console-boot-splash.md b/.changeset/console-boot-splash.md
deleted file mode 100644
index 7849076e82..0000000000
--- a/.changeset/console-boot-splash.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-'@object-ui/console': patch
----
-
-fix(console): paint a boot indicator during the pre-React white frame
-
-The console's `index.html` shipped an empty `<div id="root">`, so a hard
-navigation showed a pure-white page until the module graph had downloaded,
-evaluated and resolved the two round trips `main.tsx` awaits before
-`createRoot().render()`. Measured on this repository's production build with
-Playwright + CDP screencast (frames classified pixel-by-pixel, corroborated by
-the Paint Timing API): 1224-2016 ms of pure white on an unthrottled localhost,
-2289-2297 ms at 20 Mbps/80 ms RTT, and 5808-6167 ms on a Fast-4G profile.
-
-The document now carries the indicator itself — an inline style block and the
-same gradient tile `LoadingScreen` opens with — so it paints from the HTML
-parser, before the first chunk is requested. It is removed on React's first
-commit into `#root`, so it never doubles up with `LoadingScreen`, which
-continues to own the init screen and its ten-language copy.
diff --git a/.changeset/console-form-container-specs-one-declaration-5596.md b/.changeset/console-form-container-specs-one-declaration-5596.md
deleted file mode 100644
index 6f199b8c8d..0000000000
--- a/.changeset/console-form-container-specs-one-declaration-5596.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-'@object-ui/app-shell': patch
-'@object-ui/console': patch
----
-
-The two form CONTAINER contracts now have ONE declaration each, derived from
-`@objectstack/spec`, and the console reads them instead of its own copies.
-
-objectui#5542 converged the LEAF of this contract — the field spec — and left the
-two containers above it untouched, because converging them was a bigger call than a
-mechanical import. `FormSectionSpec` and `FormViewSpec` were each hand-declared
-twice under the same names, once in `packages/app-shell`'s `SchemaForm.tsx` and once
-in `apps/console`'s `FormPage.tsx`. Unlike the leaf — whose console copy was a clean
-subset — these two had **already drifted, in both directions**, so neither copy was a
-subset of the other and there were two live answers to "what may an author write":
-
-- `FormSectionSpec` — app-shell declared `description` / `visibleWhen` / `visibleOn`;
-  the console declared none of them. The console's `columns` admitted the string arm
-  (`'1' | '2' | '3' | '4'`); app-shell's took numbers only.
-- `FormViewSpec` — the console declared `label` / `groups` / `sharing` /
-  `submitBehavior`; app-shell stopped at `type` plus `sections`.
-
-The drift is decided by asking the **contract**, not by picking a side. `columns`
-does admit the string arm (`FormSectionSchema.columns` unions `z.enum(['1','2','3','4'])`
-with the four numeric literals, folded to a number by its own transform), so
-app-shell's numbers-only declaration was rejecting metadata the platform accepts —
-objectui#5040's own symptom, not a deliberate narrowing. `label` on the form view is
-the opposite answer: `FormViewSchema` **rejects** it (`unrecognized_keys`, measured
-against the installed `@objectstack/spec` 17.0.0), because a form config is titled,
-not labelled. The value that read actually finds is the VIEW's identity label, which
-arrives on the `ExpandedViewItem` envelope or beside the config on a flattened
-runtime overlay — so it is declared on `FormPage.tsx`'s own `FormViewBody`, next to
-the body it unwraps, rather than smuggled onto the form contract.
-
-Both types are therefore **derived from the spec's own `FormSection` / `FormView`
-with named narrowings** — the repo's sanctioned form for a spec-shaped local type
-(`scripts/check-spec-symbol-derivation.mjs`) — rather than restated. Every key the
-two layers agree on comes from the spec and cannot fall behind it; the four positions
-where this layer is deliberately narrower are each named in an `Omit` list and
-restated once next to its reason: `fields` keeps the converged 26-key leaf (deriving
-it would silently re-open #5542), and `label` / `description` / `visibleWhen` /
-`visibleOn` keep the shapes this repo's renderers and evaluators actually consume
-rather than the spec's `I18nLabel` and `ExpressionInput`. `apps/console`'s
-`submitBehavior` union — previously hand-written under the comment "Mirrors the spec
-FormView.submitBehavior union" — is now read back off the shared type, making the
-mirror structural. `@object-ui/app-shell` re-exports both names from its package root
-(type-only, erased at build — nothing is added to the bundle), because a type that
-cannot be imported is a type that gets retyped.
-
-The pins are what make future drift loud, and each half is pinned on both sides.
-`form-spec.containers.test.tsx` and `FormPage.viewSpec.test.ts` compare the
-non-narrowed half of each type against the spec's own symbol, so re-hand-writing
-either declaration fails `type-check` the day the spec moves rather than years later
-when someone reads two files side by side — and the console's pins read both types
-back out of the **exported** `buildSections` signature rather than naming them, so a
-re-inlined local copy fails even if it agrees on every key on the day it is written.
-Their liveness controls are what stop them being phantom checks: the removed copies
-are pinned NOT equal to the shared types (proving the `Equal` helper still
-discriminates), the renderer's honoured `RenderableSection` is pinned not equal
-either (so the authored-document and honoured-row types cannot be collapsed again),
-and an undeclared key is still rejected (so the derivation smuggled in no index
-signature or `any`). Every narrowing carries a matching negative pin, so "derived"
-cannot quietly become "widened to whatever the spec says".
-
-Behaviour is unchanged — the runtime always accepted these keys. The vitest halves
-prove it: a section spelling its column count as the string `'3'` lays out identically
-to the numeric `3` on both sides, and a section carrying the keys only one side used
-to declare builds the same rows.
diff --git a/.changeset/console-form-field-spec-one-declaration-5542.md b/.changeset/console-form-field-spec-one-declaration-5542.md
deleted file mode 100644
index 59b1a9fdc5..0000000000
--- a/.changeset/console-form-field-spec-one-declaration-5542.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-'@object-ui/app-shell': patch
-'@object-ui/console': patch
----
-
-The form-field authoring contract now has ONE declaration, and the console reads it
-instead of its own copy.
-
-objectui#5040 was not a missing key. It was that **two hand-written descriptions of
-one contract drifted**, and nothing could notice, because each was only ever checked
-against itself. PR #5537 converged the two app-shell descriptions into
-`views/metadata-admin/form-spec.ts`. A **third** survived in `apps/console`:
-`FormPage.tsx` declared its own nine-key `interface FormFieldSpec`, under the same
-name, in a different package — so the same failure mode stayed fully available.
-
-Measured key by key before choosing a route, because the two honest outcomes are
-"same contract, import it" and "genuinely narrower layer, rename it and pin the
-subset". The console's copy was a strict subset — 9 of the shared type's 26 keys,
-every one identical in type, none console-only — and it sat in a position that
-describes an **authored document**: `FormSectionSpec.fields`, read straight off the
-`/meta/view/:name` payload, the same spec `FormView` metadata-admin renders (both
-files even spell the same six-member `type` union and call the element type
-`FormFieldSpec`). The narrow, renderer-honoured shape is a different type that
-already exists in that file, `RenderableField`. So this was one contract described
-twice, and the console's description was wrong about the document: legal metadata —
-`visibleWhen`, `dependsOn`, `type`, `options`, `immutable`, the recursive `fields`,
-and ten more keys — was undeclared there. That is #5040's own symptom, "the type
-rejects the configuration the runtime accepts", which no runtime test can see.
-
-`@object-ui/app-shell` therefore re-exports `FormFieldSpec` from its package root
-(type-only, erased at build — nothing is added to the bundle), and `FormPage.tsx`
-imports it and deletes the local declaration. Reachability is the load-bearing half:
-a type that cannot be imported is a type that gets retyped, and retyped copies drift.
-`form-spec.ts` itself is untouched.
-
-`FormPage.fieldSpec.test.ts` is the pin that makes future drift loud. It reads the
-field-spec type back out of the **exported** `buildSections` signature rather than
-naming it, so re-inlining a local `interface FormFieldSpec` fails `type-check` even
-if the copy agrees on every key on the day it is written — which is exactly what did
-not happen to the copy this change removes. Its liveness controls are what stop it
-being a phantom check: the removed nine-key shape is pinned NOT equal to the shared
-type (so the `Equal` helper is proven to still discriminate), `RenderableField` is
-pinned not equal to it either (so the honoured-row and authored-document types cannot
-be collapsed again), and an undeclared key is still rejected (so the import did not
-smuggle in an index signature). Behaviour is unchanged: the runtime always accepted
-these keys, and the vitest half proves the same rows are built.
diff --git a/.changeset/console-form-marked-refusal-5210.md b/.changeset/console-form-marked-refusal-5210.md
deleted file mode 100644
index 3c95052807..0000000000
--- a/.changeset/console-form-marked-refusal-5210.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-'@object-ui/react': minor
-'@object-ui/components': patch
----
-
-The console form now renders a refusal message the producer explicitly marked
-as user-facing, instead of always substituting a generic string
-(objectui#5210).
-
-An application's hook guards could not talk to their users. When a hook refused
-a write with 403, the form replaced the server's text with
-`form.noPermissionToSave` unconditionally — the recorded objectstack#3821 fix,
-which exists because a raw refusal body puts untranslated platform diagnostics
-(`FORBIDDEN: insufficient privileges to update showcase_private_note
-pi-TgoJ4_DM55Fqz`) in front of end users. The external report behind this change
-had 11 guards whose deliberate, localized guidance — which role owns the action,
-whom to ask — never reached anyone, and named the incentive that creates:
-returning 400 instead of 403 for permission failures, degrading the status
-semantics logs, monitoring and API consumers depend on.
-
-The maintainer ruling (2026-08-19) was a producer-side opt-in rather than a
-chattier 403 branch, and the platform half shipped as objectstack#9934: a hook
-marks its refusal text with `userMessage` at throw time. This is the consumer
-half.
-
-- `@object-ui/react` gains `declaredUserMessage(err)` — the one "is this
-  marked?" read. It answers the marking verbatim, from the two places the
-  adapter boundary parks the envelope (the error itself, where
-  `@objectstack/client` lifts it, and `details`), and `null` for everything
-  else.
-- The form prefers a marked message over both its generic strings, on ANY
-  status — the marking is status-agnostic; 403 is where this was reported, not
-  a fence the contract draws.
-
-**Unmarked refusals are unchanged**: a 403 with no marking still shows the
-generic `form.noPermissionToSave`, and the raw text still goes to the browser
-console only. objectstack#3821's protection is preserved by construction, not
-by re-guessing which 403 bodies are presentable — the mark and the marked text
-are one field, so no boundary that rewraps or substitutes `message` can promote
-platform prose into the user-facing channel, and platform code never sets it.
diff --git a/.changeset/console-formpage-runtime-default-seed-5727.md b/.changeset/console-formpage-runtime-default-seed-5727.md
deleted file mode 100644
index d69e013e00..0000000000
--- a/.changeset/console-formpage-runtime-default-seed-5727.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-'@object-ui/console': patch
----
-
-The console's form routes no longer seed a RUNTIME `defaultValue` into the
-control, so the server-side resolution the declaration asks for actually happens
-(objectui#5727).
-
-`readPrefill` in `apps/console/src/components/FormPage.tsx` seeded every declared
-default unconditionally. A `defaultValue` may be a literal, or an *instruction*
-the server resolves per insert — a `DEFAULT_VALUE_TOKENS` token (`NOW()`,
-`current_user`) or a CEL Expression envelope. Seeding one of those literally put
-the text `NOW()` into a datetime input on both `/forms/:name` and the public
-`/f/:slug` route, and submitting it sent that string as the field's value —
-which is neither absent nor null, so `ObjectQL.applyFieldDefaults` never resolved
-the declared default and the column stored the token text instead of a timestamp.
-
-The seed is now guarded by `isRuntimeDefault` from `@object-ui/core` — the same
-published classifier `@object-ui/plugin-form`'s `schemaDefaults.ts` guards its
-seeding with, and the one this renderer already reads once removed (through
-`isServerOwnedValue`) for the create-mode `required` carve-out. A runtime default
-leaves the key ABSENT rather than empty, because absent is precisely the case the
-engine resolves.
-
-Nothing else about the prefill precedence moves: a literal default still seeds, a
-stored record value still wins over a default, and an explicit `prefill_<field>=`
-param still wins over both — including for a field whose default is a runtime
-token, since a value a producer supplies is not a declaration awaiting
-resolution.
diff --git a/.changeset/console-formpage-visible-predicates-5594.md b/.changeset/console-formpage-visible-predicates-5594.md
deleted file mode 100644
index 60c95e1a1c..0000000000
--- a/.changeset/console-formpage-visible-predicates-5594.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-'@object-ui/console': patch
----
-
-The console's standalone form renderer now evaluates conditional field visibility.
-
-`apps/console/src/components/FormPage.tsx` is a **second, independent form renderer**
-— its own `buildSections`, its own JSX — and it serves both the public
-`/f/:slug` route and the internal `/forms/:name` route. It read neither spelling of
-the FormView field visibility predicate: a repo-wide grep for a `visibleWhen` /
-`visibleOn` *read* inside that file returned zero. So a field an author conditioned on
-`record.priority == 'urgent'` — legal, spec-strict metadata that `@objectstack/spec`
-normalises to `visibleWhen` (ADR-0089), and that the metadata-admin designer both
-authors and honours — rendered unconditionally on both routes. Fail-open and silent:
-the author saw the field always, with no diagnostic.
-
-objectui#2212 recorded this exact symptom and PR #2214 fixed it — in a **different
-chain**: `ModalForm` → `resolveFormViewLayout` → `@object-ui/plugin-form`
-`sectionFields.ts` → `@object-ui/components` `renderers/form/form.tsx`. `FormPage.tsx`
-is on that chain at no point, and #2212's regression pin lives with the chain it fixed,
-so nothing in the suite could see this copy. One contract, two implementations, each
-only ever checked against itself.
-
-The wiring is **#2212's ruling applied verbatim** rather than a second predicate
-semantics invented for this renderer, because two form renderers disagreeing about what
-`visibleWhen` *means* would be a worse defect than one renderer ignoring it. The
-predicate goes through the canonical engine — `evalFieldPredicate` (`@object-ui/core`,
-`evaluator/fieldRules.ts`) — so the accepted wire shapes (bare CEL string and
-`{ dialect, source }`), the bound scope (`record.*` = the live input values, `previous.*`
-= the stored record an edit form started from), and the fail-open-but-loud behaviour on
-an unevaluable predicate are the shared ones by construction. Resolution is
-canonical-first, `visibleWhen ?? visibleOn`, matching both sibling readers:
-`sectionFields.ts` and app-shell's `readVisibility`.
-
-Two things deliberately did **not** change. A field hidden by its predicate still
-submits its value — conditional visibility is a rendering rule in both renderers, and
-making it a submit-payload rule would be a new contract decided once for both, not
-invented in the second one. And `FormPage` is **not** folded onto the plugin-form chain:
-the second-renderer question is real, but it belongs with the #5596 convergence track,
-not with a predicate that is dead today.
-
-`FormPage.visibleWhen.test.tsx` is the regression pin, and it lives next to *this*
-renderer on purpose — a pin that cannot see the second copy is how the first gap
-survived. With the fix reverted and the pin in place the suite reports
-`11 failed | 1 passed (12)`; the one green is the control that has to be green (a field
-with no predicate still renders), without which every "the field is absent" assertion
-would be equally satisfied by a renderer that draws nothing at all.
diff --git a/.changeset/console-lazy-docs-portal-5467.md b/.changeset/console-lazy-docs-portal-5467.md
deleted file mode 100644
index 9b44325e88..0000000000
--- a/.changeset/console-lazy-docs-portal-5467.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-'@object-ui/console': patch
----
-
-The console's `/docs` portal is code-split for real: its four pages leave the eager closure instead of only pretending to.
-
-`AppContent.tsx` lazy-imports `DocsLayout` / `DocsSlug` / `DocPage` for the
-app-scoped `/apps/:packageId/docs` tree (ADR-0048). `App.tsx` imported the same
-three statically for the platform portal at `/docs` (ADR-0046 section 6), so all
-of them sat in the eager graph regardless and the `import()` moved nothing —
-three `INEFFECTIVE_DYNAMIC_IMPORT` warnings on every `vite build`
-(objectui#5467). A static import on either side silently defeats the split for
-both, and the only signal is a build warning that fails nothing.
-
-`App.tsx` now reaches all four docs pages through `lazy()` behind `Suspense`,
-matching the pattern `AppContent.tsx` already uses. `DocsIndex` joins them even
-though it carried no warning: `AppContent` renders `AppDocsIndex` at that slot,
-so nothing imported `DocsIndex` dynamically, but left static it alone would keep
-`DocShell`, `use-book-data` and `book-nav` eager and the portal would only
-half-leave the closure.
-
-Measured on this branch with the `dist/eager-closure.json` gauge added by
-objectui#5324, both builds exiting 0:
-
-| | before | after |
-|---|---|---|
-| `INEFFECTIVE_DYNAMIC_IMPORT` warnings | 46 | 44 |
-| eager closure, gzipped | 3,881,609 B | 3,870,058 B |
-| eager chunks | 58 | 52 |
-
-Six chunks leave the eager closure: `plugin-markdown` (4,212 B gz),
-`CreateViewDialog` (3,617 B), `use-book-data` (1,966 B), `DocShell` (476 B),
-`componentRegistry` (99 B), and `src` (129,555 B), the last of which rolldown
-folds into the entry chunk rather than dropping — which is why the entry chunk
-grows from 25,910 to 154,378 B gzipped while the closure as a whole shrinks by
-11,551 B. The entry stays far under that budget's 350 KB line, and the eager
-closure is the number a page load actually pays.
-
-What does NOT move is `vendor-markdown`, 164,708 B gzipped and the reason this
-looked like a bigger win than it is. Three eager chunks import it statically,
-and only one of them was this portal: `plugin-chatbot` reaches it directly, and
-`packages/fields`' `MarkdownContent` — lazy in source — is folded into the
-eagerly imported `ui-components` chunk by the `advancedChunks` group that claims
-every `packages/fields` module. That is objectui#5325's mechanism, not this
-card's, and it is why the saving here is 0.30% rather than 4%.
diff --git a/.changeset/console-preboot-branding-origin-5660.md b/.changeset/console-preboot-branding-origin-5660.md
deleted file mode 100644
index d642b3dd34..0000000000
--- a/.changeset/console-preboot-branding-origin-5660.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-'@object-ui/console': patch
----
-
-The console's pre-boot branding script now resolves its server origin from
-`VITE_SERVER_URL` — the same variable every module-side consumer reads — instead of
-`window.__CONSOLE_SERVER_URL`, a global nothing in this repository ever set
-(objectui#5660).
-
-The two callers of `GET /api/v1/runtime/config` share one in-flight request, and
-that sharing keys on the FULL URL. So the origin was half of the contract: the
-inline script in `index.html` read one spelling and `src/main.tsx` read another, and
-whenever they disagreed the two never found each other. A same-origin production
-build hid it completely — both spellings collapse to `''` — so the split surfaced
-only in a dev pointing the console at a separate server, where it cost two requests
-to two different servers and let pre-boot branding paint from the wrong one.
-
-The pre-boot fetch is kept, not deleted: it is the request the module side JOINS.
-`sharedGetJson()` can only hand an earlier request to a later caller, and this
-script is the earlier one by construction — it runs during HTML parse, before the
-bundle is fetched, while `initRuntimeConfig()` is awaited before
-`createRoot().render()`. Deleting it would not remove a request; it would move the
-single remaining one later, onto the critical path to first paint, and leave the
-page's empty `<title>` and favicon unbranded until React mounts.
-
-Vite substitutes its HTML env token only when the variable is set and leaves it
-verbatim otherwise, so the unset case is read as same-origin `''` rather than
-allowed to reach the URL as a path segment.
diff --git a/.changeset/console-studio-builder-decorative-lazy-5486.md b/.changeset/console-studio-builder-decorative-lazy-5486.md
deleted file mode 100644
index e557f79f0b..0000000000
--- a/.changeset/console-studio-builder-decorative-lazy-5486.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-'@object-ui/console': patch
----
-
-`registerStudioComponents.tsx` no longer claims a code split it never had: `studio:builder` imports `BuilderLanding` directly instead of through a `lazy()` that deferred nothing.
-
-The registration wrapped `import('@object-ui/app-shell')` in `lazy()` behind a
-`Suspense` fallback — naming the same barrel the line above it imports
-statically for `registerAppComponent`, and the same barrel `App.tsx` pulls
-`BuilderLanding` from to render the standalone `/studio` landing full-screen.
-Either reason alone makes the `import()` unable to move a module into another
-chunk (objectui#5486).
-
-**This moves no modules and is not a bundle improvement.** `BuilderLanding` was
-already in the eager graph via `App.tsx` and still is. Measured on
-`dist/eager-closure.json`, both builds exiting 0: the eager closure holds the
-same 52 chunks with the same names, and the only difference is 130 B gzipped
-(413 B raw) off the entry chunk — the deleted `lazy()`, `Suspense` and fallback
-text themselves, 0.003% of a 3,875 KB closure. Nothing leaves the closure,
-because nothing could.
-
-What it does fix is honesty. The old code told every reader the builder was
-deferred, and it emitted an `INEFFECTIVE_DYNAMIC_IMPORT` warning on every
-console build — the console's count of those drops from 44 to 43, with the 43
-remaining ones all belonging to the `packages/fields` barrel (objectui#5325).
-A permanent warning that fails nothing is how a team learns to skim past build
-warnings, and a decorative `lazy()` is how the next reader learns something
-false about the chunk graph.
-
-The `lazy()` shape is not the mistake. The sibling `registerAccountComponents.tsx`
-lazy-imports `./pages/system/ProfilePage`, a specifier nothing else pulls in
-statically, and is genuinely deferred; it is untouched. Making the *builder*
-genuinely lazy would mean taking `App.tsx` off the static import too, changing
-how `/studio` mounts, and it only pays if app-shell's own graph cleaves behind
-the barrel — a separate measured card, not folded in here.
diff --git a/.changeset/console-user-preference-request-budget.md b/.changeset/console-user-preference-request-budget.md
deleted file mode 100644
index a629873f79..0000000000
--- a/.changeset/console-user-preference-request-budget.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
----
-
-Tests only: pin the console `sys_user_preference` request budget across one
-mount (objectui#5544). Three distinct preference keys, one read each, and every
-consumer still receives its own row. No runtime code changes, nothing to release.
diff --git a/.changeset/crud-guide-declarative-view-binding-5446.md b/.changeset/crud-guide-declarative-view-binding-5446.md
deleted file mode 100644
index 936ad20c97..0000000000
--- a/.changeset/crud-guide-declarative-view-binding-5446.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
----
-
-Test-only change: extended `packages/plugin-grid/src/__tests__/guideCrudAppRenders.test.tsx`
-to measure the `content/docs/guide/building-crud-app.md` rewrite for objectui#5446 (a
-docs-only fix — the guide now teaches the declarative `dataSource: { object, view }`
-binding instead of the `view` / `data.queryParams` keys `ObjectGrid` never read). No
-published package behaviour changes.
diff --git a/.changeset/current-user-default-prefill-5683.md b/.changeset/current-user-default-prefill-5683.md
deleted file mode 100644
index b519b0fb64..0000000000
--- a/.changeset/current-user-default-prefill-5683.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-'@object-ui/permissions': minor
-'@object-ui/plugin-form': minor
----
-
-Create forms pre-fill the `current_user` defaultValue token with the acting user (#5683). `PermissionContextValue` gains `userId` (from `/me/permissions`; `null` = unknown), and the create-form seeding resolves `defaultValue: 'current_user'` on `user` / `lookup→sys_user` fields to that id — the same value the engine stamps at insert, so the pre-fill is a preview of the server's own resolution, not a second default contract. Unknown user (no provider / anonymous / role-based provider) seeds nothing and keeps the omit-and-let-the-engine-resolve behavior. `NOW()` and CEL defaults stay server-owned.
diff --git a/.changeset/cyan-donkeys-tickle.md b/.changeset/cyan-donkeys-tickle.md
deleted file mode 100644
index acd39b5025..0000000000
--- a/.changeset/cyan-donkeys-tickle.md
+++ /dev/null
@@ -1,4 +0,0 @@
----
----
-
-Tooling only, no package released: port `scripts/check-entry-guard.mjs` from objectstack and wire it into `Lint`, so a `scripts/**` entry guard hand-typed with `process.argv[1]` cannot land. The 29 guards this tree already carries are baselined SHRINK-ONLY and converted separately (objectui#6092).
diff --git a/.changeset/dashboard-aria-member-retired-5830.md b/.changeset/dashboard-aria-member-retired-5830.md
deleted file mode 100644
index a104aca90f..0000000000
--- a/.changeset/dashboard-aria-member-retired-5830.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-'@object-ui/types': minor
----
-
-**Published TS surface narrowed:** `DashboardComponentSchema` no longer declares
-the `aria` member (`{ ariaLabel?, ariaDescribedBy?, role? }`). Its doc comment
-claimed alignment with `@objectstack/spec AriaPropsSchema`, but the spec removed
-`dashboard.aria` at the #3896 audit close-out — `DashboardSchema.shape.aria` is
-a tombstone that refuses any value and tells authors to delete the key — and no
-dashboard renderer ever read `schema.aria` (objectui#5830).
-
-What an author loses is the **type-level suggestion** only: the key was already
-refused at parse (the Zod twin inherits the spec tombstone by reference), and
-`BaseSchema`'s index signature means an existing `aria:` line still compiles.
-There is **no runtime behaviour change** — the key never rendered, and stored
-documents carrying it already failed validation before this release.
diff --git a/.changeset/dashboard-config-aria-retired-5852.md b/.changeset/dashboard-config-aria-retired-5852.md
deleted file mode 100644
index 9ce2a42a1a..0000000000
--- a/.changeset/dashboard-config-aria-retired-5852.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-'@object-ui/types': minor
----
-
-**Retired the designer-surface dashboard `aria` pair — `DashboardConfig.aria` and `DashboardConfigSchema.aria`** (objectui#5852).
-
-Both spellings are named verbatim above so a host can grep its own sources: the
-retired member is `aria`, on the TypeScript interface `DashboardConfig`
-(`@object-ui/types`, `designer.ts`) and on its Zod mirror `DashboardConfigSchema`
-(`@object-ui/types/zod`). It declared `{ label?: string; description?: string }`.
-
-**Why.** The spellings `label`/`description` match neither `@objectstack/spec`'s
-`AriaProps` vocabulary (`ariaLabel` / `ariaDescribedBy` / `role`) nor anything a
-renderer maps, so no read point could have consumed them even in principle.
-Re-measured on `main` at the retirement: zero `.aria` reads in
-`packages/plugin-designer/src`, `packages/plugin-dashboard/src` and
-`apps/console/src`; zero occurrences of either name anywhere in the `objectstack`
-repo; and `DashboardConfigPanel.tsx` — the panel the interface's own doc comment
-says it serves — imports neither name.
-
-**The two directions differ, and neither is a no-op:**
-
-- **TypeScript (a narrowed suggestion, not a compile break).** `DashboardConfig`
-  carries a `[key: string]: any` catch-all, so an existing `aria:` line still
-  compiles; what is gone is the editor suggestion and the false implication that
-  the key was part of the contract.
-- **Zod (a behaviour change — read this one).** `aria` is now an ADR-0049
-  retirement tombstone (`z.never().optional()`), following this package's
-  existing convention. Previously an authored `aria` was **accepted and
-  preserved** in `safeParse` output; it is now **refused by name**, with `aria`
-  in the issue path and a message telling the author to delete the key. A plain
-  deletion was deliberately not taken: `DashboardConfigSchema` is a bare
-  `z.object` with no `.strict()`, so deleting the key would have made an
-  authored `aria` **silently disappear** from the parsed output instead — a
-  quiet data loss in place of a loud refusal.
-
-**External caveat.** In-repo consumer count is zero, but that is not the npm
-count: `@object-ui/types` is published, and stored dashboard configuration is
-not reachable from this repo. A host that authored `aria` on a `DashboardConfig`
-document will now see a validation error naming the key where it previously saw
-a silently carried value. The remedy is to delete the key — it never reached a
-renderer.
diff --git a/.changeset/dashboard-declare-honoured-inputs.md b/.changeset/dashboard-declare-honoured-inputs.md
deleted file mode 100644
index c0129d95e5..0000000000
--- a/.changeset/dashboard-declare-honoured-inputs.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-'@object-ui/plugin-dashboard': minor
----
-
-`dashboard` now publishes the authoring inputs its renderer already honours — `widgets`, `label`, `description`, `header`, `globalFilters`, `dateRange`, `refreshInterval` — so `validateTree`, the generated `sdui.manifest.json` and `sdui-intrinsics.d.ts` stop warning authors off keys that work (previously only `columns`/`gap`/`className` were published, and every other honoured key drew `unknown-prop`). Each declared key is accepted by the spec's strict `DashboardSchema`, so the manifest never offers a key the save gate refuses. The legacy `title` spelling and the retired `aria` key stay deliberately unpublished and are pinned as such; the `schema.title || schema.label` fallback read is unchanged, so documents in the wild keep rendering their header title.
diff --git a/.changeset/dashboard-expandable-family-convergence-5692.md b/.changeset/dashboard-expandable-family-convergence-5692.md
deleted file mode 100644
index b7fcc7a8cf..0000000000
--- a/.changeset/dashboard-expandable-family-convergence-5692.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-'@object-ui/plugin-dashboard': patch
----
-
-`plugin-dashboard`'s two private copies of the reference-bearing field family now
-read `@object-ui/core`'s published `EXPANDABLE_FIELD_TYPES` instead of restating
-it — `LOOKUP_TYPES` in `recordFields.tsx` and the inline disjunction inside
-`computeLookupExpand` in `ObjectDataTable.tsx`. Both carry the identity pin the
-already-converged consumers carry, so a member-identical private copy fails
-rather than quietly re-forking the table.
-
-Two behaviour changes on the dashboard table's `$expand`, in opposite directions:
-
-- **A `tree` column is now expanded.** A self-referencing hierarchy field is
-  reference-bearing and a member of the shared family, so its cell renders the
-  parent record's display name instead of a bare id — the same treatment the form
-  and grid roads already gave it.
-- **A `reference`-typed column is no longer expanded.** Measured before removing
-  it: `reference` is absent from `@objectstack/spec`'s closed `FieldType`
-  vocabulary and is refused by `FieldSchema.safeParse`, so no spec-compliant
-  object schema can declare a field whose stored type is `reference`. Dropping it
-  is a no-op on real data; the spelling is a legacy dialect alias on the
-  action-param surface, folded to `lookup` before any field-type data is read.
-
-`EXPANDABLE_FIELD_TYPES` itself is unchanged — the measurement did not license
-widening a published shared set.
diff --git a/.changeset/dashboard-header-collapse-5812.md b/.changeset/dashboard-header-collapse-5812.md
deleted file mode 100644
index 9c0d11f887..0000000000
--- a/.changeset/dashboard-header-collapse-5812.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-'@object-ui/plugin-dashboard': patch
----
-
-`DashboardRenderer` no longer emits an empty dashboard header wrapper. The
-wrapper used to render whenever `header` was declared, while each of its
-children — title, description, actions — was additionally suppressible. With
-the console page chrome present (`hideHeaderText`, set because the chrome
-already renders the dashboard's title and description) and no `header.actions`,
-every child evaluated falsy and the DOM still received
-`<div class="col-span-full mb-4"></div>`: zero children, yet a full grid row
-(measured 64px) plus `mb-4` of dead band above the filter bar, on every console
-dashboard page (objectui#5812, measured on HotCRM 17.1.0).
-
-The three children are now computed first and the wrapper renders only if one
-of them survives. Nothing else changes: a standalone embed (no chrome) renders
-title and description exactly as before, and declared `header.actions` keep the
-wrapper alive even under the chrome, since the chrome renders text only. Authors
-needed this — dropping `header` from the metadata to reclaim the pixels would
-have cost the standalone embed its title, which is what `header` is for.
diff --git a/.changeset/dashboard-self-contained-unreachable-arm-4620.md b/.changeset/dashboard-self-contained-unreachable-arm-4620.md
deleted file mode 100644
index 7d8e70c295..0000000000
--- a/.changeset/dashboard-self-contained-unreachable-arm-4620.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-'@object-ui/plugin-dashboard': patch
----
-
-`DashboardRenderer` drops the unreachable `DatasetWidget` fork from its self-contained
-(card-less) branch, leaving that branch to render `SchemaRenderer` unconditionally
-(objectui#4620).
-
-`isSelfContained` is defined as `widget.type === 'metric' && !datasetBound`, and the
-`isSelfContained` arm of `renderedNode` then forked on `datasetBound` a second time. The
-`datasetBound` side of that inner fork could never execute: reaching it required
-`isSelfContained` to be true, which requires `!datasetBound`. Behaviour is unchanged —
-the removed arm never ran, and the reachable fork in the Card branch (the one that gives
-a dataset-bound metric its title and border chrome) is untouched.
-
-The cost was to readers, not to users: the shape read as "both branches handle
-dataset-bound widgets" when only one can, and a previous PR mirroring this fork onto
-`DashboardGridLayout` had to pay for the reachability argument before it could decline to
-copy the dead limb. A comment now names the invariant in place so the arm is not re-added.
diff --git a/.changeset/dashboard-stable-empty-rows-4629.md b/.changeset/dashboard-stable-empty-rows-4629.md
deleted file mode 100644
index 9fc9806548..0000000000
--- a/.changeset/dashboard-stable-empty-rows-4629.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-'@object-ui/plugin-dashboard': patch
----
-
-`ObjectDataTable` and `ObjectPivotTable` now use a module-scope frozen empty for
-"no rows yet" instead of a fresh array literal per render (objectui#4629).
-
-Both spelled the resolved row list as `Array.isArray(rawData) ? rawData : []`, so
-whenever `rawData` was a truthy non-array — a provider-config `data`, or a `bind`
-path that resolves to an object — the fallback produced a NEW array identity on
-every render. In `ObjectDataTable` that value keys the `derivedColumns` memo, so
-every column was re-derived (`buildFieldMeta`, a fresh `cell` closure, the
-`isSystemField` pass, the `fieldLabel` lookups) and then discarded by the
-`finalData.length === 0` early return. In `ObjectPivotTable` the value is handed
-straight to `PivotTable`, where it keys the cross-tabulation memo, so the pivot
-rebuilt its row/column sets, bucket map and totals on every render over no rows
-at all.
-
-Nothing rendered wrong before or after; this is wasted work in the empty window,
-plus the live `react-hooks/exhaustive-deps` warning the conditional raised. It is
-the same module-scope frozen empty `data-table.tsx` adopted for its own
-`EMPTY_ROWS` (objectui#4618), applied to the `provider: 'object'` siblings.
diff --git a/.changeset/dashboard-table-header-one-spelling-5425.md b/.changeset/dashboard-table-header-one-spelling-5425.md
deleted file mode 100644
index 8a0de721b2..0000000000
--- a/.changeset/dashboard-table-header-one-spelling-5425.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-'@object-ui/plugin-dashboard': patch
----
-
-A dashboard table's auto-derived column headers spell a field key the same way every other path in the `table` widget family does.
-
-`ObjectDataTable` derives headers on two paths — from the author's declared
-`columns`, and from the object schema when no columns were declared. The
-declared path (and the static `data-table` half of the same widget family)
-already used `humanizeFieldKey`, whose docstring names it "the single home for
-the convention, because both halves of the `table` widget family need it and
-they must agree". The auto-derived path carried a third, inline spelling that
-split camelCase but never turned `_` into a space, so it left a raw underscore
-on screen. Measured over the same object's columns:
-
-```
-path                                     close_date    needs_analysis
-object-bound, AUTO-DERIVED   (before)    Close_date    Needs_analysis
-object-bound, AUTO-DERIVED   (after)     Close Date    Needs Analysis
-object-bound, DECLARED columns           Close Date    Needs Analysis
-static `data-table`, no columns          Close Date    Needs Analysis
-```
-
-One dashboard can hold all three widgets over one object, so a single field key
-rendered under two spellings — the defect class objectui#5425 rules out. The odd
-path adopts the shared convention rather than the convention gaining a fourth
-dialect. camelCase keys are unaffected (`unitPrice` read `Unit Price` before and
-after — the coincidence that kept the snake_case divergence unnoticed), and a
-translated header still wins: only the fallback handed to `fieldLabel` changed.
-
-Dimension MEMBER labels are untouched by this. The same card reported dashboard
-members rendering a prettified enum instead of the picklist's translated label,
-measured on 17.1.0; re-measured on this branch it no longer reproduces — the
-analytics label net shipped in 17.5.0 routes every non-metric dataset dimension
-through the field's declared options and the locale bundle. That behaviour had
-no test stated in the card's terms and now has one, over the four dashboards the
-card measured, including the property that a bar axis and a pivot header cannot
-disagree about one stored value.
diff --git a/.changeset/dashboard-table-measure-desc-first-5845.md b/.changeset/dashboard-table-measure-desc-first-5845.md
deleted file mode 100644
index 6eb74642b6..0000000000
--- a/.changeset/dashboard-table-measure-desc-first-5845.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-'@object-ui/plugin-dashboard': minor
----
-
-Dashboard `table` widget — a numeric **measure** column now sorts **descending
-on the first click** (objectui#5845).
-
-The sortable headers shipped in objectui#5827 started every column ascending,
-which left the card's own motivating complaint — the largest industry rendering
-last — two clicks away. For a measure in an analytics widget the question a
-click asks is "who is biggest", so that column now cycles
-**descending → ascending → the dataset's own order**.
-
-Unchanged: a **dimension** column, and a measure whose values are not numbers
-(a `min()`/`max()` over a text field), keep **ascending → descending → the
-dataset's own order** — the idiom the console's own DataTable uses. The
-first-click direction is decided by the same measure-and-all-values-are-numbers
-classification that decides right-alignment, so it follows the column's *role*
-rather than "it looks like digits": a digit-keyed dimension (a year, a quarter)
-still starts ascending.
-
-Blanks still sort **last in both directions** — that arm is now what a measure
-column's very first click runs — and `aria-sort` reports the direction actually
-applied.
diff --git a/.changeset/dashboard-table-widget-polish-5827.md b/.changeset/dashboard-table-widget-polish-5827.md
deleted file mode 100644
index 9714c2330f..0000000000
--- a/.changeset/dashboard-table-widget-polish-5827.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-'@object-ui/plugin-dashboard': minor
----
-
-Dashboard `table` widget (dataset-backed, flat grouped table) — four rendering
-fixes so it reads as a table rather than a raw dump (objectui#5827):
-
-- **Numeric columns right-align**, header and cells. `tabular-nums` was already
-  applied to every cell and could not do its job while the digits were flushed
-  left. A column qualifies when it is a MEASURE and every non-null value in it
-  is a number — the declared column `type` cannot decide it, because the
-  analytics executor stamps `type: 'number'` on every measure regardless of the
-  aggregate, so a `min()`/`max()` over a text field would have been
-  right-aligned on the strength of a label. Dimensions stay left-aligned even
-  when their bucket keys are digits: a grouping axis is not a quantity.
-- **Sortable headers.** Each header is a keyboard-reachable button that cycles
-  ascending → descending → back to the dataset's own order, with the console's
-  existing sort indicator and `aria-sort` on the `th`. Blanks sort last in
-  BOTH directions. The sort is client-side over the rows already fetched — the
-  widget issues one `queryDataset` call and paginates nothing, so no round trip
-  is involved.
-- **The empty-dimension bucket sorts last** in the default order instead of
-  floating to the top. It keeps its `—` label; only its position moves.
-- **Row hover feedback on every row**, not only on a drillable one. A drillable
-  row keeps its stronger accent fill.
-
-The CSV export now follows the order the table is showing, which is the same
-"the CSV is the table's data" convention its cell text already followed.
-Drill-through is unaffected: rows are reordered as `(row, incoming index)`
-pairs, so a drill still resolves through the server's parallel raw-value
-sidecar.
-
-Unchanged: the cross-tab (a `pivot` with ≥2 dimensions) renderer, the KPI and
-chart paths, and every non-dataset table in the console.
diff --git a/.changeset/dashboard-title-locale-writeback-5428.md b/.changeset/dashboard-title-locale-writeback-5428.md
deleted file mode 100644
index 849b85b703..0000000000
--- a/.changeset/dashboard-title-locale-writeback-5428.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-'@object-ui/plugin-designer': patch
-'@object-ui/app-shell': patch
----
-
-A widget title stored as an inline per-locale map is editable again in both dashboard
-authoring surfaces, and a save writes back only the active locale's entry
-(objectui#5428).
-
-`@objectstack/spec` widened `I18nLabel` from `string` to `string | Record` at
-17.0.0-rc.6, so a stored widget title may be an inline per-locale map while both
-authoring panels edit a title in ONE single-line input. Writing the input's value back
-as the whole value would collapse every other locale on the first keystroke, so both
-surfaces took the same conservative branch: show a map-valued title resolved, and make
-it READ-ONLY.
-
-That branch could not lose data, but it rested on a premise the spec had already
-invalidated — "nothing can reach this path from stored metadata yet, `I18nLabel` was
-plain `string` through rc.5" — stated sixty lines below a comment in the same file
-documenting the rc.6 widening that makes a stored map reachable. Both could not hold.
-The pinned spec is 17.0.0. What the read-only branch did in practice from rc.6 onward
-was not protect an unreachable path: it denied an author the ability to edit a widget
-title in their own locale.
-
-objectui#5301's maintainer ruling settled the write rule for the sibling surface — a
-save replaces only the active locale's entry and preserves the others — and
-`@object-ui/i18n` ships it as `setLocalized`, co-located with `pickLocalized` because
-the read and the write have to agree. Both panels now adopt it:
-
-- `@object-ui/plugin-designer`'s `DashboardEditor` widget property panel;
-- `@object-ui/app-shell`'s `DashboardWidgetInspector` in metadata-admin.
-
-A plain-string title keeps saving as a plain string, so the common path is unchanged.
-An edit made in a locale the stored map does not carry ADDS an entry under that locale
-rather than overwriting the entry the display fell back to.
-
-The pins are preservation pins, not "the input is editable" pins: at both surfaces a
-keystroke on a map-valued title must leave every other locale's entry byte-identical.
-Reverse-verified by mutating each write back to the flattening form and confirming those
-assertions go red at both surfaces.
-
-Not a multi-locale editor: an author still reaches only the entry for the locale they
-are in. Authoring every locale from one panel remains an open product question. The
-stale deferrals both comments carried pointed at objectui#4163, which closed as
-completed on 2026-08-15 while the placeholders were still in the tree; they are replaced
-with the rule that is actually in force rather than re-pointed at another tracker.
diff --git a/.changeset/dashboard-widget-dataset-stale-cast-5067.md b/.changeset/dashboard-widget-dataset-stale-cast-5067.md
deleted file mode 100644
index ba87f15eca..0000000000
--- a/.changeset/dashboard-widget-dataset-stale-cast-5067.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
----
-
-Internal only — this publishes nothing, declared explicitly with an empty frontmatter
-rather than left undeclared.
-
-`DashboardRenderer.tsx`'s dataset-bound check (`const datasetBound = !!(widget as
-any).dataset`) drops its `as any` (objectui#5067). The comment's stated reason —
-"the bundled DashboardWidget type gains `dataset` only after objectui bumps
-`@objectstack/spec`" — is stale: the repo already carries `@objectstack/spec@17.0.0`,
-whose `DashboardWidget` declares `dataset`, and `packages/types/src/complex.ts`'s
-`DashboardWidgetSchema` inherits it through its `extends Omit<Partial<SpecDashboardWidget>,
-…>` (`dataset` is not in the `Omit` list). `widget.dataset` type-checks directly; the cast
-was pure redundant widening, and a harmful one — after `as any`, `.dataset` reads as
-`any`, so a future spec change to that key's shape would not go red here.
-
-**No runtime behaviour changes.** `!!(widget as any).dataset` and `!!widget.dataset`
-evaluate identically for every input; `as any` is a compile-time-only annotation. Proven
-with a reverse check: temporarily typo'ing the property to `widget.datasetTypoXYZ` turns
-`pnpm --filter @object-ui/plugin-dashboard type-check` red with `TS2339: Property
-'datasetTypoXYZ' does not exist on type 'DashboardWidgetSchema'`, confirming the removed
-cast was suppressing real type coverage rather than papering over a genuine gap.
-
-The ADR-0021 point the original comment made — a dataset-bound widget renders through
-the governed `queryDataset` path (`DatasetWidget`) instead of the inline object-aggregate
-schema — is unchanged and kept; only the now-false justification for the cast is rewritten.
diff --git a/.changeset/dashboard-widget-type-closed-enum.md b/.changeset/dashboard-widget-type-closed-enum.md
deleted file mode 100644
index 11f2c6bbf9..0000000000
--- a/.changeset/dashboard-widget-type-closed-enum.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-"@object-ui/types": minor
-"@object-ui/plugin-designer": patch
-"@object-ui/app-shell": patch
----
-
-Close the dashboard widget `type` vocabulary, and admit `metric-card` as objectui's own component extension.
-
-`DashboardWidgetSchema.type` was `string` on the TypeScript interface and `z.string()` in the Zod twin — an unbounded hatch. A typo'd family, a chart type the spec retired, and a component type nothing registers all type-checked and validated, surfacing only as the renderer's red `OBJUI-001` panel at runtime.
-
-It is now the CLOSED `DashboardWidgetTypeName` / `DashboardWidgetTypeSchema`: the spec's own `ChartTypeSchema` families **by reference**, plus two named, closed objectui extension sets — `DASHBOARD_WIDGET_TYPE_EXTENSIONS` (`list`, `custom`: objectui-only widget families) and `DASHBOARD_COMPONENT_WIDGET_TYPES` (`metric-card`: an objectui SDUI **component** type the widget slot holds directly, per the maintainer ruling of 2026-08-14 — objectui's own component enum, explicitly not the spec widget enum).
-
-Three drifts the closure surfaced and this change fixes: the dashboard designer's palette offered `grid`, which is not a widget family in either contract and was refused at publish; the metadata-admin widget inspector and the designer both wrote an unvalidated `string` from their select boxes; and a `@object-ui/types` fixture pinned `bar-chart`, a `plugin-charts` component type, on a dataset-bound widget that could never render as one.
diff --git a/.changeset/data-table-header-declared-key-5351.md b/.changeset/data-table-header-declared-key-5351.md
deleted file mode 100644
index c0b154de2d..0000000000
--- a/.changeset/data-table-header-declared-key-5351.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-'@object-ui/core': minor
-'@object-ui/components': minor
-'@object-ui/plugin-dashboard': minor
-'@object-ui/plugin-detail': minor
----
-
-`data-table` reads the declared `header`; the producers translate `label` into it.
-
-`TableColumn` declares `header: string` and does not declare `label`. The
-renderer's column normalization nonetheless read `header: col.header || col.label`,
-so the same key had one spelling the type admits and one only the runtime did.
-That alias is gone (objectui#5351), and the translation it used to perform happens
-once at each producer instead: metadata vocabulary in, adapter vocabulary out.
-
-**This narrows what `data-table` accepts, so read this if you author `data-table`
-nodes by hand.** A column spelled `{ label: 'Stage', accessorKey: 'stage' }` on a
-directly authored `data-table` now renders a **headerless** column over live
-cells. Spell it `header` — the key `TableColumn` has always declared. Columns
-reaching `data-table` through `object-data-table`, `object-grid` or a related
-list are unaffected: those producers resolve `header` for you from the spec's
-`ListColumnSchema.label`, so every spelling they accepted before they still
-accept.
-
-`@object-ui/core` gains `columnHeader()` alongside `columnIdentity()` — the reader
-producers use to cross that boundary. It is adapter-first (`header` wins over
-`label`), so an author who addressed the table directly is never overwritten.
-
-`object-data-table` also gains a fix from the same move: a column carrying a
-`label` used to render a **blank** header there even while the alias existed,
-because the widget's field-meta enrichment overwrote the authored `label` before
-the adapter ever saw it. `{ field: 'stage', label: 'Stage' }` now renders "Stage".
-
-The sibling `accessorKey: col.accessorKey || col.name` alias is **unchanged** here
-and still resolves. Retiring it is objectui#5120's remaining step, which is
-gated on two published skill guides that teach that spelling.
diff --git a/.changeset/date-range-default-range-binding-4984.md b/.changeset/date-range-default-range-binding-4984.md
deleted file mode 100644
index 60e7298530..0000000000
--- a/.changeset/date-range-default-range-binding-4984.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-'@object-ui/types': patch
----
-
-`DashboardComponentSchema.dateRange.defaultRange` is now bound to
-`DateRangeDefaultRange` from `@objectstack/spec/ui` instead of restating it as a
-hand-written 14-member union (objectui#4984).
-
-The union was byte-faithful to the spec — all 14 members, same order — so nothing
-a user hits changes today. What was missing is the tie that keeps it faithful:
-`resolveDashboardFilterDefs` takes `Pick<DashboardComponentSchema, 'globalFilters' |
-'dateRange'>`, so this union is what typechecks every TS-constructed dashboard, and
-a preset the spec ADDS would have been a legal document that objectui's own types
-said could not exist — the "narrower than the contract it implements" shape whose
-consequence in objectui#4163 was that the bad reads were invisible to `tsc`.
-
-No gate reported it: `check:spec-symbols` rule 1 matches by NAME and an inline union
-on an interface member has no symbol to collide with, while rule 2's claim heuristic
-was waved through by the `SpecGlobalFilter` reference a few lines above. Binding makes
-the file's existing "Aligned with @objectstack/spec" comment structural rather than
-prose.
-
-The emitted `.d.ts` collapses the inline union to the imported alias; the published
-type surface is unchanged — measured with the TypeScript checker over the emitted
-declarations (679 reachable exports from `dist/index.d.ts`, 22 from `dist/complex.d.ts`,
-and `defaultRange` resolving to the same 14 string-literal members before and after).
diff --git a/.changeset/dead-metadata-converters-6224.md b/.changeset/dead-metadata-converters-6224.md
deleted file mode 100644
index 63c5a43b3d..0000000000
--- a/.changeset/dead-metadata-converters-6224.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-Delete the dead `src/utils/metadataConverters.ts` module. It had zero importers, was not
-re-exported from the package barrel, and no `exports` subpath reached it — `toObjectDefinition`,
-`toFieldDefinition`, `MetadataObject` and `MetadataField` were never part of the published
-surface, so nothing external can break. The module was removed rather than left alone because it
-carried two patterns the live code no longer uses: a name-heuristic `isSystem` (the server's real
-`system` flag is the source of truth) and a three-way `referenceTo` tolerance for a target the
-spec spells `reference`. A dead copy that disagrees with the live one is what a future author
-copies from.
diff --git a/.changeset/dead-refresh-callback-objectview.md b/.changeset/dead-refresh-callback-objectview.md
deleted file mode 100644
index 6f077fa36d..0000000000
--- a/.changeset/dead-refresh-callback-objectview.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
----
-
-Internal only, no released behaviour change: `plugin-view`'s `ObjectView` no
-longer declares a `handleRefresh` callback that nothing referenced.
-
-The callback bumped `refreshKey` but was never passed to the toolbar, exposed on
-a handle, or wired to any control — it advertised a refresh entry point the
-component does not have, which cost objectui#4549 a detour to rule out. The
-reachable refresh paths are unchanged (`onMutation` auto-subscribe, delete, bulk
-delete, form success), and the real toolbar Refresh button continues to live in
-`plugin-list`'s `ListView`, reached through `renderListView`.
diff --git a/.changeset/default-children-retired-5051.md b/.changeset/default-children-retired-5051.md
deleted file mode 100644
index 0605f03d1c..0000000000
--- a/.changeset/default-children-retired-5051.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-'@object-ui/types': minor
-'@object-ui/core': minor
-'@object-ui/components': minor
----
-
-The register-meta key `defaultChildren` is retired (objectui#5051).
-
-It was declared in four places, produced in eleven, and read in **none**. The designer's
-drop path builds a new node from its twin key only — `PageDesigner.tsx`,
-`props: paletteItem?.defaultProps ?? {}` — with no `children:` line, so a palette item
-that declared `defaultChildren` dropped an **empty** node and the declared children never
-materialised. Nothing rendered the wrong thing; an entire declaration surface was simply
-inert, which is the declared-but-unenforced shape ADR-0049 targets. Per the maintainer
-ruling of 2026-08-19, the key is removed rather than wired up; if designer
-default-children UX is ever product-wanted it returns as its own designed card.
-
-**If you author plugins against the published register-meta table, drop the key.** It is
-gone from `skills/objectui/guides/plugin-development.md`, which had been teaching it. A
-meta that still declares it stays *valid*: `ComponentMetaSchema` is a plain `z.object`,
-and measured on zod 4.4.3 that STRIPS unknown keys rather than rejecting them — so the
-key is silently dropped from the parse output instead of failing validation. TypeScript
-authors get the loud signal instead: all three `ComponentMeta` declarations
-(`@object-ui/types` `base.ts` and `plugin-scope.ts`, `@object-ui/core` `Registry.ts`) no
-longer offer it, so re-declaring it is now a compile error.
-
-**No runtime behaviour changes in either direction.** No code path read the key before
-this change, and the eleven producers that set it (`sidebar.tsx` x10, `span.tsx`) were
-feeding a reader that did not exist. Dropping a `span` or any of the ten sidebar types
-into the designer produces exactly the node it produced yesterday.
-
-Two suites keep it retired, one per package: `packages/types` pins the zod twin (the key
-is absent from the parse output, with a surviving sibling asserted present through the
-same parse as the control) plus the two TS twins with `@ts-expect-error`, and
-`packages/core` pins the registration surface the eleven producers were written against.
-Both are compile-time-enforced through each package's chained `tsconfig.test.json`.
diff --git a/.changeset/default-view-agenda-retired-5784.md b/.changeset/default-view-agenda-retired-5784.md
deleted file mode 100644
index ae59ebf296..0000000000
--- a/.changeset/default-view-agenda-retired-5784.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-'@object-ui/types': minor
----
-
-`'agenda'` leaves `defaultView` on all three of its declaration faces
-(objectui#5784 — the `defaultView` sibling of objectui#5740's retirement on
-`CalendarViewSchema.view`; ADR-0049 enforce-or-remove): the
-`ObjectCalendarSchema` TS interface (an inline union `#5740`'s
-`CalendarViewMode` narrowing could not reach), the zod `ObjectCalendarSchema`,
-and the list-view `calendar` config's objectui-only `defaultView` extension.
-All three are now `['month', 'week', 'day']`.
-
-The declarations admitted a value nothing enforced: `ObjectCalendar`'s props
-declare `defaultView?: 'month' | 'week' | 'day'`, its schema read casts to the
-same three values, and `CalendarView` renders no agenda view. An author
-writing the type-legal, zod-valid `defaultView: 'agenda'` on an
-`object-calendar` node or in a list view's `calendar` config got a month
-calendar with no error or warning. The spec side already agrees:
-`@objectstack/spec`'s `ObjectCalendarProps.defaultView` is
-`['month', 'week', 'day']`. No in-repo, example, or catalog app authors
-`defaultView: 'agenda'` (measured for objectui#5784 with positive controls,
-including the objectstack tree — its only `agenda` token is the Agenda
-job-scheduler library).
-
-**This narrows the accept set: an author who writes `defaultView: 'agenda'`
-will now be refused at validation.** `defaultView` is a declared key, and
-declared keys are validated even under `.passthrough()`, so
-`defaultView: 'agenda'` is a **validation error that previously parsed
-green** (an `invalid_value` issue on the `defaultView` /
-`calendar.defaultView` path, offering `month`/`week`/`day`). Undeclared keys
-still pass through unchanged. Breaking on the published zod surface; ships as
-`minor` per this repo's version-alignment policy (majors track
-`@objectstack`).
-
-The runtime boundary is unchanged: `ObjectCalendar` still resolves an
-off-union raw `defaultView` away to its `'month'` default. Docblocks and both
-zod `describe` strings now teach the three-value set.
diff --git a/.changeset/delete-dead-release-workflow-5405.md b/.changeset/delete-dead-release-workflow-5405.md
deleted file mode 100644
index b1c00f27a1..0000000000
--- a/.changeset/delete-dead-release-workflow-5405.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
----
-
-CI/docs only — this publishes nothing, declared explicitly with an empty frontmatter
-rather than left undeclared.
-
-Deletes `.github/workflows/release.yml`, a workflow that never ran once in this
-repository's history, and removes the two places on
-`content/docs/guide/ci-cd-pipeline.md` that documented it as a release path.
-
-It triggered on `push: tags: ['v*']`. No tag matching that glob has ever existed here:
-of the 2896 tags on the remote, every one is a Changesets per-package tag
-(`@object-ui/<pkg>@<semver>`) and not one begins with `v`. Nothing creates tags except
-the Changesets action, so the trigger had no way to fire.
-
-It is obsolete rather than misconfigured, which matters because the two have opposite
-fixes. The workflow parsed and registered fine (GitHub lists it `active`) and would fire
-if a `v*` tag were pushed — the job it would do, "Create GitHub Release", is simply
-already being done by `changeset-release.yml`, whose Changesets action publishes GitHub
-Releases tagged `@object-ui/<pkg>@<version>`. Its own npm publish step was still
-commented out under "Uncomment the following steps when ready to publish to npm" while
-the repo has been publishing to npm through Changesets for months, and its one-version
-model (a single `v<semver>` for the whole repo, pointing at the root `CHANGELOG.md`)
-never matched the 39-package fixed group this repo actually releases.
-
-The doc edit is not optional housekeeping: `scripts/__tests__/ci-cd-pipeline-doc.test.ts`
-pins that page to `.github/workflows/` in both directions, so a page still naming
-`release.yml` after the file is gone fails "never names a workflow file that does not
-exist".
-
-No package `src/` is touched, so no `@object-ui/*` package changes behaviour and there is
-nothing here for a consumer to upgrade to.
diff --git a/.changeset/designer-field-key-parity-gate.md b/.changeset/designer-field-key-parity-gate.md
deleted file mode 100644
index af9f06da57..0000000000
--- a/.changeset/designer-field-key-parity-gate.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
----
-
-Tooling and tests only; no published behaviour changes.
-
-Adds `check:designer-field-key-parity`, a gate that compares the field designers'
-statically declared payload shapes (`FieldMetadataPayload`, `ServerFieldSchema`,
-`DesignerFieldDefinition`) against the accept set of the installed
-`@objectstack/spec` `FieldSchema`, plus the draft-I/O round-trip half as a test in
-`@object-ui/app-shell`. Both are new checks over existing code — nothing shipped
-in a package changed, and no offending key was fixed: each one the gate surfaced is
-filed as its own card and recorded in the gate's ledger.
diff --git a/.changeset/designer-publish-package-binding.md b/.changeset/designer-publish-package-binding.md
deleted file mode 100644
index 4bba3134eb..0000000000
--- a/.changeset/designer-publish-package-binding.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-'@object-ui/data-objectstack': minor
-'@object-ui/app-shell': minor
----
-
-The metadata designer states its package on the publish step, not only on the save (#5420)
-
-Studio's designer save→publish loop bound the draft to a software package on the
-save (`PUT ?mode=draft&package=<id>`) and then sealed it with a publish that named
-no package at all. `objectstack#10354` (shipped in `@objectstack/rest` 17.2.0) taught
-`POST /meta/:type/:name/publish` to accept `?package=<id>`, so the second call can now
-state the same binding the first one already states.
-
-- `MetadataClient.publish()` accepts `packageId` and sends `?package=<id>`, the same
-  wire spelling and the same `encodeURIComponent` treatment `save()` gives it.
-- `MetadataResourceEditPage` reads the binding for BOTH steps from one derivation
-  (`readActivePackageBinding`), so the two calls of one loop cannot drift apart. The
-  `?package=all` "show everything" scope keeps folding to "no package".
-
-The parameter is **omitted**, never sent empty, when the designer holds no binding.
-Empty and absent are the same to the framework's normaliser today, but absent is the
-shape the save door already followed, and the framework's promotion path branches on
-the key being present downstream.
-
-What this buys is **reachability**, not speed: it lets `#9612`'s package-closure
-narrowing at the runtime publish gate fire on an HTTP-driven promotion at all. That
-narrowing has a second, independent gate this does not touch — objects carrying no
-`_packageId` provenance are kept unconditionally — so on a tenant-authored overlay
-corpus stating the package still narrows nothing.
diff --git a/.changeset/dom-leak-sweep-components-5574.md b/.changeset/dom-leak-sweep-components-5574.md
deleted file mode 100644
index ce389acf86..0000000000
--- a/.changeset/dom-leak-sweep-components-5574.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
----
-
-Tests only — this publishes nothing, declared explicitly with an empty frontmatter
-rather than left undeclared. The one file changed is
-`packages/app-shell/src/__tests__/widget-dom-leak-sweep.test.tsx`, which
-`packages/app-shell/tsconfig.json` excludes from the build program
-(`"exclude": [… "**/*.test.tsx"]`).
-
-Measured rather than asserted, because emitted-output behaviour varies per package:
-`packages/app-shell/dist` was built twice from a cleared `dist/` **and** a cleared
-`tsconfig.tsbuildinfo` — once at the `origin/main` version of that file, once at this
-branch's version — and sha256-compared. 862 emitted files, 431 of them `.d.ts`, every
-hash equal. (The first attempt at this measurement read as an empty `dist/`: `tsc` is
-`composite`, so with the build info left in place it skipped the emit entirely and
-produced no output to compare. Clearing the build info is part of the measurement,
-not a detail.)
-
-Widens the objectui#3291 DOM-leak canary sweep to `packages/components/src/renderers/**`.
-That family — 158 registry-reachable types across five namespaces — was outside the
-gate's discovery entirely, which is why `ui:grid`'s leak had to be found by hand. The
-first run records a ledger: 119 of 158 targets leak, in eight measured shapes, every
-renderer named. Nothing is skipped or allow-listed; the per-target assertion stays exact
-set equality in both directions, so a renderer fix cannot go green until its ledger row
-is deleted in the same change.
diff --git a/.changeset/dom-leak-sweep-fixture-depth-5630.md b/.changeset/dom-leak-sweep-fixture-depth-5630.md
deleted file mode 100644
index d471f6afd3..0000000000
--- a/.changeset/dom-leak-sweep-fixture-depth-5630.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
----
-
-Test-only: deepen the `element:definition-list` / `element:repeater` /
-`element:metadata_viewer` fixtures in the DOM-leak sweep
-(`packages/app-shell/src/__tests__/widget-dom-leak-sweep.test.tsx`) past their
-empty-state placeholder branch, so their clean reading covers the real,
-populated markup instead. No renderer source changed and no published
-behaviour changes.
diff --git a/.changeset/draft-changes-panel-eager-attribution-comment.md b/.changeset/draft-changes-panel-eager-attribution-comment.md
deleted file mode 100644
index e3d23fb00c..0000000000
--- a/.changeset/draft-changes-panel-eager-attribution-comment.md
+++ /dev/null
@@ -1,4 +0,0 @@
----
----
-
-Comment-only correction in `packages/app-shell/src/preview/DraftChangesPanel.tsx`. The block above the `/meta` spelling fold stated that this file's `@objectstack/spec/shared` import puts that subpath on the console's eager graph, and attached a byte figure and a prohibition to that claim. Ablation on `origin/main` shows the import is worth ~+285 bytes gzipped: the subpath is held eager by a runtime import inside `@objectstack/core`, upstream of this repo. The comment now records the mechanism and points at the upstream card. No source behaviour is touched and no published behaviour changes.
diff --git a/.changeset/dts-build-exit-code-5370.md b/.changeset/dts-build-exit-code-5370.md
deleted file mode 100644
index b6fe0bc6dc..0000000000
--- a/.changeset/dts-build-exit-code-5370.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
----
-
-Build tooling only — this publishes nothing, declared explicitly with an empty frontmatter
-rather than left undeclared. No package `src/` is touched: `@object-ui/layout`'s `vite build`
-now exits non-zero when the declaration step reports type errors, instead of printing them
-and exiting 0 (objectui#5370). The typings and the JavaScript it emits are unchanged.
diff --git a/.changeset/dts-explicit-extensions-5365.md b/.changeset/dts-explicit-extensions-5365.md
deleted file mode 100644
index 73de8c9d34..0000000000
--- a/.changeset/dts-explicit-extensions-5365.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-'@object-ui/components': patch
-'@object-ui/layout': patch
----
-
-The typings both packages publish now carry an explicit extension on every relative specifier, so a consumer on `moduleResolution: nodenext` can follow them.
-
-`vite-plugin-dts` emits one declaration file per source file, and TypeScript
-copies a module specifier into the declaration verbatim. `export * from './ui'`
-therefore shipped extensionless in `dist/index.d.ts` — 21 such re-exports in
-`@object-ui/components`, 7 in `@object-ui/layout`, 128 across the two emitted
-trees. Node16/NodeNext resolution does not extension-search a relative
-specifier, so the compiler could follow none of the hops and every symbol they
-carried read as absent from the package:
-
-```
-error TS2305: Module '"@object-ui/components"' has no exported member 'Badge'.
-```
-
-Measured on `@object-ui/app-shell`, the largest consumer and the one that pulls
-in both packages: 880 TS2305 across 162 files (864 from `components`, 16 from
-`layout`), plus 215 TS7006 as fallout from the imports that stopped resolving.
-On `@object-ui/fields`, 178 TS2305 and 57 TS7006. Both are zero now.
-
-The emitted `.js` never had the defect — rolldown resolves the same specifier
-away — which is why `pnpm check:esm-specifiers`, whose verdict is about
-specifier-preserving `.js` builds, correctly never scanned either package. The
-fix is therefore in the declaration EMIT (`scripts/vite-dts-explicit-extensions.ts`,
-shared by both `vite.config.ts` files), not in the sources: the same source line
-produces a clean `.js` and a broken `.d.ts`, so no source edit can express the
-difference. The rewriter resolves each specifier against the source tree the
-output mirrors — a file hop becomes `./x.js`, a directory hop `./x/index.js` —
-throws on anything it cannot resolve, and after the build re-parses the emitted
-declarations to assert every relative specifier both carries an extension and
-names a file the build really emitted.
-
-`packages/fields` takes the `nodenext` pin as a result — the same two lines
-`packages/react` has carried since objectui#4538 — so the property is enforced by
-the compiler on the consumer side rather than by review. `packages/app-shell`
-does not: it type-checks clean without the pin and still shows 23 errors with it,
-none of them from these two packages. That residue is filed separately.
diff --git a/.changeset/eager-closure-budget-5324.md b/.changeset/eager-closure-budget-5324.md
deleted file mode 100644
index 230d596709..0000000000
--- a/.changeset/eager-closure-budget-5324.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
----
-
-CI and build tooling only — this publishes nothing, declared explicitly with an empty
-frontmatter rather than left undeclared. No package `src/` is touched.
-
-The console "performance budget" now weighs the **eager closure** instead of one chunk.
-
-`.github/workflows/performance-budget.yml` gzipped `apps/console/dist/assets/index-*.js`
-and compared it against a 350 KB line. Measured on `77f846a8b`, that chunk is 25,910 bytes
-gzipped, while the closure it statically pulls in — every chunk the browser must fetch and
-parse before the app renders — is 3,881,609 bytes across 58 of 507 chunks. The gate passed
-on 0.67% of the payload it claimed to govern, and `advancedChunks` routes vendor and
-workspace code into named chunks on purpose, so most regressions land outside the entry
-chunk. objectui#5266 is the worked example: 89 KiB gzipped added to every page load, landing
-in `vendor-objectstack-*.js`, structurally invisible here (objectui#5324).
-
-`emitEagerClosureReport` in `apps/console/vite.config.ts` walks rolldown's own
-`chunk.imports` from the entry chunks — static edges only, because the dynamic edge is the
-lazy boundary — gzips the bytes actually written to disk, and writes
-`dist/eager-closure.json`. `scripts/check-eager-closure-budget.mjs` applies the ceiling.
-The split is deliberate: a size ceiling enforced inside `vite build` would fail every
-Vercel preview and every local build, which is how a budget gets switched off rather than
-fixed. Exit codes are distinct — `1` over budget (a verdict about the bundle), `2` no
-trustworthy measurement (a verdict about the gauge) — so a broken gauge is never reported
-as a clean bundle, and vice versa.
-
-Every check in that path is a counter-probe, because this gate's failure mode is silent: a
-walk that finds too little, a stale report, an absent field read as zero all produce a
-SMALL number, and a budget reads a small number as good news. So the build refuses to
-publish a figure unless `react-dom` is inside the closure and at least one chunk is outside
-it, and the checker refuses a report whose totals disagree with its own chunk list, whose
-version it does not recognise, or that has collapsed to its entry chunk — that last one
-being precisely the gauge this replaces.
-
-The ceiling is 3,960,000 gzipped bytes: today's measurement plus 78,391 bytes of headroom.
-It passes on current `main`, and the headroom is deliberately narrower than the 89 KiB
-regression the gate exists to catch, so a repeat of objectui#5266 fails it (verified: the
-baseline plus 89 KiB comes out 12.4 KB over). Both constraints are asserted in
-`scripts/__tests__/check-eager-closure-budget.test.ts`, not merely argued in a comment.
-
-This is a truthful current-state ceiling, not a target. 3.79 MB gzipped before first render
-is a bad payload and the honest long-term line is far below it; lowering it is a separate
-decision with its own work behind it. The entry-chunk budget and its 350 KB line are
-unchanged — replacing a blind gauge is not licence to drop the check that was already there.
diff --git a/.changeset/esm-load-comment-mask-5382.md b/.changeset/esm-load-comment-mask-5382.md
deleted file mode 100644
index 70abee6d08..0000000000
--- a/.changeset/esm-load-comment-mask-5382.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
----
-
-CI tooling only — this publishes nothing, declared explicitly with an empty frontmatter
-rather than left undeclared. No package `src/` is touched.
-
-Fixes the comment mask in `scripts/check-node-esm-load.mjs` (objectui#5382). Leg 1 of
-the gate blanked comments out of every source with two ordered regexes and then matched
-specifiers in the result. The block-comment pass ran first and had no notion of already
-being inside a `//` line, so a slash-star sequence occurring in ordinary line-comment
-prose — a package glob, a path pattern, a wildcard import, all of them ordinary here —
-opened a comment that ran to the next closing delimiter anywhere in the file and blanked
-every line between, live code included.
-
-Re-measured on `main` at 478ec54ce over the 805 emitted sources of the 13
-specifier-preserving packages: the mask found 2132 relative specifiers and the TypeScript
-parser found 2133. The one it could not see is a real `import` in
-`packages/app-shell/src/preview/DraftChangesPanel.tsx`, hidden by a line comment naming
-the `@objectstack` chunk group by glob two lines above it.
-
-That direction is the bad one. Since `SPECIFIER_DEBT` emptied, leg 1 is a hard
-requirement rather than a ratchet, so a blind spot in it is somewhere a regression can
-sit permanently while the run reports clean and only the nightly load leg can see the
-consequence.
-
-Leg 1 now reads each file exactly as written and takes its module edges from
-`check-phantom-dependencies.mjs`'s shared TypeScript scanner — the same one
-`check-package-self-import.mjs` uses, so three gates cannot drift apart on what a module
-edge is. Comments, strings, template literals and regex literals stop being questions
-this gate has an opinion about. Reported line numbers stay the compiler's: the specifier
-literal is located inside the statement the parser already identified, which matters
-because `tsc` reports this class at the specifier and the statement opens on a different
-line for 255 of 2066 relative specifiers here.
-
-The gate's verdict is unchanged — 0 findings before, 0 findings after — because the
-newly visible import already carries its `.js` extension. What changed is that it is now
-visible. The whole cheap leg went from 0.71s to 2.43s.
-
-`readTsconfig()` in the same script strips comments with the same kind of
-context-unaware regex and is a separate live instance of this class. It is deliberately
-untouched here and remains open as objectui#5367.
diff --git a/.changeset/evaluateexpression-jsdoc-links-5580.md b/.changeset/evaluateexpression-jsdoc-links-5580.md
deleted file mode 100644
index d8167b1959..0000000000
--- a/.changeset/evaluateexpression-jsdoc-links-5580.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-'@object-ui/core': patch
----
-
-Both `evaluateExpression` references in the `ExpressionEvaluator.registerFunction`
-JSDoc are now qualified, so each resolves to the entity it means (objectui#5580).
-
-`ExpressionEvaluator.ts` declares two things spelled `evaluateExpression`: the method
-on `ExpressionEvaluator` (bare expression, throws) and the module-level export
-(context bag, fail-soft, delegating to `evaluate`). The `registerFunction` block
-referred to both under the one spelling, four lines apart.
-
-The prose link was not merely ambiguous, it was bound wrong. Measured with
-`checker.getSymbolAtLocation` on the pre-fix source, `{@link evaluateExpression}`
-resolved to the module-level `FunctionDeclaration` — the fail-soft one — inside the
-sentence that calls it *"the throwing sibling"*. The neighbouring `{@link evaluate}`
-binds to the method, but only because no module-level `evaluate` exists to outrank
-it, so the rule "an unqualified link resolves to the enclosing class's member" does
-not hold here. The link is now `{@link ExpressionEvaluator.evaluateExpression}`,
-which the checker resolves to the `MethodDeclaration`.
-
-The `@example`'s final line is the module-level export — its second parameter is a
-context bag and the `${...}` wrapper only resolves on the `evaluate` path — but it sat
-two lines below calls that establish `evaluator.` as the receiver, and a `.d.ts` hover
-carries no import to disambiguate. It now names the module-level export and shows the
-import it needs.
-
-This is prose only: the diff is confined to a block comment and no declaration moves.
-It is scored `patch` rather than the empty-frontmatter form because the block is
-emitted into what npm ships — measured, this edit moves both
-`dist/evaluator/ExpressionEvaluator.d.ts` and `dist/evaluator/ExpressionEvaluator.js`
-(this package builds with a bare `tsc`, which preserves comments in the JS emit), and
-the ten changed lines in that JS are all comment lines.
-
-`registerFunction-jsdoc-links.test.ts` pins the binding against the checker rather
-than asserting it in prose, since a `{@link}` that binds to the wrong entity is
-indistinguishable in source from one that binds right.
diff --git a/.changeset/filecell-error-slot-5431.md b/.changeset/filecell-error-slot-5431.md
deleted file mode 100644
index c6a890b5e6..0000000000
--- a/.changeset/filecell-error-slot-5431.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-'@object-ui/fields': minor
----
-
-**API addition (public-surface widening):** `FileCell` — the compact upload
-control `@object-ui/fields` exports for line-item grid cells — gains the
-published optional `error?: string` slot, mirroring `LookupField` and
-`FileField`: the same validation slot `@objectstack/spec/ui`'s
-`FieldWidgetPropsSchema` declares and `FieldWidgetComponentProps` names
-(objectui#3222). When set, `FileCell` puts `aria-invalid` on its own focusable
-picker button; the message text stays with the host (objectui#5431).
-
-`GridField` now passes that slot for a required-but-empty `file` cell — the one
-cell type objectui#3318's per-cell `aria-invalid` delivery left out. Before
-this, a required `file` cell flagged only the visual ring and `title` on the
-`td`; no element in the cell subtree announced the state, so assistive tech was
-told nothing (a wrapper-only mark is exactly what objectui#5223 forbids). Text,
-number, select, and lookup cells were wired in PR #5429; `file` cells now
-behave identically.
diff --git a/.changeset/fix-parity-aria-line-ref.md b/.changeset/fix-parity-aria-line-ref.md
deleted file mode 100644
index 9197bb525c..0000000000
--- a/.changeset/fix-parity-aria-line-ref.md
+++ /dev/null
@@ -1,4 +0,0 @@
----
----
-
-Test-only change to the parity gate's `aria` exemption comment; no published behaviour changes. Fixes a stale `file:line` reference to `packages/plugin-detail/src/index.tsx` (was `:335-337`, now `:554-556`) in `apps/console/src/__tests__/registry-inputs-spec-parity.test.ts`.
diff --git a/.changeset/flow-resume-result-5417.md b/.changeset/flow-resume-result-5417.md
deleted file mode 100644
index 5de2804350..0000000000
--- a/.changeset/flow-resume-result-5417.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-'@object-ui/app-shell': minor
-'@object-ui/i18n': minor
----
-
-A screen flow's resume result reaches the user — on both outcomes (objectui#5417).
-
-A dogfood walkthrough reported that a refused `resume` and a successful one
-"render identically: the dialog closes and the page is unchanged", leaving no
-gesture that distinguishes "created" from "rejected". Re-measured against `main`
-before any change, one half of that was already fixed — `interpretFlowResponse`
-reads the ADR-0112 envelope, and `FlowRunner`'s `toast.error` has carried its
-prose since the `400 FLOW_FAILED` classification landed in `17.6.0`, five minors
-after the version the report was measured on. There was no interpreter bug and
-no un-consolidated fourth call site. Three gaps in the RUNNER's disposition were
-real, and they are what changed:
-
-- **A terminal failure no longer closes the dialog.** The reason it closed is
-  unchanged and is not reversed: on a `FLOW_FAILED` the engine has already
-  consumed the suspension, so a resubmit can only reach "No suspended run" and
-  must not be offered. Closing was one way to withhold that dead retry and the
-  expensive one — the user had just typed a form they could no longer see, and
-  the engine's sentence names a value that left the screen with it. The dialog
-  now stays open with the submit affordance withdrawn: the flat footer swaps
-  Submit for Close, and an `object-form` step drops its Save (which also stops a
-  second click from duplicating the record it had already persisted).
-- **The refusal has a second, non-expiring carrier.** The toast stays — it is
-  viewport-fixed, so it still reaches a user scrolled past a tall step's header
-  — and an inline destructive `Alert` (`role="alert"`) now holds the same
-  sentence inside the dialog, beside the values that produced it. A retryable
-  refusal (`INVALID_SCREEN_INPUT`, transport, 5xx) keeps Submit live as before,
-  and its banner clears as soon as the user starts editing.
-- **A successful run invalidates what the flow WROTE, not just what the user is
-  looking at.** Both hosts answered `onComplete` with
-  `notifyDataChanged({ objectName: <this page's object> })`, so a flow that
-  created a quote from an Opportunity page never told the related list that
-  would now contain it — the record did not appear until a manual reload. The
-  runner cannot know which objects a flow touched, so it emits
-  `{ objectName: '*' }`: the same scope, for the same stated reason, that the
-  record page's manual ⟳ already uses. Everything mounted refetches in place
-  over the invalidation bus, with no remount.
-
-The runner's copy now goes through `@object-ui/i18n` instead of being hardcoded
-English: a new `flowRunner` namespace (`title`, `submitting`, `saveAndContinue`,
-`nextStep`, `completed`) in all ten packs, plus reuse of
-`common.{loading,cancel,close,submit}` and `wizard.missingRequired`. The
-server's own refusal sentence is still passed through untranslated — it is prose
-the automation engine composed for a human, not copy with a key.
diff --git a/.changeset/form-control-renderers-dom-props-5632.md b/.changeset/form-control-renderers-dom-props-5632.md
deleted file mode 100644
index c13febb1a2..0000000000
--- a/.changeset/form-control-renderers-dom-props-5632.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-'@object-ui/components': patch
----
-
-**Behaviour change:** the eighteen renderers whose host element is a form
-control no longer forward their whole prop bag to it. They route it through a
-form-control DOM declaration — the same `pickDomProps` mechanism `grid`, `flex`,
-`stack`, `container` and `text` were converged on — so an authored schema key
-becomes an HTML attribute only if the contract declares it one (objectui#5632,
-the `BARE_SPREAD_MINUS_NAME` slice of objectui#5574).
-
-The eighteen: `action:button`, `action:icon`, `ui:button`, `ui:checkbox`,
-`ui:combobox`, `ui:date-picker`, `ui:email`, `ui:file-upload`, `ui:input`,
-`ui:input-otp`, `ui:password`, `ui:radio-group`, `ui:sidebar-menu-button`,
-`ui:slider`, `ui:sonner`, `ui:switch`, `ui:textarea`, `ui:toggle`.
-
-What this stops reaching the DOM: the renderer's own declared props, consumed
-off `schema` to render the control AND spread onto the element a second time as
-attributes HTML does not define, plus the authored node's SDUI metadata and the
-flattened `props` container. Measured across `examples/schema-catalog`, rendered
-through the real `SchemaRenderer`: 284 illegitimate attributes over 287
-form-control nodes — `button[label]` 140, `button[icon]` 25, `input[inputtype]`
-23, `input[label]` 19, `toggle[label]` 14, `radio-group[options]` 8,
-`date-picker[placeholder]` 7, `file-upload[label]` 7, `file-upload[buttontext]`
-7, `checkbox[label]` 6, `textarea[label]` 6, `toggle[arialabel]` 6,
-`switch[label]` 4, `password[label]` 3, `email[label]` 2, `radio-group[direction]`
-2, and six singletons. The same probe reads 0 after, with `grid`'s 26 nodes at 0
-both times as the control and an unchanged node census across the two runs.
-
-`name` and `disabled` are DELIBERATELY still forwarded. Both are legal on a form
-control and neither was ever part of the leak — the ledgered shape for this
-group is thirteen attributes, not fourteen, precisely because HTML defines
-`name` on these hosts. The whitelist this group uses is therefore the shared
-SDUI one PLUS those two, not the bare `toDomProps` the container renderers take:
-that would have stripped the form-serialization key off every control and
-silently re-enabled every disabled one, and no gate in the repo would have gone
-red for it.
-
-Nothing an author writes renders differently: every leaked key was already being
-read off `schema` and applied. `id`, `role`, `tabIndex`, `className`, `style`,
-event handlers and the open `data-*` / `aria-*` families are unchanged.
-
-Anything that read one of the leaked attributes off the DOM — a CSS attribute
-selector such as `[label="Save"]`, or a test asserting `inputtype` on a rendered
-`ui:input` — must read the schema instead. No `@object-ui` code did; this is
-called out because the attributes were externally visible while they lasted.
diff --git a/.changeset/form-designer-namespaced-field-type-4838.md b/.changeset/form-designer-namespaced-field-type-4838.md
deleted file mode 100644
index 88b03f1e62..0000000000
--- a/.changeset/form-designer-namespaced-field-type-4838.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-Studio's form designer canvas now emits the namespaced `FormField.type` spelling
-instead of passing `objectDef.fields[x].type` through raw (objectui#4838).
-
-Per the maintainer ruling on that card, a bare spec-type name (`markdown`,
-`html`, `richtext`, …) is **not** a legal `FormField.type` — one widget, one
-legal spelling, the namespaced widget id. `ObjectFormDesigner` was the measured
-producer of the bare spelling: it handed a raw object-metadata type straight to
-`isWideFieldType`, a helper whose vocabulary is `FormField.type`. It now
-normalizes through `mapFieldTypeToFormType`, the one place that widget decision
-is made.
-
-User-visible effect: a `repeater` field is finally laid out full-row on the
-canvas, matching the runtime form. `repeater` is a spec `FieldType` that
-resolves to the wide `field:grid` widget, but bare `repeater` is not one of
-`WIDE_FIELD_TYPES`' bare members, so the raw pass matched nothing — the canvas
-showed it at normal width while the real form spanned it. Fields whose spec name
-doubles as a widget id (`textarea`, `markdown`, `html`, `richtext`, `grid`) are
-unaffected; they matched under both spellings.
-
-The two tolerant consumers this makes look redundant are deliberately left
-alone, each scheduled under its own follow-up with deprecation care: the
-`field:`-prefix fallback in `renderFieldComponent`, and `WIDE_FIELD_TYPES`' dual
-spellings. Removing a tolerance is the consumer-tightening half, and other
-producers have not been normalized yet.
diff --git a/.changeset/form-field-predicate-current-user-6010.md b/.changeset/form-field-predicate-current-user-6010.md
deleted file mode 100644
index 6946763e4b..0000000000
--- a/.changeset/form-field-predicate-current-user-6010.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-'@object-ui/components': minor
----
-
-**Behaviour change.** Form section and field `visibleWhen` predicates that silently failed
-OPEN now actually evaluate — and a rule that resolves FALSE now hides the field
-(objectui#6010).
-
-`current_user` was bound on two of the three `visibleWhen` surfaces and not the third. A
-page component or app/nav gate got it (`ExpressionProvider` → `SchemaRenderer`), and a
-per-option gate got it (`resolveCascadingOptions(…, predicateScope)`), but every
-`resolveFieldRuleState` call in the form renderer passed `undefined` for the scope
-argument, so a form SECTION or FIELD predicate saw `record` and `previous` and nothing
-else. `'sales_manager' in current_user.positions` therefore named an **unbound root**
-there, and the visibility fallback is fail-open — so the gate did not hide the field from
-the people it named, it **showed the field to everyone**, with no signal beyond one
-deduped `console.warn`.
-
-**What changes for you, in the direction that matters:** if you authored a form-field or
-form-section `visibleWhen` naming `current_user`, saw the field render, and concluded the
-rule was permissive — it was not permissive, it was broken, and it is now enforced. That
-same field will now **hide** for every user the predicate resolves FALSE for. Audit any
-`visibleWhen` on a form field or section that references `current_user` / `user` /
-`ctx.user` / `os.user` before upgrading; a predicate that was quietly inert becomes live.
-
-Two things deliberately do **not** change:
-
-- **A genuinely unbound root still fails open.** A predicate the engine cannot evaluate at
-  all still logs one warning and leaves the element visible. Only *evaluated-and-false*
-  hides. `visibleWhen` remains presentation, not access control — use field-level security
-  or RLS to stop someone reading something.
-- **The deprecated `visibleOn` alias** on a form field now binds the same scope, because
-  ADR-0089 D2 folds it into `visibleWhen` at parse; binding one scope for the canonical
-  spelling and another for its alias would have reproduced the same defect one spelling
-  over. The synthesised legacy `condition: { field, equals }` predicate is unaffected — it
-  is generated from a structured object and can only ever name `record.<field>`.
-
-This restores the contract both ADRs already declared: ADR-0068 D1 — *"a predicate authored
-against any one form evaluates identically"* — and ADR-0089 D1 — *"runtime record surfaces
-bind `record` + `current_user`"*. All five surfaces are now pinned against one authored
-predicate text in
-`packages/components/src/renderers/form/__tests__/predicate-scope-parity-6010.test.tsx`,
-so the next divergence is loud instead of silent.
diff --git a/.changeset/form-reset-notification-channels-5235.md b/.changeset/form-reset-notification-channels-5235.md
deleted file mode 100644
index 6a2d2c3f14..0000000000
--- a/.changeset/form-reset-notification-channels-5235.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-'@object-ui/components': patch
----
-
-The form renderer now keeps a `defaultValues` reset off `onChange` and off the
-`form_change` `onAction` for **every** caller — including one that memoizes the
-callback (objectui#5235).
-
-"A record landing is not a user edit" was already this file's documented,
-pinned behaviour, but two of the three channels delivered it by accident of
-React's effect ordering: every layout DESTROY runs before any layout CREATE, so
-a caller passing a fresh callback each render had its value subscription torn
-down before the reset and re-established after. The guarantee was therefore
-delivered by the callback's *identity changing*. Wrap the same callback in
-`React.useCallback` — taught everywhere as a semantically neutral performance
-optimization — and the identity stays put, the effect never re-runs, the
-subscription survives the reset, and the whole loaded record comes back to the
-host as if the user had typed it: the false "the user edited this" signal
-objectui#2968 was filed about, in a form no type, doc or call site warned about.
-
-The reset now states what those two channels report, the way `onDirtyChange`
-already did (it computes its payload against the freshly installed baseline and
-calls the host outright). Callers passing inline arrows see byte-identical
-behaviour; callers who memoize stop receiving a phantom edit.
-
-Not a contract change: whether a value channel *should* report a programmatic
-reset stays open in objectui#5235. This only removes the answer's dependence on
-caller identity.
diff --git a/.changeset/formatpercent-comment-citations-4596.md b/.changeset/formatpercent-comment-citations-4596.md
deleted file mode 100644
index 6e68a460df..0000000000
--- a/.changeset/formatpercent-comment-citations-4596.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
----
-
-Comments only — this publishes nothing, declared explicitly with an empty frontmatter
-rather than left undeclared (objectui#4596).
-
-Why the empty form is the right declaration here: both changed comments are **internal
-reasoning**, not consumer-visible API documentation. One sits inside `formatMeasure`'s
-body; the other is a test-file header. No released behaviour changes, and no declaration
-changes — `dist/utils/dataset-format.d.ts` is byte-identical across this change
-(measured: sha `be5f5938…`, 10,580 bytes on both sides), so nothing a consumer types
-against or reads on hover moves.
-
-Stated honestly, because an earlier draft of this note got it wrong: the shipped
-JavaScript **does** change. `tsconfig.base.json` sets `removeComments: false`
-deliberately and `@object-ui/core` builds with a plain `tsc`, so a body comment is
-emitted — `dist/utils/dataset-format.js` goes from 14,716 to 15,457 bytes, and it is the
-only one of the package's 180 dist files that moves. The test file is excluded from the
-build program (`src/**/__tests__/**`) and never reaches `dist` at all. Bytes moving is
-not the criterion; released behaviour and consumer-visible surface are, and neither does.
-
-Three comments cited `formatPercent` as the live example of the divide-by-100 percent
-route. Each was accurate when written and stopped being true when objectui#4590 landed:
-`formatPercent` renders through `style: 'percentPoints'` with no division. The comments
-now argue the route on its own merits without the expired citation, and record what
-replaced it — no caller in this repo takes the divide-by-100 route today. `formatPercent`
-was the last one; the two remaining `style: 'percent'` sites hand `Intl` a FRACTION, which
-is that style's own contract, and the route otherwise survives only where a test builds it
-in order to show it disagreeing.
-
-The measured argument underneath is unchanged, and the tie / extreme-magnitude pins that
-keep the percentage-points route honest are untouched. The `27,581 of 1,200,013` figure
-now names the grid it came from — objectui#4576's tie-dense grid, 0.005 steps to 2,000,
-precisions 0/1/2, on `formatMeasure`'s call shape — so it stops reading as a discrepancy
-against objectui#4590's `27,577 of 1,200,003`, which is the same grid re-measured through
-`formatPercent`.
diff --git a/.changeset/formfieldspec-dependson-5040.md b/.changeset/formfieldspec-dependson-5040.md
deleted file mode 100644
index 183a8fc65c..0000000000
--- a/.changeset/formfieldspec-dependson-5040.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-metadata-admin: `FormFieldSpec` declares `dependsOn`, and the widget half reads
-the same declaration instead of its own copy of it (objectui#5040)
-
-`FormFieldSpec` — the authoring type for a metadata-admin form layout, the
-element type of `FormSectionSpec.fields[]` — did not declare `dependsOn`.
-`widgets.tsx` held a second, inline description of the same object as
-`WidgetProps.fieldSpec`, and that one did, because two registered widgets read
-it as their primary configuration: `field-selector` resolves
-`dependsOn || reference || 'objectName'` to decide whose field catalog to
-offer, and `dynamic-config` uses it to pick a sub-schema out of
-`WidgetContext.dynamicSchemas`. One value travelling down one channel,
-described twice, disagreeing on the one key that decides what those widgets
-show — so
-
-```ts
-{ field: 'fields', widget: 'field-selector', dependsOn: 'objectName' }
-```
-
-the only configuration that makes `field-selector` work, was a `TS2353` for
-anyone who typed their spec. It survived because in-repo specs reach the form
-through `as any` / loose types, so the authoring type was never asked.
-
-No runtime behaviour changes: `MetadataField` already handed `dependsOn`
-through and both widgets already read it. What changes is the type face — it
-now admits what the runtime has always accepted. The two descriptions are one
-declaration, extracted to a leaf module
-(`views/metadata-admin/form-spec.ts`) that both halves import, because
-`SchemaForm.tsx` imports `./widgets.js` and a back-edge would close a cycle.
-`SchemaForm.tsx` re-exports `FormFieldSpec` and `VisibilityPredicate`, so every
-existing importer is unaffected.
-
-`dependsOn` is `string | string[]` here, deliberately **not**
-`@object-ui/types`' wider canonical `DependsOnInput`, which also admits
-`{ field, param }` objects: both readers index `[0]` and use the result as a
-field name, so the wider shape would be a type that lies. Converging the two is
-its own decision, pinned as a refusal rather than taken silently.
diff --git a/.changeset/formpage-conditional-rule-surfaces-5627.md b/.changeset/formpage-conditional-rule-surfaces-5627.md
deleted file mode 100644
index 6f9028e014..0000000000
--- a/.changeset/formpage-conditional-rule-surfaces-5627.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-'@object-ui/console': patch
----
-
-`FormPage` — the console's own form renderer, serving both the public `/f/:slug`
-route and the internal `/forms/:name` one — now honours the three conditional-rule
-surfaces it still dropped after objectui#5594: section-level `visibleWhen` /
-`visibleOn`, and the object-level field rules `visibleWhen` / `readonlyWhen` /
-`requiredWhen` (objectui#5627).
-
-This is the second form renderer in the repo, and it honoured exactly one of the
-four surfaces the sibling chain does. A section an author conditioned away rendered
-in full — heading and every control — on both routes including the anonymous one.
-The object-level half was worse than fail-open hiding: `readonly` was whatever the
-static flag said, so a field a `readonlyWhen` should have locked stayed editable and
-paired with the server's fail-closed unbound-scope behaviour into "the user edits,
-the save reports success, and the value never lands".
-
-Both halves evaluate through the SHARED machinery rather than a fourth consumer-side
-copy of the rule semantics: `@object-ui/core`'s `resolveFieldRuleState` for the three
-field rules — which brings the settled rulings with it, including the `serverOwnedValue`
-carve-out that keeps a create form from requiring a producer-owned control (#4069 /
-#4085) — and its `evalFieldPredicate` for the section predicate, with the canonical-first
-`visibleWhen ?? visibleOn` read every sibling reader spells.
-
-Visibility stays a RENDERING rule at both granularities: a hidden section's fields
-still submit their values, exactly as a hidden field's have since #5594.
diff --git a/.changeset/formpage-maxlength-override-5595.md b/.changeset/formpage-maxlength-override-5595.md
deleted file mode 100644
index 337dd53ada..0000000000
--- a/.changeset/formpage-maxlength-override-5595.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-'@object-ui/console': patch
----
-
-`buildSections` now honours a FormView field's `maxLength` override instead of always
-taking the object's ceiling (objectui#5595).
-
-The function merges a form's field overrides with the target object's field definitions,
-and its own docstring states the rule: *"Field-level FormField overrides take precedence
-over object defaults."* Every key in the loop is built that way — `override.label ??
-def.label`, `override.required ?? def.required`, `override.placeholder ?? def.placeholder`
-— except one, which read `def.maxLength` unconditionally. So an author who set a tighter
-per-form limit (a short public intake form over a column whose object-level ceiling is
-generous) got the generous one.
-
-The failure was silent in the worst direction: no diagnostic, no warning, and the form
-still submits, so the symptom is a value the author believed the input refused being
-accepted. It is load-bearing rather than cosmetic — the merged row reaches the DOM at two
-`maxLength={field.maxLength}` sites, the `textarea` arm and the default `input type="text"`
-arm.
-
-`override.maxLength ?? def.maxLength` — `??` rather than `||`, matching the sibling keys,
-so an explicitly declared `0` stays a value the author wrote rather than falling through
-to the column's ceiling. This narrows only what the input allows; the object's storage
-ceiling still decides at submit time, so nothing that was accepted before is now rejected
-anywhere but at the keyboard.
-
-Why it survived: the console's local `FormFieldSpec` did not declare `maxLength` at all
-until objectui#5542, so no one typing a spec in this app could write the override in the
-first place, and the inert merge branch was never exercised. #5542 converged that type
-onto the shared app-shell declaration, which does declare the key — making the gap
-expressible, and therefore findable.
-
-The pin `#5542` left behind — `expect(row.maxLength).toBeUndefined()` in
-`FormPage.fieldSpec.test.ts`, which recorded the old answer explicitly rather than
-assuming it — is **inverted** to `toBe(40)` rather than deleted. It was the pre-registered
-evidence for this fix, and it is what made the gap findable in the first place, so it
-keeps its place and names the honoured answer.
diff --git a/.changeset/formpage-record-id-param-comment-4319.md b/.changeset/formpage-record-id-param-comment-4319.md
deleted file mode 100644
index d20c6fa828..0000000000
--- a/.changeset/formpage-record-id-param-comment-4319.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
----
-
-Comment-only repair in `apps/console`'s `FormPage`: the `FORM_RECORD_ID_PARAM`
-docblock no longer borrows `createdRecordPath.ts` as a second witness for
-`@object-ui/app-shell`'s root-barrel unreachability. That sibling case was
-resolved when the host-app resolver was published from the package root, so a
-reader following the cross-reference found the opposite of what it promised.
-The surviving justification is unchanged and still true — the root barrel does
-not re-export `./urlParams` — and now states that fact directly. No published
-behaviour changes.
diff --git a/.changeset/gantt-navconfig-comment-once.md b/.changeset/gantt-navconfig-comment-once.md
deleted file mode 100644
index 0390f51d96..0000000000
--- a/.changeset/gantt-navconfig-comment-once.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
----
-
-`ObjectGantt` internal cleanup, measured as a zero-pixel change:
-
-- The comment block above the `navConfig` default repeated its own last two
-  lines verbatim, leaving a mid-sentence fragment. The sentence is now stated
-  once, in full.
-- The drawer default no longer spells the spec-deprecated `width`
-  (`@deprecated [#2578 -> size]`). It is now `{ mode: 'drawer' }`, so
-  `resolveOverlayWidth` returns `undefined` and `RecordDetailDrawer`'s own
-  `width` default supplies the identical `min(960px, 60vw)`. The resolved
-  overlay width is unchanged on every viewport, and is now pinned by a test.
-
-No published behaviour changes.
diff --git a/.changeset/gantt-viewmode-declared-both-branches-5074.md b/.changeset/gantt-viewmode-declared-both-branches-5074.md
deleted file mode 100644
index 650da3c57f..0000000000
--- a/.changeset/gantt-viewmode-declared-both-branches-5074.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-'@object-ui/types': minor
-'@object-ui/plugin-gantt': minor
----
-
-**`viewMode` is now declared authoring surface on `ObjectGanttSchema`, and both
-gantt renderer branches honour it** (objectui#5074, maintainer ruling
-2026-08-19: declare-and-wire; the spec half landed first upstream).
-
-- `ObjectGanttSchema` (TS interface and zod mirror) declares `viewMode`,
-  DERIVED from the pinned `@objectstack/spec` `GanttConfigSchema.viewMode`
-  enum by reference, so the member list cannot drift. Deliberately no
-  default: an omitted `viewMode` keeps letting a persisted layout
-  (`persistLayoutKey`) seed the timeline granularity before the renderer's
-  `'day'` fallback.
-- The timeline branch (`GanttView`) now receives an authored `viewMode`.
-  Previously only the resource-workload branch (`resourceView` +
-  `assigneeField`) honoured it, so `viewMode: 'month'` on an ordinary gantt
-  view was silently ignored.
-- The `(schema as any).viewMode` cast in `ObjectGantt` is retired; both
-  branches read the declared `ganttConfig.viewMode`, which also honours the
-  key when authored inside the spec's `gantt` config block.
-- Accept-set note: `viewMode` is now a DECLARED key, so an off-enum value
-  (e.g. `viewMode: 'hour'`) becomes a zod validation error where it
-  previously passed through unvalidated. Values on the published spec enum
-  are unaffected.
diff --git a/.changeset/gate-listlocalinstalls-marketplace-5620.md b/.changeset/gate-listlocalinstalls-marketplace-5620.md
deleted file mode 100644
index cb6c4165c2..0000000000
--- a/.changeset/gate-listlocalinstalls-marketplace-5620.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-`MarketplacePackagePage`'s third fetch effect — `listLocalInstalls` — is now gated on
-`marketplaceEnabled` and `isAdmin`, the same two predicates the page's other two fetch
-effects already check, in addition to (not instead of) its existing
-`features.installLocal` check (objectui#5620).
-
-`listLocalInstalls`'s only consumer is `localInstalls.find(...)` in the content branch,
-which is unreachable whenever the page has already returned `MarketplaceDisabled` (no
-marketplace on this runtime) or `MarketplaceAccessDenied` (a refused viewer) — both
-decided ahead of the content branch since objectui#5533 and objectui#5583. Before this
-fix, a runtime with `features.installLocal: true` still fired the request — and
-discarded its answer — on a marketplace-off runtime and for a non-admin, the same
-wasted-round-trip class objectui#5533 established the fix for on this page, on the flag
-that card was not about.
-
-`features.installLocal` remains its own axis: a runtime can mount a local kernel install
-path with no marketplace proxy at all, so the fix adds the two predicates as a
-conjunction rather than replacing the existing check. The request still fires exactly
-when it did before AND the viewer would actually see its answer.
diff --git a/.changeset/governed-surface-human-merge-5149.md b/.changeset/governed-surface-human-merge-5149.md
deleted file mode 100644
index 7d63234c48..0000000000
--- a/.changeset/governed-surface-human-merge-5149.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
----
-
-Instruction files only — this publishes nothing, declared explicitly with an empty
-frontmatter rather than left undeclared. `AGENTS.md` records the governed surface
-(`AGENTS.md`, `CLAUDE.md`, `.claude/**`, `docs/adr/**`) and the rule that agent seats
-leave a PR touching it in draft for a human merge.
diff --git a/.changeset/grid-column-spelling-docs-5352.md b/.changeset/grid-column-spelling-docs-5352.md
deleted file mode 100644
index d80cdfb618..0000000000
--- a/.changeset/grid-column-spelling-docs-5352.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
----
-
-Docs and skills only — this publishes nothing, declared explicitly with an empty
-frontmatter rather than left undeclared. No package `src/` is touched, so no
-`@object-ui/*` package changes behaviour and there is nothing here for a consumer
-to upgrade to.
-
-Corrects the two published corpora that taught `object-grid` columns in a `name`
-spelling `ObjectGrid` does not read. `ListColumnSchema` (`@objectstack/spec/ui`) is a
-strict object whose column-identity key is `field`; `{ "name": ... }` is refused by
-name (`unrecognized_keys: ["name"]`) and, at runtime, contributes no column.
-
-- `content/docs/api/schema-reference.md` — the `ObjectGridSchema` example authored a
-  MIXED array (four bare strings followed by one column object). Two defects in one
-  array: the object entry spelled `name`, and mixing forms is itself unsupported —
-  `normalizeColumns` dispatches the whole array on `columns[0]`, so a column object
-  standing behind a bare string is dropped whatever it spells. Renaming the key alone
-  does not fix it; the example is now uniformly `ListColumn` objects. The `columns`
-  row of the property table now names `field` and states the no-mixing rule.
-- `skills/objectui/guides/page-builder.md` — the grid example's three columns were
-  all-object in the `name` spelling, so the grid rendered its row-number column and no
-  data columns at all. Now spelled `field`. A note was added between the grid and form
-  examples, which sit adjacent and mean the OPPOSITE thing by the same pair of words:
-  `ListColumn.field` names the object field a column shows, while `FormField.name`
-  names the field a form input writes. That adjacency is the documented cause of this
-  defect family (`packages/core/src/utils/column-identity.ts`).
-
-The adjacent `object-form` example is unchanged and was never wrong — `FormField.name`
-is that layer's real key.
diff --git a/.changeset/grid-default-filters-lowering-4082.md b/.changeset/grid-default-filters-lowering-4082.md
deleted file mode 100644
index 1fa03310a2..0000000000
--- a/.changeset/grid-default-filters-lowering-4082.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-"@object-ui/plugin-grid": patch
----
-
-`ObjectGrid` lowers the deprecated `defaultFilters` through `toFilterNode` instead of
-byte-copying it onto `$filter` (objectui#4082).
-
-The query assembly already lowered the canonical `filter` key through `toFilterNode` —
-the repo's single "last hop before the wire" (objectui#4041) — while the legacy branch
-beside it assigned `params.$filter = schema.defaultFilters` verbatim. That made this the
-one leg on the chain reaching the wire unlowered: `plugin-list`'s `buildEffectiveFilter`
-and `plugin-view`'s non-grid fetch both already route the same value through
-`toFilterNode` / `mergeFilterNodes`.
-
-Byte-copying is refused on the wire for both shapes the slot carries. `defaultFilters` is
-declared `Record<string, any>` (the MongoDB-style shape) and `isFilterAST` is false for a
-plain object; an array of `ViewFilterRule` objects fails the same predicate. Either one
-answers `400 INVALID_FILTER` — measured against a real backend in objectui#3431.
-
-`toFilterNode` handles both without new logic: objects route through
-`convertFiltersToAST`, rule arrays lower element-wise, and an AST already in the slot
-passes through untouched, so nothing is lowered twice. It also folds an absent or empty
-source to `undefined`, which is why the truthiness guard is gone — `defaultFilters: {}`
-used to send `$filter: {}`, asking the server a question with no content in a shape it
-refuses; now `$filter` is omitted, matching the canonical key's documented behaviour.
-
-**Grade — this is less dormant than the card assumed.** objectui#4082 was filed
-observation-class on "no measured producer", reasoning that `defaultFilters` is not in
-`object-grid`'s registered `inputs` so an author writing it only draws a save-gate
-warning. That reasoning covers authors, but not the framework: `plugin-view`'s
-`ObjectView` writes the slot itself, forwarding an active named view's `filter` as
-`defaultFilters: viewFilter || schema.table?.defaultFilters` in its `gridSchema` memo —
-and `plugin-view`'s own README documents `listViews.<name>.filter` as
-`[{ field, operator, value }, …]`, the exact shape objectui#3431 measured as
-`400 INVALID_FILTER`. The registered `object-view` / `view` renderer passes no
-`renderListView`, so that path falls through to `ObjectGrid` rather than to `ListView`,
-and `ListView`'s lowering does not cover it. So a schema-registration host — the
-documented authoring path — reached the raw assignment whenever an active named view
-carried a filter. Not asserted here: a failing request captured against a running
-deployment. `app-shell` is unaffected either way; it supplies `renderListView` and
-delegates to `ListView`, which lowers.
-
-Not in scope, and deliberately not done: retiring `defaultFilters`. This is
-consumer-side only — the key the schema admits is unchanged, and its precedence behind
-the canonical `filter` is unchanged.
-
-The sibling legacy `defaultSort` leg was graded and needs no change; see the PR for the
-measurements.
diff --git a/.changeset/grid-dom-attribute-whitelist-4787.md b/.changeset/grid-dom-attribute-whitelist-4787.md
deleted file mode 100644
index 1dc2d35067..0000000000
--- a/.changeset/grid-dom-attribute-whitelist-4787.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-'@object-ui/components': patch
----
-
-The `ui:grid` renderer now forwards to the DOM by whitelist, so schema keys no longer
-land on the rendered `<div>` as invalid HTML attributes (objectui#4787).
-
-`grid.tsx` ended in a bare `{...gridProps}` spread that removed only `data-obj-*` and
-`style`, so everything else `SchemaRenderer` hands a registered component reached the
-element. Measured on a canary node, eight attributes leaked:
-`columns="4"`, `gap="4"`, `mdcolumns="2"`, `smcolumns="2"`, `name="grid_node"`,
-`props="[object Object]"`, `colorvariant="x"` (the flattened `props` container) and an
-unknown authored `zzcanary="leak"`. A responsive `columns` object rendered as
-`columns="[object Object]"`. Layout was unaffected, so every catalog grid example
-rendered with them — the reason this went unnoticed.
-
-The spread now goes through `toDomProps` from `@object-ui/core`, the same whitelist
-objectui#3291 established in `packages/fields` and objectui#4425 phase 2 promoted to the
-SDUI widget contract. Keys that are *declared* DOM-safe survive — `id`, `className`,
-`role`, `tabIndex`, plus the open `data-*` and `aria-*` families, which is how the
-designer's `data-obj-id` / `data-obj-type` still arrive — and `style` continues to be
-forwarded by name. Nothing an author can add to a grid node reaches the DOM implicitly
-any more, including keys `GridSchema` does not have yet; enumerating today's keys to
-strip would have re-rotted on the next schema addition.
-
-No authored input changes and no layout changes: the grid's own vocabulary was always
-read off `schema`, never off these props.
diff --git a/.changeset/grid-select-published-fields.md b/.changeset/grid-select-published-fields.md
deleted file mode 100644
index 932e1c1a56..0000000000
--- a/.changeset/grid-select-published-fields.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-Studio 的记录网格只请求服务端真有的列——「添加字段」不再把整个网格打成「该视图的查询被拒绝」
-
-在 Data 支柱点一下「添加字段」，整片网格立刻变成错误态，并建议「清除筛选条件」——而现场根本没有筛选条件。
-
-根因是投影的来源错了。`gridColumns` 取的是**草稿**对象的字段名，而这个数组是下游取数的输入；`addField` 只往本地草稿推一个 `field_<N>`。于是列一变就重新取数，`select` 里带着服务端不存在的列，data API 按设计拒绝——它的错误信息还专门解释了为什么不能静默丢弃未知列：那会把窄投影悄悄答成宽投影。
-
-修法的边界是**实测**出来的，不是猜的：把字段存成草稿返回 200 且 `state=draft`，紧接着的 `select` 指名它**仍然** 400。物化发生在**发布**时，所以「有没有保存」是错的问题，「服务端有没有」才是——答案在 `layered().effective` 这条基线里。
-
-因此新增 `publishedFieldNames`（加载时取自基线），并让 `gridColumns` 只保留其中存在的列。新字段照常在右侧检查器里被选中和配置（那本来就是配置它的地方），发布之后它可查询了，才作为列出现在网格里。
-
-过滤放在列数组这一处、而不是取数那一侧，是为了让「网格要什么」只有一个真相源。
-
-回归测试 `DataPillar.gridProjection.test.tsx` 断言在**交给对象视图的列数组**上——那个数组就是投影本身；如果只监视取数调用，日后把数组在下游改一手也能过，缺陷就悄悄搬回来了。撤掉这一行过滤，第二条精确转红、第一条仍绿。
diff --git a/.changeset/grid-unresolved-column-diagnostic-5349.md b/.changeset/grid-unresolved-column-diagnostic-5349.md
deleted file mode 100644
index 43d1c5a7d1..0000000000
--- a/.changeset/grid-unresolved-column-diagnostic-5349.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-'@object-ui/plugin-grid': patch
----
-
-`ObjectGrid` says which column it dropped, instead of rendering a header-only grid in silence.
-
-objectui#5068 retired the undeclared `accessorKey` / `header` tolerance branch, so
-`ListColumnSchema`'s `field` / `label` is now the only column spelling the renderer
-reads. That was right — the spec refuses `accessorKey` and `header` by name, and the
-census found zero authored usages. But it relocated a failure mode instead of removing
-it: a column authored in a spelling the renderer does not read contributed nothing, and
-nothing said so. No error, no warning, no empty state — the author got a grid with its
-row-number column and no data columns, which is a success receipt for a disagreement
-between the renderer and the author.
-
-An authored column that can never resolve now emits one `console.warn` naming the
-address rather than the symptom: which block (`object-grid` or the `view:grid` alias),
-which object and label, which `columns[i]`, the keys that entry actually carries, and the
-rewrite that works — for a column authored `{ accessorKey: 'amount', header: 'Amount' }`
-the message spells out `{ field: 'amount', label: 'Amount' }`. It reuses the channel `ObjectGrid` already had for "you declared it, the renderer dropped
-it" (the export-format warning), rather than adding a second differently-shaped one.
-
-Rendering is unchanged in every case: this is additive. The diagnostic reads the
-`columns` input and nothing else — it never asks whether the grid found rows, because
-`object-grid` legitimately draws them from five different places (a bare `data` array,
-`data.provider: 'value'`, legacy `staticData`, `bind`, or a host that owns the fetch and
-passes the window down as a `data` React prop, which is what `plugin-list`'s `ListView`
-does). All five are pinned by test, in both directions. A `hidden: true` column is
-authored intent and is never reported, and so are the arms that legitimately produce no
-columns of their own: no `columns` key, an empty `columns` array, and the `string[]`
-spelling.
-
-A throw was rejected: a grid that renders nothing today would become a page that renders
-nothing.
diff --git a/.changeset/grid-user-actions-collision-5240.md b/.changeset/grid-user-actions-collision-5240.md
deleted file mode 100644
index 8f7c79a354..0000000000
--- a/.changeset/grid-user-actions-collision-5240.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-'@object-ui/plugin-grid': patch
----
-
-`object-grid` harvests row-action predicate fields from the OBJECT's `userActions` block only — a view's toolbar policy can no longer shadow it.
-
-`userActions` names two different blocks. On a **view** it is toolbar policy —
-the spec's `UserActionsConfigSchema` (`sort`, `search`, `filter`, `refresh`,
-`rowHeight`, `addRecordForm`, `editInline`, `buttons`), which rejects `edit` by
-name. On an **object** it is the CRUD-predicate block (`edit` / `delete` /
-`create` carrying `visibleWhen` / `disabledWhen`, objectui#2614) — and that is
-the only shape `listViewPredicates` can read, since its loop skips every
-non-object value.
-
-`ObjectGrid` read the key view-first when building the `$select` projection
-(`(schema as any).userActions ?? resolvedSchema.userActions`). A view carrying a
-perfectly legal toolbar block therefore shadowed the object's CRUD predicates,
-the harvest found none, and the predicate's operand left the projection. CEL then
-faults on the absent key, fails closed, and the row Edit/Delete button disappears
-for everyone with nothing pointing at the projection — objectui#3501's failure,
-reached with a success receipt at every step.
-
-The view-level block is not hypothetical: `SpecBridge.transformListView` copies
-it onto the `object-grid` node the renderer receives, and `app-shell`'s
-`ObjectView` builds one unconditionally.
-
-The harvest now reads the resolved object block only. Both `userActions` read
-sites carry a comment naming the collision, and
-`__tests__/gridNonAuthorKeys.test.tsx` pins each clause of it: the two shapes,
-the producer that writes the view one, the harvest's blindness to it, and the
-projection that must keep the object's operand with a toolbar block present.
-
-Toolbar policy itself is untouched — it was never read through this path.
diff --git a/.changeset/grid-widget-aria-invalid-3318.md b/.changeset/grid-widget-aria-invalid-3318.md
deleted file mode 100644
index e644f0adf7..0000000000
--- a/.changeset/grid-widget-aria-invalid-3318.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-'@object-ui/fields': patch
----
-
-Grid field widget: announce a form-level validation failure to assistive tech.
-
-A required `grid` submitted while still empty rendered its "is required" message
-but marked nothing — every row was a ghost row, and ghost rows were skipped by
-the widget's per-cell validity channel. A sighted user saw the red message; a
-screen-reader user was told nothing at all.
-
-The host failure now drives the per-cell channel the widget already owns: when
-the `error` slot is set on an empty grid, the ghost entry row's required cells
-flag, and the mark sits on each cell's own control rather than on the `td`
-wrapper (a `td` is not focusable, and assistive tech reads validity from the
-control). Populated grids are unaffected — they already marked their own empty
-required cells inline.
diff --git a/.changeset/hollow-view-overlay-hydration-pin-5773.md b/.changeset/hollow-view-overlay-hydration-pin-5773.md
deleted file mode 100644
index a389f4ca47..0000000000
--- a/.changeset/hollow-view-overlay-hydration-pin-5773.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
----
-
-Tests only — this publishes nothing, declared explicitly with an empty frontmatter
-rather than left undeclared. No package `src/` is touched; the only file added is
-`packages/app-shell/src/views/InterfaceListPage.hollowOverlayHydration.test.tsx`.
-
-objectui#5773 — pins the intended post-objectui#5233 behaviour at the seam the card
-named: `InterfaceListPage`'s hollow-view hydration effect merging a personalization
-overlay row it fetched through `listViewOverrides`/`getView` (the same undocked-narrowing
-read path `narrowPersonalizationOverlay`'s docblock in `packages/data-objectstack/src/index.ts`
-describes).
-
-Reachability was measured, not reasoned about — constructed through the REAL
-`ObjectStackAdapter` write (`updateViewConfig`/`buildPersistedViewBody`, the same seam
-`ObjectView.overlayPatchOnly.test.ts` uses) and the REAL `InterfaceListPage` render, not a
-hand-written override fixture. Two cases:
-
-- A hollow ADR-0017 expansion item (system view, no `columns`) plus the CURRENT
-  (post-#5233) thin overlay row a toolbar toggle writes today: the page renders
-  `defaultColumnsFromObject`'s defaults — reachable, and the intended behaviour per the
-  card's disposition (an overlay was never a legitimate source of a view body).
-- The same hollow view with a PRE-#5233 fat overlay row (the shape an install that has
-  not touched this view since before the fix is still carrying, per
-  `ObjectView.overlayPatchOnly.test.ts`'s own "PRE-FIX" framing): the page renders the
-  frozen stale columns instead — a control proving the pin above discriminates a real
-  hydration-effect outcome rather than passing vacuously.
-
-Confirmed load-bearing by reverse verification: with the hydration effect's guard
-short-circuited (`if (true) return;`), the CONTROL case flips from the frozen `["status"]`
-to the un-hydrated defaults `["name","status"]` — the assertion depends on the fetch +
-merge actually running. No production code changed; `InterfaceListPage.tsx`'s hydration
-effect already behaves this way today, this was untested rather than unreachable.
diff --git a/.changeset/home-ai-studio-flag-5521.md b/.changeset/home-ai-studio-flag-5521.md
deleted file mode 100644
index 411aa0a99d..0000000000
--- a/.changeset/home-ai-studio-flag-5521.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-'@object-ui/app-shell': minor
----
-
-Console Home stops offering the metadata-authoring front door on a deployment
-whose own runtime config says authoring is not offered there (objectui#5521).
-
-The "Build an app" cover card is now withheld when
-`GET /api/v1/runtime/config` reports `features.aiStudio: false`. On the composed
-hosted-SaaS shape that card led a plain tenant into the full authoring flow
-behind a runtime whose `/api/v1/meta/*` answers `403` and whose ToolRegistry
-holds zero authoring handlers — the entry was offered and the refusal arrived at
-submit. The lockdown criterion for that shape is two-part, UI entry hidden AND
-API refused; only the backend half was green.
-
-- The card is **hidden, not dimmed**, because that is the flag's own declared
-  meaning on both sides of the wire: `RuntimeFeatures.aiStudio` documents "when
-  false, the SPA hides the AI authoring affordances", and the serving plugin
-  documents "set false to force-hide the authoring UI".
-- `features.marketplace` keeps the different presentation objectui#5504 gave it
-  — a dimmed card plus a visible localized reason. That flag means a route is
-  reachable; this one means force-hide. "Start with a template" is untouched:
-  installing a marketplace package is not AI metadata authoring and answers to
-  its own flags.
-- No reason line is rendered in its place. `home.build.noCapability` says the
-  *account* lacks "Manage Metadata"; on a runtime with no authoring at all the
-  surface is absent for everyone, and pointing a viewer at a permission that
-  would not help them is the misdirection objectui#5557 is about.
-- Unknown fails **OPEN** (`!== false`), the doctrine `isMarketplaceEnabled()`
-  already encodes: a runtime predating the flag, or one whose config fetch
-  failed, keeps the card exactly as visible as before.
-
-No new authorable config key, no new server surface, and no new copy — the flag
-was already being served and already reaches the browser.
diff --git a/.changeset/host-dispatch-action-keys-5611.md b/.changeset/host-dispatch-action-keys-5611.md
deleted file mode 100644
index 1f43f6e852..0000000000
--- a/.changeset/host-dispatch-action-keys-5611.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-'@object-ui/core': patch
----
-
-The dev-mode unknown-key warning stops flagging `overrideNotice`, the console's
-privileged-override safety copy (objectui#5611).
-
-`ActionRunner.execute` classifies the object it was HANDED, and a console host
-hands it a DISPATCH, not a stored metadata row. `DeclaredActionsBar` composes
-`overrideNotice` on that dispatch and two param-collection handlers read it —
-yet the key inventory only mirrored AUTHORED surfaces, so the runner reported a
-key two files read as one "no reader recognizes", and prescribed promoting it to
-an explicit field on `ActionDef`. That prescription is the one shape the
-2026-08-22 maintainer ruling forbids for this key, so acting on the diagnostic
-walked an author into a rejected design. A false warning on the product's own
-privileged path — the branch that finalises an approval over approvers who have
-not acted — is how a dev console gets muted.
-
-Adds an exported `HOST_DISPATCH_ACTION_KEYS` (sole member `overrideNotice`) to
-`actions/actionKeys.ts` and unions it into `KNOWN_ACTION_KEYS`, which is the
-fourth input to that set and the first one that is not an authored-surface
-mirror. Measured before and after on the exact dispatch the bar composes: the
-warning went from one call naming `overrideNotice` to none, `KNOWN_ACTION_KEYS`
-grew by exactly one member, and an action carrying a real typo alongside it
-still warns — naming `targt` only.
-
-The authored surface does not move. `overrideNotice` is still NOT declared on
-`ActionDef` and still NOT in `ACTION_DEF_KEYS`; writing it in an action literal
-remains a compile error, and the AST-derived pin over the interface is unchanged.
-Membership in `KNOWN_ACTION_KEYS` widens what the WARNING tolerates, never what
-an author may write — `actionKeys.pin.test.ts` now pins both halves, including
-the new list's exact contents so a second member cannot arrive quietly.
diff --git a/.changeset/host-only-viewtypes-tree-icon-5321.md b/.changeset/host-only-viewtypes-tree-icon-5321.md
deleted file mode 100644
index 1c922a8bed..0000000000
--- a/.changeset/host-only-viewtypes-tree-icon-5321.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-'@object-ui/plugin-view': patch
----
-
-A host-composed `tree` view is now labelled with the tree icon in `ObjectView`'s
-view switcher instead of the grid one, and the `tree` / `chart` view types are
-recorded as host-composition-only surfaces (objectui#5321).
-
-`viewSwitcherSchema`'s `iconMap` carried an entry for every view type except
-`tree`, so a tree view fell through to the `|| 'table'` fallback and was drawn
-with the grid glyph. objectui#2916 fixed exactly this once, for `chart`, by
-adding a single key — nothing recorded that the map had to be COMPLETE, so the
-next missing member went unnoticed. The map is now typed
-`Record<ViewType, string>`, which is how `ViewSwitcher`'s own
-`DEFAULT_VIEW_ICONS` (the consumer of these strings) has always been declared:
-a future `ViewType` member fails `type-check` rather than silently rendering as
-a grid. The `tree` value is `'list-tree'`, the same `ListTree` glyph
-`DEFAULT_VIEW_ICONS` already names for this view type, and the runtime fallback
-stays for host props that carry an unrecognised type. Reached in practice by
-the console, whose `CreateViewDialog` offers `tree` among the view types a user
-can create.
-
-No authoring surface changes. `generateViewSchema` renders eight view types
-while `ObjectViewSchema.defaultViewType` and `NamedListView.type` admit six of
-them, so `tree` and `chart` are selectable only through the component's `views`
-prop. The maintainer ruled on 2026-08-20 that both stay recorded as
-host-composition-only rather than being added to those unions, following the
-objectui#5097 precedent; the record now lives beside that one, with the branch
-set derived from a source fence, the authored unions pinned at the type level,
-and host reachability measured.
diff --git a/.changeset/humanize-label-single-home-5444.md b/.changeset/humanize-label-single-home-5444.md
deleted file mode 100644
index 1e4cfdd0ee..0000000000
--- a/.changeset/humanize-label-single-home-5444.md
+++ /dev/null
@@ -1,52 +0,0 @@
----
-'@object-ui/core': patch
-'@object-ui/fields': patch
-'@object-ui/plugin-charts': patch
----
-
-The value-fallback label prettifier `humanizeLabel` has one implementation instead of two byte-identical copies.
-
-`humanizeLabel` turns a stored value into a display string when nothing else
-resolves it — an option with no declared label, an object name, a chart axis
-member. It existed twice, byte for byte: once in `@object-ui/fields` (read by
-`plugin-grid`, `plugin-gantt`, `plugin-detail` and by that package's own
-renderers) and once as a deliberate local copy in `plugin-charts`'
-`ObjectChart.tsx`, whose comment said it was there "to avoid a dependency on
-`@object-ui/fields`".
-
-Two copies of one convention is a live hazard rather than tidiness: one
-dashboard can hold a chart and a grid over the same stored value, so a change
-landing on one copy alone would put that value on screen under two spellings at
-once. The single implementation now lives in `@object-ui/core` — the shared
-ancestor both packages already depend on, so the dependency the copy existed to
-avoid is still avoided and no new edge is created, and core takes no React
-(objectui#4389: core-canonical logic, plugins consume). Both former sites
-re-export it, so `import { humanizeLabel } from '@object-ui/fields'` keeps
-working unchanged.
-
-**Nothing rendered changes.** The surviving implementation is byte-identical to
-both deleted copies, and each former call site is pinned by identity against the
-core function — not by a copied output table that someone would have to remember
-to edit in two places.
-
-The core module also writes down, for the first time, why this convention stays
-distinct from `humanizeFieldKey` (the KEY fallback, in `@object-ui/plugin-dashboard`),
-which additionally splits camelCase:
-
-```
-input                humanizeFieldKey     humanizeLabel
-needs_analysis       Needs Analysis       Needs Analysis
-NeedsAnalysis        Needs Analysis       NeedsAnalysis        <- differ
-unitPrice            Unit Price           UnitPrice            <- differ
-BestCase             Best Case            BestCase             <- differ
-lost-to-competitor   Lost-To-Competitor   Lost To Competitor   <- differ
-```
-
-A field KEY is authored in the codebase and carries a machine spelling, so
-splitting camelCase recovers words its author meant. A stored VALUE is arbitrary
-tenant data, where a mid-token capital is not reliably a word boundary and
-splitting it rewrites what the tenant wrote (`McDonald` to `Mc Donald`). The two
-conventions also do not nest — on the last row each leaves alone the separator
-the other rewrites. Whether they should ever converge is a separate decision
-that would move rendered output in four packages at once; it is deliberately not
-made here.
diff --git a/.changeset/i18n-global-reset-4514.md b/.changeset/i18n-global-reset-4514.md
deleted file mode 100644
index 93f3476d18..0000000000
--- a/.changeset/i18n-global-reset-4514.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
----
-
-Test harness only, no published behaviour change (objectui#4514).
-
-Mounting an `I18nProvider` in a test file left react-i18next's global
-default-instance pointer on that provider's instance, so every later
-provider-less render in the same file resolved through it — a failure that
-surfaced hundreds of lines away, in a test nobody had touched, and passed when
-run alone. `vitest.setup.base.ts` now restores the pointer after every test.
-
-`I18nProvider` and `useObjectTranslation()` are unchanged: the global fallback
-that makes the hook provider-safe stays exactly as designed. The five source
-files in this change are all `*.test.*` plus their harness.
diff --git a/.changeset/i18n-guide-label-rule-5081.md b/.changeset/i18n-guide-label-rule-5081.md
deleted file mode 100644
index 16ec799ad5..0000000000
--- a/.changeset/i18n-guide-label-rule-5081.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
----
-
-Docs + gate ledger only — this publishes nothing, declared explicitly with an empty
-frontmatter rather than left undeclared.
-
-`skills/objectui/guides/i18n.md` attributed its label rule to `@objectstack/spec` v4 in two
-places (`:117`, `:162`) while every manifest here declares `^17.0.0` and `node_modules`
-carries `17.0.0` — thirteen majors, on the surface an AGENT reads before it writes a user's
-project. The version number was the reported defect; measurement against the installed
-package found the rule it was backing to be wrong as well, which is why neither arm of the
-original fork (renumber to v17, or drop the qualifier and keep the sentence) was writable:
-both would have laundered a v4-era false statement into a current one. Maintainer ruling
-2026-08-20, option A: restate the rule per the installed spec, with no version qualifier.
-
-Measured against `@objectstack/spec` 17.0.0's published dist, `I18nLabelSchema` is a union
-of a plain string and an inline locale map whose keys must match
-`/^(default|[A-Za-z]{2,3}(-[A-Za-z0-9]{2,8})*)$/` — a BCP-47 tag, or `default`. The guide now
-states both forms, shows an inline-map example on the two keys this repo was measured to
-resolve (`card.title` and `button.label`, both through `pickLocalized`), and keeps its
-"don't use `{key, defaultValue}`" advice with the real reason: that key-reference vocabulary
-was retired in objectstack#5055, the spec rejects the object with its own message, and if one
-reaches a renderer anyway `pickLocalized` falls through to the first string value and paints
-the raw translation key on screen.
-
-The `KNOWN_CLAIMS` entry that inventoried the fossil as `stale` is deleted in the same commit
-— the downward ratchet in `scripts/__tests__/doc-version-claims.test.ts` ("no entry may
-outlive the claim it excuses") turns red otherwise — and that file's header prose, which
-restated the now-falsified two-branch fork, is corrected to record what the fork actually
-turned out to be.
diff --git a/.changeset/i18nlabel-comment-4611.md b/.changeset/i18nlabel-comment-4611.md
deleted file mode 100644
index 3a243e944e..0000000000
--- a/.changeset/i18nlabel-comment-4611.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-'@object-ui/types': patch
----
-
-`ActionParam`'s doc block no longer claims that spec 17 narrowed `I18nLabel` to a
-plain string (objectui#4611).
-
-The paragraph explaining why `label` / `options[].label` are inherited rather than
-locally overridden justified itself with a claim about `@objectstack/spec` that was
-never true: "in spec 17 `I18nLabelSchema` is `z.ZodString` — inline per-locale objects
-were dropped in favour of translation files". Measured against the installed GA pin
-`@objectstack/spec@17.0.0` (`dist/ui/index.d.ts:614`), `I18nLabelSchema` is a union of
-a string and a string-to-string record, and the schema's own doc block states two
-authorized forms with "Both are real; neither is deprecated by this schema". Executed
-against `dist/ui/index.mjs`: plain string accepted, inline locale map accepted,
-`{ key, defaultValue }` rejected. A reader who believed the comment would have taken a
-widening to `string | I18nLabel` for a no-op — which is what the finding recorded, one
-seat having nearly done exactly that.
-
-The replacement describes what `I18nLabel` admits and cites the spec's own doc block
-rather than restating a zod expression; where today's spelling is named it is scoped as
-a measurement against 17.0.0 with its file and line, so it ages as a reading rather than
-as a standing fact. The decision itself is unchanged and never depended on the false
-premise — `label` flows in by reference through the spec's schema, and a local
-`string | I18nLabel` collapses to `I18nLabel` whichever forms the union holds.
-
-Documentation only, and the release-visible surface is the declaration file: measured
-with the package's real `tsc` build (`removeComments: false`, per `tsconfig.base.json`),
-108 emitted files on both sides, `dist/ui-action.d.ts` 29,176 → 31,026 bytes, and every
-other file byte-identical — including `dist/ui-action.js` (3,480 bytes, unchanged sha),
-because the comment documents an `interface`, which is erased at emit along with its
-leading comment. No behaviour changes; hover text and the shipped `.d.ts` do.
diff --git a/.changeset/i18nlabel-inverted-pin-5612.md b/.changeset/i18nlabel-inverted-pin-5612.md
deleted file mode 100644
index ffa052d0b1..0000000000
--- a/.changeset/i18nlabel-inverted-pin-5612.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-'@object-ui/types': patch
----
-
-The `I18nLabel` "inverted pin" now watches the premise it claims to watch, and
-`ui-action.ts` no longer imports a symbol it never uses (objectui#5612, objectui#5613).
-
-Both are residue of the same removed local `label` / `options[].label` override.
-
-The `it(...)` case in `packages/types/src/__tests__/page-nav-misc-spec-parity.test.ts`
-that called itself an inverted pin on the spec's `I18nLabel` rested on one assertion,
-`const label: SpecI18nLabel = 'Priority'`, under a comment claiming spec 17 had narrowed
-`I18nLabel` to a plain string and that a re-widening would stop it compiling. A plain
-string is assignable under the narrow shape *and* under the wide one, so that assignment
-could only ever fail if the plain-string form were removed — the opposite of the event it
-was written to catch. The widening had already landed: `@objectstack/spec@17.0.0`
-declares `I18nLabelSchema` as a union of a string and a string-to-string record
-(`dist/ui/index.d.ts:614`), and the pin stayed green through it. It reported protection
-it did not provide, and asserted a false premise in its own name.
-
-It is retargeted at what actually holds the decision up — not which single form the spec
-has, but that **both** authorized forms stay assignable, on the spec type and on the
-inherited `ActionParam['label']` and `options[].label`. It now fails when either form is
-withdrawn, and deliberately does not fail on a further widening, since inheriting by
-reference is exactly what stays correct as the authorized set moves. The comment is
-rewritten against the schema's own doc block (two authorized forms, "Both are real;
-neither is deprecated by this schema") instead of the false premise. Verified by
-construction: against a locally built narrow `type I18nLabel = string` the new assertions
-fail with `TS2344` and `TS2322`, where the old assignment compiles clean under both
-shapes.
-
-`ui-action.ts`'s `I18nLabel` type import is deleted — no type position had used it since
-the override was removed, and nothing re-exported it — and the doc paragraph that
-recorded the pin as `NOT guarded` is corrected, since the same change makes it a guard.
-
-No behaviour changes; the release-visible surface is the declaration file. Measured with
-the package's real `tsc` build, both legs building from a cleared `dist/` and cleared
-composite build info: 108 emitted files on both sides, exactly one differing —
-`dist/ui-action.d.ts`, 31,026 → 31,117 bytes, JSDoc prose only, no declaration changed.
-Every other file is byte-identical, including `dist/ui-action.js` (3,480 bytes, unchanged
-sha), because the comment documents an `interface`, which is erased at emit along with
-its leading comment. The deleted type import contributes no emitted delta at all, and the
-rewritten test file is not part of the build.
diff --git a/.changeset/inbox-actor-name-retired-5203.md b/.changeset/inbox-actor-name-retired-5203.md
deleted file mode 100644
index ebb7ec8a97..0000000000
--- a/.changeset/inbox-actor-name-retired-5203.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
----
-
-Internal only — this publishes nothing, declared explicitly with an empty frontmatter
-rather than left undeclared.
-
-Retires `InboxNotification.actor_name` (`packages/app-shell/src/layout/inboxGrouping.ts`),
-which was dead at both ends. `mergeInboxRows`
-(`packages/app-shell/src/hooks/sharedUserFeeds.ts`) is the single producer of every row
-the bell and Home's action centre render and never mapped it; neither consumer read it;
-and `sys_inbox_message` declares no actor column for it to have been mapped FROM. It was
-the last declared-but-unfilled member of that interface after objectui#5190 removed the
-sibling `source_object` / `source_id` pair.
-
-**No published type surface changes.** `InboxNotification` is not reachable from
-`@object-ui/app-shell`'s public entry: neither `src/index.ts` nor `src/layout/index.ts`
-re-exports it, the built `dist/index.d.ts` does not name it, and the package `exports`
-map offers only `.` and `./styles.css` — no deep subpath an external consumer could
-import it through. The type is internal to the package, so removing an optional member
-of it is not an externally observable narrowing and nothing user-visible ships. Runtime
-behaviour is unchanged in both directions: no code path produced the field and no code
-path read it.
-
-Two pins keep it retired, in opposite directions — a TYPE PIN in
-`layout/__tests__/inboxGrouping.test.ts` that fails if the field is re-declared, and a
-runtime key-set pin in `hooks/__tests__/sharedInboxFeed.rowShape.test.tsx` that fails if
-the producer is ever changed to spread raw `sys_inbox_message` columns through instead
-of mapping them field by field.
diff --git a/.changeset/inert-lifecycle-path-readout-5768.md b/.changeset/inert-lifecycle-path-readout-5768.md
deleted file mode 100644
index e95f072043..0000000000
--- a/.changeset/inert-lifecycle-path-readout-5768.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-'@object-ui/plugin-detail': minor
----
-
-`record:path` stops looking like a control it cannot be.
-
-The record page draws the object's lifecycle across the top from the
-`stageField` role, and it drew each stage as a filled, shadowed, equal-width
-pill — a segmented button group, sitting exactly where a CRM user reaches for
-the stage control. Nothing was behind it. Measured in a browser on a shipped
-build (HotCRM `crm_quote`, and this is generic record chrome, so every object
-that declares a `stageField` has it): the segments were `role="listitem"` with
-`cursor: auto` and `tabindex` null, no ancestor `button`/`tab`/`a`, and a full
-pointer sequence (pointerdown → mousedown → pointerup → mouseup → click) left
-the record's status untouched. Advancing a record needs the edit form or a bulk
-action. Users spent two or three clicks on the path before concluding it was
-decoration.
-
-There is no write path to connect it to, and this change does not open one:
-this renderer's only channel is `useRecordContext()`, whose value exposes
-`data` / `refresh` / `headerSystemActions` / `onToggleFavorite` and no
-record-field mutation. Editing runs through `record:details`'
-`<InlineEditProvider>` + `<InlineEditSaveBar>` (`dataSource.update(...,
-{ ifMatch })`) or an action via `useActionEngine`; neither reaches this
-component.
-
-So the promise is withdrawn rather than honoured. Each stage now renders as a
-thin decorative rail segment with its label as plain text beneath it — the
-vocabulary app-shell's approval step readout already uses. Gone: the per-stage
-filled pill, the shadow, the ring, the bordered chip, the equal-width tap
-target. Kept exactly as they were: which stage is current (`aria-current="step"`
-and type weight), the travelled/untravelled distinction, the check on completed
-stages, and the separated `lost`-terminal group. The accessible semantics did
-not move — `role="list"` / `role="listitem"` with no tab stop was already
-correct for a readout, and it stays that way.
-
-Three DOM attributes carry the state that colour used to be the only carrier
-of, so the classification is assertable without reading CSS:
-`data-stage-state` (`completed` | `current` | `upcoming`),
-`data-stage-terminal` (`won` | `lost`), and `data-stage-rail` on the decorative
-indicator.
-
-**Not in this change:** click-to-advance. A stage control that writes
-`stageField` through the same permission/validation envelope an edit takes is a
-separate feature with its own appetite, and folding it in here was explicitly
-ruled out.
diff --git a/.changeset/interfacelistpage-drop-derived-marker-title-6343.md b/.changeset/interfacelistpage-drop-derived-marker-title-6343.md
deleted file mode 100644
index 02a60cf22f..0000000000
--- a/.changeset/interfacelistpage-drop-derived-marker-title-6343.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-Interface-page maps: drop the derived marker-title binding, restoring the
-object's own declaration as the authority
-
-`defaultMapFromObject` bound a `titleField` alongside `locationField`, derived
-from the object's display field. That binding was added to route around a forge
-in `ObjectMap` — `getMapConfig` filled an absent `titleField` with the literal
-`'name'`, and the marker title was a plain `record[titleField]` read, so an
-object whose display field was not `name` titled every popup `undefined`. The
-forge is gone: `ObjectMap` now resolves marker titles through
-`@object-ui/core#getRecordDisplayName`, the same ADR-0079 resolver the kanban,
-calendar and gantt renderers already used — which is why none of them binds a
-derived title either.
-
-What the binding did once the forge was gone was invert precedence. It reaches
-the resolver as `options.titleField`, i.e. step 0 — ahead of `titleField` on the
-object, ahead of the declared `nameField` pointer, and ahead of the legacy
-`titleFormat` template. A field name derived by the page could therefore only
-ever change the answer by out-ranking something the object itself declared; in
-every other case it reproduced, at step 0, the string the resolver already
-computes further down its ladder. The deriver now binds `locationField` and
-nothing else, exactly like its kanban / calendar / gallery / gantt siblings.
-
-No authoring surface changes. An author's own `map.titleField` is untouched — it
-travels as the view-level `map` block, `ListView` merges it per key, and the
-resolver honours it at step 0 by design. Objects that declare nothing resolve to
-the same field as before, now via the resolver's own type-aware derivation
-rather than a binding forced ahead of it; objects that declare a `titleFormat`
-template (or a `titleField`) now have that declaration honoured on the map, as
-it already was on every other visualization.
diff --git a/.changeset/issue-5373-retire-crud-schema.md b/.changeset/issue-5373-retire-crud-schema.md
deleted file mode 100644
index 1643a2efca..0000000000
--- a/.changeset/issue-5373-retire-crud-schema.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-'@object-ui/types': minor
-'@object-ui/core': minor
----
-
-Retire `CRUDSchema` and the `type: 'crud'` node spelling (objectui#5373,
-maintainer ruling 2026-08-20, route 2) under ADR-0049 enforce-or-remove.
-
-`crud` had four declaration faces and no registered renderer, for the whole
-life of the key: the TS interface (`packages/types/src/crud.ts`), the zod
-mirror (`packages/types/src/zod/crud.zod.ts`), a dedicated branch in
-`validateSchema` that affirmatively PASSED it, and `CRUDBuilder` in
-`@object-ui/core`. A node spelling it painted the OBJUI-001 "Unknown component
-type" panel, and `content/docs/api/schema-reference.md` published it as
-reference material — so a reader (or an AI author) who copied the page got a
-red panel.
-
-Removed from `@object-ui/types`: the `CRUDSchema` interface and its zod
-mirror, the four shapes that existed only to type its keys — `CRUDOperation`,
-`CRUDFilter`, `CRUDToolbar`, `CRUDPagination` and their zod mirrors and
-`…SchemaType` aliases — and `CRUDSchema` as a member of `CRUDComponentSchema`,
-which is what took it off the node union `AnySchema`. `ActionSchema`,
-`DetailSchema` and `CRUDDialogSchema` are unchanged and remain the union's
-members.
-
-Removed from `@object-ui/core`: `CRUDBuilder` and the `crud()` factory.
-
-Authoring `crud` is now REFUSED BY NAME rather than passed or silently
-ignored. `validateSchema` returns an `error` with `code: 'RETIRED_TYPE'` on
-`schema.type` — at any depth, since it is what `validateChildren` recurses
-with — so `assertValidSchema` throws and `isValidSchema` answers `false`. The
-message names the migration: `object-grid` for the record table with its
-toolbar, filters, pagination and row/batch actions, `object-form` for the
-create/edit form, and `detail` for the record view. `api/schema-reference.md`
-is rewritten around those shapes.
-
-Note on blast radius: the repository itself contains zero authored `crud`
-nodes and zero registrations of the key (measured on the merge base against
-the doc gate's own 659-key registry derivation, which reads `register` and
-`registerLazy` alike). That is an IN-REPO zero, not an npm zero — a published
-consumer that imported the `CRUDSchema` type, called `crud()` / `CRUDBuilder`,
-or authored `type: 'crud'` will see a compile error or a validation error
-respectively. Both are the intended, loud replacement for a shape that has
-never rendered.
diff --git a/.changeset/issue-5389-workspace-admin-positions.md b/.changeset/issue-5389-workspace-admin-positions.md
deleted file mode 100644
index 2c12bc2f6d..0000000000
--- a/.changeset/issue-5389-workspace-admin-positions.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-'@object-ui/auth': patch
----
-
-Restore platform-admin detection for permission-set-derived administrators.
-
-`useIsWorkspaceAdmin` decides Setup app + Studio visibility, App Marketplace
-gating and the "Build an app" CTAs. Its third source read `user.roles`, a key
-the protocol-17 session face no longer emits (framework ADR-0090 D3 renamed it
-to `positions`). An administrator whose adminship comes from the
-`admin_full_access` permission set — the single-tenant deployment shape, where
-there is no organization member row and the server deliberately no longer
-overwrites `user.role` — matched none of the three sources and read as **not an
-administrator**: Setup and Studio simply disappeared for them.
-
-The hook now reads `user.positions[]`, the one spelling the session publishes.
-Detection is restored for that path and unchanged everywhere else: an active
-member row with an admin role, a stored `user.role` admin scalar, and
-preview/no-auth mode all behave exactly as before, and nobody who was not an
-administrator becomes one — pinned by four negative cases alongside the
-positive one.
-
-Also corrects the now-stale documentation that described the removed spelling:
-the hook's own docblock, the `roles?: string[]` declaration on the client
-`AuthUser` (kept for one remaining compile-time reader; see objectui#5424), and
-two comments in `@object-ui/app-shell`'s Home page. No behaviour change from the
-comment corrections.
diff --git a/.changeset/issue-5474-static-table-narrow-types.md b/.changeset/issue-5474-static-table-narrow-types.md
deleted file mode 100644
index 11b8b4627f..0000000000
--- a/.changeset/issue-5474-static-table-narrow-types.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-'@object-ui/types': minor
-'@object-ui/components': minor
----
-
-Split the static `table` column type off the rich shared `TableColumn`
-(objectui#5474, maintainer ruling 2026-08-22: Option C), so declared =
-enforced holds per renderer.
-
-`TableColumn` is unchanged and remains the rich shape `data-table`,
-`CRUDSchema` and detail-view relations honour. The static `table` renderer's
-`TableSchema.columns` now declares the new narrow `StaticTableColumn`
-(`header`, `accessorKey`, `className`, `cellClassName`, `width` — exactly the
-keys that renderer reads). The eleven keys the static renderer never read are
-retired from its surface as ADR-0049 tombstones: `hoverable` / `striped` on
-`TableSchema`, and `minWidth` / `align` / `fixed` / `type` / `sortable` /
-`filterable` / `resizable` / `editable` / `cell` on its columns.
-
-Breaking for authored metadata that wrote those keys on a `type: 'table'`
-node: they were silently inert before and are now refused loudly — a tsc
-error on the interface (`?: never`) and a parse rejection naming the key in
-`@object-ui/types/zod`. That loud refusal is the ruled outcome. Migration:
-nodes that wanted the interactive behaviour move to `type: 'data-table'`
-(whose columns keep the rich `TableColumn`); right-aligned columns on the
-static table use `cellClassName: 'text-right'`; alternate-row styling uses
-Tailwind on `className`.
diff --git a/.changeset/issue-5619-workspace-admin-unresolved.md b/.changeset/issue-5619-workspace-admin-unresolved.md
deleted file mode 100644
index a6dd79f81b..0000000000
--- a/.changeset/issue-5619-workspace-admin-unresolved.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-'@object-ui/auth': minor
-'@object-ui/app-shell': minor
-'@object-ui/console': minor
----
-
-Stop showing an access-denied screen to a real administrator while their
-adminship is still resolving.
-
-`useIsWorkspaceAdmin()` returned a bare `boolean`, so "the inputs have not
-arrived yet" and "resolved: not an admin" were the same answer. One of its three
-sources — the active organization member row — is fetched some round trips after
-the session (`listOrganizations` → `getActiveOrganization` → `getActiveMember`),
-so an administrator whose adminship lives only in that row rendered at least
-once as a non-admin, and every gate downstream acted on it: the two marketplace
-surfaces painted `MarketplaceAccessDenied`, the console chrome dropped and
-re-added its admin nav entry, and `AppContent` fired a `<Navigate to="/home"
-replace>` that the later flip could not undo.
-
-**Breaking (published API, hence `minor` per this repo's version policy):**
-`useIsWorkspaceAdmin(): boolean` is replaced by
-`useWorkspaceAdminStatus(): { isAdmin: boolean; isResolved: boolean }`. The old
-name is removed rather than kept alongside, so a call site that ignores the
-third state fails to compile instead of silently refusing an administrator.
-
-    -const isAdmin = useIsWorkspaceAdmin();
-    +const { isAdmin, isResolved } = useWorkspaceAdminStatus();
-
-`AuthProvider` gains `isMembershipResolved` on its context — the organization /
-member pipeline has reached a terminal state — because `organizations`,
-`activeOrganization` and `activeMember` read `[]` / `null` / `null` both before
-the pipeline starts and after it finds nothing.
-
-No extra wait for administrators: `isResolved` is true the instant `isAdmin` is,
-so an admin the session already identifies through `positions[]` never waits on
-the member row.
diff --git a/.changeset/issue-5709-unconsumed-widget-option-warning.md b/.changeset/issue-5709-unconsumed-widget-option-warning.md
deleted file mode 100644
index c4a5485748..0000000000
--- a/.changeset/issue-5709-unconsumed-widget-option-warning.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-'@object-ui/sdui-parser': minor
----
-
-`validateTree` now reports a dashboard widget `options` key that no renderer
-consumes as a `unconsumed-widget-option` **warning** naming the consumed set
-(objectui#5709 ruling). The census behind the accepted set — the spec's five
-declared query keys (`dateGranularity`, `sortBy`, `sortOrder`, `limit`,
-`stageOrder`) plus the `description` sub-caption convention key — is
-re-measured on every test run against `@objectstack/spec` and the
-`plugin-dashboard` renderer sources. The check fires only on dataset-bound
-shorthand widgets (the spec-legal form) hosted by `dashboard` /
-`dashboard-grid` nodes, and honours the spec's per-widget
-`suppressWarnings: ['unconsumed-widget-option']` escape hatch. Warning
-severity only: documents keep parsing, saving and rendering. Exported for
-other surfaces: `checkDashboardWidgetOptions`, `CONSUMED_WIDGET_OPTION_KEYS`,
-`DASHBOARD_WIDGET_HOST_TYPES`, `UNCONSUMED_WIDGET_OPTION`.
diff --git a/.changeset/issue-5821-table-column-editable-mirror.md b/.changeset/issue-5821-table-column-editable-mirror.md
deleted file mode 100644
index 7f9b967e00..0000000000
--- a/.changeset/issue-5821-table-column-editable-mirror.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-'@object-ui/types': patch
----
-
-Add `editable` to the rich `TableColumnSchema` zod mirror. The `TableColumn` interface declares `editable?: boolean` and `data-table` honours it, but the mirror omitted the key, so a non-strict parse silently stripped it — and since the renderer treats absence as `true`, a column an author locked with `editable: false` came out of validation editable again. Columns locked with `editable: false` now stay locked through any pipeline that parses metadata via `@object-ui/types/zod` (including the CLI `validate` route).
diff --git a/.changeset/issue-6275-validation-engine-dangling-see.md b/.changeset/issue-6275-validation-engine-dangling-see.md
deleted file mode 100644
index 47ffe32e45..0000000000
--- a/.changeset/issue-6275-validation-engine-dangling-see.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
----
-
-Comment-only change in `@object-ui/core`: the `SimpleExpressionEvaluator` doc block
-no longer points at the deleted `SECURITY_FIX_SUMMARY.md`, and states the security
-rationale inline instead. Releases nothing — the class is not exported, so the doc
-block reaches no `.d.ts`, and no behaviour, type or API surface changes.
diff --git a/.changeset/issue-6567-hoist-internalformroute-import.md b/.changeset/issue-6567-hoist-internalformroute-import.md
deleted file mode 100644
index e8d1e73a62..0000000000
--- a/.changeset/issue-6567-hoist-internalformroute-import.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
----
-
-Test-only: in `apps/console/src/components/FormPage.predicateScope.test.tsx`, hoist
-`InternalFormRoute`'s import from a dynamic `await import()` inside the
-`hop1SessionPrincipal` case to module scope. That load was costing 10204ms of the
-case's 15000ms budget — it is the file's first value request for
-`@object-ui/app-shell`, aliased to source — which made the file's one anti-inert
-case fail under full-project parallel load. Same module, same binding, loaded
-before the timed window instead of inside it. No published behaviour changes.
diff --git a/.changeset/kanban-calendar-nav-width-converge.md b/.changeset/kanban-calendar-nav-width-converge.md
deleted file mode 100644
index 7f827c27d4..0000000000
--- a/.changeset/kanban-calendar-nav-width-converge.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
----
-
-`ObjectKanban` and `ObjectCalendar` internal cleanup, measured as a zero-pixel
-change — the convergence of the two renderers #6305 left behind.
-
-Each carried the house default `min(960px, 60vw)` at **two** sites: the
-`navConfig` default (`{ mode: 'drawer', width: 'min(960px, 60vw)' }`) and a
-render-site `width={(navigation.width as any) ?? 'min(960px, 60vw)'}`. Both are
-gone. `width` is spec-deprecated (`@deprecated [#2578 -> size]`) and
-`resolveOverlayWidth` gives an explicit `width` priority OVER `size`, so
-spelling it kept the deprecated branch load-bearing on the path most boards and
-calendars take. With both omitted, `resolveOverlayWidth` returns `undefined` and
-`RecordDetailDrawer`'s own `width` default supplies the identical
-`min(960px, 60vw)`.
-
-The resolved overlay width is therefore unchanged on every viewport, for both a
-board/calendar that declares no `navigation` and one that authors
-`navigation.width` — each is now pinned by a test. The three renderers agree
-again.
-
-No published behaviour changes.
diff --git a/.changeset/layout-renderers-dom-props-5574.md b/.changeset/layout-renderers-dom-props-5574.md
deleted file mode 100644
index b018f67b4b..0000000000
--- a/.changeset/layout-renderers-dom-props-5574.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-'@object-ui/components': patch
----
-
-**Behaviour change:** the `flex`, `stack`, `container` and `text` renderers no
-longer forward their whole prop bag to the host element. They route it through
-`toDomProps` — the same whitelist `grid` was converged on — so an authored
-schema key becomes an HTML attribute only if the SDUI DOM contract declares it
-one (objectui#5574).
-
-What this stops reaching the DOM: the renderer's own declared props, which were
-consumed off `schema` to build the class list AND spread onto the element a
-second time as attributes HTML does not define. Measured across
-`examples/schema-catalog`, rendered through the real `SchemaRenderer`: 1194
-illegitimate attributes over 1141 nodes — `text[content]` 522, `flex[align]`
-198, `flex[gap]` 193, `stack[gap]` 153, `flex[justify]` 98, `container[padding]`
-14, `container[maxwidth]` 6, `flex[direction]` 5, `stack[align]` 4,
-`text[value]` 1. The same probe reads 0 after, with `grid`'s 26 nodes at 0 both
-times as the control.
-
-Nothing an author writes renders differently: every leaked key was already being
-read off `schema` and applied as a class, so the markup loses attributes that
-never had meaning and keeps the styling that did. `id`, `role`, `tabIndex`,
-`className`, `style`, event handlers and the open `data-*` / `aria-*` families
-are unchanged — including `data-obj-id` / `data-obj-type`, which now arrive
-through the `data-*` family rather than by hand.
-
-Anything that read one of the leaked attributes off the DOM — a CSS attribute
-selector such as `[gap="4"]`, or a test asserting `align` on a rendered `flex` —
-must read the schema or the class instead. No `@object-ui` code did; this is
-called out because the attributes were externally visible while they lasted.
diff --git a/.changeset/lazy-plugin-jsdoc-compiles.md b/.changeset/lazy-plugin-jsdoc-compiles.md
deleted file mode 100644
index e2dd0c0aa0..0000000000
--- a/.changeset/lazy-plugin-jsdoc-compiles.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-"@object-ui/react": patch
----
-
-Fix `createLazyPlugin`'s JSDoc example, which taught a call that does not compile.
-
-The `@example` block passed `() => import('@object-ui/plugin-grid')` as the
-`importFn`. ObjectUI plugin packages export their components by name and have no
-`default`, so that call supplies the module namespace object — rejected by the
-compiler (`Property 'default' is missing`) and, at runtime, handed to
-`React.lazy` as the component. The examples now unwrap the named export via the
-`async` spelling, which is the form that actually type-checks. This ships in the
-published `.d.ts`, so it is what editors show on hover.
diff --git a/.changeset/list-user-actions-collision-5398.md b/.changeset/list-user-actions-collision-5398.md
deleted file mode 100644
index 62a0d3c775..0000000000
--- a/.changeset/list-user-actions-collision-5398.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-'@object-ui/plugin-list': patch
----
-
-`list-view` harvests row-action predicate fields from the OBJECT's `userActions` block only — a view's toolbar policy can no longer shadow it.
-
-`userActions` names two different blocks. On a **view** it is toolbar policy —
-the spec's `UserActionsConfigSchema` (`sort`, `search`, `filter`, `refresh`,
-`rowHeight`, `addRecordForm`, `editInline`, `buttons`), which rejects `edit` by
-name. On an **object** it is the CRUD-predicate block (`edit` / `delete` /
-`create` carrying `visibleWhen` / `disabledWhen`, objectui#2614) — and that is
-the only shape `listViewPredicates` can read, since its loop skips every
-non-object value.
-
-`ListView` read the key view-first when building the `$select` projection
-(`(schema as any).userActions ?? (objectDef as any)?.userActions`). A view
-carrying a perfectly legal toolbar block therefore shadowed the object's CRUD
-predicates, the harvest found none, and the predicate's operand left the
-projection. CEL then faults on the absent key, fails closed, and the row
-Edit/Delete button disappears for everyone with nothing pointing at the
-projection — objectui#3501's failure, reached with a success receipt at every
-step.
-
-This is the sibling of the `plugin-grid` read site fixed in objectui#5426, and
-it was the worse of the two: `app-shell`'s `ObjectView` builds the view-level
-`userActions` it hands down as an object literal of two spreads, so the left
-operand was `{}` at worst — never nullish. The `??` never fell through, and the
-object's CRUD predicates were never consumed at all on that path, whether or
-not an author wrote any toolbar policy.
-
-The harvest now reads the object block only. Both `userActions` read sites in
-`ListView.tsx` carry a comment naming the collision, and
-`__tests__/ListView.userActionsCollision.test.tsx` pins each clause of it: the
-two shapes, a producer that manufactures the view one, the harvest's blindness
-to it, and the projection that must keep the object's operand with a toolbar
-block — or an empty block — present on the view.
-
-Toolbar policy itself is untouched — it was never read through this path.
diff --git a/.changeset/list-view-nested-aria-label-i18n-5134.md b/.changeset/list-view-nested-aria-label-i18n-5134.md
deleted file mode 100644
index f330b77a6a..0000000000
--- a/.changeset/list-view-nested-aria-label-i18n-5134.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-'@object-ui/plugin-list': patch
----
-
-`ListView` now resolves the nested `aria.ariaLabel` against the audience's locale
-instead of casting it to a string (objectui#5134).
-
-`@objectstack/spec`'s `AriaPropsSchema` types `ariaLabel` as `I18nLabel` — a plain
-string **or** an inline locale map (`{ en: 'Accounts', 'zh-CN': '客户' }`). The only
-read site in this repo spread it into the DOM as
-`{ 'aria-label': schema.aria.ariaLabel as string }`, and `as string` is a cast, not a
-conversion: a map-valued label reached the DOM as `aria-label="[object Object]"`, which
-a screen reader announces as the list view's accessible name — in every locale. The
-read now goes through the spec's own `resolveI18nLabel` (the resolver four other
-in-repo read sites already use) against `useDisplayLocale()`.
-
-Reachability, stated plainly: the path is **live but unexercised**. `I18nLabel` was a
-plain `string` through `@objectstack/spec` 17.0.0-rc.5, so no stored map-valued label
-predates rc.6, and no measured author writes one today — but map values are legitimate
-and arrive via API/import, so an imported list view carrying
-`aria: { ariaLabel: { en: …, 'zh-CN': … } }` is spec-valid metadata that renders a wrong
-accessible name. This is the map form working as declared, not a defect users are
-currently hitting.
-
-Behaviour on the string arm is byte-identical, including `''` (falsy before and after,
-so no attribute). One edge changes for the better: a map that matches no locale used to
-render `aria-label="[object Object]"` (`{}` is truthy) and now omits the attribute — an
-unnamed region beats a garbage-named one.
-
-The **flat** `schema.ariaLabel` is deliberately untouched: it carries a different
-vocabulary (objectui's keyed `{ key, defaultValue?, params? }` ref, resolved by
-`SchemaRenderer`'s `resolveKeyedI18nLabel`), and neither resolver accepts the other's
-shape.
diff --git a/.changeset/listview-comment-pair-4559.md b/.changeset/listview-comment-pair-4559.md
deleted file mode 100644
index 2f012823cd..0000000000
--- a/.changeset/listview-comment-pair-4559.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-'@object-ui/plugin-list': patch
----
-
-Two comment corrections in `ListView.tsx` (objectui#4559, objectui#4966). No runtime
-behaviour changes and the emitted bundle is byte-identical; the published `.d.ts` does
-change, which is why this is a `patch` rather than an empty frontmatter.
-
-**objectui#4559 — the sort rationale stopped prescribing a formula field.** The comment
-block above the `sortFields` memo still called a formula field "the supported
-alternative (… which sorts like any text column)". Since objectui#4294 the
-`list.sortRelationalHint` string in this same file says the opposite ("Not a formula
-field: it is virtual, so no column is stored for it and the server refuses to sort by
-one"), the memo underneath filters formula out via `UNMATERIALIZED_FIELD_TYPES`, and the
-server answers such a sort with `400 INVALID_SORT` (objectstack#6994). The parenthetical
-now names the remedy the hint, the server's refusal and the README already share — a
-stored field that denormalizes the name onto this object, written when the source
-changes. This was the last copy of the retired advice in the repo.
-
-**objectui#4966 — `formatActionLabel`'s docblock now sits above `formatActionLabel`.**
-It had drifted two declarations up, so the exported `parseSortConfig` carried two
-stacked leading comments and the helper carried none. This one was not cosmetic: because
-`parseSortConfig` is exported, `vite-plugin-dts` copied the misattributed block into
-`dist/ListView.d.ts`, so every consumer's editor hover and TypeDoc introduced the sort
-parser with a sentence about action labels. Moving the block removes it from the `.d.ts`;
-`formatActionLabel` is module-private, so its now-correct docblock does not appear there.
-It also matters to `scripts/check-spec-symbol-derivation.mjs`, whose rule 2 reads the
-comment block *attached* to a declaration — a misattributed docblock is the mechanism by
-which a claim gets scored against the wrong symbol. This block carries no spec-alignment
-phrase, so nothing fired today.
-
-No tests accompany this change and none could: both edits are comment-only, and there is
-no runtime behaviour to pin. The `.d.ts` delta was measured with the package's real
-`vite build` before and after, not asserted.
diff --git a/.changeset/listview-map-view-level-config-5042.md b/.changeset/listview-map-view-level-config-5042.md
deleted file mode 100644
index 44ca3ccd04..0000000000
--- a/.changeset/listview-map-view-level-config-5042.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-'@object-ui/plugin-list': minor
-'@object-ui/app-shell': minor
----
-
-**Behaviour change:** the spec's view-level `map` block on a list view is now read at
-runtime. `ListMapConfigSchema` (objectstack#9340) has been authorable and validated since
-the `@objectstack/spec` 17.1.0 pin — it flows into this repo's own `ListViewSchema` by
-reference — but nothing consumed it: `ListView`'s `case 'map'` forwarded only the legacy
-`schema.options.map` bag, so declaring `map: { titleField: 'title', locationField:
-'location' }` on a view changed nothing and marker titles fell back to the renderer's
-placeholder.
-
-The block now reaches `plugin-map` and drives every one of its seven reads — coordinate
-extraction, marker title and description, and the initial camera. Precedence follows the
-convention the sibling visualization blocks in the same file already set: the view-level
-block wins over `options.map`, per key, exactly as `kanban` / `calendar` / `gallery` /
-`timeline` / `gantt` each merge their spec config over the legacy bag. Both sources go
-through the existing objectui#5177 key whitelist, and the branch still emits the flat
-form, so `getMapConfig`'s objectui#5018 precedence rule ("neither flattener emits a `map`
-key at all") stays true.
-
-The visualization switcher had the same gap with a sharper consequence: the capability
-gate that decides which visualizations are offered also read `options.map` alone, so a
-view binding its coordinates in the spec block was filtered out of its own
-`appearance.allowedVisualizations` and fell back to `['grid']`. The gate now asks the same
-merged config the render seam forwards, so the two cannot disagree — including for a
-binding split across the two sources.
-
-`InterfaceListPage` (ADR-0047 interface pages) forwards the referenced view's `map` block
-for the same reason. It is passed alongside the auto-derived `options.map` rather than
-replacing it, so a partial authored block — `map: { titleField: 'title' }` — keeps the
-derived coordinate binding instead of dropping it.
-
-No defaults are introduced for `zoom` / `center`: an undeclared camera stays undeclared,
-so the fit-to-queried-records behaviour ruled in objectui#5000 is unchanged.
diff --git a/.changeset/lookup-cell-chip-cap.md b/.changeset/lookup-cell-chip-cap.md
deleted file mode 100644
index 4f1c77677a..0000000000
--- a/.changeset/lookup-cell-chip-cap.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-'@object-ui/fields': patch
----
-
-A multi-value lookup cell no longer grows its row without bound: `LookupCellRenderer`
-now shows at most 3 chips and collapses the rest into one muted `+N` chip, the same
-cap `UserCellRenderer` has always applied to its avatar stack in the very same file.
-
-Previously the array branch rendered EVERY referenced record as its own chip inside a
-`flex-wrap` container. In a grid column that wraps to one chip per line, so a cell
-referencing a large set — a production 排班计划 row referencing 60+ work objects — grew
-a single row to several screens of height and blew the page layout apart. The same
-uncapped rendering reached every surface that resolves through `getCellRenderer('lookup')`:
-grid, related lists, gallery, kanban, report and dashboard tables, and the record detail
-sections.
-
-The collapsed names stay reachable: the `+N` chip's `title` lists the display names of
-the hidden references (resolved through the same option/label/record-name path as the
-visible chips), and the record's own detail view remains the place to see the full set.
-The first 3 chips keep their per-record links (#4336) and their resolution order —
-nothing changes for cells with 3 or fewer references.
diff --git a/.changeset/lookup-dropdown-cell-renderer-5492.md b/.changeset/lookup-dropdown-cell-renderer-5492.md
deleted file mode 100644
index d43f0e19a2..0000000000
--- a/.changeset/lookup-dropdown-cell-renderer-5492.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-'@object-ui/fields': patch
----
-
-A lookup's inline dropdown renders its columns through the same cell renderer the browse-all picker uses, so one `lookup_columns` declaration cannot produce two answers.
-
-A form's lookup field offers two ways to pick a related record, and both read
-the same declaration: the inline dropdown under the field, and the
-"browse all records" picker behind it. The picker resolved every cell through
-the type-aware cell renderer. The dropdown did not — it printed
-`record[descriptionField]` verbatim into the option subtitle and concatenated
-`label: String(rawValue)` into the row's `title` attribute. Measured on the
-same declaration, on a real 17.1.0 deployment:
-
-```
-column          inline dropdown (before)          browse-all picker
-lookup          T5MsMCuwP4t_yUHq (bare FK id)     the related record's name
-date            2026-08-20T00:00:00.000Z (ISO)    a formatted date
-select          pending (enum code)               the authored option label
-```
-
-Both surfaces now call one shared module — `widgets/lookupColumnDisplay.tsx`,
-which owns column normalisation, the field-descriptor enrichment from the
-referenced object's schema, and the render itself. The picker's own
-`renderCellContent` and `columnFieldDescriptors` are now thin calls into it, so
-there is a single renderer left to drift from. The dropdown's extra columns are
-rendered into the option row itself; the row's `title` keeps the full option
-label, which is what a truncated label needs, instead of a raw-value dump.
-
-No query changed and no contract widened. `lookupColumns` entries stay bare
-field names — no dot paths, no populate/expand semantics — because neither
-surface's request carries populate to begin with: the picker resolves a
-foreign-key id to a name client-side, in the lookup cell renderer, and the
-dropdown now inherits exactly that. An unresolved reference therefore renders
-what the picker renders for it, and keeps its column: a slot is dropped only
-when the record holds no value for the field, decided on the raw value and
-never on what the renderer makes of it, so an unresolved id can never degrade
-into a silently empty column.
diff --git a/.changeset/loud-lamps-shake.md b/.changeset/loud-lamps-shake.md
deleted file mode 100644
index eae0d16227..0000000000
--- a/.changeset/loud-lamps-shake.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-"@object-ui/react": minor
-"@object-ui/plugin-detail": minor
-"@object-ui/plugin-grid": minor
-"@object-ui/plugin-form": minor
----
-
-`object-grid` / `object-form` / `detail-view` resolve their data source the same way, and a block that resolves none says so
-
-The three object-bound blocks disagreed about how the data-source adapter reached
-them. `object-grid` and `object-form` were registered through wrappers that read
-it from `SchemaRendererProvider` context; `detail-view` was registered as the raw
-component, which reads a React `dataSource` prop. `SchemaRenderer` itself reads
-only context, so the two wirings were mutually exclusive: measured with correct
-keys in every cell, provider wiring gave the grid `find` 1 and the detail view
-`findOne` 0, and prop wiring gave exactly the reverse. Neither reported anything.
-
-All three now resolve the adapter through one rule — an explicit `dataSource`
-prop first, the provider context second. This is additive: `detail-view` keeps
-its prop form (and direct `<DetailView dataSource={…} />` callers are untouched),
-`object-form` gains a prop form it did not have, and `object-grid` no longer
-throws `useSchemaContext must be used within a SchemaRendererProvider` when a
-page has no provider.
-
-And the silence is over. A block in this family that resolves no adapter renders
-a **No data source resolved** panel naming the block, the object it was about to
-read, and the ancestor that injects the adapter — instead of a header-only grid,
-a field-less form card, or nothing at all. The check is opt-in per block, so a
-placement with inline rows, inline `customFields`, an inline record or an `api`
-endpoint is untouched.
-
-New from `@object-ui/react`: `useResolvedDataSource`, `NoDataSourcePanel`,
-`noDataSourceMessage`, and a `requiresDataSource` prop on `ElementDataSourceGate`.
diff --git a/.changeset/lucide-icon-record-name-gate.md b/.changeset/lucide-icon-record-name-gate.md
deleted file mode 100644
index 2a2f9ca90f..0000000000
--- a/.changeset/lucide-icon-record-name-gate.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
----
-
-Adds `check:icon-record-names`, a repo-level gate asserting that every authored icon
-name reaching a resolver that reads lucide's runtime `icons` record is a live key of
-that record. lucide retires a spelling by dropping it from that record while keeping
-it as a deprecated named export, so a retired name still imports, still type-checks
-and still renders as a component while resolving to nothing as a string — the class
-behind objectui#5586 and objectui#5622, each of which left a local pin behind. The
-gate judges against the record itself rather than any list of retired spellings, and
-re-discovers the resolver population on every run.
-
-No published behaviour changes: the touched `src/` files carry comment updates only,
-and the three repaired spellings are in example schemas and the docs playground.
diff --git a/.changeset/lucky-buttons-warn.md b/.changeset/lucky-buttons-warn.md
deleted file mode 100644
index 739ac7445c..0000000000
--- a/.changeset/lucky-buttons-warn.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-'@object-ui/plugin-detail': patch
----
-
-`record:activity` now says out loud when an unrecognised `filterMode` is folded onto `all`.
-
-`normalizeFilterMode` folds every value it does not recognise onto `'all'` — the widest of the four declared modes — so a near-miss like `comments-only` opened the panel on the unfiltered stream instead of the slice the author asked for, and said nothing. The fallback is kept (a dropdown handed a value with no matching item renders blank), but the fold now emits one deduped diagnostic naming the offending value and the declared modes. Nothing that renders changes.
diff --git a/.changeset/lucky-forms-omit-server-defaults.md b/.changeset/lucky-forms-omit-server-defaults.md
deleted file mode 100644
index 2df9bd659d..0000000000
--- a/.changeset/lucky-forms-omit-server-defaults.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-'@object-ui/console': patch
----
-
-Console form pages no longer submit a cleared server-owned field as a blank.
-
-A field whose declared `defaultValue` is an instruction the server resolves per
-insert (a `NOW()` / `current_user` token, or a CEL expression envelope) opens
-with an empty control on a create form, and its key stays out of the payload
-while nothing touches it. But a submitter who typed into that control and then
-cleared it put the key back holding `''` — and `ObjectQL.applyFieldDefaults`
-resolves a declared default only for a field arriving absent or null, so the
-blank was stored and the declaration silently defeated.
-
-Such a key is now dropped from a CREATE submit on both the internal
-`/forms/:name` and the anonymous `/f/:slug` route. A blank cleared from a field
-with no runtime default — or with a static one — is still submitted, because
-that is the user removing a value; and an edit submit is untouched, where a
-cleared column is a deliberate removal.
diff --git a/.changeset/lucky-pugs-shake.md b/.changeset/lucky-pugs-shake.md
deleted file mode 100644
index 71af6fb8c7..0000000000
--- a/.changeset/lucky-pugs-shake.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-"@object-ui/components": patch
----
-
-`ui:dropdown-menu` now resolves a menu item's authored `icon` to a glyph instead of drawing the name as raw text.
-
-Both arms of the item renderer — `DropdownMenuItem` and `DropdownMenuSubTrigger` — rendered `icon` straight into a text node, so an item authored as `{ "label": "Copy", "icon": "copy" }` drew the literal word `copy` beside its label. The name is now resolved through `resolveIcon`, the same lucide **record** surface `ui:button` and the `action:*` family already resolve against: a live name draws its glyph, and an unknown or retired spelling draws nothing rather than degrading to a wrong glyph.
-
-The `components-overlay-dropdown-menu/with-icons` catalog fixture declared the retired lucide spelling `edit`, which is absent from lucide's runtime `icons` record and would therefore have drawn no glyph; it now declares `square-pen`, the live key the retired export resolves to by identity.
diff --git a/.changeset/map-marker-title-binding.md b/.changeset/map-marker-title-binding.md
deleted file mode 100644
index aa8627f38f..0000000000
--- a/.changeset/map-marker-title-binding.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-Interface-page maps: derive a marker-title binding from the object's display field
-
-An ADR-0047 interface page that whitelists `map` derives its map binding with
-`defaultMapFromObject`, which bound only `locationField`. With no `titleField`
-reaching `ObjectMap`, `getMapConfig` filled the gap with the literal `'name'`
-and the marker title is a plain `record[titleField]` read — so on any object
-whose display field is not `name` (for example one keyed by `title`), every
-marker popup titled itself `undefined`.
-
-The derivation now also binds the object's display field, resolved with the
-field-name half of ADR-0079's precedence: the declared `nameField` (and its
-`displayNameField` / `NAME_FIELD_KEY` aliases), otherwise the shared
-`deriveTitleField` scan from `@object-ui/core` — the same ranking the kanban,
-calendar and gantt renderers resolve titles through, so a map and a board over
-one object agree on what a record is called. When nothing resolves the key is
-omitted rather than defaulted. A hand-declared `map` block still wins per key.
diff --git a/.changeset/marketplace-catalog-runtime-before-admin-5557.md b/.changeset/marketplace-catalog-runtime-before-admin-5557.md
deleted file mode 100644
index 69a66da580..0000000000
--- a/.changeset/marketplace-catalog-runtime-before-admin-5557.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-The marketplace **catalog** page now tells a non-admin that the runtime has no
-marketplace, instead of telling them they lack permission (objectui#5557).
-
-`MarketplacePage` ordered its two early returns admin-first, so on a runtime that
-mounts no marketplace at all (`features.marketplace: false` — an `OS_CLOUD_URL=off`
-deployment, the EE deploy template's factory default) an unprivileged member got
-"access denied" for a surface that exists for nobody. That answer sends them to
-ask an administrator for a grant that would not help them, and it left the
-informational disabled state built in objectui#5504 unreachable for every
-non-admin. The runtime check now answers first, because "this deployment has no
-marketplace" is true regardless of who is asking.
-
-This restores the sibling-page invariant for the one class of viewer it still
-failed for: `MarketplacePackagePage` was reordered the same way in objectui#5533,
-so on a marketplace-off runtime the catalog page and the package detail page now
-give a non-admin the same kind of answer.
-
-Scope, deliberately narrow:
-
-- **Admin-first ordering stays correct where a marketplace exists.** On a runtime
-  with `features.marketplace: true`, a non-admin still gets `MarketplaceAccessDenied`
-  — the catalog is an install surface, and a member who cannot install has nothing
-  to do with it. That boundary is pinned by an explicit test, not left to prose:
-  without it, a change that simply dropped the admin check would look correct.
-- Nothing an admin sees changes, on either kind of runtime.
-- No new i18n keys, and no change to `MarketplaceAccessDenied` or
-  `MarketplaceDisabled` themselves — only which of the two the page reaches for,
-  and in which order it decides.
-- The disabled state is still the server's own answer (`features.marketplace`),
-  never inferred from a failed request, and it still fails open.
diff --git a/.changeset/marketplace-detail-admin-guard-order-5583.md b/.changeset/marketplace-detail-admin-guard-order-5583.md
deleted file mode 100644
index b50d522485..0000000000
--- a/.changeset/marketplace-detail-admin-guard-order-5583.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-The marketplace package detail page decides "you are not an admin" before it fetches,
-instead of after the load has already failed.
-
-`MarketplacePackagePage` ordered its early returns with the `!isAdmin` guard *after*
-both the loading branch and the `error || !data` branch, and gated its two fetch
-effects on `features.marketplace` alone. On a runtime that mounts a marketplace, a
-non-admin who opened a package URL was therefore walked through the fetch and the
-skeleton, and — when the load failed — was handed the destructive "Failed to load
-package" card carrying the server's own error message. Whether that viewer was
-refused or handed a diagnosis about a surface they are not allowed to use came down
-to whether an unrelated request happened to succeed.
-
-The guard now sits ahead of both branches, and `getMarketplacePackage` and
-`getCloudInstallationInfo` are gated on `isAdmin` as well, so the page stops issuing
-requests on behalf of a viewer it has already decided to turn away. That is the
-discipline objectui#5533 established on this same page for `features.marketplace`,
-applied to the other predicate that decides the same thing. It is also the ordering
-`MarketplacePage` carries after objectui#5557, so the two sibling pages now answer one
-runtime the same way for every viewer. The server remains the authority on what a
-non-admin may fetch; this only stops the client doing work it would discard.
-
-Unchanged for an admin, deliberately and under test: a failing load still produces the
-destructive card with the server's message intact, and a successful one still renders
-the package. A "fix" that hoisted the refusal unconditionally, or that deleted the
-failure branch, would satisfy every non-admin assertion and fail those two.
-
-`loading` stays seeded from `marketplaceEnabled` alone rather than from
-`marketplaceEnabled && isAdmin`. `isAdmin` reads `activeMember`, which `AuthProvider`
-resolves asynchronously *after* the session settles, so an admin whose role comes from
-the org member row renders once as a non-admin before the flag flips. Seeding `false`
-there would leave that first admin render with `loading: false` and no data — the
-destructive card, painted for a frame before the effect could raise the flag again.
-`MarketplacePackagePage.guardOrder.test.tsx` pins the flip case for that reason, along
-with the ordering, the skipped requests, and the marketplace-off boundary the guard
-must not jump above.
diff --git a/.changeset/marketplace-detail-disabled-state-5533.md b/.changeset/marketplace-detail-disabled-state-5533.md
deleted file mode 100644
index 672d7f993a..0000000000
--- a/.changeset/marketplace-detail-disabled-state-5533.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-The marketplace **package detail** page now states that the marketplace is turned
-off, instead of red-erroring, on a runtime that has none (objectui#5533).
-
-`MarketplacePackagePage` takes the same `isMarketplaceEnabled()` early return its
-sibling catalog page took in objectui#5504, rendering the informational
-`MarketplaceDisabled` state when the server reports `features.marketplace: false`
-(an `OS_CLOUD_URL=off` deployment — the EE template's factory default). Until now
-the same runtime answered a bookmarked or pasted package URL with a destructive
-"Failed to load package / Not found." card, so the two sibling pages reached
-opposite conclusions about one runtime: the catalog called it configuration, the
-detail page called it a failure.
-
-Both requests the page fires for its own view are skipped in that state — the
-package fetch and the cloud-installation probe — rather than fired and discarded:
-a discarded request still reaches the server and can race the destructive card
-onto the screen before the disabled state settles.
-
-Scope, deliberately narrow:
-
-- **Not** a "swallow all errors" change. With `features.marketplace: true` the page
-  behaves exactly as before, and a package that genuinely is not there still
-  renders the destructive card carrying the server's own message. The flag is the
-  runtime's own answer, never inferred from the shape of a failure, and it fails
-  open — a runtime that answers nothing keeps its detail page.
-- The `installLocal` surfaces are untouched. That is a different capability flag,
-  and an air-gapped `OS_CLOUD_URL=off` runtime still has a working install-local
-  path.
-- No new i18n keys: `marketplace.disabled.*` and `marketplace.action.backHome`
-  already ship in all ten locale packs.
diff --git a/.changeset/marketplace-disabled-state-5504.md b/.changeset/marketplace-disabled-state-5504.md
deleted file mode 100644
index 4462a09136..0000000000
--- a/.changeset/marketplace-disabled-state-5504.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-'@object-ui/app-shell': minor
-'@object-ui/i18n': minor
----
-
-Marketplace-less runtimes now say so instead of erroring: `OS_CLOUD_URL=off` is a
-first-class disabled state, and the load-failure hint describes the control plane
-the runtime was actually pointed at (objectui#5504).
-
-`apps/objectos-ee/deploy/.env.example` ships `OS_CLOUD_URL=off` as its factory
-default, so a stock self-hosted stack has no marketplace at all. The Console still
-recommended one: Home led with "Start with a template" and "Browse App
-Marketplace", and the click landed on a red **Failed to load marketplace / Not
-found** card whose hint claimed this runtime "points at the public ObjectStack
-cloud by default" and advised setting `OS_CLOUD_URL`. Both claims were false for
-exactly the deployment reading them — the operator had not left the default, and
-the advice pointed back at the template that told them to set `off`. "Marketplace
-disabled by configuration" is a configuration conclusion, not a load failure.
-
-- `isMarketplaceEnabled()` (`runtime-config`) reads the server's own
-  `features.marketplace`, which `RuntimeConfigPlugin` derives per request from the
-  serving app's route table (objectstack#8356). It is never inferred from the shape
-  of a failed request: a control plane that is merely DOWN leaves the flag `true`,
-  so an outage still renders as an outage. Unknown fails OPEN.
-- The marketplace page renders an informational "App Marketplace is turned off"
-  state — muted, not `destructive` — and issues no request it knows will 404.
-- Home's "Start with a template" cover greys out with a visible localized reason,
-  and the "Browse App Marketplace" shortcut is withheld, exactly as they already
-  are for the `manage_metadata` capability gate.
-- `marketplace.load.failedHint` is replaced by `failedHintConfigured` (naming the
-  configured control plane) and `failedHintSameOrigin`. The "points at the public
-  cloud by default" sentence is gone: it was rendered unconditionally, including on
-  every runtime whose operator had overridden `OS_CLOUD_URL`.
-
-All ten locale packs carry the new keys.
diff --git a/.changeset/master-detail-formtype-vocabulary.md b/.changeset/master-detail-formtype-vocabulary.md
deleted file mode 100644
index 00f7c1d493..0000000000
--- a/.changeset/master-detail-formtype-vocabulary.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-"@object-ui/plugin-form": patch
----
-
-`object-master-detail-form` declares `formType` as a closed vocabulary instead of a bare `string`.
-
-The block declared `formType` as `type: 'string'` while the sibling `object-form` declared the
-same key as an `enum`, and both funnel into the renderer that switches on those variant names. A
-value outside the vocabulary therefore matched no branch and fell through to the flat field list
-with no diagnostic — measured, a `formType` of `'wizzard'` renders the parent half with its
-authored sections silently gone.
-
-The declared set is `simple | tabbed`, measured against the master-detail composition rather than
-copied from the sibling's six: `drawer` and `modal` host the parent half in a portal dialog outside
-the master-detail container, so its single bottom Save bar has no form to submit; `wizard` mounts
-only the current step's fields and turns that Save bar into a `Next`; `split` renders inline but
-persists through `dataSource.create` instead of the atomic batch.
-
-Authoring-surface only. The manifest, the JSX-page compiler and the save gate now report an
-out-of-vocabulary value as `invalid-enum`; rejection at publish time remains `@objectstack/spec`'s.
diff --git a/.changeset/max-tool-roundtrips-deprecate-5605.md b/.changeset/max-tool-roundtrips-deprecate-5605.md
deleted file mode 100644
index 895bfcddfe..0000000000
--- a/.changeset/max-tool-roundtrips-deprecate-5605.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-'@object-ui/plugin-chatbot': patch
-'@object-ui/types': patch
----
-
-`maxToolRoundtrips` on `ChatbotSchema` is deprecated: it is inert, and an author
-who sets it is now told so instead of being left believing the documented cap
-applies (objectui#5605).
-
-The key was declared authorable in `@object-ui/types` (interface and zod, with a
-description), threaded from the authored document through the chatbot renderer at
-three call sites, accepted by `useObjectChat`, given a default — and then dropped.
-Measuring the installed chat runtime says it cannot be honoured from here rather
-than that someone forgot to wire it: `@ai-sdk/react`'s `useChat` takes `ChatInit`
-plus throttle/resume, and `ChatInit` declares exactly one loop control — the
-boolean predicate `sendAutomaticallyWhen` — and no numeric cap under any
-spelling. The numeric knob was removed from `useChat` in a major, and its
-successor was renamed through `continueUntil` to `stopWhen` / `stepCountIs`,
-which the installed `ai` package declares only on `generateText`, `streamText`
-and the tool-loop agent settings — all server-side. ObjectUI is backend-agnostic,
-so it owns no server loop to cap either, and putting the number in the request
-body would only move the same dead key one hop onto a wire contract no backend
-reads.
-
-This is stage one of a two-stage retirement, so nothing an author already wrote
-breaks: the key still parses, still carries its declared shape, and the renderer
-still threads it. What changes is that it is now marked `@deprecated` in the
-interface, the zod description and the docs, and that authoring it logs a
-one-time notice naming the knob that does work — `planning.maxIterations` on the
-agent. A follow-up removes the declaration once this deprecation has shipped in a
-release.
diff --git a/.changeset/metadata-client-actor-retired-4834.md b/.changeset/metadata-client-actor-retired-4834.md
deleted file mode 100644
index 2aa8de93c1..0000000000
--- a/.changeset/metadata-client-actor-retired-4834.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-'@object-ui/data-objectstack': minor
----
-
-**Breaking (published surface):** remove `options.actor` from `MetadataClient`'s
-`save`, `reset`, `publish` and `rollback`, and stop emitting the `X-Actor`
-request header.
-
-The server stopped honouring that header. objectstack#7941 ruled that the
-recorded actor is the identity the request was authorized as, and removed the
-header limb from the `/meta` write resolver — attribution cannot drift from
-authorization. The option therefore typed cleanly, sent a header, and could not
-influence the audit or history row it appeared to address: a false affordance
-that promised attribution and silently failed to deliver it.
-
-Three declarations go: `MetadataClientSaveOptions.actor` (inherited by
-`MetadataDeleteOptions` via `extends`, so it served both `save` and `reset`),
-and the inline `{ actor?: string }` on each of `publish` and `rollback`.
-`MetadataAuditEntry.actor` is unaffected — that is the server's read-back of
-who acted, and it remains the way to see attribution.
-
-Marked `minor` rather than `major` per this repo's version-alignment policy
-(the fixed group's major tracks `@objectstack`, and `major` in a changeset
-would drag all 39 packages off that cadence).
-
-No caller in this repo passed `actor`; the census found the only in-repo
-occurrence was the client's own unit test. Callers outside this repo that still
-pass it are unaffected at runtime beyond losing a header the server already
-ignored — the property is dropped rather than forwarded, pinned by
-`metadata-actor-retired-4834.pin.test.ts`.
diff --git a/.changeset/metadata-lock-state-5024.md b/.changeset/metadata-lock-state-5024.md
deleted file mode 100644
index 785458cbfb..0000000000
--- a/.changeset/metadata-lock-state-5024.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-'@object-ui/data-objectstack': patch
-'@object-ui/app-shell': patch
----
-
-The metadata lock banner can no longer render an amber, padlocked box with no
-title, and the ADR-0010 §3.6 lock vocabulary is declared once instead of three
-times (objectui#5024).
-
-`MetadataLayered.lock` and `MetadataAuditEntry.lockState` each spelled the four
-states out by hand, 42 lines apart in one file, compared by no gate. They are now
-one exported `MetadataLockState` — derived from `GetMetaItemLayeredResponseSchema`'s
-`z.enum` in `@objectstack/spec`, which already owns this vocabulary, so the copies
-were restating a schema rather than filling a gap.
-
-The user-visible half is the banner. Its title was three independent `&&` branches
-with no fallback, while the switch that opens the banner is true for any non-`none`
-value — so a lock state outside the four opened the box and left the headline
-empty. That is reachable without a fifth state ever being added here:
-`MetadataClient.layered()` casts the wire value through unchecked, so a newer
-server reaches this banner as-is. Measured, not assumed — feeding `no-publish`
-through the page rendered the padlock, the border and an empty title. The title is
-now a keyed lookup with a loud fallback that names the unrecognised token, so a
-fifth state fails `type-check` here and, if one arrives from a server anyway, the
-operator reads a sentence instead of a blank box.
diff --git a/.changeset/nav-selection-root-keys-edge-5600.md b/.changeset/nav-selection-root-keys-edge-5600.md
deleted file mode 100644
index 5fd1bb1b3c..0000000000
--- a/.changeset/nav-selection-root-keys-edge-5600.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
----
-
-Internal layering fix, behaviour-unchanged: publishes nothing, declared explicitly
-with an empty frontmatter rather than left undeclared.
-
-Inverts the dependency edge objectui#5600 found: `nav-selection.ts` — otherwise pure
-URL-parsing plumbing (`parseSurfaceParam` / `formatSurfaceParam` / `parseNavSelParam`
-and friends) — statically imported `APP_NAV_ROOT_KEYS` from the 510-line
-`AppNavInspector.tsx`, so every consumer of the URL helpers (including two small
-utilities, `console/ai/artifactStudioPath.ts` and, transitively via
-`useSurfaceDeepLink.ts`, the studio-design surface) pulled a React inspector
-component into their static import graph for one array of root keys.
-
-`APP_NAV_ROOT_KEYS` (`['nav', 'navigation', 'tabs', 'items', 'menu']`) is a plain
-string-literal array — it describes nav SHAPE, not the inspector — so it now lives in
-`nav-selection.ts` instead. `AppNavInspector.tsx` never read the array itself, only
-re-exported it (`export const APP_NAV_ROOT_KEYS = ROOT_KEYS;` as its last line), so
-the fix is a straight move with no back-import needed on that side.
-
-Verified structurally rather than by reading the import line: a BFS over static
-(non-type, non-dynamic) relative imports from `nav-selection.ts` and the other
-non-test importers no longer reaches `AppNavInspector.tsx` (158 files visited, target
-not found), where the same walk over the pre-fix tree found it in 6 files via
-`nav-selection.ts -> AppNavInspector.tsx` directly.
diff --git a/.changeset/node-gate-data-predicate-report-5687.md b/.changeset/node-gate-data-predicate-report-5687.md
deleted file mode 100644
index 5465efc0e4..0000000000
--- a/.changeset/node-gate-data-predicate-report-5687.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-'@object-ui/react': patch
----
-
-`SchemaRenderer`'s node visibility gate now emits a dev-only warning when a
-predicate reads `data.*` and the data-source adapter cannot answer that read, so
-an author who wrote `properties: { visible: "data.status == 'draft'" }` sees the
-constant they authored instead of shipping it (objectui#5687).
-
-At the node tier `data` is the data-source **adapter** — the object `${data.total}`
-in a props bag resolves against — and it has never been the row. A predicate
-written with the deprecated `data.*` spelling therefore resolves `undefined ==
-'draft'`, which is a perfectly good `false`: the block is hidden on every row, and
-because it does not throw, the unresolvable-predicate reporter added for
-objectui#5454 never fired. Measured on this base, the same predicate written as a
-`{ dialect: 'cel' }` envelope *does* throw and *was* already reported — so whether
-an author heard about the identical mistake depended on which dialect they happened
-to write it in, which is the arbitrariness objectui#5454 existed to remove.
-
-**No verdict changes and no interpolation changes** (maintainer ruling,
-2026-08-22, option A). The node tier keeps its documented `data` = adapter
-semantics; objectui#5330's row binding does not extend here. The evaluator's answer
-is returned exactly as computed and `${data.*}` interpolation is untouched — only
-the silence moved.
-
-The report fires on a `data.*` read the bound adapter answers with `undefined`, not
-on the spelling. A genuine adapter read stays silent (`data.total > 0` against an
-adapter carrying `total`), a canonical `record.*` predicate stays silent, and a
-correctly-hiding gate stays silent. Dev builds only, `console.warn`, deduped per
-node type + key + predicate source — the same module, Set and lifecycle as the
-objectui#5454 reporter.
-
-This loudness is temporary by design: it dissolves when objectui#5330's deprecation
-window for the `data.*` row spelling closes.
diff --git a/.changeset/normalise-client-error-user-message-5901.md b/.changeset/normalise-client-error-user-message-5901.md
deleted file mode 100644
index d6739f5405..0000000000
--- a/.changeset/normalise-client-error-user-message-5901.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-'@object-ui/data-objectstack': patch
----
-
-Preserve the producer's `userMessage` marking when `normaliseClientError` re-wraps a refusal.
-
-`ApiErrorSchema.userMessage` (objectstack#9934) is the opt-in channel an application author
-sets at throw time to say "this text is for the end user", and the contract states it
-status-agnostic — any refusal status may carry it. Both of the shapes this adapter re-wraps
-into typed errors dropped the marking: a hook that refused a write with `VALIDATION_FAILED`
-or `CONCURRENT_UPDATE` and marked its own sentence had that sentence discarded at the
-adapter boundary, before any surface could render it. Nothing threw and the typed error was
-otherwise correct, so the only symptom was the user reading a generic string instead of the
-sentence their administrator wrote.
-
-The marking now rides both re-wraps, in the form the shared reader (`declaredUserMessage`)
-already looks for: on the details bag for `DataApiValidationError`, exactly the way `fields`
-already survives, and on a new readonly `userMessage` member for `ConcurrentUpdateError`,
-which has no details bag. Unmarked refusals are untouched — they carry no key and still read
-as `null`, so nothing a producer did not opt into can reach a user.
diff --git a/.changeset/notready-t-interpolates.md b/.changeset/notready-t-interpolates.md
deleted file mode 100644
index 5c806e4ec1..0000000000
--- a/.changeset/notready-t-interpolates.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-'@object-ui/i18n': patch
----
-
-fix(i18n): `useObjectTranslation`'s provider-less `t` now interpolates its inline `defaultValue`
-
-With no `I18nProvider` mounted, react-i18next hands back its not-ready `t`, which
-returns `options.defaultValue` **verbatim** — so an inline default written
-`'Deleted {{count}} rows'` reached the user with the braces intact. 68 inline
-defaults across 24 files rendered through that path on any host that embeds an
-ObjectUI component without a provider, which is the configuration
-`createSafeTranslation` exists for.
-
-`useObjectTranslation` now runs its not-ready result through the same one
-interpolator `createSafeTranslation`'s `fallbackT` uses, so both provider-less
-renderers fill exactly the `{{name}}` spelling the copy is already gated to. The
-ready path is untouched: with a provider, i18next's own `t` is returned by
-reference and nothing is interpolated twice. Pre-interpolated template-literal
-defaults (`` `Deleted ${n} rows` ``) stay correct — they have no holes left to
-fill — so no call site changes.
diff --git a/.changeset/npm-presence-publish-predicate-5442.md b/.changeset/npm-presence-publish-predicate-5442.md
deleted file mode 100644
index c77030eafe..0000000000
--- a/.changeset/npm-presence-publish-predicate-5442.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
----
-
-CI only — this publishes nothing, declared explicitly with an empty frontmatter rather
-than left undeclared.
-
-`.github/workflows/changeset-release.yml` keys its publish lane on **"is the version this
-commit declares already on npm?"** instead of on **"are changesets pending?"**
-(objectui#5442, maintainer ruling 2026-08-22, Option B).
-
-The two predicates read as interchangeable and come apart exactly where it costs a
-release. The version PR is cut from `main` at T and merged at T+n; `main` takes ~18
-merges a working day and the merge does not remove the changesets that landed in
-between. Those belong to the *next* version, but keyed on them the version this commit
-just bumped to is skipped, and the next version PR bumps straight past it. Measured on
-`bc21c704b`: of the 90 versions `packages/core/CHANGELOG.md` declares, 16 never reached
-npm, and the repository said `17.6.0` while `dist-tags.latest` said `17.5.0`.
-
-The npm predicate is also cheaper than the one it replaces rather than a trade against
-it: an ordinary landing does not move the manifest version, so it answers "already
-published" and the expensive job is skipped.
-
-Alongside it, a **loud check**. The defect was never a red run — run 3370 on `cfeb378b5`
-completed `success` having published nothing — so the publish lane now reads the registry
-back and fails if the version it exists to ship is still absent. A repo/npm divergence is
-a failing run, not something an audit finds 16 versions later.
-
-The refresh lane is untouched and still cannot publish: no `publish:` input and no npm
-credentials in its `env:`, the double denial that keeps a scheduled tick from releasing
-something nobody merged.
diff --git a/.changeset/object-schema-metadata-derive-from-spec.md b/.changeset/object-schema-metadata-derive-from-spec.md
deleted file mode 100644
index 501ecb2388..0000000000
--- a/.changeset/object-schema-metadata-derive-from-spec.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-'@object-ui/types': minor
-'@object-ui/app-shell': patch
-'@object-ui/react': patch
----
-
-`ObjectSchemaMetadata` is now derived from `@objectstack/spec`'s `ServiceObject`
-instead of being a hand-written copy (objectui#5362; maintainer ruling
-2026-08-20: the object document type belongs to the spec).
-
-What changes on the published type surface:
-
-- **Gained:** the full spec object-document surface, including the three keys
-  the runtime already reads but the old interface rejected as excess
-  properties: `icon`, `titleFormat`, `listViews` (plus `pluralLabel`,
-  `nameField`, `displayNameField`, `managedBy` as a spec key, and the rest of
-  the spec document).
-- **Removed:** nine members the old interface declared that no objectui
-  runtime code reads and the spec document does not know: `extends`,
-  `triggers`, `primary_key`, `relationships`, `name_field` (the spec spelling
-  is `nameField`), `soft_delete`, `audit_trail`, `version`, `cache`.
-  `ObjectTrigger` and `ObjectRelationship` remain exported unchanged.
-- **Kept:** `editMode` — the one measured client-side member the runtime reads
-  (`recordFormNavigation` / `AppContent`) — now declared on the new
-  `ObjectSchemaClientExtensions` interface, which the derivation intersects.
-  Note the spec's strict parse rejects `editMode` on published documents
-  (`unrecognized_keys`); it is a client-type member only.
-
-Spelling settlement: `listViews` (camelCase) is canonical — `list_views`
-appears nowhere in `@objectstack/spec` 17.2.0. Runtime read sites in
-`@object-ui/app-shell` and `@object-ui/react` keep a documented snake-spelling
-READ fallback for stored pre-settlement documents (that stock has never been
-censused — objectstack#7917); the CRUD guide and its pinned transcription now
-author the canonical spelling.
diff --git a/.changeset/objectchart-fieldoptionlabel-ref-5587.md b/.changeset/objectchart-fieldoptionlabel-ref-5587.md
deleted file mode 100644
index 4b61e3f15d..0000000000
--- a/.changeset/objectchart-fieldoptionlabel-ref-5587.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-'@object-ui/plugin-charts': patch
----
-
-`ObjectChart` now depends on the `fieldOptionLabel` resolver directly instead of
-holding it behind a ref, so a chart re-resolves its groupBy option labels when
-the resolver genuinely changes (objectui#5587).
-
-The ref existed for a reason that no longer holds. `useSafeFieldLabel()` returned
-a fresh object on every render outside an i18next provider, so a direct
-dependency made `fetchData`'s `useCallback` identity fresh on every render, and
-the effect that depends on `fetchData` refetched on every render — an unbounded
-loop. `ObjectChart` worked around that locally with `fieldOptionLabelRef` plus a
-`useEffect` keeping it current. `useObjectLabel`'s memo now holds with or without
-an i18next instance bound (objectui#5564), so the resolver's identity is stable
-on both paths and the indirection buys nothing.
-
-It did cost something, and that is the user-visible half: a ref-hidden dependency
-meant `fetchData` did NOT re-run when the resolver changed. A chart mounted
-before its `I18nProvider`, or rendered across a language switch, kept serving
-groupBy labels resolved by the old resolver until some unrelated dependency
-(object name, filter, aggregate) happened to move. It now refetches once on that
-transition and shows labels in the active language.
-
-Pinned by `ObjectChart.fieldOptionLabelRefetch.test.tsx`, which counts fetches
-across forced re-renders both outside and inside a provider. Reverting
-`useObjectLabel.ts` to its pre-objectui#5564 state turns the no-provider case red
-(2 fetches instead of 1, alongside React's "Maximum update depth exceeded"), so
-the removal is pinned to the fix that unlocked it rather than to a comment.
diff --git a/.changeset/objectmap-marker-title-resolver-5953.md b/.changeset/objectmap-marker-title-resolver-5953.md
deleted file mode 100644
index fa48d3279b..0000000000
--- a/.changeset/objectmap-marker-title-resolver-5953.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-'@object-ui/plugin-map': patch
----
-
-`ObjectMap` now resolves marker titles through `@object-ui/core`'s
-`getRecordDisplayName` (ADR-0079), instead of reading a hard-coded `'name'` key.
-
-`getMapConfig` used to fill an absent title binding with the string literal
-`'name'`, and the marker transform then did a bare `record[titleField]` read. For
-every object whose display field is not literally `name`, that read was
-`undefined`, so each marker popup titled itself `undefined`. The literal is gone
-from both branches that carried it, and the read site hands the decision to the
-same resolver `ObjectKanban`, `ObjectCalendar` and `ObjectGantt` already title
-their items through — `ObjectMap` was the fourth renderer and the only one still
-outside it.
-
-An authored `map.titleField` keeps winning outright: it is passed through as the
-resolver's explicit `titleField` option, which it checks first. What is new
-underneath is everything a static field-name binding cannot express — the
-object's declared `nameField`, its deprecated `displayNameField` alias, a legacy
-`titleFormat` template, type-aware field derivation, and a name-ish probe over
-the record's own keys for the inline-data case where no object definition is
-fetched at all.
-
-Records with no resolvable name now read `Record #<id>` rather than `undefined`
-or a uniform `Marker`; the `Marker` placeholder is kept only for a record that
-carries no id either. No authoring surface changes and no new map config keys.
diff --git a/.changeset/objectmap-schema-data-shorthand-5305.md b/.changeset/objectmap-schema-data-shorthand-5305.md
deleted file mode 100644
index c21345fce8..0000000000
--- a/.changeset/objectmap-schema-data-shorthand-5305.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-'@object-ui/plugin-map': patch
----
-
-`ObjectMap` reads `schema.data` in one place again, so an array-shorthand map stops
-making a metadata request it never uses.
-
-The fetch effect carried a second short-circuit beside the `props.data` one
-objectui#5003 fixed: it read `schema.data` directly and tested whether that value was
-itself an array. eslint reported it as `missing dependency: schema.data` — the last
-`react-hooks/exhaustive-deps` warning on that effect.
-
-The dependency was never actually missing. `getDataConfig(schema)` already returns
-`schema.data` verbatim, and the result is memoized on `JSON.stringify(rawDataConfig)`
-into `dataConfig`, which **is** one of the effect's declared dependencies. The authored
-rows therefore reached the effect before this change; the direct read was a duplicate of
-an already-threaded value, which is why neither adding a dependency nor deleting the
-branch was right.
-
-The array handling moved into `getDataConfig`, where `ObjectGrid`'s own `getDataConfig`
-already pins the same normalization (`"Check if data is an array (shorthand format)"`).
-Same rows render, and the effect now reads only `dataConfig`.
-
-One behavioural consequence, and it is the point: an array under `data` now yields
-`provider: 'value'`, so `hasInlineData` is true and the sibling effect no longer calls
-`dataSource.getObjectSchema()` for it. That request's only read site is
-`buildExpandFields()` inside the object-provider fetch branch, which an inline schema
-never reaches — so the call was pure waste, and the shorthand now behaves exactly like
-the declared `{ provider: 'value', items }` form it is shorthand for.
-
-Deleting the branch instead was measured, not assumed: with no producer-side handling,
-an array-shorthand map renders `Error: DataSource required for object/api providers`
-rather than its markers. The shorthand is a live convention in six sibling blocks
-(`ObjectGrid`, `ListView`, `ObjectTree`, `ObjectChart`, `ObjectDataTable`,
-`calendar-view-renderer`), so `object-map` would have become the one block in the family
-that answers it with an error box.
diff --git a/.changeset/objectpivottable-i18n-resolver-refs-5625.md b/.changeset/objectpivottable-i18n-resolver-refs-5625.md
deleted file mode 100644
index b5f4cc6308..0000000000
--- a/.changeset/objectpivottable-i18n-resolver-refs-5625.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-'@object-ui/plugin-dashboard': patch
----
-
-`ObjectPivotTable` now depends on the `fieldLabel` / `fieldOptionLabel`
-resolvers directly instead of holding them behind refs, so a pivot re-derives
-its header and option labels when the resolver genuinely changes
-(objectui#5625).
-
-The refs existed for a reason that no longer holds. `useSafeFieldLabel()`
-returned a fresh object on every render outside an i18next provider, so a direct
-dependency would have re-run the metadata-derivation effect on every render —
-and that effect ends in `setFieldLabelMaps` / `setFieldNameLabels` with freshly
-built objects, so each run scheduled the next one: an unbounded derive loop.
-`ObjectPivotTable` worked around that locally with `fieldLabelRef` /
-`fieldOptionLabelRef` plus a `useEffect` keeping them current.
-`useObjectLabel`'s memo now holds with or without an i18next instance bound
-(objectui#5564), so both resolvers have a stable identity on both paths and the
-indirection buys nothing.
-
-It did cost something, and that is the user-visible half: a ref-hidden
-dependency meant the derivation did NOT re-run when the resolver changed. A
-pivot mounted before its `I18nProvider`, or rendered across a language switch,
-kept showing its top-left header label and its select-option cell labels as
-resolved by the old resolver — until some unrelated dependency (the data source,
-the object name) happened to move. It now re-derives once on that transition and
-renders in the active language.
-
-This is the same removal objectui#5587 made in `ObjectChart`, one package over.
-
-Pinned by `ObjectPivotTable.i18nResolverDeps.test.tsx`, which counts derivations
-across forced re-renders both outside and inside a provider, checks that the two
-derived state maps settle, and asserts the language-switch re-derivation.
-Reverting `useObjectLabel.ts` to its pre-objectui#5585 state turns the
-no-provider case red (derivations in the dozens instead of 1), so the removal is
-pinned to the fix that unlocked it rather than to a comment.
diff --git a/.changeset/objectview-overlay-pair-completeness-5025.md b/.changeset/objectview-overlay-pair-completeness-5025.md
deleted file mode 100644
index 85273d19a3..0000000000
--- a/.changeset/objectview-overlay-pair-completeness-5025.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-`sanitizeViewOverride` now strips a half-filled `between` from a stored view
-overlay, instead of handing it back to the merge (objectui#5025,
-objectstack#8815).
-
-The overlay recovery pass asked "is this filter row filled in?" with the
-shape-blind predicate objectstack#8815 retired — `value == null || value === ''
-|| (Array.isArray(value) && value.length === 0)`. That is correct for `scalar`
-and `list` and blind to `pair`: a `between` carrying one bound is
-`['2024-01-01', '']`, an array of length 2, so the pass read it as a real
-condition and kept it. The two write paths (`plugin-list`'s `ListView` and
-app-shell's `viewFilterFold`) were converted to the builder's arity-aware
-`isFilterValueComplete`; this read path was the third verbatim copy, and the one
-whose job was to clean up exactly the rows the other two used to write. Until
-now a stored half-range survived the pass, reached the query, and the server
-refused the whole view (`400 INVALID_FILTER`) for every user on every later
-read.
-
-The pass now delegates to the same `isFilterValueComplete` the write paths use,
-on both of the at-rest shapes it handles (the spec `ViewFilterRule` object and
-the legacy runtime triple). A complete range — bounds of `0` and `false`
-included — is untouched, and the `scalar` and `list` families read exactly as
-before, since the retired predicate was already right for them. One shape is
-newly stripped beyond the half-filled array: a `between` whose value is a bare
-scalar, which `ViewFilterRuleSchema` itself refuses.
-
-Which operators want no value at all is unchanged and still answered by
-app-shell's `VALUELESS_FILTER_OPERATORS` — that set is already derived from the
-builder's `VALUELESS_FILTER_BUILDER_OPERATORS` rather than being a private copy,
-and its parity is pinned.
diff --git a/.changeset/objectview-sort-sink-4869.md b/.changeset/objectview-sort-sink-4869.md
deleted file mode 100644
index 9408f95811..0000000000
--- a/.changeset/objectview-sort-sink-4869.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-'@object-ui/plugin-view': patch
----
-
-**Bug fix:** a non-grid `object-view` (calendar / kanban / gallery / timeline)
-whose sort came from the deprecated `table.defaultSort` no longer comes back
-empty. `ObjectGridSchema.defaultSort` is declared a single `{ field, order }`
-object, and `ObjectView`'s own fetch handed it to `$orderby` verbatim — where
-the ObjectStack adapter reads it as an `$orderby` map and folds it with
-`Object.entries`, so the request went out sorting by two columns literally
-named `field` and `order`. The server answers `400 INVALID_SORT`, `ObjectView`
-swallows the error, and the view rendered with no records — while the *same*
-metadata sorted correctly as a grid, because `ObjectGrid` lowers that pair
-before using it (objectui#4869, maintainer ruling 2026-08-22).
-
-`ObjectView` now performs the same legacy-to-canonical lowering `ObjectGrid`
-already does (`sort ?? (defaultSort ? [defaultSort] : undefined)`) and routes
-the whole chain — named view sort, `views` prop sort, `table.sort`,
-`table.defaultSort` — through the shared `convertSortToQueryParams` sink. This
-was the last object-bound read site sending an authored sort to `$orderby`
-unlowered; every other block (gantt, map, calendar, timeline,
-`record:line_items`) already did, so an adapter that implements `find` itself
-now receives one normalized `Record<field, direction>` from all of them instead
-of two different dialects.
-
-Precedence is unchanged, and both spellings of the pair keep working. The
-shared sink was deliberately **not** widened to accept a bare `{ field, order }`:
-its input slot also legitimately carries `$orderby`'s own map, in which
-`{ field: 'desc' }` is a valid ordering by a column named `field`, so widening
-it would make one shared function guess.
-
-Two visible shape changes on the wire, both semantically identical to before: a
-string `table.sort` such as `'name desc'` now serializes as `-name` rather than
-riding through as `name desc`, and a `SortConfig[]` arrives as a map rather than
-as an array.
diff --git a/.changeset/olive-cameras-repeat.md b/.changeset/olive-cameras-repeat.md
deleted file mode 100644
index 6688e0b3d6..0000000000
--- a/.changeset/olive-cameras-repeat.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-"@object-ui/plugin-map": patch
----
-
-`ObjectMap`: make the marker `useMemo` actually memoize.
-
-`getMapConfig(schema)` ran unmemoized in the render body, so `mapConfig` carried
-a fresh object identity on every render. The marker transform names `mapConfig`
-in its dependency array, so it recomputed on every single render — walking every
-record through `extractCoordinates` and the display-name resolver, and re-running
-`ObjectMapConfigSchema.safeParse` on each pass — while declaring that it does not.
-The invalidation cascaded on into `filteredMarkers`, `clusteredData`,
-`markerBounds` and `initialViewState`.
-
-`mapConfig` is now memoized on `schema`, the one value `getMapConfig` reads.
-Behaviour is unchanged; the config is still rebuilt whenever the schema
-genuinely changes.
diff --git a/.changeset/olive-donkeys-shave.md b/.changeset/olive-donkeys-shave.md
deleted file mode 100644
index 6e765665f9..0000000000
--- a/.changeset/olive-donkeys-shave.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-'@object-ui/plugin-dashboard': minor
----
-
-Dashboard flat `table` widget: render the server's grand total as a `tfoot` row (objectui#5846).
-
-The flat branch now requests the `[]` marginal grouping — the same server-side
-totals machinery the cross-tab has used since framework#1753 — and renders the
-answer under the console's existing `dashboard.total` label. Totals are computed
-by the server with each measure's TRUE aggregate (a `sum` sums, an `avg`/`min`/
-`max` reports the whole-set aggregate); nothing is recombined client-side. The
-row lives in `tfoot`, so it is exempt from sorting, renders below the `—` null
-bucket, and never joins the drillable rows.
-
-No footer is rendered when the executor answers no `[]` grouping, and none is
-requested for a table truncated by `options.limit`, whose visible rows a
-whole-set total could not be reconciled against.
diff --git a/.changeset/olive-donkeys-smile.md b/.changeset/olive-donkeys-smile.md
deleted file mode 100644
index e643a315e7..0000000000
--- a/.changeset/olive-donkeys-smile.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-"@object-ui/plugin-charts": minor
----
-
-Dashboard chart widgets no longer render as a blank area when their height class
-resolves to `auto`.
-
-`ChartContainer`'s min-size fallback was applied only to the wrapper `div`.
-Recharts measures its own `width:100%;height:100%` size-detector element, and a
-percentage height never resolves against an ancestor's `min-height`, so the
-wrapper obediently grew to 280px while the measured element stayed at 0 — and
-Recharts renders no children at all for a non-positive box. The result was a
-widget card with its title over an empty chart area: no marks, no refusal, no
-empty state, and permanent, because a box that never changes fires no resize.
-The floor is now applied to the measured element as well, under the same
-condition, so an author's explicit height still wins.
diff --git a/.changeset/olive-moons-reclassify.md b/.changeset/olive-moons-reclassify.md
deleted file mode 100644
index c01ea206f0..0000000000
--- a/.changeset/olive-moons-reclassify.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
----
-
-Test-only. The zod-mirror parity guard's declared-but-unmirrored ledger is split by
-remedy: 23 callback-shaped keys move out of `UnmirroredDeclared` (121 to 98 keys) into
-a separately pinned `RuntimeOnlyDeclared`, reconciled against the same measurement
-through the union of both ledgers. No published type, no mirror and no runtime
-behaviour changes; nothing releases.
diff --git a/.changeset/olive-pugs-sing.md b/.changeset/olive-pugs-sing.md
deleted file mode 100644
index 0ebe368860..0000000000
--- a/.changeset/olive-pugs-sing.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-'@object-ui/plugin-dashboard': patch
----
-
-Dashboard record fields: percent columns now render through the one percent
-scaling decision instead of a second, drifted copy of it.
-
-`renderFieldValue`'s `%`-format branch normalised the value itself before
-calling `formatPercent` (`const normalized = value > 1 ? value / 100 : value`,
-then `normalized * 100`). `formatPercent` already applies `percentDisplayValue`,
-which `@object-ui/core` documents as the single source of truth for percent
-display scaling, so the branch was re-deciding what core owns — and its copy had
-drifted from it in three measured ways:
-
-- `(value / 100) * 100` is not value-preserving in binary floating point,
-  re-introducing one call frame upstream the round trip that was removed from
-  inside `formatPercent`. On the 0.001-step grid to 200, 19,978 of 199,000
-  values change bit pattern and 1,108 rendered strings move, every one a
-  last-digit off-by-one: a stored `1.605` rendered `1.60%` where half-up is
-  `1.61%`.
-- A stored fraction below `0.01` was scaled twice — the local `* 100` put it
-  back under 1, so core's fraction arm scaled it again. `0.005` (0.5%) rendered
-  `50.00%`.
-- The local test was `value > 1` rather than core's symmetric `|value| < 1`, so
-  a negative already in percentage points took the fraction arm: `-5` rendered
-  `-500.00%`.
-
-The branch now hands the raw stored value to `formatPercent` — the identical
-call the list-view percent cell already makes for an ordinary percent column —
-so a percent reads the same as a record field, as a grid cell and as a dashboard
-measure. Output moves where it was wrong: values at or above 1 whose round trip
-lost a digit, fractions below `0.01`, negatives at or below `-1`, and exactly
-`1`, which is one percentage point by core's convention and now renders
-`1.00%` at two decimals, where the local `value > 1` test had made it
-`100.00%`.
diff --git a/.changeset/one-origin-dev-configs-5745.md b/.changeset/one-origin-dev-configs-5745.md
deleted file mode 100644
index a9ed98970c..0000000000
--- a/.changeset/one-origin-dev-configs-5745.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
----
-
-Dev/build configuration only — this publishes nothing, declared explicitly with an
-empty frontmatter rather than left undeclared. No package `src/` is touched. The
-files changed are `apps/console/.env.development`, `examples/console-starter/.env.*`
-and `examples/console-starter/vite.config.ts`; `.env.development` is not part of
-`@object-ui/console`'s published artifact (`files: ["dist"]`, built from
-`.env.production`, which is untouched), and the example is private and on the
-changeset `ignore` list.
-
-Converge the dev stacks on one origin: empty `VITE_SERVER_URL` and let the Vite
-proxy do the split-host hop.
-
-Both dev env files pointed `VITE_SERVER_URL` at `http://localhost:3000` while the
-page was served from `:5180` (console) and `:5173` (starter). Every client in these
-apps coalesces an unset value to `''` and then builds a relative `/api/...` URL, so
-an empty value routes same-origin through the dev proxy instead. `console-starter`
-had no `server` block at all, so it gets the same one-stanza `/api` proxy
-(`DEV_PROXY_TARGET` or `http://localhost:3000`) that `apps/console` already carries;
-no port is pinned, because its README documents the example on Vite's default 5173.
-
-This is the ruled prerequisite for the `sameOriginOnly` action-runtime default. Under
-that default a non-empty `VITE_SERVER_URL` makes every relative-target `type: 'api'`
-action resolve cross-origin and be fetched bare — no `Authorization`, no
-`X-Tenant-ID`, no `Accept-Language` — i.e. a 401 for the standard `pnpm dev` stack.
-
-`examples/console-starter/.env.production` is emptied too. Its committed
-`https://demo.objectstack.ai` was not a deliberate choice for the example: it is the
-same pre-convergence value the sibling console carried until 2026-05-24, when
-`c351c9604` ("default published SPA to same-origin") cleared it there for CORS-blank
--page reasons and touched only `apps/console/.env.production`. The starter was left
-behind by that commit, and as a fork-ready scaffold its committed value is the
-production origin every fork inherits. Split-origin deployments inject
-`VITE_SERVER_URL` at build time, the way the console's own `.env.production` already
-documents.
diff --git a/.changeset/owd-width-single-home-5477.md b/.changeset/owd-width-single-home-5477.md
deleted file mode 100644
index 10aa33c86c..0000000000
--- a/.changeset/owd-width-single-home-5477.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-`ObjectSettingsPanel` now calls `isExternalWider` from `owd-sharing.ts` instead of
-re-declaring `OWD_WIDTH` and the ADR-0090 D11 width comparison inline (objectui#5477).
-
-`owd-sharing.ts` states its own purpose — it is "the single home" for the pieces the
-per-object Settings tab and the package-level OWD overview must agree on, the D11
-"external ≤ internal" comparison among them — and the Settings tab was the one surface
-not calling it. The two implementations were verified equivalent before the swap, over
-the full domain of both dials plus `undefined`, the rejected legacy aliases and
-prototype-chain keys: 144 input pairs, zero disagreements. The module's extra `!!`
-truthiness guards are redundant at this call site, which already normalizes both dials
-to `''`, and `'' in OWD_WIDTH` is false regardless. So no author-visible verdict
-changes — the same three pairs warn, and the same twenty-two stay calm.
-
-The substantive half is the pin that keeps it that way. `ObjectSettingsPanel.owdAgreement.test.tsx`
-drives BOTH surfaces over the full 5×5 cross-product of the values their dials offer and
-requires all three legs — the Settings tab's rendered warning, the overview's per-row
-error, and `isExternalWider` itself — to agree on every pair, with the violating pairs
-pinned by name so the sweep cannot pass vacuously. Re-inlining a drifted copy into either
-surface, swapping the `(internal, external)` argument order, or refining D11 in only one
-place now fails a test instead of silently leaving the authoring surface enforcing the
-old rule.
diff --git a/.changeset/page-source-tailwind-framing-5461.md b/.changeset/page-source-tailwind-framing-5461.md
deleted file mode 100644
index 4762675119..0000000000
--- a/.changeset/page-source-tailwind-framing-5461.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-'@object-ui/types': patch
----
-
-`PageSchema.kind`'s TSDoc names the real per-tier styling primitive for source-authored pages instead of the "HTML + Tailwind" framing ADR-0080's own amendment retracted.
-
-This is a published type surface: the TSDoc ships in `@object-ui/types`'s built
-`.d.ts` and is what an author reads on hover over `kind`. It said a `kind:'html'`
-page is "constrained JSX/HTML + Tailwind" — and it links
-`content/docs/guide/react-pages.md`, which objectui#5413 has already corrected to
-say the opposite. Shipped type documentation was contradicting the guide it points
-readers to.
-
-ADR-0080's header amendment (2026-06-30, under ADR-0065, Accepted) supersedes that
-framing on styling: a page's `source` is *runtime metadata*, the console's Tailwind
-is compiled at build time by scanning the console's own `src`, and there is no
-safelist — so an authored utility class produces CSS only by coincidence, when
-objectui already ships that exact class, and otherwise produces nothing with no
-error anywhere. That is the ADR-0065 failure mode verbatim ("works only by
-coincidence"), and it is how a modal's `bg-black/50` backdrop reached production
-fully transparent.
-
-The tiers themselves are unchanged, and every load-bearing claim in the TSDoc
-survives verbatim — parse-never-execute and untrusted-author safety for `html`,
-the deprecated `'jsx'` alias, EVALUATED-in-the-main-tree with no sandbox behind the
-`react-pages` host capability for `react`, the ADR-0080 citation and the guide
-link. Only the styling conclusion changes, to the primitive each tier actually has:
-
-| `kind` | Style with |
-|---|---|
-| `"html"` | The blocks' own structured props (`` `<flex direction gap>` ``, `` `<grid columns>` ``) plus a JSON `style` object. |
-| `"react"` | Inline `style` objects. |
-
-Colors on both tiers come from the theme as `hsl(var(--token))`, so a page follows
-light/dark and whatever theme the deployment installs. The TSDoc now also names the
-rule that reports a violation — `page-source-className-tailwind`, shipped in
-`@objectstack/lint@11.5.0` as `validatePageSourceStyling` and reported by
-`os validate` as a warning on both tiers.
-
-No behaviour change, and the accepted `kind` set is untouched.
-
-`packages/components/src/renderers/layout/react-page.tsx` carries the same
-correction on its two source comments (the injected-scope note and
-`buildComponentScope`), and gains the styling note the file was missing. Those are
-internal comments — they do not project into any `.d.ts` and change no export — so
-they get no entry of their own; there is nothing an `@object-ui/components`
-consumer could read in a CHANGELOG and act on.
diff --git a/.changeset/page-source-tailwind-prose-retraction-5469.md b/.changeset/page-source-tailwind-prose-retraction-5469.md
deleted file mode 100644
index f125f38941..0000000000
--- a/.changeset/page-source-tailwind-prose-retraction-5469.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-'@object-ui/react-runtime': patch
-'@object-ui/sdui-parser': patch
-'@object-ui/components': patch
----
-
-Documentation no longer teaches the "JSX/HTML + Tailwind" framing for a page's
-`source`, which ADR-0080's own 2026-06-30 header amendment (under ADR-0065,
-Accepted) retracted. objectui#5461 corrected three sites; a multiline census
-found eight more, in three spellings a line-oriented grep could not see.
-
-A page's `source` is *runtime metadata*. The console's Tailwind is compiled at
-build time by scanning the console's own `src`, and there is no safelist, so it
-never sees your page: an authored utility class produces CSS only by coincidence
-(when objectui already ships that exact class) and otherwise produces nothing,
-with no error anywhere. That is the ADR-0065 "works only by coincidence" failure
-mode, and it is how a modal's `bg-black/50` backdrop reached production fully
-transparent. `os validate` reports it as `page-source-className-tailwind`, a
-warning on kinds `html`, `react` and `jsx`, shipped in `@objectstack/lint@11.5.0`.
-
-The tiers themselves are unchanged and every load-bearing claim survives —
-parse-never-execute, the untrusted-author safety argument for `html`, and the
-deprecated `'jsx'` alias. Only the styling primitive is corrected, to the wording
-`content/docs/guide/react-pages.md` §Styling already uses:
-
-| `kind` | Style with |
-|---|---|
-| `"html"` | The blocks' own structured props (`` `<flex direction gap>` ``, `` `<grid columns>` ``) plus a JSON `style` object. |
-| `"react"` | Inline `style` objects. |
-
-Colors on both tiers come from the theme as `hsl(var(--token))`.
-
-Why each package has an entry — each was measured against its built artefact, not
-assumed:
-
-- **`@object-ui/react-runtime`**: `README.md` is published to npm (npm includes
-  `README.md` in the tarball regardless of `files`). Its "no sandbox" callout is
-  the paragraph that routes untrusted-author work to the `html` tier, and it
-  carried the retracted framing line-wrapped across `:17-18`. It also gains the
-  §Styling section it was missing — the absence is why the framing survived here.
-- **`@object-ui/sdui-parser`**: the corrected header of `src/types.ts` projects
-  verbatim into the published `dist/types.d.ts`.
-- **`@object-ui/components`**: the corrected header of
-  `src/renderers/basic/html-elements.tsx` projects verbatim into the published
-  `dist/renderers/basic/html-elements.d.ts`. The `kind === 'html'` dispatch-arm
-  comment in `src/renderers/layout/page.tsx` does **not** project (it is inside a
-  function body) and is included here only because the same package already owes
-  an entry.
-
-No behaviour change: this is prose only. `CHANGELOG.md` occurrences are
-deliberately untouched — immutable release history.
diff --git a/.changeset/palette-canonical-discussion-5495.md b/.changeset/palette-canonical-discussion-5495.md
deleted file mode 100644
index 18563f664d..0000000000
--- a/.changeset/palette-canonical-discussion-5495.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-'@object-ui/app-shell': minor
----
-
-**The page-editor palette now offers the canonical `record:discussion` instead of the `record:chatter` alias.**
-
-The two spellings are one renderer under two names — `@object-ui/plugin-detail` registers both against `RecordChatterRenderer` — and the palette deliberately carries one entry per renderer. It carried the wrong one. `record:discussion` is the canonical spelling: `@object-ui/core`'s `public-blocks.ts` records `record:chatter` as that same block "under a Salesforce-familiar name, kept for schemas", app-shell's own page synthesiser (`buildDefaultPageSchema`) has emitted the canonical name all along, and the console's AI block vocabulary already leaves the alias uncurated for exactly this reason. The palette was the last surface still pointing at the alias, and it did so only because the `@objectstack/spec` build pinned when the entry was written had no canonical member to offer; the currently pinned build declares both. The author-facing label moves **"Chatter feed" → "Discussion"**. Maintainer ruling 2026-08-22 on objectui#5495.
-
-**The alias keeps rendering — this changes what Studio advertises, not what works.** `record:chatter` moves from `BLOCK_TYPE_META` into `PALETTE_EXCLUSIONS`, which is the palette's ledger of "renders, but is not offered". Every page schema in the wild that spells the block the Salesforce way renders exactly as before, and both halves are now pinned by a test (`palette-discussion-alias.test.tsx`) that asserts the registry resolves the alias to the *same renderer function* as the canonical name and that an alias schema still produces the discussion panel — so "no longer offered" cannot quietly drift into "no longer rendered".
-
-One knock-on worth knowing when you open an existing page: the block-editor canvas draws a node's icon and colour tone from the palette entry, so an existing `record:chatter` node now shows the generic unknown-block icon in the outline instead of the message icon. This is the pre-existing behaviour for any renderable-but-unoffered type — until this change it was the *canonical* `record:discussion` that read this way, including in every page the platform generates itself, so the affected spelling is now the rarer one.
diff --git a/.changeset/palette-exclusion-reason-truthfulness.md b/.changeset/palette-exclusion-reason-truthfulness.md
deleted file mode 100644
index ad1bcf1077..0000000000
--- a/.changeset/palette-exclusion-reason-truthfulness.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
----
-
-Corrects two `PALETTE_EXCLUSIONS` reason strings in the Studio page-palette ledger that
-claimed "no renderer" for `element:text_input` and `element:record_picker`, both of which
-have registered renderers, and pins the class with a test. The exclusions themselves are
-unchanged decisions and no published behaviour moves: the reason strings are developer-facing
-ledger prose, read by no runtime code path.
diff --git a/.changeset/param-dialog-title-fallback-4282.md b/.changeset/param-dialog-title-fallback-4282.md
deleted file mode 100644
index 41c71b6810..0000000000
--- a/.changeset/param-dialog-title-fallback-4282.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-The console's param-collection dialog now titles itself from `action.label` alone —
-the unreachable `|| action?.title` fallback beside it is removed (objectui#4282).
-
-`title` is declared on no action surface in the ecosystem: it is absent from
-`@objectstack/spec`'s `ActionSchema` (44 keys walked at spec 17.0.0), from
-`@object-ui/core`'s `ActionDef` and its pinned `ACTION_DEF_KEYS` / `SPEC_ACTION_KEYS`
-inventories, and from `@object-ui/types`' renderer view (`ui-action.ts`) and `crud.ts`
-`ActionSchema` / `BaseSchema`. None of the four action renderers — `action:button`,
-`action:icon`, `action:group`, `action:menu` — forwards it either. So the right-hand
-side of that `||` could not be reached by authored metadata: a fallback that cannot
-fire, which is the "declared is not enforced" shape objectstack#4075 exists to reduce.
-Nothing a user hits changes; the line now reads exactly one key, matching the
-`description` line directly below it.
-
-`useConsoleActionRuntime.paramDialogTitle.test.tsx` pins the reader so the alias cannot
-be reinstated silently: an action carrying `title` and no `label` must open an untitled
-dialog rather than a dialog named by a key no producer sets.
diff --git a/.changeset/paramtofield-reference-rule-derives-from-core-5312.md b/.changeset/paramtofield-reference-rule-derives-from-core-5312.md
deleted file mode 100644
index a3aa770c31..0000000000
--- a/.changeset/paramtofield-reference-rule-derives-from-core-5312.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-`ActionParamDialog`'s "this param carries a reference target" rule now derives from the shared reference-field family instead of the last private copy of it.
-
-`packages/app-shell/src/utils/paramToField.ts` restated the rule inline as
-`LOOKUP_WIDGET_TYPES.has(type) || type === 'user'` — the fourth and last
-hand-maintained answer to one question ("does this widget resolve a foreign key,
-so hand it `reference_to` / `display_field` / the rest of the picker config").
-The other three converged on `@object-ui/core`'s `EXPANDABLE_FIELD_TYPES` in
-objectui#4770 / #4790 / #4815; this face is now the fourth.
-
-No reachable behaviour change. The shared set is one member wider (`tree`), and
-that member can never be a widget key on this surface: it is absent from
-`fields`' widget map and `mapFieldTypeToFormType` sends it to `field:lookup`, so
-every key the rule tests arrives as `lookup`. Both halves are pinned, so
-registering a real `tree` widget surfaces the change instead of shipping it
-silently.
-
-The module's second rule — which widget keys degrade to a text input for want of
-a declared `referenceTo` — is a different set over overlapping types (`user`
-defaults its target to `sys_user` and must never degrade) and was deliberately
-left un-merged, matching the same split the plugin-grid twin keeps.
-
-Also retires a comment that claimed the disjunction "moves in lockstep with
-plugin-grid's `bulkParamToField` twin — the two param faces are never split".
-Measured on the tip before this change, that was false in both senses: the twin
-had read core's Set since objectui#4815 while this line read a private literal,
-so the two shared nothing and no gate could report a split; and the two member
-sets already differed, by `tree`. Lockstep now holds mechanically — the pin is
-on object identity (a spy on core's `has`), so a member-identical private copy
-fails where a value check would pass.
diff --git a/.changeset/pending-drafts-bar-locale-parity-5705.md b/.changeset/pending-drafts-bar-locale-parity-5705.md
deleted file mode 100644
index 6bafb84358..0000000000
--- a/.changeset/pending-drafts-bar-locale-parity-5705.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-'@object-ui/i18n': patch
----
-
-`console.ai.pendingDrafts` — the standing unpublished-changes bar's five strings —
-now exists in all ten locale packs. It previously existed only in `en` and `zh`, so
-`ar`, `ru`, `pt`, `es`, `fr`, `de`, `ko` and `ja` rendered the English defaults and
-`all-locales-key-parity` failed on `main` (objectui#5705).
-
-The feature landed `en`-only in objectui#5696; the follow-up in objectui#5697 was
-titled for the locale packs but reached only `zh`, so eight packs × five keys stayed
-missing and the parity assertion — which carries no allowlist — was red on `main` and
-on every PR whose diff touched source. Source-free diffs skip the shard that runs it,
-which is why the breakage survived several merges.
-
-Each pack keeps its own conventions rather than `en`'s: the eight all quote with `"`,
-`ru` puts the number last (`…: {{count}}`) as it already does for the sibling
-`home.pendingDrafts` counts, and `ja` uses the full-width `：` before `{{detail}}`
-because that value is a runtime message rather than a single token — both choices
-carry an in-pack note. Terminology is taken from each pack's existing publish-bar
-vocabulary (`home.pendingDrafts`, `console.ai.seedWarn`) so the two banners read
-alike.
-
-Both interpolations survive verbatim in every pack — `{{count}}` in `count` and
-`{{detail}}` in `publishedWithFindings` — asserted mechanically against the evaluated
-packs, not by eye. The unrelated `home.pendingDrafts` block (`message` / `cta`) is a
-different node and is untouched.
diff --git a/.changeset/pending-drafts-i18n-keys.md b/.changeset/pending-drafts-i18n-keys.md
deleted file mode 100644
index 84dab23b48..0000000000
--- a/.changeset/pending-drafts-i18n-keys.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-'@object-ui/i18n': patch
-'@object-ui/app-shell': patch
----
-
-Follow-up to #5696: the pending-drafts bar's strings live at `console.ai.pendingDrafts.*` with en+zh locale entries — the i18n call-site key gate and ratchet flagged the original root-level keys that existed nowhere.
diff --git a/.changeset/per-user-active-org-and-session-user-purge-5664.md b/.changeset/per-user-active-org-and-session-user-purge-5664.md
deleted file mode 100644
index 45bdd142c8..0000000000
--- a/.changeset/per-user-active-org-and-session-user-purge-5664.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-'@object-ui/auth': patch
-'@object-ui/console': patch
----
-
-The active organization id is now stored per user, and a change of session user drops the
-previous user's client state wholesale (objectui#5664).
-
-`auth-active-organization-id` was a single un-namespaced `localStorage` key while its
-siblings were already user-scoped (`objectui-recent-items:u:`, `objectui-favorites:u:`,
-`flow-palette-recents:u:`). On a browser handed from one account to another — a shared
-machine, a kiosk, a handover, a support session — the arriving user's console read the
-PREVIOUS user's organization id. The header workspace chip rendered the previous user's
-workspace for a user whose `organization/list` was empty, and the consequence past the
-cosmetics is the one worth stating: the polluted org context suppressed
-`RequireOrganization`'s routing into the guided "Create your workspace" first-run flow, so
-a brand-new user on that browser silently never got the new-user flow at all.
-
-Nothing about row visibility rode on this. With the stale id the server answers
-`403 USER_IS_NOT_A_MEMBER` on `get-full-organization` and `set-active`, and lists zero
-environments; the damage was entirely in what the client believed about itself.
-
-Three changes, and the third is the one that closes the class rather than the instance:
-
-- The key is per-user (`auth-active-organization-id:u:$userId`), matching the convention
-  its siblings already use.
-- It can no longer be written un-namespaced at all. Where no session user is known yet the
-  value lives in memory for that page-load only — a namespacing that kept a bare-key
-  fallback would re-open the defect the first time a write happened before the user id
-  resolved.
-- **A change of session user drops the previous user's client state wholesale.** This is an
-  allowlist sweep of both `localStorage` and `sessionStorage`, not a list of known keys, so
-  the NEXT storage key someone adds without a `:u:` scope is covered before it is written.
-  Only device-scoped entries survive: the arriving session's own bearer token, the pointer
-  recording whose state the browser holds, and the UI theme.
-
-Both properties objectui#5703 established are preserved and still pinned: `get()` prefers a
-non-null `localStorage` read and falls back to the in-memory value, and the memory value is
-nulled BEFORE storage is touched — by `clear()` as before, and now by the user-change purge
-too, so the outgoing user's org id cannot outlive their persisted key on the sign-out-then-
-sign-in path that never reloads the page.
-
-Existing browsers are not migrated. A value sitting under the retired bare key is
-unattributable — nothing recorded whose org id it is — so migrating it is precisely the
-defect it would be migrating away from, and it is deleted instead. A signed-in user loses
-nothing durable: the active organization is a server-owned fact that
-`AuthProvider.refreshOrganizations` re-asks for whenever the list is non-empty and no
-active org is held, including the ADR-0081 single-membership repair. One boot re-supplies
-it; users with no organization land on the guided first-run flow, which is the outcome this
-card is about.
-
-`apps/console`'s pre-render auth preflight purges every spelling of the active-org key —
-the retired bare one and each `:u:` scope — when it finds a dead bearer token, and
-deliberately leaves the session-user pointer in place so the next sign-in can still tell
-that the browser changed hands.
diff --git a/.changeset/per-view-config-alias-fold-2890.md b/.changeset/per-view-config-alias-fold-2890.md
deleted file mode 100644
index 1636fc20ce..0000000000
--- a/.changeset/per-view-config-alias-fold-2890.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-'@object-ui/core': patch
----
-
-`normalizeListViewSchema` now folds the four per-view-type config aliases phase 3
-carried over — `kanban.groupField` → `groupByField`, `kanban.cardFields` →
-`columns`, `gallery.imageField` → `coverField`, `timeline.dateField` →
-`startDateField` (objectui#2890).
-
-These are the pre-#2231 objectui spellings, kept declared alongside the spec keys
-so stored view metadata would keep validating. They now fold at the same
-component boundary as the A1–A5 vocabulary folds, in the same one-directional
-shape: the canonical key wins when a config carries both, and the legacy key is
-removed from the result so a missed read-site fails loudly instead of quietly
-taking the legacy path.
-
-One rendering behaviour changes, and it is a correction of the same inverted
-precedence the `densityMode` fold fixed: `ListView`'s kanban adapter resolves the
-card field list as `cardFields || columns` — legacy over canonical — so a kanban
-config carrying **both** rendered the legacy `cardFields` value and silently
-ignored the spec-canonical `columns`. After the fold the authored `columns` is
-what reaches it. Configs carrying only one of the two are unaffected, and every
-other reader of these four keys was already canonical-first.
-
-`calendar.defaultView` is deliberately **not** folded: it aliases nothing and has
-no spec counterpart, so it wants promotion upstream rather than a rename.
diff --git a/.changeset/percent-figure-grid-citation-5608.md b/.changeset/percent-figure-grid-citation-5608.md
deleted file mode 100644
index 7c6075e49b..0000000000
--- a/.changeset/percent-figure-grid-citation-5608.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
----
-
-Comments only — this publishes nothing, declared explicitly with an empty frontmatter
-rather than left undeclared (objectui#5608).
-
-Two live sites still carried the bare `27,581 of 1,200,013` figure with neither the grid
-nor the measured surface named: the `DisplayNumberFormatOptions.style` doc comment and a
-comment in the percentage-points test. Both were accurate. Neither was *reconcilable* — a
-reader who had also seen `packages/fields`'s `27,577 of 1,200,003` met two counts that
-look like a contradiction, and a figure a reader cannot reconcile is what makes a correct
-comment get distrusted wholesale. That is the same defect class objectui#4596 was queued
-for, and the wording here is lifted from its PR rather than phrased a third way — a third
-phrasing for one fact is the defect one level up.
-
-Both counts stand unchanged. The disambiguator is the surface measured, so each site now
-names it: objectui#4576's tie-dense grid (0.005 steps to 2,000, precisions 0/1/2) on
-`formatDisplayNumber` / `formatMeasure`'s call shape, against objectui#4590's re-measure
-of the same route through `formatPercent`. No value, assertion or behaviour moves.
-
-Why the empty form is the right declaration, stated from what was measured rather than
-carried over from objectui#4596's PR — the two cases are mirror images. There, a function
-BODY comment was changed, so the emitted `.js` moved and the `.d.ts` did not. Here the
-changed source comment is the JSDoc on an exported interface member: the interface erases
-at runtime, so the new prose reaches `dist/utils/number-display.d.ts` and is absent from
-`dist/utils/number-display.js` (checked on a real build of the package). The second site
-is a test file, excluded from the build program by `src/**/__tests__/**` and never in
-`dist` at all.
-
-So a consumer-visible byte does move — the text shown on hover. That is documentation of
-an existing measurement, not a change to the measurement, the type, or any behaviour:
-nothing a consumer types against or calls is different, which is why this releases
-nothing. Bytes moving is not the criterion; released behaviour and consumer-visible
-surface are, and neither moves.
diff --git a/.changeset/pivot-table-stable-empty-rows-5562.md b/.changeset/pivot-table-stable-empty-rows-5562.md
deleted file mode 100644
index d7423a5b53..0000000000
--- a/.changeset/pivot-table-stable-empty-rows-5562.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-'@object-ui/plugin-dashboard': patch
----
-
-`PivotTable` no longer re-runs its cross-tabulation memo on every render when it
-has no rows (objectui#5562).
-
-The component spelled the empty array twice — as the destructuring default for
-`schema.data` and as the `Array.isArray` fallback that keeps a provider-config
-object out of iteration — so a schema declaring no `data` key, or one whose
-`data` is a provider config rather than rows, produced a fresh array identity on
-every render. That value is the first entry of the memo's dependency list, so
-the memo rebuilt its two ordered key sets, its `bucket[row][col]` map, the
-aggregated matrix and the row/column/grand totals on every render, over nothing.
-Both spellings now resolve to one module-scope frozen empty, so "no rows" is a
-stable value and the memo holds.
-
-Wasted work only: the churn feeds a memo rather than a `setState`, and
-`PivotTable` holds no prop-to-state sync, so nothing rendered wrong and no
-render loop was possible. The identical fix landed for `data-table` in
-objectui#4618 and for `ObjectPivotTable` in objectui#4629; this closes the
-direct-use path those two did not cover, where `DashboardRenderer` and
-`DashboardGridLayout` construct pivot schemas without `ObjectPivotTable` in the
-chain.
diff --git a/.changeset/plain-taxis-attend.md b/.changeset/plain-taxis-attend.md
deleted file mode 100644
index 4b7cd354ce..0000000000
--- a/.changeset/plain-taxis-attend.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-'@object-ui/console': patch
----
-
-Approvals drawer: the business summary card no longer renders a field the object
-declares `hidden: true`.
-
-`payloadSummary` built the card from the request's `payload_json` snapshot behind
-five filters (system keys, the lead amount key, null/object/empty values,
-unresolved opaque ids, a six-field cut) and no field-visibility filter, so a
-hidden field that survived to the first six survivors rendered in the card,
-labelled. The drawer now reads the open request's object metadata and drops the
-declared-hidden keys before the six-field cut, so the next business field is
-promoted into the freed slot rather than the card silently shrinking. The lead
-amount figure at the top of the same card takes the same trim.
-
-Per the platform ruling, `hidden: true` is a UI-only contract and `internal: true`
-is the serialization primitive, so this is the UI enforcing the only contract
-`hidden` has — not a client-side compensation. Field-level security is unchanged
-and remains the server's answer. The metadata read is the same cached
-`GET /meta/object/:name` the record form already performs, once per object per
-page visit, and an unanswered read leaves the card exactly as it renders today.
diff --git a/.changeset/plugin-component-input-deprecate-5674.md b/.changeset/plugin-component-input-deprecate-5674.md
deleted file mode 100644
index 7f89a7f1de..0000000000
--- a/.changeset/plugin-component-input-deprecate-5674.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-'@object-ui/types': patch
----
-
-`PluginComponentInput` is deprecated in favour of `ComponentInput` (objectui#5674).
-
-This is stage 1 of a two-stage retirement the maintainer ruled on 2026-08-22: deprecate
-for a release, then remove. Nothing is removed here — the export still exists and still
-names the same type.
-
-`@object-ui/types`' entry point publishes `ComponentInput as PluginComponentInput`. Until
-objectui#4972 that alias pointed at a genuinely different declaration: `plugin-scope.ts`
-restated its own nine-key `ComponentInput`. objectui#5671 converged that declaration onto
-`base.ts`, so the alias became a second published name for the *same* type, carrying no
-information the first does not. Two published names for one type is a shape that costs
-readers a step and gives AI-authored code a coin-flip between spellings.
-
-**Why a deprecation window rather than a deletion.** The measurement that licenses
-deleting an export from a published package is *"no importer"*, and what can be measured
-from inside this repository is only *"no importer here"*. In-repo the name has zero
-importers — searched across every root (`packages/`, `apps/`, `content/`, `docs/`,
-`skills/`, `examples/`, `e2e/`, `scripts/`, and the root docs), plus the sibling framework
-repository, with a control name searched identically so a broken search could not read as
-a clean one; the only occurrences are the alias itself and prose about it. What no search
-here can see is a consumer on npm. The deprecation window is the answer to that
-unmeasurable half: it converts a silent break into a warned one before the removal lands.
-
-**Reversibility, deliberately.** Deprecating is undoable; deleting a published export is
-not. Where the evidence is one-sided, the retirement takes the reversible step first.
-
-The tag reaches consumers rather than only the source: a JSDoc block on an export
-specifier survives declaration emit and lands attached to that specifier in the emitted
-`index.d.ts`, which was measured for this change rather than assumed. With comments
-stripped, the emitted entry point is byte-identical before and after — the published
-*type* surface does not move, it only gains the notice.
-
-Stage 2 (removing the alias, and the now-dead re-export in `plugin-scope.ts` that exists
-only to feed it) is filed as a follow-up and ships as a `minor`, per this repo's policy
-that its own breaking changes never declare `major`.
diff --git a/.changeset/plugin-form-readme-classname-quantifier-5131.md b/.changeset/plugin-form-readme-classname-quantifier-5131.md
deleted file mode 100644
index 112411d63c..0000000000
--- a/.changeset/plugin-form-readme-classname-quantifier-5131.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-'@object-ui/plugin-form': patch
----
-
-`README.md`'s "Not a `FormField` key" table said a field-level `className` is
-"read on exactly one pseudo-field, `type: 'section-divider'`". That quantifier
-holds only for the renderer's *explicit* read — `className={fp.className}` on
-the `section-divider` branch of
-`packages/components/src/renderers/form/form.tsx`. The same renderer forwards
-every key it did not destructure, and `className` is not among the names taken
-off the field config, not among the ones `stripRendererOnlyProps` removes, and
-so rides `{...fieldProps}` into `renderFieldComponent`, whose built-in `input`
-branch spreads it onto `<Input>`. A field-level `className` therefore lands
-visibly on ordinary built-in controls, and a reader taking "exactly one"
-literally concludes the opposite of what the code does (objectui#5131).
-
-The cell now describes the contract rather than the reader count: an undeclared
-key still rides the props spread down to whichever component the field resolves
-to, nothing in the contract promises that, and a registered widget honours it
-only if it happens to spread its leftover props — the wording the docs site
-already ships, so the two sources agree again. The advice in the row is
-unchanged and was never wrong (`span` / `colSpan` for width,
-`FormSchema.fieldContainerClass` for the grid), and the explicit
-`section-divider` read is kept, now named as explicit.
-
-This is a documentation fix to a file `plugin-form` publishes to npm, which is
-why it carries a version: the npm landing page only picks up the correction on a
-release. No behaviour, export, type, or `dist` byte changes.
diff --git a/.changeset/plugin-map-reach-test-narration.md b/.changeset/plugin-map-reach-test-narration.md
deleted file mode 100644
index 7fe78586d7..0000000000
--- a/.changeset/plugin-map-reach-test-narration.md
+++ /dev/null
@@ -1,4 +0,0 @@
----
----
-
-Comment-only correction in `packages/plugin-map/src/ObjectMap.listViewMapConfigReach.test.tsx`: the narration above the `titleField` arm attributed the `'Marker'` placeholder to `getMapConfig`, which never held it. No assertion, fixture or published behaviour changes.
diff --git a/.changeset/properties-template-visibility-diagnostic-5756.md b/.changeset/properties-template-visibility-diagnostic-5756.md
deleted file mode 100644
index 5d050acf44..0000000000
--- a/.changeset/properties-template-visibility-diagnostic-5756.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-'@object-ui/react': patch
----
-
-`SchemaRenderer`'s node visibility gate now also catches the `${…}`-templated
-spelling of the objectui#5454/#5687 diagnostics when it is written inside
-`properties`, e.g. `properties: { visible: "${data.status == 'draft'}" }`
-(objectui#5756).
-
-The `properties.*` evaluation loop runs, and interpolates every `${…}` template it
-finds, **before** the visibility gate ever sees the value — so by the time the
-existing diagnostics ran, a template-spelled predicate had already collapsed into a
-plain boolean and there was no predicate text left to inspect. The bare-string
-spelling of the exact same gate (`properties: { visible: "data.status == 'draft'"
-}`) was unaffected — nothing interpolates a string with no `${` in it — and was
-already reported; only the template spelling was structurally invisible.
-
-Reached by moving the diagnostic check to inside the `properties` evaluation loop,
-on the predicate's raw (pre-interpolation) text, gated on the key being one of the
-six visibility keys the render chain consults (`visibleWhen` / `visible` /
-`visibleOn` / `visibility` / `hidden` / `hiddenOn`) — a `properties.content`
-interpolation, or any other non-visibility key, is untouched and stays silent.
-
-Reports only the key that actually **decides** the node's visibility, mirroring
-objectui#5454's own leg semantics (its reporter is likewise only ever invoked on
-the leg the chain's early-return sequence actually reaches): a `properties.visible`
-template that a co-declared `visibleWhen` outranks is not reported for deciding
-nothing.
-
-**No verdict changes and no interpolation changes.** The diagnostic call's return
-value is discarded; the real verdict is still computed afterward, off the
-post-evaluation, post-hoist schema, by the same code path as before this change.
-Same two reporters as objectui#5454/#5687 (unresolvable-predicate / adapter-only-data
-predicate), same dedupe `Set`, same `console.warn` severity, same dev-only gate —
-only the silence moved, one render-step earlier.
diff --git a/.changeset/proto-instrument-fixture.md b/.changeset/proto-instrument-fixture.md
deleted file mode 100644
index a3e358f90f..0000000000
--- a/.changeset/proto-instrument-fixture.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
----
-
-Test-only (objectui#6524): the `__proto__` instrument fixture in
-`MetadataService.objectPayloadFieldsMap.test.ts` was spelled as a plain object
-literal, which per Annex B.3.1 sets the prototype instead of adding a key — so
-the assertion parsed an empty `fields` map and would have stayed green if the
-spec began refusing the name. Respelled as a computed key and pinned with the
-literal-versus-computed control. No published behaviour changes.
diff --git a/.changeset/quick-reference-release-sync-5394.md b/.changeset/quick-reference-release-sync-5394.md
deleted file mode 100644
index d88e63d9ed..0000000000
--- a/.changeset/quick-reference-release-sync-5394.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
----
-
-Release tooling and repo docs only — this publishes nothing, declared explicitly with an
-empty frontmatter rather than left undeclared.
-
-`changeset:version` now runs `scripts/sync-quick-reference-release.mjs` after bumping the
-manifests, so `QUICK_REFERENCE.md`'s "Current Release" block moves in the same commit as
-the versions it quotes. Before this, the release path had no human in it and nothing
-updated the doc, so the block fossilised once per release and the anti-fossil gate
-`scripts/__tests__/quick-reference-current-release-4143.test.ts` reddened `main` on the
-push build every time (objectui#4642, objectui#4977, objectui#5394). The gate is
-unchanged — it is the judge; this is the thing that keeps the doc true.
-
-No package `src/` is touched, so no `@object-ui/*` package changes behaviour and there is
-nothing here for a consumer to upgrade to.
diff --git a/.changeset/radio-multiple-docblock-correction.md b/.changeset/radio-multiple-docblock-correction.md
deleted file mode 100644
index 2d7522ebdd..0000000000
--- a/.changeset/radio-multiple-docblock-correction.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
----
-
-Comment-only correction in `@object-ui/fields`. The `MULTI_VALUE_FORM_TYPES` docblock in
-`field-type-alias.ts` asserted that every `MULTI_CAPABLE_TYPES` member other than `select`
-renders both arities inside one widget, naming `LookupField`, `FileField` and `ImageField`
-while silently omitting `radio` — which reads `multiple` nowhere, and so is the one member
-with no multi-arity renderer. The docblock now states that exception, pins it to this repo's
-own single-value contract for `radio`, and points at the producer-side work that refuses the
-authored combination. No published behaviour changes.
diff --git a/.changeset/react-form-view-bridge-drifted-arms-5652.md b/.changeset/react-form-view-bridge-drifted-arms-5652.md
deleted file mode 100644
index 3f0c9b7965..0000000000
--- a/.changeset/react-form-view-bridge-drifted-arms-5652.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-'@object-ui/react': minor
----
-
-The spec-bridge's form-view input now accepts everything `@objectstack/spec`'s
-FormViewSchema accepts — three key types had drifted narrower, and one of them
-had inverted (objectui#5652).
-
-`bridges/form-view.ts` held a third hand-written description of the FormViewSchema
-contract, after the leaf (objectui#5542) and the two containers (objectui#5596)
-were converged elsewhere. A description nothing compares is one spec release from
-being a fork, and this one had already drifted on the keys that decide whether a
-legal document renders:
-
-- `FormSection.columns` refused the string spelling of a column count, which the
-  contract admits and folds to a number in its own pipe. It is now the contract's
-  type, and the bridge performs the fold — the `object-form` node's section
-  declares `columns` as a number and its container indexes a grid-class map by
-  it, so forwarding `'2'` handed every downstream renderer a value outside the
-  type it declares.
-- `FormField.dependsOn` was declared `string[]`, which is the exact inverse of the
-  contract: it admitted only the array arm the contract rejects, and refused the
-  bare parent-field name that is the one configuration making `field-selector`
-  and `dynamic-config` work (objectui#5040).
-- `visibleWhen`, on both fields and sections, was declared `string`, so the
-  ADR-0089 expression object — the arm `evalFieldPredicate` reads — could not be
-  described at all. Both arms now travel whole onto the node.
-
-A section's `fields` may also be a bare object-field name, the spec shorthand the
-list bridge already honours. The form bridge ran it through the object mapper
-instead, producing a field with no identity (`{ name: undefined }`) for the most
-ordinary section a form can declare; it is now forwarded verbatim, which is what
-the node's own `fields` slot admits.
-
-Each drift-prone key's type is now bound to the `@objectstack/spec` symbol that
-owns it rather than restated, so it cannot drift again, and the compile-time pins
-in `FormViewWidenedArms.test.ts` fail if a future edit restates any of them by
-hand. The documented subset itself is unchanged: the keys this bridge does not
-declare, including the retirement ledger it keeps, stay exactly as they were.
diff --git a/.changeset/react-pages-guide-source-contradictions-5413.md b/.changeset/react-pages-guide-source-contradictions-5413.md
deleted file mode 100644
index dbc67fae9f..0000000000
--- a/.changeset/react-pages-guide-source-contradictions-5413.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
----
-
-Docs only — this publishes nothing, declared explicitly with an empty frontmatter rather
-than left undeclared.
-
-`content/docs/guide/react-pages.md` contradicted the framework's sources on four points.
-The guide is live material (`@object-ui/react-runtime`'s README links it twice), so each
-one was reachable teaching. All four were re-measured against `objectstack@f094214b3` and
-resolved toward the source:
-
-- **Tailwind styling.** The guide taught Tailwind `className` as the react tier's styling
-  primitive, which ADR-0080's 2026-06-30 amendment retracted under ADR-0065 (Accepted): a
-  page's `source` is runtime metadata the console's build-time Tailwind never scans, so an
-  authored utility class silently produces no CSS. Replaced with the per-tier primitive the
-  shipped `page-source-className-tailwind` rule names — inline `style={{ … }}` with
-  `hsl(var(--token))` on the react tier, structured props plus a JSON `style` object on the
-  html tier — and added a Styling section giving the mechanism.
-- **`record:*` scope.** The family was offered as the illustrative in-scope example while
-  `os validate` rejects it (`react-block-needs-record-context`, severity error, matched by
-  type). The tag-derivation rule is kept — it is accurate — and the exclusion, the real
-  error text, and the per-block alternatives are now stated beside it.
-- **`adapter.find` options.** The `Live data` sample passed `filters:`, which is not a
-  `QueryParams` key; `convertQueryParams` reads only `$`-prefixed keys, so the sample
-  returned the object's records unfiltered with no error. Corrected to `$filter`. The same
-  sample also treated the result as an array — `find` resolves to a `QueryResult`, so
-  `.map` on it throws; corrected to `res.data` alongside it.
-- **Block inventory.** The guide conflated the runtime scope (every public non-container
-  block) with the authored contract (`REACT_BLOCKS`: `ObjectForm`, `ListView`,
-  `ObjectChart`, `Block`). Both are now stated as two tiers, with the generated
-  `react-blocks.md` named as the prop authority, and the flat-props example moved off two
-  deprecated `ObjectGrid` spellings (`pageSize`, `fields`) onto the canonical
-  `pagination` / `fields` on `ListView`.
diff --git a/.changeset/readonly-richtext-raw-markup-5498.md b/.changeset/readonly-richtext-raw-markup-5498.md
deleted file mode 100644
index c14d4ec2e2..0000000000
--- a/.changeset/readonly-richtext-raw-markup-5498.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-'@object-ui/fields': patch
----
-
-A readonly `markdown` / `html` / `richtext` form field now renders its content
-FORMATTED instead of showing the user its markup source (objectui#5498).
-
-`RichTextField`'s readonly early return rendered `{value}` as a React text child,
-so a readonly field of any of those three types displayed the stored markup as
-literal characters — a markdown field's asterisks and hashes, a richtext field's
-tags. The `prose` classes on that wrapper were the tell: they style rendered rich
-content, and there was none to style. Every other read surface — grid, kanban
-card, gallery, related list, dashboard record panel and the record detail page's
-read mode — dispatches through `getCellRenderer` and rendered the same stored
-bytes formatted, so one field disagreed with itself depending on which surface it
-was read on.
-
-The readonly branch now renders through the same components `getCellRenderer`
-resolves: `markdown` through the GFM renderer, `html` and `richtext` through the
-sanitizing HTML renderer. The two renderers moved out of the package barrel into
-`widgets/richTextDisplay.tsx` so the widget can reach them without importing the
-barrel back, and both sides now read one shared type-to-renderer table rather
-than two that can drift apart.
-
-The editor header's format label is fixed with it: it was computed as
-`field.format || 'markdown'`, and `format` is declared on `date` / `datetime` /
-`time` / `phone` / `auto_number` and on no rich-content type — so it read
-`undefined` for every real field and labelled an `html` field "Format: markdown".
-The label is now derived from the field type's display pipeline, so it names the
-syntax the value is actually stored in.
diff --git a/.changeset/reanchor-adr-0124-d1-citations-5701.md b/.changeset/reanchor-adr-0124-d1-citations-5701.md
deleted file mode 100644
index e176b10272..0000000000
--- a/.changeset/reanchor-adr-0124-d1-citations-5701.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
----
-
-Traceability only — this publishes nothing, declared explicitly with an empty frontmatter
-rather than left undeclared. The change is comment text at eight live source sites; no
-executable line moves, and `git diff -U0` carries zero non-comment added or removed lines.
-
-`server enforces, client is courtesy` was cited at those eight sites as the framework's
-**`ADR-0057 D10`**. That decision reads *"Setup-nav surfacing follows the capability
-(ADR-0029 K2); the object stays open"* — nav-entry tiering, not enforcement location. The
-rule these sites actually invoke is decided by the framework's **`ADR-0124 D1`**, *"The
-server is the enforcement point; client-side gating is a usability courtesy"* (Accepted
-2026-08-18). #5699 fixed the repo-ambiguity half of this defect — whose ADR numbering the
-citation meant — and deliberately left the anchor half; this is that half.
-
-The new anchor is derived from an authority, not chosen: the framework's own ADR-0057
-carries a note aimed at precisely this citation — *"If a citation of `ADR-0057 D10`
-brought you here looking for that rule, ADR-0124 is where it is decided."* The substantive
-claim at every site is unchanged; only the anchor moves.
-
-The disambiguating parenthetical #5699 shipped — *"framework numbering; this repo's own
-ADR-0057 is an unrelated document"* — is retired along with the number it disambiguated.
-It warned about a collision specific to `0057`; this repository has no ADR-0124 at all
-(its own series stops at `0059`), and ADR-0124 records that a fresh, unambiguous number
-was chosen so that citations of it would not need such a warning. The `the framework's …`
-possessive stays at every site, so each one still says whose numbering it means.
-
-Left byte-untouched, deliberately: `packages/data-objectstack/src/appAccessProbe.test.ts`
-cites the same decision for *"an app gated by an absent optional service"* — the
-capability/service-gating family that decision genuinely does decide, so it is correct as
-it stands. `docs/adr/0036-field-conditional-rules.md`, the wording all eight derive from,
-carries the same misattribution and moves in its own PR: `docs/adr/**` is a governed
-surface that stops at draft for human merge.
diff --git a/.changeset/record-activity-open-vocabulary-fallback.md b/.changeset/record-activity-open-vocabulary-fallback.md
deleted file mode 100644
index f1e300a948..0000000000
--- a/.changeset/record-activity-open-vocabulary-fallback.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-'@object-ui/plugin-detail': patch
----
-
-`record:activity` renders an author-extended `sys_activity.type` instead of dropping it
-
-**Behaviour change.** `activityRowToFeedItem` used to return `null` for any
-`sys_activity.type` outside `ACTIVITY_TYPE_TO_FEED_TYPE`: the row was stored,
-queryable and invisible, with only a console warning to say so. It now renders
-through a defined fallback presentation (`UNMAPPED_ACTIVITY_FEED_TYPE`, the
-generic `system` feed type), still announced once per distinct type.
-
-This follows the maintainer ruling of 2026-08-24 on objectstack#11507,
-direction 4: `sys_activity.type` is **author-extensible**. Every field on
-`sys_activity` is `readonly: true` and objectql's `validateRecord` skips
-readonly fields on both write branches, and ADR-0052 §5b.2 forwards an author's
-`activityMilestones[].type` into the column verbatim — so a value the platform
-never declared is legitimate stored data, not a mistake, and dropping it
-reproduces the objectui#5840 failure for every author who writes one.
-
-The types this map deliberately excludes (`commented` / `mentioned` / `login` /
-`logout` → `undefined`) are unchanged: those are decisions, not gaps, and they
-still return `null` silently. `ACTIVITY_TYPE_TO_FEED_TYPE` itself is unchanged,
-so the copy `RecordDetailView` reads is unaffected.
-
-The pin that goes with it replaces the set-equality check objectui#5840 removed,
-and is deliberately two-directional: the map must cover every **built-in** type
-(superset — a new built-in turns it red), and an unknown type must reach the
-feed through the fallback (never dropped, never crashing). Set equality is not
-asserted in either spelling, and the docblock says so, because pinning to the
-closed declaration is what made #5840 drop stored rows.
diff --git a/.changeset/record-activity-scheduled-event-5840.md b/.changeset/record-activity-scheduled-event-5840.md
deleted file mode 100644
index 011e1447b6..0000000000
--- a/.changeset/record-activity-scheduled-event-5840.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-"@object-ui/plugin-detail": patch
----
-
-`record:activity` no longer discards scheduled activities. `sys_activity` rows with
-`type: "scheduled"` now map to the `event` feed kind instead of being dropped before any
-filter runs, so a not-yet-held meeting reaches the timeline and `types: ['event']` stops
-being a permanently empty tab. Held meetings are unchanged: `completed` still maps to
-`task` and still hides unless `showCompleted` is set, which is what keeps an upcoming
-meeting visible by default while a finished one is not.
-
-The unknown-type default is unchanged and deliberately so — a row whose type nothing maps
-is still dropped rather than bucketed into `system`, because rendering an unmeasured kind
-as something it is not would be new wrong data rather than recovered data. What changes is
-that the drop is no longer silent: an unmapped type now logs one `console.warn` naming it,
-once per type. Types the map knows and deliberately excludes (`commented`, `mentioned`,
-`login`, `logout`) stay silent, since those are decisions rather than gaps.
diff --git a/.changeset/record-activity-types-filter-never-widens-5841.md b/.changeset/record-activity-types-filter-never-widens-5841.md
deleted file mode 100644
index 94250820b8..0000000000
--- a/.changeset/record-activity-types-filter-never-widens-5841.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-"@object-ui/plugin-detail": patch
----
-
-`record:activity` no longer widens when its `types` filter cannot be honoured. An
-unrecognised or empty kind list used to sanitise to `undefined`, which the filter
-pipeline reads as "no filter authored" — so three distinct authored intents collapsed
-into one rendering, and the widest one: a page that named the wrong kind was served
-every activity on the record, with no diagnostic anywhere at runtime. The principle now
-held is that a sanitiser may narrow an author's request or refuse it, but must never
-silently widen it; widening turns a typo into "show the user everything", which is the
-one outcome no author asked for, and it hides behind a plausible result — a populated
-timeline reads as working, an empty one gets investigated.
-
-**Behaviour change.** A page authoring `types: []`, or a `types` list whose every entry
-is unrecognised, now renders an EMPTY timeline where it previously rendered every kind.
-That is the fix rather than a regression, but a page relying on the old fallback will
-visibly change: `types: []` is honoured as "no kinds", and a list that keeps nothing
-filters to nothing. A mixed list keeps its recognised entries and drops the rest. Omitting
-`types` is unchanged and remains the only way to say "no filter". A `types` that is not a
-list at all (`types: 'comment'` — brackets dropped) is likewise refused rather than
-ignored, since a filter that cannot be read is not a request to remove the filter.
-
-Unrecognised entries are now named out loud: one `console.warn` listing them and the
-declared feed item types, deduped so one bad kind warns once however many times the feed
-re-renders, matching the unknown-activity-type diagnostic already in this file. A
-well-formed filter stays silent, `types: []` included — there is nothing to report about
-a request that was carried out exactly.
diff --git a/.changeset/record-alert-cta-label-i18n-4998.md b/.changeset/record-alert-cta-label-i18n-4998.md
deleted file mode 100644
index c42fa2e98f..0000000000
--- a/.changeset/record-alert-cta-label-i18n-4998.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-'@object-ui/plugin-detail': patch
----
-
-`record:alert`'s renderer-local `RecordAlertProps` CTA slot (`action.label`) is
-widened to `string | I18nLabel` in both copies (`properties.*` and the flat
-compat mirror) in `packages/plugin-detail/src/renderers/record-alert.tsx`.
-
-The renderer already resolves `action.label` through the same inline-locale-map
-`pickLocalized` call as `title` / `body` (`const ctaLabel =
-pickLocalized(props.action?.label, language)`), so a bare `string` declaration
-was narrower than the renderer's own runtime behavior — the same
-declaration-narrower-than-the-renderer contradiction objectui#4970 fixed for
-`title` / `body` one level up in the same interface (objectui#4998).
-
-Type-only: the block's published authoring surface still declares `action` as
-a bare `object` with the member shape in prose only
-(`plugin-detail/src/index.tsx`), so there is no manifest arm to align yet —
-that half stays parked on the `ComponentInput` member-shape question (PR
-#3795) and is out of scope here.
diff --git a/.changeset/record-alert-loading-frame-diagnostic-5776.md b/.changeset/record-alert-loading-frame-diagnostic-5776.md
deleted file mode 100644
index e6b72b9772..0000000000
--- a/.changeset/record-alert-loading-frame-diagnostic-5776.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-'@object-ui/plugin-detail': patch
----
-
-`record:alert`'s `visible` predicate no longer logs a spurious `record is not
-defined` evaluation-failure warning during the record-detail loading frame.
-
-The predicate is evaluated on every render (Rules of Hooks), including the
-frame before `useRecordContext().data` has loaded. In that frame `record` is
-unset, `usePredicateRecordContext` binds an empty context bag by design (no
-`record` key at all), and a bare/`${…}` predicate referencing `record.*`
-faulted with `record is not defined` — logged via `console.warn` on every
-page load, even the correct, working ones, because the SAME predicate
-resolved fine one frame later once `record` populated. The banner's own
-visibility was never wrong (it already hides unconditionally while unloaded);
-only the diagnostic was permanently misleading on the happy path.
-
-The predicate is now skipped while `record` hasn't loaded — the same
-condition the banner's own "hide while unloaded" early return already used —
-since its verdict in that frame was never consulted anyway. A predicate that
-is genuinely broken (bad field, bad syntax) still faults, and still logs, on
-every frame once `record` is populated (objectui#5776).
diff --git a/.changeset/record-alert-row-binding-4807.md b/.changeset/record-alert-row-binding-4807.md
deleted file mode 100644
index ecca389daf..0000000000
--- a/.changeset/record-alert-row-binding-4807.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-'@object-ui/plugin-detail': minor
----
-
-`record:alert` binds the row through `usePredicateRecordContext`, so an
-author-declared `properties.visible` is actually consulted.
-
-`renderers/record-alert.tsx` was the last predicate face in the repo still
-handing `useCondition` a root-only `{ record }` bag. Every other row-scoped
-predicate — the four generic action renderers (objectui#4075) and app-shell's
-`DeclaredActionsBar` (objectui#4077) — binds the row through the shared
-`usePredicateRecordContext(record)` helper, which resolves the three spellings
-objectui#5330 ruled on: canonical `record.status`, the deprecated row-action
-shorthand `status`, and deprecated legacy `data.status`.
-
-Under the root-only bag only the canonical spelling worked, and the two others
-failed in **opposite** directions — both of them silently, because this call
-site is fail-soft:
-
-- **row-action shorthand** (`status == 'x'`) resolved nothing, so the evaluator
-  threw. The legacy `${…}` path answers a throw with its own source text, a
-  non-empty and therefore truthy string, so the verdict was **SHOWN on every
-  row**. A banner the author had gated was permanently on screen.
-- **legacy `data.*`** (`data.status == 'x'`) did not throw at all. App-shell's
-  ambient predicate scope (`providers/ExpressionProvider.tsx`) carries
-  `data: {}`, so the predicate read that object instead of the row, compared
-  `undefined`, and the verdict was a constant false — **never shown**.
-
-**Behaviour change, stated plainly:** a shipped `record:alert` whose `visible`
-was written in either deprecated spelling was inert and is now live. A banner
-that was permanently visible may begin to hide, and one that never appeared may
-begin to show — that is the point of the fix, but it is a verdict change rather
-than a no-op. Canonical `record.*` predicates are unaffected in verdict: they
-resolved before and resolve now, pinned on both polarities. An in-tree census
-found no `record:alert` `visible` predicate outside this package's own tests.
-
-A node-level `visibleWhen` is a separate gate one tier up in `SchemaRenderer`,
-with its own deliberate bindings (`data` is the data-source adapter there, not
-the row). This change does not touch it; the two still compose as AND.
-
-The renderer's header comment described the shared-scope behaviour it did not
-have. It now describes what the file does, including the fail-soft policy and
-the two-gate composition.
diff --git a/.changeset/record-detail-param-dialog-title-5610.md b/.changeset/record-detail-param-dialog-title-5610.md
deleted file mode 100644
index f8c16e205f..0000000000
--- a/.changeset/record-detail-param-dialog-title-5610.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-`RecordDetailView`'s param-collection dialog now titles itself from `action.label`
-alone — the unreachable `|| action?.title` fallback beside it is removed
-(objectui#5610).
-
-This was the second copy of the limb objectui#4282 removed from
-`useConsoleActionRuntime`. `RecordDetailView` builds its own action runtime rather
-than routing through that hook, so the two near-identical `paramCollectionHandler`s
-have drifted as a pair and the first fix could not reach this one.
-
-`title` is declared on no action surface in the ecosystem: it is absent from
-`@objectstack/spec`'s `ActionSchema` (44 keys walked at spec 17.0.0), from
-`@object-ui/core`'s `ActionDef` and its pinned `ACTION_DEF_KEYS` / `SPEC_ACTION_KEYS`
-inventories, and from `@object-ui/types`' renderer view (`ui-action.ts`) and `crud.ts`
-`ActionSchema` / `BaseSchema`. None of the four action renderers — `action:button`,
-`action:icon`, `action:group`, `action:menu` — forwards it either. So the right-hand
-side of that `||` could not be reached by authored metadata: a fallback that cannot
-fire, which is the "declared is not enforced" shape objectstack#4075 exists to reduce.
-Nothing a user hits changes; the line now reads exactly one key, matching the
-`description` line directly below it.
-
-`RecordDetailView.paramDialogTitle.test.tsx` pins the reader so the alias cannot be
-reinstated silently: an action carrying `title` and no `label` must open an untitled
-dialog rather than a dialog named by a key no producer sets. A pin per reader is the
-only shape that covers both handlers, since the hook's own pin cannot see this site.
diff --git a/.changeset/record-picker-empty-text-i18n-5590.md b/.changeset/record-picker-empty-text-i18n-5590.md
deleted file mode 100644
index 8c53ac4a90..0000000000
--- a/.changeset/record-picker-empty-text-i18n-5590.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-'@object-ui/components': patch
----
-
-`element:record_picker`'s `emptyText` now resolves the inline per-locale map its
-contract has admitted since rc.6, and its published declaration says so
-(objectui#5590).
-
-`@objectstack/spec` widened this key to the `I18nLabel` union
-(`string | Record< string, string >`) at 17.0.0-rc.6, and the installed 17.0.0 GA
-still carries it — measured, not assumed:
-`ElementRecordPickerPropsSchema.safeParse({ object: 'account', emptyText: { en, 'zh-CN' } })`
-succeeds. The renderer honoured only the string arm, handing the map straight to a
-text node. React refuses a plain object in a child position rather than stringifying
-it, so an author writing the map form the contract accepts did not get a mis-rendered
-empty state — the whole picker subtree threw
-`Objects are not valid as a React child (found: object with keys {en, zh-CN})`.
-
-The read site now resolves through `pickLocalized`, the objectui-side helper the
-sibling text-node sites already read through (`element:text.content`,
-`element:button.label`, `page:card.title`), which spells a miss as `''` rather than
-the spec resolver's `undefined`. The default is applied before resolution, so
-`emptyText` absent still means "No records" and an authored empty string still
-renders empty.
-
-The `ComponentMeta` entry, which held a single `'string'` arm precisely because the
-renderer dropped the other one, now declares `['string', 'object']`. That narrowing
-was correct for exactly as long as it was true: with the map arm reaching the screen
-resolved, withholding it would be the false declaration in the other direction — the
-manifest gate reporting `type-mismatch` on a legal write the same input's own
-`description` teaches the author to make. The `apps/console` specimen that pinned the
-narrow arm named this release condition in its own words ("keeps its single `'string'`
-arm until the render site catches up") and is flipped here, keeping its controls.
-
-Three comments in the renderer deferred this gap to objectui#4163, which closed as
-completed on 2026-08-15 while the gap was still open; the file now carries no
-reference to it. The `ComponentInput.type` doc in `@object-ui/types` cited this very
-key as its worked example of an arm deliberately withheld, and is corrected in the
-same change so the example stays true.
diff --git a/.changeset/record-picker-label-association-5771.md b/.changeset/record-picker-label-association-5771.md
deleted file mode 100644
index df693b93c5..0000000000
--- a/.changeset/record-picker-label-association-5771.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-'@object-ui/components': patch
----
-
-`element:record_picker`'s `label` is now programmatically associated with its
-`SelectTrigger` combobox — fixing a case where the caption the block's own
-registration prose advertised (`'Caption rendered above the picker, in a
-<label> element'`) named nothing at all (objectui#5771).
-
-Pre-fix, the render body was `{label && <label className="…">{label}</label>}`
-against a `SelectTrigger` with no `id`: neither end of the association carried
-any wiring. That is a step worse than the sibling gap objectui#5735 closed on
-`element:text_input` — there the `label` half was already correctly wired and
-only `description` was adrift; here the label element had no `htmlFor` and the
-trigger had no `id`, so the picker had no accessible name unless a
-`placeholder` happened to render text into the trigger's content.
-
-The fix follows the shape objectui#3341 already ruled on for the same defect
-class (`InlineCreateRelated`'s `<label>`/`<Input>` pair) and objectui#5735
-just landed on the complement block: `htmlFor`/`id` against the
-`SelectTrigger` — a `button` with `role="combobox"`, and therefore labelable,
-so no `aria-labelledby` is needed (Radix sets none on the trigger) — wired
-**when `schema.id` exists**, matching `element:text_input`'s precedent rather
-than an always-on `useId()` fallback. Only the author can supply `schema.id`,
-so a picker authored without one keeps its pre-fix, unassociated caption text
-exactly as before; nothing about this change mints an id the author did not
-provide. The `<label>` element itself is also swapped for the shared `Label`
-(`@radix-ui/react-label`) primitive `element:text_input` already uses for the
-same wiring, rather than a bare `<label>` with a `htmlFor` bolted on.
-
-The registration prose for `label` is corrected to describe what the code now
-does (tied to the control by `htmlFor` when the node carries an `id`) instead
-of a caption association the renderer never performed.
diff --git a/.changeset/record-picker-label-placeholder-i18n-5637.md b/.changeset/record-picker-label-placeholder-i18n-5637.md
deleted file mode 100644
index 58a25eaf35..0000000000
--- a/.changeset/record-picker-label-placeholder-i18n-5637.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-'@object-ui/components': patch
----
-
-`element:record_picker`'s `label` and `placeholder` now resolve the inline
-per-locale map their contract admits, and their published declarations say so
-(objectui#5637).
-
-These are the two remaining keys of the trio objectui#5590 fixed one of. All
-three members of `ElementRecordPickerPropsSchema` are the `I18nLabel` union
-(`string | Record< string, string >`) — measured on the installed
-`@objectstack/spec` 17.1.0 pin, where each resolves to
-`optional -> union -> string | record` and
-`safeParse({ object: 'account', <key>: { en, 'zh-CN' } })` succeeds. The
-renderer honoured only the string arm on both, and the two keys failed in two
-different ways:
-
-- `placeholder` was read raw and handed to `SelectValue`. React refuses a plain
-  object in that position rather than stringifying it, so the whole picker
-  subtree threw
-  `Objects are not valid as a React child (found: object with keys {en, zh-CN})`
-  — the same harm objectui#5590 removed from `emptyText`.
-- `label` went through the file's local `toText`, whose object branch ends
-  `String(o.label ?? o.name ?? o.title ?? o.en ?? '')`. Reaching `o.en`
-  unconditionally is an English pick wearing locale resolution's clothes, so a
-  `zh-CN` viewer was shown the English entry — and a map that simply omits `en`
-  resolved to `''`, which the `{label && …}` render site drops, making the
-  picker's label element DISAPPEAR with nothing thrown and nothing logged.
-
-Both keys now resolve at their own read site through `pickLocalized`, the same
-helper the settled `emptyText` shape uses. `toText` is deliberately unchanged:
-it is shared with the row values (`toText(row?.[labelField])`), which are record
-field values rather than `I18nLabel`, so teaching it locale resolution would
-have changed a second, unrelated call site. The `placeholder` default is applied
-before resolution, so an absent key still means "Select a record…" and an
-authored empty string still renders empty.
-
-The two `ComponentMeta` entries, which held a single `'string'` arm precisely
-because the renderer dropped the other one, now declare `['string', 'object']`
-— declared in the change that makes the arm render, never before, which is the
-order `ComponentInput.type` prescribes and the order `emptyText` set.
-
-KNOWN GAP, unchanged by this release: the sibling `label` read sites in
-`renderers/layout/containers.tsx` compose
-`translateLabel(pickLocalized(…), language)`, and that second helper is not
-applied here — `translateLabel` and its `KNOWN_LABEL_DICT` are module-private to
-that file. Only the locale-map resolution lands in this change; a plain-English
-string `label` is still rendered verbatim in every language, exactly as before.
diff --git a/.changeset/record-quick-actions-resultdialog-pin-5711.md b/.changeset/record-quick-actions-resultdialog-pin-5711.md
deleted file mode 100644
index 351cbd3b8a..0000000000
--- a/.changeset/record-quick-actions-resultdialog-pin-5711.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
----
-
-Test-only change — no published behaviour changes.
-
-Adds a component-level test pinning that a `record:quick_actions` action's
-declared `resultDialog` reaches the ambient `<ActionProvider>`'s shared
-`ActionRunner` and opens the reveal dialog with the response value (success
-toast suppressed), plus the negative leg — with no provider, the response is
-silently discarded and the documented `console.warn` fires. Closes the gap
-found while implementing objectstack#10681 (objectui#5711).
diff --git a/.changeset/record-title-drop-undeclared-objectdef-titlefield-6531.md b/.changeset/record-title-drop-undeclared-objectdef-titlefield-6531.md
deleted file mode 100644
index c9b1b8e39c..0000000000
--- a/.changeset/record-title-drop-undeclared-objectdef-titlefield-6531.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-'@object-ui/core': patch
----
-
-`getRecordDisplayName`: stop consulting the undeclared object-level
-`titleField`, restoring `nameField` as the top of the object ladder
-
-Step 0 of the unified record-title resolver read
-`options?.titleField ?? objectDef?.titleField`. The second leg ranked an
-object-level `titleField` above `nameField` — the pointer ADR-0079 Phase 2 made
-canonical — and above the deprecated `displayNameField` alias and the legacy
-`titleFormat` template.
-
-`@objectstack/spec`'s object schema does not declare that key, and it is not
-merely undeclared: the schema is a `strictObject`, so
-`ObjectSchema.safeParse({ …, titleField: 'x' })` fails with `unrecognized_keys`
-— the same code a nonsense key gets — while `nameField`, `displayNameField` and
-`titleFormat` all parse and survive. A producer census across both repos found
-nothing that puts the key on an object-shaped payload: not the metadata, not any
-`getObjectSchema` implementation (the ObjectStack adapter stamps only reference
-keys and field-widget hints), not the lookup-chip path, not the
-search-candidate path, and not the platform's own server-side resolver
-(`@objectstack/objectql#titleFieldOf` reads `nameField` → `displayNameField`).
-Reading a key no producer can ship is a consumer-side alias — the shape
-Commandment #0.1 bans — and it inverted the governed-authority default on top of
-that.
-
-No authoring surface changes and no view loses its author-chosen title field:
-`titleField` remains a real, declared VIEW key (`ui/CalendarConfig`,
-`ui/GalleryConfig`, `ui/GanttConfig`, `ui/ListMapConfig`,
-`ui/ObjectKanbanProps`, `ui/TimelineConfig`), views hand it in as
-`options.titleField`, and that half of step 0 still wins over everything.
-The behaviour change is confined to an object payload that carried a key the
-contract rejects: it now resolves through the declared ladder instead.
diff --git a/.changeset/reference-rail-entries-stale-prose.md b/.changeset/reference-rail-entries-stale-prose.md
deleted file mode 100644
index 560c79cef5..0000000000
--- a/.changeset/reference-rail-entries-stale-prose.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
----
-
-Test-only comment refresh in `registry-inputs-spec-parity.test.ts`: the
-`record:reference_rail.entries` exemption note no longer narrates the
-`ReferenceRailEntry` `icon` divergence as an open contract question (ruled
-Option B 2026-08-22, objectui#5494 landed the derivation from
-`@objectstack/spec/ui`), and drops the "the renderer reads it" premise that was
-false when written. The exemption itself is unchanged — `inputs` is a flat
-scalar carrier and still cannot express an array of objects. No published
-behaviour changes.
diff --git a/.changeset/reference-rail-entry-spec-derived.md b/.changeset/reference-rail-entry-spec-derived.md
deleted file mode 100644
index fd9b93bab6..0000000000
--- a/.changeset/reference-rail-entry-spec-derived.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-"@object-ui/plugin-detail": minor
----
-
-**`ReferenceRailEntry` is now the spec's type, and the reference-rail `icon` key retires** (objectui#5494, maintainer ruling 2026-08-22).
-
-`ReferenceRailEntry` is owned by `@objectstack/spec` as of 17.1.0. The hand-written interface in `record-reference-rail.tsx` is replaced by a re-export of the spec's `ReferenceRailEntry` (derived from `ReferenceRailEntrySchema`, `$strict` over `{ objectName, relationshipField, title?, limit?, displayField? }`), and `buildDefaultPageSchema` no longer emits `icon` on the reference-rail entries it synthesizes.
-
-**Migration — if you write `icon` on `record:reference_rail` entries, remove it.** Be aware of what this does and does not change:
-
-- **Runtime validation does not move.** The spec's strict schema already refused `icon` at save — that refusal is unchanged. What was broken was objectui's declaration: the TS type advertised a key that could never be saved.
-- **Nothing ever rendered `icon`.** No render path in `RecordReferenceRailRenderer` has ever read the key (measured back to the file's first commit, and independently by the spec's `ui-reference-rail-unknown-keys-refused` migration entry). An authored `icon` that survived in unsaved/preview metadata was already a silent no-op — after this change the TS type says so instead of suggesting otherwise.
-- **The published TS surface narrows.** Code that imported `ReferenceRailEntry` from `@object-ui/plugin-detail` internals and set `icon` will now get a type error. That error is the contract speaking: remove the key.
-
-The reference-rail icon affordance is retired rather than proposed upstream: a stock scan of this repo, its examples and schema-catalog corpus, and the objectstack tree (examples, templates, docs) found no reachable authored usage of `icon` on reference-rail entries. Stored customer metadata is not reachable from this seat and was not scanned.
diff --git a/.changeset/registerfunction-casefold-doc-5363.md b/.changeset/registerfunction-casefold-doc-5363.md
deleted file mode 100644
index def190682d..0000000000
--- a/.changeset/registerfunction-casefold-doc-5363.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-'@object-ui/core': patch
----
-
-`ExpressionEvaluator.registerFunction` now documents the case-fold it has always
-performed: the name is stored — and must be called — in UPPER CASE
-(objectui#5363).
-
-`registerFunction('formatCurrency', fn)` registers `FORMATCURRENCY`, because the
-method delegates to `FormulaFunctions.register`, which stores under
-`name.toUpperCase()`. That fold is correct for the spreadsheet-style built-in
-vocabulary (`SUM`, `IF`, `UPPER`) and is unchanged here — but nothing declared
-it on the public method, and two things keep it from being self-evident at the
-call site. The registry API stays case-insensitive, so `getFormulas().has()` and
-`.get()` both answer to the original spelling and never reveal the fold; only
-expressions see the stored key, because the evaluation scope is built from
-`FormulaFunctions.toObject()`, a plain object whose identifiers are matched
-case-sensitively. And a wrong-case call site does not raise: `evaluate()`
-catches, warns, and returns `defaultValue ?? expression`, so the template
-renders its own `${...}` source as literal text on screen rather than erroring.
-
-Behavior is untouched — this is the declaration catching up with what the code
-enforces. It ships as a patch rather than as an empty changeset because the
-JSDoc is emitted into the published `dist/evaluator/ExpressionEvaluator.d.ts`,
-so it is what consumers see on hover.
-
-`ExpressionEvaluator.test.ts` gains three cases pinning the half that was
-uncovered — that the given spelling does *not* resolve in an expression, that
-the failure renders the raw template source instead of throwing, and that the
-registry API stays case-insensitive underneath — so making registration
-case-preserving fails a test instead of silently invalidating the new JSDoc.
diff --git a/.changeset/release-lane-tests-and-concurrency-5404.md b/.changeset/release-lane-tests-and-concurrency-5404.md
deleted file mode 100644
index 31f50fe34e..0000000000
--- a/.changeset/release-lane-tests-and-concurrency-5404.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
----
-
-CI only — this publishes nothing, declared explicitly with an empty frontmatter rather
-than left undeclared.
-
-Two changes to `.github/workflows/changeset-release.yml`, the workflow whose last step
-publishes to npm.
-
-**The duplicate `pnpm test` is gone.** It re-tested a commit already on `main`, so it
-could never keep anything out — it could only stop the release afterwards, and it did:
-runs #3606 and #3901, 2 of the last 27 release-PR merges, failed there and skipped the
-changesets step entirely. It cost 31m19s of a 33m22s job (medians over the 106 runs of
-#3712-#3911 that executed; install 6s, build 35s, the changesets action 24s). The
-backstop for `main` is `ci.yml`'s push lane, which runs the whole suite under coverage
-across four shards and enforces the thresholds on the merged report.
-
-**The concurrency group is now keyed by commit rather than by branch.** A group shared by
-every push to `main` does not queue: GitHub holds one pending run per group and cancels
-the rest, so 93 of those same 200 runs were `cancelled` with an empty jobs array — not
-one step ever ran. On a workflow that publishes, a discarded run is a discarded publish.
-Ordering moves into a fail-open wait step that holds a run until every older release run
-has finished, so runs are still serialised, but a contended lane now delays a release
-instead of dropping it.
diff --git a/.changeset/remove-inert-showrefresh-5567.md b/.changeset/remove-inert-showrefresh-5567.md
deleted file mode 100644
index 017478cc2f..0000000000
--- a/.changeset/remove-inert-showrefresh-5567.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-'@object-ui/plugin-view': minor
-'@object-ui/app-shell': patch
----
-
-Remove the inert `showRefresh` designer input from the `object-view` registration (objectui#5567).
-
-The `object-view` designer no longer offers a "Show Refresh Button" toggle, and the registration no longer defaults `showRefresh: true`. The key was declared, documented, and defaulted, but `ObjectView` never read it — an author who wrote `showRefresh: false` on an `object-view` node always got a no-op. **Behaviour is unchanged for every existing app**, because nothing ever consumed the key.
-
-Migration: nothing to do. If you wrote `showRefresh` on an `object-view` node, the key simply disappears from the designer's property panel; it never controlled anything. The live refresh channel is `userActions.refresh` (rendered by the list toolbar in `@object-ui/plugin-list`), which is unaffected. `showRefresh` on other surfaces (e.g. `CRUDToolbar`) is also unaffected.
-
-`@object-ui/app-shell` only drops its two producer writes of the dead key (the app `ObjectView` wrapper and the metadata-admin `ViewPreview`) — no user-visible change.
diff --git a/.changeset/replay-dispatch-error-5695.md b/.changeset/replay-dispatch-error-5695.md
deleted file mode 100644
index 8c014116b1..0000000000
--- a/.changeset/replay-dispatch-error-5695.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-'@object-ui/plugin-chatbot': patch
-'@object-ui/app-shell': patch
----
-
-Confirm-replay dispatch errors (bare `{error: …}` envelopes) now resolve the 确认修改 card instead of leaving it on 应用中 forever: `detectReplayOutcome` classifies them as a provisional failure, and a later successful authoring result in the same turn (the model self-repairing, e.g. after an `object not found` on a blueprint-local name) supersedes it via `detectAuthoringVerdict` — so the card never says 未生效 over a change that actually landed. Real publish failures (`publishFailed` envelopes) are never superseded. Measured live on the local rig, 2026-08-24.
diff --git a/.changeset/report-view-datasource-object-key-5116.md b/.changeset/report-view-datasource-object-key-5116.md
deleted file mode 100644
index 2d3435113c..0000000000
--- a/.changeset/report-view-datasource-object-key-5116.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-'@object-ui/app-shell': minor
----
-
-`ReportView` reads a report's data binding through the one key the contract declares — `dataSource.object`.
-
-The view accepted `resource` as a second spelling of `object`, in two places, and
-named that spelling in a warning the user could read:
-
-```
-:171  liveReport?.objectName || liveReport?.dataSource?.object
-                             || liveReport?.dataSource?.resource
-:273  dataFetchSource.dataSource.object || dataFetchSource.dataSource.resource
-:275  console.warn('ReportView: dataSource missing object/resource property')
-```
-
-`resource` is not on this binding. `ElementDataSourceConfig` declares `object`,
-`view?`, `filter?`, `sort?` and `limit?`; its `@objectstack/spec` twin
-`ElementDataSourceSchema` is a strict object, so an extra `resource` key is
-*rejected* there rather than ignored; and the binding's own predicate
-`isElementDataSourceConfig` decides on `object`. A `resource`-only binding
-therefore was never a binding on any other renderer in the system — it rendered
-here and silently produced nothing anywhere else, with neither end reporting a
-problem. That divergence is what a consumer-side alias buys: one renderer
-answering a question the contract says has no answer.
-
-`resource` is a real key on other surfaces — `CRUDSchema.resource`, the
-`DataSource` adapter's first parameter, `LiveExportOptions.resource` — and all
-three are untouched. None of them is this one.
-
-Behaviour, measured by rendering each input shape before and after. Only the
-`resource`-only shape moves:
-
-| binding | before | after |
-| --- | --- | --- |
-| `object` only | queries that object | unchanged |
-| `resource` only | queries it as if declared | not queried; named warning, no rows, fallback field list |
-| both | queries `object` | unchanged |
-| neither | not queried; warning | unchanged |
-
-So off-spec report metadata that used to render now fails loudly instead of
-appearing to work. A producer census found nothing that would notice: no site in
-this repository, and none in the `objectstack` framework repository, writes
-`resource` onto a report `dataSource`. The limb was speculative in the commit
-that introduced it, and per AGENTS.md #0.1 an off-spec spelling is corrected at
-the producer, never taught a second dialect by the renderer.
-
-The `:275` wording now names only `object`. A diagnostic that lists a key the
-contract does not declare is not a small thing: it is the system telling an
-author — increasingly, an author's code generator — that the wrong spelling is
-supported.
diff --git a/.changeset/retire-codecov-upload-5436.md b/.changeset/retire-codecov-upload-5436.md
deleted file mode 100644
index 66b7492a39..0000000000
--- a/.changeset/retire-codecov-upload-5436.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
----
-
-CI only — this publishes nothing, declared explicitly with an empty frontmatter rather
-than left undeclared.
-
-`ci.yml`'s `Test (coverage)` job no longer uploads to Codecov. `CODECOV_TOKEN` was never
-set on this repository and Codecov no longer accepts tokenless uploads, so the step failed
-server-side (`Token length: 0`) on every push after objectui#5403 landed — a permanently
-red lane that trains everyone to ignore red. Per the maintainer ruling of 2026-08-22
-(Option B), the upload is retired rather than the secret set: the merged report is now
-published as the `coverage-report` build artifact (7 days, matching the shard blobs it is
-derived from) alongside the existing step summary.
-
-The coverage GATE is untouched and was never Codecov's: the configured
-`coverage.thresholds` are enforced by the merge step over the whole merged map, and the
-shard legs still override them to zero so that merge step remains the only place the gate
-runs. objectui#5403's loud verdict step is carried forward rather than deleted — it now
-reports `shards=… blobs=… merge=… report=…` and is green only when all four shards passed,
-all four blobs arrived, they merged, the thresholds were enforced over the result, and the
-report was published. A threshold breach is annotated separately from a lane that never
-delivered, because the two call for opposite actions.
-
-What is given up is the Codecov trend dashboard and its PR coverage comments.
diff --git a/.changeset/retire-components-action-param-dialog-5685.md b/.changeset/retire-components-action-param-dialog-5685.md
deleted file mode 100644
index 803fed5351..0000000000
--- a/.changeset/retire-components-action-param-dialog-5685.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-'@object-ui/components': minor
----
-
-Retire `ActionParamDialog`: the `custom` barrel's second action-param dialog is
-removed, and the app-shell dialog is recorded as the surviving implementation
-(objectui#5685, maintainer ruling of 2026-08-22).
-
-**Breaking for any out-of-repo host that imported it** (declared `minor` per the
-repo's version-alignment rule — the major tracks `@objectstack`, never an
-API-break count): `@object-ui/components` no longer exports `ActionParamDialog`
-or `ActionParamDialogProps`. Measured at the branch point, the export had zero
-production consumers — its only in-repo importers were its own five test files,
-which retire with it, and no other repository in the organization imports the
-symbol from this package.
-
-This file was the repo's SECOND implementation of the action-param surface, and
-its audit trail is the reason it retires instead of being maintained: the last
-close look (objectui#4758) found per-option `visibleWhen` not evaluated at all,
-and the five hardcoded English strings this card originally recorded were the
-next drift installment. A dormant second dialect of a governed surface is one
-production import away from being live; removing it removes the whole drift
-class.
-
-FROM → TO for an out-of-repo host:
-
-- `import { ActionParamDialog } from '@object-ui/components'` — no drop-in
-  replacement is published. The surviving implementation is
-  `@object-ui/app-shell`'s `ActionParamDialog` (`src/views/ActionParamDialog.tsx`),
-  rendered by app-shell's action runtime (`useConsoleActionRuntime`,
-  `RecordDetailView`) rather than exported standalone. A host that needs its own
-  param form builds on `@object-ui/fields`' shared field widgets
-  (`resolveFormWidgetType` / `getLazyFieldWidget`, ADR-0059) — the same seam the
-  surviving dialog renders through.
-
-The unreleased objectui#4758 changeset for this component (`select` options
-through the shared option evaluator) is withdrawn in the same change: the
-component retires before that fix ever ships, so the release notes carry the
-removal rather than new behaviour of a surface this release does not contain.
diff --git a/.changeset/retire-theme-component-schema-5489.md b/.changeset/retire-theme-component-schema-5489.md
deleted file mode 100644
index 121ce3a106..0000000000
--- a/.changeset/retire-theme-component-schema-5489.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-'@object-ui/types': minor
----
-
-Retire `ThemeComponentSchema` (`type: 'theme'`) — a component kind no renderer
-implemented (objectui#5489).
-
-`packages/types/src/theme.ts` declared a theme-manager **component** carrying
-`themes[]`, `activeTheme`, `allowSwitching`, `persistPreference` and
-`storageKey`, and `packages/types/src/zod/theme.zod.ts` published the matching
-Zod object as a member of `ThemeUnionSchema` and therefore of
-`AnyComponentSchema`. Nothing rendered it: `'theme'` appears at no
-`ComponentRegistry.register(...)` / `registerLazy(...)` site in `packages/*/src`,
-and in neither `PROTOCOL_COMPONENTS` nor `PALETTE_PLACEHOLDER_BLOCKS`
-(`packages/components/src/renderers/placeholders.tsx`), so it did not even
-resolve to a placeholder — a page declaring one got the registry's "Unknown
-component type" panel (OBJUI-001) instead of a theme manager. Declared-but-
-unenforced, removed under the maintainer ruling of 2026-08-21 on
-objectstack#10485 (option B).
-
-Removed from the published surface: the `ThemeComponentSchema` type
-(`@object-ui/types`), the `ThemeComponentSchema` Zod object
-(`@object-ui/types/zod`), the `ThemeComponentSchemaType` inference alias, and the
-`'theme'` member of `ThemeUnionSchema` / `AnyComponentSchema`. A schema spelling
-`type: 'theme'` is now REFUSED by `AnyComponentSchema.safeParse` rather than
-accepted and then rendered as an error panel, which is pinned by a test.
-
-**The theme system is unchanged.** `Theme` (the spec's authoring theme
-document), `ThemeDefinitionSchema`, `ThemeModeSchema`, `ThemeEngine`
-(`@object-ui/core`) and `ThemeProvider` (`@object-ui/react`) are all retained and
-untouched — the same ruling retains them explicitly. Author a theme as a
-document handed to `ThemeProvider`; that path never went through the removed
-component kind.
diff --git a/.changeset/retire-theme-switcher-preview-5647.md b/.changeset/retire-theme-switcher-preview-5647.md
deleted file mode 100644
index 29633b09ba..0000000000
--- a/.changeset/retire-theme-switcher-preview-5647.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-'@object-ui/types': minor
----
-
-Retire `ThemeSwitcherSchema` (`type: 'theme-switcher'`) and
-`ThemePreviewSchema` (`type: 'theme-preview'`) — the two remaining theme
-component kinds, which no renderer implemented — together with
-`ThemeUnionSchema`, the union that after objectui#5489 held only these two
-members (objectui#5647).
-
-`packages/types/src/theme.ts` declared a theme-switcher control (`variant`,
-`showMode`, `showThemes`, `lightIcon`, `darkIcon`) and a theme-preview panel
-(`showColors`, `showTypography`, `showComponents`), and
-`packages/types/src/zod/theme.zod.ts` published the matching Zod objects as
-the two members of `ThemeUnionSchema` and therefore of `AnyComponentSchema`.
-Nothing rendered either: neither literal appears at any
-`ComponentRegistry.register(...)` / `registerLazy(...)` site in
-`packages/*/src` (202 registered keys enumerated; positive control on the same
-pipeline: `tooltip` → 1), nor in `PROTOCOL_COMPONENTS` /
-`PALETTE_PLACEHOLDER_BLOCKS`
-(`packages/components/src/renderers/placeholders.tsx`), and no fixture
-declares either kind (control: `"type": "form"` → 81) — so a page declaring
-one got the registry's "Unknown component type" panel (OBJUI-001), never a
-switcher or a preview. Declared-but-unenforced, removed under the 2026-08-21
-maintainer ruling (option B) on objectstack#10485, extended to these siblings
-by inheritance on identical evidence (objectui#5647).
-
-Removed from the published surface: the `ThemeSwitcherSchema` /
-`ThemePreviewSchema` types (`@object-ui/types`), the matching Zod objects and
-`ThemeUnionSchema` (`@object-ui/types/zod`), and the `ThemeSwitcherSchemaType`
-/ `ThemePreviewSchemaType` inference aliases. `zod/theme.zod.ts` now exports
-nothing and stands as the tombstone module. A schema spelling
-`type: 'theme-switcher'` or `type: 'theme-preview'` is now REFUSED by
-`AnyComponentSchema.safeParse` rather than accepted and then rendered as an
-error panel, which is pinned by a test.
-
-**The theme system is unchanged.** `Theme` (the theme document vocabulary,
-owned by `@object-ui/types` since objectui#5716), `ThemeEngine`
-(`@object-ui/core`) and `ThemeProvider` (`@object-ui/react`) are retained and
-untouched — the rulings retain them explicitly. Author a theme as a document
-handed to `ThemeProvider`; that path never went through the removed component
-kinds.
diff --git a/.changeset/retire-usebranding-hook-5368.md b/.changeset/retire-usebranding-hook-5368.md
deleted file mode 100644
index bf5f6e24d2..0000000000
--- a/.changeset/retire-usebranding-hook-5368.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
----
-
-Delete `apps/console/src/hooks/useBranding.ts`, a `@deprecated` wrapper with zero callers.
-
-Nothing published changes. The console's npm tarball ships only `dist`, `plugin.*` and
-`README.md` (`files` in `apps/console/package.json`) — `src` is never in it — and the
-package's single `exports` entry resolves to `plugin.js`, which is compiled from
-`plugin.ts` alone and imports nothing from `src`. With no importer anywhere in the repo,
-the hook was also absent from the built SPA bundle. Empty frontmatter is therefore the
-accurate declaration: a source deletion under a released package that releases nothing.
diff --git a/.changeset/retired-field-type-gate-4914.md b/.changeset/retired-field-type-gate-4914.md
deleted file mode 100644
index ca91ef84fd..0000000000
--- a/.changeset/retired-field-type-gate-4914.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-'@object-ui/core': patch
-'@object-ui/fields': patch
-'@object-ui/components': patch
-'@object-ui/plugin-detail': patch
-'@object-ui/plugin-view': patch
-'@object-ui/plugin-dashboard': patch
-'@object-ui/plugin-list': patch
----
-
-A RETIRED field-type spelling is now refused — out loud, once — by every
-field-type predicate in the renderer, not just by the widget road
-(objectui#4914, maintainer ruling B of 2026-08-18).
-
-`@object-ui/fields` exports a single `isRetiredFieldType(t)` gate, and it runs
-ahead of six predicate faces that previously granted a retired spelling
-first-class treatment: the filter builder's operator buckets and its value
-control (`@object-ui/components`), the detail page's highlight-strip picker
-(`@object-ui/plugin-detail`), `normalizeFieldType` (`@object-ui/plugin-view`),
-the dashboard's `$expand` whitelist and `isLookupType`
-(`@object-ui/plugin-dashboard`), and the list toolbar's lookup-like filter
-control (`@object-ui/plugin-list`). Each one now fires the migration
-prescription on the console — once per spelling across all of them, never once
-per predicate — and then answers as it would for a spelling it does not
-recognise.
-
-This closes the whole CLASS rather than one word: the gate is quantified over
-`RETIRED_FIELD_TYPES`, so the next retirement covers all seven consumers on the
-day it lands. It is the shape objectui#4932 and objectui#4942 already
-established for the form and inline-edit roads.
-
-Measured before the change, and the reason the fix is a gate rather than a
-deletion: `owner` was not dead in these faces. `operatorsForFieldType('owner')`
-equalled the `user` bucket item for item, `computeLookupExpand` actively
-requested `$expand` for it, `isLookupType('owner')` was `true` alongside
-`reference`, and `normalizeFieldType('owner')` answered `'select'` exactly as
-`picklist` does. Deleting the members alone would have traded a visible
-contradiction for a SILENT degradation — a filter picker collapsing to a bare id
-box, `$expand` quietly stopping so cells show raw foreign-key ids — which is
-verbatim the failure mode `RETIRED_FIELD_TYPES`' own docblock exists to prevent.
-The gate keeps that fallback and adds the half that was missing: the author is
-told.
-
-The boundary question is answered on record: `owner` arriving through a
-backend-vocabulary normalizer is an authoring error to refuse loudly, not
-legitimate foreign input to tolerate. The open backend vocabulary those
-normalizers exist for is untouched — `reference`, `picklist`, `money`, `int`,
-`datetime_tz` and the rest are equally absent from the spec's closed `FieldType`
-and are equally unretired, so they classify exactly as before.
-
-`RETIRED_FIELD_TYPES`, `reportRetiredFieldType` and `resetRetiredFieldTypeReports`
-move to `@object-ui/core` and are re-exported from `@object-ui/fields`, so that
-package's published surface is unchanged apart from the newly ruled gate.
-`@object-ui/components` is a consumer of the gate and `@object-ui/fields`
-depends on it, so a single shared table could not live in `fields` — and a
-second copy would have meant a second dedupe set and two console lines for one
-spelling. No package gained a new dependency.
-
-A retired spelling never loses a stored value: `retypeFilterValue` is
-deliberately not gated, and the refused filter row stays operable rather than
-drawing a blank operator trigger.
diff --git a/.changeset/retired-lucide-spellings-5622.md b/.changeset/retired-lucide-spellings-5622.md
deleted file mode 100644
index aa246fa963..0000000000
--- a/.changeset/retired-lucide-spellings-5622.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-'@object-ui/plugin-detail': patch
-'@object-ui/components': patch
-'@object-ui/plugin-list': patch
----
-
-Repair five retired lucide icon spellings that reach a record-reading resolver, and pin
-the names against the runtime `icons` record so the next lucide bump goes red instead of
-silently blanking a glyph (objectui#5622).
-
-lucide retires a spelling by dropping it from its runtime `icons` record while KEEPING it
-as a deprecated named export. A retired name therefore still imports, still type-checks,
-and still renders wherever it is used as a COMPONENT — and resolves to `null` wherever it
-is used as a STRING, because every string lookup here reads that record. Nothing goes red
-either way. Measured against the installed `lucide-react@1.31.0` (1767 record entries) at
-implementation time.
-
-What a user sees change:
-
-- `DetailView`'s mobile Edit action (`icon: 'edit'` → `'square-pen'`) draws its icon
-  again. Its items become an `action:bar` schema whose renderers resolve `icon` through
-  `renderers/action/resolve-icon.ts`, so the touch-breakpoint edit affordance had been
-  drawing a label with nothing beside it. `Edit === SquarePen`, so the glyph is unchanged.
-- The `ui:icon` renderer's own declared default (`'smile'` → `'face-slightly-smiling'`, in
-  both the registration `icon` and the `name` input's `defaultValue`) resolves again: the
-  designer palette entry's glyph was blank, and an `icon` dropped from that palette
-  rendered nothing plus a `console.warn`. `Smile === FaceSlightlySmiling`, so the palette
-  looks exactly as it did.
-- `plugin-list`'s `ViewSwitcher` moves `Grid` → `Grid3x3`, `BarChart3` → `ChartColumn`
-  (both identical objects, no visual change) and `GanttChartSquare` → `ChartGantt`. The
-  gantt one IS a glyph change: it matches the spelling the sibling `plugin-view` switcher
-  landed in objectui#5586, so one view type no longer draws two different icons depending
-  on which switcher is on screen.
-
-Four resolvability pins are added — in `plugin-detail`, `plugin-list`, `components` and
-alongside the `DeclaredActionsBar` fixtures. Each asserts `icons`-record MEMBERSHIP rather
-than resolvability, because every retired spelling repaired here is the SAME component
-object as its replacement (`Edit === SquarePen`, `Smile === FaceSlightlySmiling`,
-`Grid === Grid3x3`, `BarChart3 === ChartColumn`, `CheckCircle === CircleCheckBig`,
-`XCircle === CircleX` are all true): a pin that rendered the glyph, or reached for the
-export, would pass on the broken name. That is the blindness that let this ship.
diff --git a/.changeset/richtext-cell-renderer-5452.md b/.changeset/richtext-cell-renderer-5452.md
deleted file mode 100644
index 8b1448c2dc..0000000000
--- a/.changeset/richtext-cell-renderer-5452.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-"@object-ui/fields": patch
----
-
-A populated `richtext` field no longer renders as a blank cell (objectui#5452).
-
-`richtext` stores HTML — the spec documents the type as "Formatted content with
-HTML/WYSIWYG", the showcase seed's own specimen is `<p>Rich <strong>text</strong></p>`,
-and this repo's designer bridge already maps `richtext` onto its `html` type. The
-display registry nevertheless dispatched it to `MarkdownCellRenderer`, whose
-sanitizing GFM pipeline runs react-markdown with no `rehype-raw` and therefore drops
-raw HTML. Because a richtext value is *entirely* HTML, everything was dropped and the
-cell body came out empty — with no error, no fallback and no console warning, so a
-populated field read as an empty field and anyone auditing data through a grid
-concluded the records were blank. Measured on the same stored bytes, a neighbouring
-`html`-typed column rendered them correctly, which is what ruled out "the value never
-arrived".
-
-`richtext` now resolves to `HtmlCellRenderer`, which sanitizes with `sanitizeHtml`
-(script/style/iframe/object/embed blocks, inline event handlers and `javascript:`
-URLs removed) and keeps everything a rich-text editor legitimately emits — headings,
-paragraphs, emphasis, lists, links, quotes. One map entry fixes every read surface at
-once: the grid, the kanban card, the gallery, the related list, the dashboard record
-panel and the record detail page all resolve their read-mode cells through this same
-`getCellRenderer`.
-
-The markdown pipeline is untouched. Passing raw HTML through it would have "fixed"
-one type by moving every `markdown` cell's trust boundary, so `markdown` still drops
-raw HTML — pinned alongside the fix, on the same bytes `richtext` must now render.
diff --git a/.changeset/rotten-pugs-invent.md b/.changeset/rotten-pugs-invent.md
deleted file mode 100644
index 752b948778..0000000000
--- a/.changeset/rotten-pugs-invent.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-Page-block canvas: draw the real icon and colour tone for block types that render fine but are not offered in the palette.
-
-The canvas read its per-node icon and tone from `BLOCK_TYPE_META`, which is the palette's *offer* list ("what may an author drag in") — while the canvas is answering a different question ("what may an author already have in this page"). The two diverge for an alias pair: `record:discussion` and `record:chatter` are one renderer under two names, so exactly one spelling is always unoffered, and a page carrying it showed a plain unknown-block box and neutral grey instead of the message icon and the blue record tone its twin gets.
-
-`block-types.ts` now declares `BLOCK_RENDERER_ALIAS_GROUPS` — spellings that resolve to the same registered renderer — and the canvas resolves display chrome through `resolveBlockDisplayMeta()`, which falls back to an alias sibling's entry. Keyed on renderer identity, not on "is excluded": palette exclusions that genuinely are not page blocks (`element:text_input`, `element:record_picker`, `element:form`, `ai:chat_window`) keep the generic box, and nothing became draggable — the palette offer list is unchanged.
diff --git a/.changeset/row-predicate-record-canon-5330.md b/.changeset/row-predicate-record-canon-5330.md
deleted file mode 100644
index cfd76abde8..0000000000
--- a/.changeset/row-predicate-record-canon-5330.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-'@object-ui/core': minor
-'@object-ui/react': minor
----
-
-Row predicates declare a canon: `record.*`. The bare shorthand and `data.*` now
-warn once, and are unchanged otherwise.
-
-A row predicate (`visible` / `disabled` / `enabled` on an action renderer, a row
-scope, a `record:alert`) has bound the row three ways since objectui#4075 —
-`record.status`, bare `status`, and `data.status` — without any of them being
-declared the contract. The maintainer ruled that question on 2026-08-20
-(objectui#5330, option B), mirroring the objectstack#7917 option-② precedent for
-the identical renderer-tolerance shape: **the canon is `record.*`**, and the
-other two enter a deprecation window.
-
-The canon states the **server's** accept set, which was this card's first
-measurement and turns out to be strictly narrower than the renderer's. Measured
-against `@objectstack/formula@17.1.0`, the engine the server evaluates with:
-
-| spelling | server runtime | server authoring oracle |
-|---|---|---|
-| `record.status` | `{ ok: true, value: true }` | accepted |
-| bare `status` | `Unknown variable: status` | refused |
-| `data.status` | `Unknown variable: data` | **silently accepted** |
-
-`buildScope({ record })` mounts exactly `['record']` — `data` is never bound and
-the row's fields are never flattened to top level. The three-way binding is a
-client tolerance with no server counterpart, which is why the warning belongs on
-this side.
-
-`data.*` is the dangerous one, and the reason the warning exists. `data` is in
-`@objectstack/formula`'s `SCOPE_ROOTS`, so the server's bare-identifier oracle
-waves it through — that list is a deliberately generous "never faults" lint
-baseline, not the runtime accept set. A `data.*` row predicate therefore passes
-every authoring gate the platform has and then binds nothing at runtime: not an
-error, a constant `false`. A `visible` that is constantly false is a button that
-silently never appears — the objectui#4075 fail-closed signature.
-
-What ships:
-
-- `@object-ui/core` exports `detectNonCanonicalRowSpelling`,
-  `warnNonCanonicalRowSpelling`, `resetRowPredicateCanonWarnings` and
-  `ROW_PREDICATE_CANONICAL_ROOT` from a new `evaluator/rowPredicateCanon.ts`,
-  which carries the canon statement and the measurement.
-- Both evaluation tiers report once, in dev: `evalRowPredicate` (core) and
-  `useCondition` (react, for bags bound by `usePredicateRecordContext`).
-- Detection reuses the server's own oracles (`collectCelRootIdentifiers`,
-  `firstUndeclaredReference`) rather than a regex, so no second dialect
-  judgement is invented client-side.
-
-**No spelling is removed and no behaviour changes.** Every predicate that
-resolved before resolves now — the ruling defers removal behind a stored-metadata
-survey, and the warning is what makes that survey possible (ADR-0078: a
-tolerance nothing ever reports can never be retired).
-
-The deprecation is scoped to the **runtime record layer**. `data` remains the
-canonical root one layer over, in a metadata-editing form (ADR-0089 D3
-`CANONICAL_ROOT_BY_LAYER`), and the detector stands down there.
diff --git a/.changeset/rowcolor-prototype-guard-6295.md b/.changeset/rowcolor-prototype-guard-6295.md
deleted file mode 100644
index de76be8132..0000000000
--- a/.changeset/rowcolor-prototype-guard-6295.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-'@object-ui/plugin-grid': patch
----
-
-Guard `useRowColor`'s two object-literal lookups with `Object.prototype.hasOwnProperty.call`.
-
-Both `config.colors` (the authored map) and the module's `COLOR_TO_CLASS` literal inherit
-`Object.prototype`, and both were reached with a bare index. A record whose colour field
-held `constructor`, `toString`, `valueOf` or `hasOwnProperty` resolved to an inherited
-function: the `if (!color)` guard passed it (functions are truthy) and `colorToClass` then
-called `.startsWith` on it, throwing a `TypeError` inside the row-className resolver during
-render — a grid crash triggered by record data rather than by metadata. The same shape one
-call deeper in `colorToClass` did not throw; it handed an `Object.prototype` member back as
-the row's `className`, which reached React as a class attribute. Both now resolve to
-`undefined`, as an undeclared value always did.
diff --git a/.changeset/runtime-config-server-side-pointer.md b/.changeset/runtime-config-server-side-pointer.md
deleted file mode 100644
index 835e851994..0000000000
--- a/.changeset/runtime-config-server-side-pointer.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
----
-
-Comment-only change to `app-shell`'s `runtime-config.ts`: the "Server-side" pointer block
-now anchors on exported symbol + package (`RuntimeConfigPlugin` from
-`@objectstack/cloud-connection`, `RuntimeConfigPlugin` from `@objectstack/objectos-runtime`,
-`createStudioRuntimeConfigPlugin` from `@objectstack/service-cloud`) instead of file paths,
-two of which had gone stale. No published behaviour changes.
diff --git a/.changeset/safe-field-label-identity-5564.md b/.changeset/safe-field-label-identity-5564.md
deleted file mode 100644
index b7ae0e40f1..0000000000
--- a/.changeset/safe-field-label-identity-5564.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-'@object-ui/i18n': patch
----
-
-`useObjectLabel` now keeps a stable identity when no i18next instance is bound,
-so the memoization it advertises holds on the no-provider path too
-(objectui#5564).
-
-react-i18next's `useTranslation` builds its return value out of a fresh `{}` on
-every render when it has nothing to bind to (`const finalI18n = i18n || {}`,
-which then feeds that hook's own `useMemo` deps), so the `i18n` object arrived
-with a new identity each render. `useObjectLabel` keyed its memo on `[t, i18n]`,
-so the memo never held: measured 4 distinct returned objects across 4 renders
-with no instance, against 1 with one. That is the wrong way round — the memo
-exists to stop downstream `useMemo`/`useCallback` deps from being re-keyed in
-heavy consumers, and `useSafeFieldLabel`'s docstring names the no-provider case
-as the one it exists to serve.
-
-Both memo dependencies are now pinned to module-level constants while no
-instance is bound. The substitution is unobservable rather than merely
-convenient: every `t()` call in the module sits inside a
-`for (… of getAppNamespaces())` loop, and `getAppNamespaces()` returns `[]`
-under exactly the same "is there a usable instance" predicate — so while the
-substitution is in effect, the closures cannot read either value. When an
-instance appears the dependencies become the live values again, so a provider
-mounting after first render recomputes the object exactly once and resolves
-real translations from then on.
-
-No API change: no new exports, no signature changes, and the returned surface is
-identical on both paths. Direct `useObjectLabel()` consumers are fixed alongside
-`useSafeFieldLabel()` ones, including `ListView.filterFields` — the consumer the
-memo's own docstring names.
diff --git a/.changeset/schema-input-bridge-permanent-4622.md b/.changeset/schema-input-bridge-permanent-4622.md
deleted file mode 100644
index 4b78051281..0000000000
--- a/.changeset/schema-input-bridge-permanent-4622.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-'@object-ui/react': patch
----
-
-`toRenderableSchema`'s header now says the bridge is permanent, instead of instructing
-callers to remove it (objectui#4622).
-
-No executable line changes — but the artifact is **not** unchanged, and that is worth
-stating plainly rather than rounding to "comment-only". This package builds with plain
-`tsc`, and `tsconfig.base.json` sets `"removeComments": false` deliberately, so the JSDoc
-is emitted into `dist/schema-input.js` as well as `dist/schema-input.d.ts` — it is both
-what an editor shows on hover at every call site and bytes that ship.
-
-Measured by building the package the way the repo builds it, at both revisions:
-`dist/schema-input.js` grows from 1,486 to 2,377 bytes (1.45 KB to 2.32 KB), and from 850
-to 1,266 bytes gzipped (0.83 KB to 1.24 KB) — **+891 bytes raw, +416 gzipped**. All 19
-differing lines in the emitted file are JSDoc continuations and the three executable lines
-are byte-identical, so the growth is the paragraph and nothing else. The trade is
-deliberate: roughly 0.4 KB gzipped, against the five-hour `Build Docs` outage the old
-paragraph's instruction produced once already.
-
-The old closing paragraph said the two competing repo-wide `SchemaNode` spellings "have
-not been reconciled" and that "when it lands, the call sites using this can go back to
-forwarding directly". Both halves went false when PR #4608 merged, and the second half is
-the harmful one: it is an instruction whose trigger condition has now fired, sitting
-directly above the function a future author is about to call.
-
-The reconciliation (objectui#4580 / PR #4608) resolved the collision in favour of
-`@object-ui/types`' union — `@object-ui/core` now re-exports it rather than hand-declaring
-an interface — while `SchemaRenderer`'s prop stays deliberately narrow per objectui#4548
-ruling Q2 (`schema: BaseSchema | string | null | undefined`, no `number` / `boolean`). So
-a `SchemaNode` became *less* assignable to that prop, not more, and the bridge is a
-permanent crossing between two intentionally different types rather than scaffolding
-awaiting a merge.
-
-Following the old instruction has a measured cost: five `apps/site` call sites were
-forwarding directly when PR #4608 landed, and `Build Docs` was red on `main` for roughly
-five hours until PR #4621 routed all five through this function (objectui#4617).
diff --git a/.changeset/sdui-parser-inline-whitespace-5661.md b/.changeset/sdui-parser-inline-whitespace-5661.md
deleted file mode 100644
index 7affbea3dc..0000000000
--- a/.changeset/sdui-parser-inline-whitespace-5661.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-'@object-ui/sdui-parser': patch
----
-
-`kind:'html'` page sources keep the space between a text run and an adjacent
-inline element: `A <strong>x</strong> page` now compiles to `A `/`<strong>`/`
-page` and renders as `A x page` rather than `Axpage` (objectui#5661).
-
-The parser collapsed each text run's whitespace to a single space — correct, and
-what HTML itself does — and then `.trim()`ed it, which is not: HTML collapses a
-whitespace run to one space, it does not delete it. The deleted space was
-precisely the separator between a run and its inline sibling, so every authored
-sentence carrying emphasis or a link in the tier the guide recommends by default
-rendered with its words run together. It was silent: the page rendered, the
-structure was right, no diagnostic fired.
-
-The rule is deliberately mechanical rather than a block/inline taxonomy invented
-for a schema tree that has none: keep one leading space when a sibling precedes
-the run, and one trailing space when a sibling element follows it. The parent's
-own start and end still drop their edge space, so `<p>  hi  </p>` is unchanged.
-
-Its one bounded cost: a whitespace-only run BETWEEN two siblings survives as a
-single space, so a pretty-printed `<ul>` gains one `' '` string child per gap
-between its `<li>`s — one space per gap, never the source's newline and
-indentation, never at the container's own edges, and never inside an item's own
-text. That bound is pinned by a test rather than left as a claim.
diff --git a/.changeset/sdui-preview-page-source-tailwind-5470.md b/.changeset/sdui-preview-page-source-tailwind-5470.md
deleted file mode 100644
index f14b09da71..0000000000
--- a/.changeset/sdui-preview-page-source-tailwind-5470.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
----
-
-Publishes nothing — declared with an empty frontmatter rather than left undeclared.
-
-The changed files are `apps/console`'s three ADR-0080 browser preview harnesses
-(`src/sdui-*-preview.tsx`) plus a test. They are dev-server-only: `apps/console`'s
-vite config declares no `build.rollupOptions.input`, so the build's only entry is
-`index.html` (resolved config, measured: `input` unset) — the three
-`sdui-*-preview.html` entries and the modules behind them never enter `dist/`.
-`@object-ui/console`'s `files` omits `src`, and its `exports` map has exactly one
-entry (`.` → `./plugin.js`, built from `tsconfig.plugin.json` including
-`plugin.ts` alone, which imports nothing from `src/`). Nothing here reaches a
-consumer.
-
-Behind the change: page `source` is runtime metadata, and the console's Tailwind
-is compiled at build time by scanning the console's own `src` with no safelist, so
-a utility class authored in real page metadata produces no CSS and no error
-(ADR-0065; ADR-0080's 2026-06-30 amendment). `sdui-tiers-preview.tsx` — the
-harness making an explicit authoring claim — now styles with each tier's real
-primitive (the html tier with `<flex>`'s structured props plus JSON `style`
-objects, the react tier with inline `style` objects, colours as
-`hsl(var(--token))`), so it demonstrates what authors are told to write and now
-follows the theme in light and dark. The two renderer-plumbing harnesses keep
-their Tailwind and declare the exception in their headers; a test pins both
-halves against the shipped `page-source-className-tailwind` rule.
diff --git a/.changeset/secret-widget-spellings-5375.md b/.changeset/secret-widget-spellings-5375.md
deleted file mode 100644
index 2f405f2118..0000000000
--- a/.changeset/secret-widget-spellings-5375.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-'@object-ui/components': minor
-'@object-ui/core': minor
----
-
-Three more secret-field spellings no longer render a secret in clear text on the form's unregistered-widget branch.
-
-Measured on `main` at `f2e11ae6f`, the real `form` renderer on the built-in path
-(no `registerAllFields()`), before and after objectui#5322's fix:
-
-```
-type            registry hit   rendered type
-ui:password     true           text
-secret          false          text
-field:secret    false          text
-```
-
-Two halves, per the maintainer ruling of 2026-08-20:
-
-- **`@object-ui/core` — an unresolvable namespaced widget id is now an authoring
-  ERROR.** A form field's widget id (`widget`, else `type`) may name the
-  `field:` namespace or a bare name; any other namespace resolves no field
-  widget (objectui#5254) and used to degrade silently to a plain text box.
-  `validateSchema` now reports `UNRESOLVABLE_FIELD_WIDGET_NAMESPACE` and
-  `assertValidSchema` throws. Behaviour change: a schema that previously
-  validated with e.g. `type: 'ui:password'` is now invalid — inventing a
-  plausible-looking widget id fails loudly instead of rendering clear text.
-  `field:` ids stay valid whether or not the widget is registered, since
-  registration is a runtime fact an authoring-time validator cannot see.
-- **`@object-ui/components` — the known secret types cover the remaining
-  spellings.** Bare `secret` and `ui:password` render the native masked input,
-  and `field:secret` is refused outright like `field:password`. Existing authors
-  need no migration.
-
-`ui:password` **is** registered — as an SDUI node renderer for a top-level
-`{ type: 'email' }`-style node — so an author who checked whether it resolved
-got a yes and still got a clear-text box on the field path. No producer emits
-any of the three; all are reachable only through a hand-authored standalone
-form schema, which is exactly the surface where the author is the producer and
-no normalizer sits in between.
diff --git a/.changeset/self-import-gate-scan-once-5402.md b/.changeset/self-import-gate-scan-once-5402.md
deleted file mode 100644
index 32ece0aee5..0000000000
--- a/.changeset/self-import-gate-scan-once-5402.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
----
-
-CI tooling only — this publishes nothing, declared explicitly with an empty frontmatter
-rather than left undeclared.
-
-`scripts/check-package-self-import.mjs` now separates the SCAN from the JUDGEMENT:
-`scanRepository(root)` performs the expensive TypeScript parse once, and `judgeScan(scan,
-exemptions)` is a pure filter over its result. `analyze()` keeps its signature and its
-behaviour exactly (differentially verified against the previous implementation over both a
-fixture tree and this repository, across all six exemption-table shapes), and the CLI's
-output is byte-identical.
-
-The reason is `scripts/__tests__/check-package-self-import.test.ts`, which asserts this
-repository is green under the repository's own exemption table AND under no exemptions at
-all. Those were two calls to `analyze(repoRoot)` — the same full parse of ~3,100 files and
-~30 MB of source performed twice — and one of them sat inside a 15-second `it()`. That
-fits uninstrumented (measured 8.8 s) and does not fit under v8 coverage (measured 41.3 s),
-so `ci.yml`'s `Test (coverage)` job failed 100% of the time from 2026-08-16 — 51 completed
-jobs, 0 successes, 50 of them this one file, every one `Test timed out in 15000ms` — and
-Codecov received nothing for four days (objectui#5402).
-
-It is a constant factor, not a race. `@vitest/coverage-v8` arms
-`Profiler.startPreciseCoverage({ callCount, detailed })` in the worker BEFORE test modules
-and their dependencies compile; V8 emits those block counters at compile time and does so
-isolate-wide, so `node_modules/typescript` is instrumented too — `coverage.exclude` filters
-the report, never the instrumentation. Measured here, the identical parse costs 4.1-4.9 s
-uninstrumented and 32-35 s when coverage was armed first, and starting coverage AFTER the
-same code is compiled costs nothing at all.
-
-The test file now scans once at module scope and judges it per assertion: the timeout-prone
-test drops from 41,268 ms to 1 ms under coverage, and the file's total work halves. No
-timeout was raised, nothing is skipped, and coverage is not disabled for anything.
-
-No package `src/` is touched, so no `@object-ui/*` package changes behaviour and there is
-nothing here for a consumer to upgrade to.
diff --git a/.changeset/sentry-undisableable-telemetry-5522.md b/.changeset/sentry-undisableable-telemetry-5522.md
deleted file mode 100644
index 11941d4db1..0000000000
--- a/.changeset/sentry-undisableable-telemetry-5522.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-'@object-ui/app-shell': patch
-'@object-ui/console': patch
----
-
-Console builds no longer carry a live Sentry DSN, and `sendDefaultPii` is now opt-in
-(objectui#5522).
-
-`@object-ui/console` publishes a pre-built SPA, so ONE artifact — built once from
-`apps/console/.env.production` — is what the hosted SaaS console and the on-premises /
-air-gapped EE images all embed. Vite inlines every `VITE_*` from that file into the
-bundle as a frozen object literal, so the DSN committed there was a live third-party
-telemetry endpoint compiled into artifacts that land inside customer networks. It could
-not be switched off afterwards either: the `VITE_SENTRY_ENABLED` kill switch is read off
-that same frozen literal, so on a shipped bundle it is `undefined` forever and editing
-env vars on the deployed host does nothing. An air-gapped deployment was measured
-sending 14 envelopes per session to sentry.io with IP + User-Agent PII, unstoppable by
-the customer.
-
-- `apps/console/.env.production` no longer defines `VITE_SENTRY_DSN`,
-  `VITE_SENTRY_ENVIRONMENT` or `VITE_SENTRY_SEND_DEFAULT_PII`. A build with no DSN never
-  imports `@sentry/react`, so the `vendor-sentry` chunk is not even fetched.
-- `sendDefaultPii` changed from opt-out (`!== 'false'`) to **opt-in** (`=== 'true'`), so
-  IP address and User-Agent are never the inherited default of a build that did not ask
-  for them.
-- The gate now fails **closed**: an absent, empty or whitespace-only DSN means do not
-  send. The direction is deliberately inverted from the usual — an unreported error is
-  recoverable, PII leaving an air-gapped deployment is not.
-
-**Action required for deployments that want error reporting** (the hosted SaaS/demo
-console): inject `VITE_SENTRY_DSN` from your build environment, the same way
-`VITE_SERVER_URL` is already injected, plus `VITE_SENTRY_SEND_DEFAULT_PII=true` if you
-still want IP/User-Agent on events. Nothing else changes for builds that opt in.
diff --git a/.changeset/shard-coverage-job-5403.md b/.changeset/shard-coverage-job-5403.md
deleted file mode 100644
index 8e30f8848f..0000000000
--- a/.changeset/shard-coverage-job-5403.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
----
-
-CI only — this publishes nothing, declared explicitly with an empty frontmatter rather
-than left undeclared. `ci.yml`'s coverage lane is sharded 4 ways with a blob-report
-merge, and the Codecov upload can no longer go missing in silence: the merge job states
-on every path whether Codecov received a report for the commit, and is red when it did
-not.
diff --git a/.changeset/signout-purge-per-key-try-5777.md b/.changeset/signout-purge-per-key-try-5777.md
deleted file mode 100644
index 8b5252c493..0000000000
--- a/.changeset/signout-purge-per-key-try-5777.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-'@object-ui/auth': patch
----
-
-`purgeSignedOutClientCaches()` — the sweep that drops the signed-out user's
-`objectui:metadata:*` seed cache on sign-out (objectui#5198) — now costs one key when a
-single `removeItem` throws, instead of aborting the rest of the sweep (objectui#5777).
-
-The `try` wrapped the WHOLE loop, not each removal. A `removeItem` that threw on key `n`
-aborted the walk, so keys `n+1..end` were never swept, and the failure was swallowed —
-`AuthProvider`'s `signOut` believed the purge had completed. The entries this sweeps are
-the previous principal's org-scoped, PERMISSION-FILTERED app list — objectui#5198
-classifies a surviving entry as a cross-principal disclosure on a shared browser, not
-mere staleness — so a partial sweep here is the sharper half of the same defect class
-objectui#5763 fixed on the sign-in path (`sweepStore` in `ActiveOrganizationStorage.ts`).
-
-`Object.keys(sessionStorage)` — the reason a guard exists here at all — stays guarded on
-its own; only the per-key guard is new. Same as `sweepStore`, a failed removal here is
-not verified by read-back and not quarantined the way `ActiveOrganizationStorage.clear()`
-(objectui#5731) quarantines a key: this function does not own reads for the metadata
-seed cache (`MetadataProvider` in `@object-ui/app-shell` does), so there is no `get()` to
-guard and nothing to quarantine — adding read-back verification would be a general
-storage-error-handling refactor of the module, out of this card's scope. What is
-mirrored is the reporting channel: a key whose `removeItem` throws is named in a
-`console.warn`, the same channel `sweepStore` and `clear()` use, so a partial sweep is
-discoverable instead of silent.
-
-Adds a partial-failure test: a `sessionStorage` whose `removeItem` throws on one metadata
-key, asserting every other metadata key on both sides of it is still swept and unrelated
-non-matching keys are untouched, plus a control that the warning fires only on an actual
-failure.
diff --git a/.changeset/simple-form-consults-declared-submit-handler.md b/.changeset/simple-form-consults-declared-submit-handler.md
deleted file mode 100644
index 74dfa9e5ef..0000000000
--- a/.changeset/simple-form-consults-declared-submit-handler.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-"@object-ui/plugin-form": patch
----
-
-`SimpleObjectForm`: consult a declared `submitHandler` before the inline-fields carve-out
-
-`ObjectFormSchema.submitHandler` is documented as handing the collected values to the host INSTEAD of calling `dataSource.create` / `dataSource.update`, so a form that declares it has a submit target with or without an adapter. `SimpleObjectForm.handleSubmit` nevertheless opened with the inline-fields carve-out (`hasInlineFields && !dataSource`), which returned before the persistence chain: a host that had declared it owns the write was never asked, and `onSuccess` confirmed a write that never happened (measured `onSuccess 1 / submitHandler 0`).
-
-The carve-out now fires only when no `submitHandler` is declared, and the "no submit target" refusal moved into the persistence chain after the seam — the shape the five variant renderers already use, reusing their shared refusal from `submitTarget.ts` rather than a private copy. A form with inline fields and no seam is unchanged: its `onSuccess` is still the write.
diff --git a/.changeset/skill-provider-envelope-teaching-5372.md b/.changeset/skill-provider-envelope-teaching-5372.md
deleted file mode 100644
index 4e6dd9e2a7..0000000000
--- a/.changeset/skill-provider-envelope-teaching-5372.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
----
-
-Published-skill teaching only — this publishes nothing, declared explicitly with an
-empty frontmatter rather than left undeclared. No package `src/` is touched: the
-change is confined to `skills/objectui/**` (the published skill package) plus one new
-test under `packages/components/src/__tests__/`, which pins the corrected teaching to
-the real renderer.
-
-The rules told authors that the `properties` / `props` envelope belonged to the
-`element:*` namespace and that every other key "lives on the node". Measured on a real
-`SchemaRenderer` inside a `SchemaRendererProvider`, `properties` is evaluated and then
-hoisted onto the node in *every* namespace — so it was the only spelling that reached a
-`data-table`'s rows from a provider `dataSource`, while the node-level and `props`
-spellings rendered a header over the empty state with nothing thrown and nothing logged.
-The guides now record that measurement instead of contradicting it.
diff --git a/.changeset/sparse-predicate-warning-cause-5399.md b/.changeset/sparse-predicate-warning-cause-5399.md
deleted file mode 100644
index adebbd2ba1..0000000000
--- a/.changeset/sparse-predicate-warning-cause-5399.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-'@object-ui/components': patch
----
-
-The `[page:header]` sparse-predicate warning no longer blames `hidden: true` — it
-states what it actually measured (objectui#5399).
-
-When an action's `visible` predicate references a `record.<key>` the bound payload
-does not carry, the warner names the missing key and then explained the cause:
-
-> Hidden (hidden: true) fields are stripped from detail payloads server-side, so a
-> predicate gating on one may evaluate to a hide-by-default verdict.
-
-That cause is false, and it names a mechanism this repo does not own. `hidden` is a
-UI concern — the framework spec describes it as "Hidden from default UI"
-(`packages/spec/src/data/field.zod.ts`) — not a projection rule. Confirmed against
-the framework checkout rather than taken on trust: ObjectQL's own strip for the
-`__search` companion documents that the `hidden` / `readonly` / `system` markers are
-"None of them is a PROJECTION rule", which is precisely why a dedicated strip rule
-had to be written for that one column; drivers answer a query with no `fields` using
-`SELECT *`; and `metadata-protocol` enumerates what the read path does drop —
-`internal: true` columns and the `__search` companion, and nothing else. The only two
-read-side uses of `field.hidden` in the framework are auto-view/auto-form column
-generation and companion-source eligibility, neither of which removes a key from a
-record body.
-
-So an author who read this diagnostic went hunting for a `hidden` flag they would
-either not find, or find on a field the payload demonstrably still returns — while
-the real source of the sparseness (a projected or partial read) went unexamined. A
-confidently wrong cause in a diagnostic is worse than no cause, because it is
-actionable in the wrong direction.
-
-The replacement states the fact this surface can actually see and the consequence it
-does own: the page bound a payload without those keys, a projected or partial read
-will not carry them, and the predicate therefore fails closed and hides the action.
-The measured half of the message — action name, missing fields, predicate source —
-is unchanged, and nothing about what triggers the warning changed.
-
-Message text only. The same false claim also sat in this warner's own doc comments
-and in the comments of the test that pins the message; both are corrected here, and
-the docstring now carries an explicit note against re-attributing the cause to
-`hidden: true`. No other call site was swept.
diff --git a/.changeset/spec-pin-17-1-0-5328.md b/.changeset/spec-pin-17-1-0-5328.md
deleted file mode 100644
index 261be17ee2..0000000000
--- a/.changeset/spec-pin-17-1-0-5328.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-'@object-ui/data-objectstack': minor
-'@object-ui/plugin-list': minor
-'@object-ui/plugin-view': minor
-'@object-ui/core': minor
-'@object-ui/app-shell': minor
----
-
-Pins `@objectstack/spec`, `@objectstack/client`, `@objectstack/formula` and `@objectstack/lint` to `17.1.0`, and adapts the two consumer surfaces the new build moves.
-
-The pin itself is a lockfile refresh — every manifest already declared `^17.0.0`, which admits `17.1.0`, so no dependency range changed. All four move together: a split resolution is what produced the dual-version spec graph that reddened `check:spec-symbols` in this repo's history.
-
-**A `icontains` filter now reaches the driver as a filter.** `icontains` is a canonical `VIEW_FILTER_OPERATORS` member as of `17.1.0`, so an author can declare it on a `ViewFilterRule` and the spec validates it — but `@object-ui/data-objectstack`'s alias table had no row for it, and an unmapped operator is how this adapter shipped an unfiltered query before (objectstack#3948). It is an identity row like `contains`: `icontains` is itself a member of `VALID_AST_OPERATORS`, so the spelling the author writes is the spelling the AST takes, and no case-sensitivity is translated away. Declared rather than left to the table's `?? op` fall-through, on the rule its own parity test states — the AST gate accepting a spelling is not the driver compiling it into a `WHERE` clause.
-
-The same operator reaches the list view's own bridge: `@object-ui/plugin-list`'s `mapOperator` gains an explicit `icontains` arm. The emitted spelling is identical to the input, but the arm is written out rather than left to the `default` passthrough — `icontains` is its own member of `VALID_AST_OPERATORS`, so a raw passthrough is accepted *today*, and depending on that coincidence is what the bridge's own parity test records as how it once stopped discriminating.
-
-`@object-ui/core` adds `onSuccess` to its spec key inventory, so an author writing the key `17.1.0` now declares is no longer warned that it is unknown. That is a diagnostic statement only — the four declared action surfaces still drop the key before it reaches the runner, which is tracked separately.
-
-**A stored view filtering case-insensitively still shows that operator when it is reopened.** `@object-ui/plugin-view`'s canonical-to-builder table is keyed by `ViewFilterOperator`, so `17.1.0` adding `icontains` failed to compile rather than letting the operator reach the FilterBuilder as a raw spelling its dropdown cannot select. It maps to the builder's `containsCaseInsensitive` — the id that authors the spec's `$icontains` — and deliberately not to `contains`, which would quietly rewrite a case-insensitive filter into a case-sensitive one the next time the view was saved.
-
-**The page-editor palette keeps one entry per renderer.** `17.1.0` retires `element:filter` from `PageComponentType` and adds `record:discussion`, leaving the member count at 34 either side — so the swap is invisible to any count-based reading. The stale `element:filter` exclusion is dropped, and `record:discussion` is excluded because it is the *same renderer* as the already-offered `record:chatter`, not because it is unauthorable. Nothing the palette offers changes.
-
-**The console eager-closure ceiling is re-baselined, by maintainer ruling.** The release is roughly 930 KB larger uncompressed and nearly all of it lands in `vendor-objectstack-*.js`, which put the closure past a ceiling that was deliberately sized to catch a 89 KiB regression — the gate refused the bump, correctly. Raising it was escalated rather than taken locally, because gate-strength policy had been ruled the maintainer's; the ruling on objectui#5531 authorised the raise. `MAX_EAGER_CLOSURE_GZIP_BYTES` and the `BASELINE` it is derived from move together in one commit, keeping headroom at 2.00% and below the 91,136-byte regression size the gate must still catch. The gate's *sensitivity* is untouched: a repeat of that regression from the new baseline still fails. No behaviour ships from this file — it is CI policy, recorded here because the version it governs is the one this changeset publishes.
diff --git a/.changeset/spec-refresh-17-2-0-5668.md b/.changeset/spec-refresh-17-2-0-5668.md
deleted file mode 100644
index 541883958e..0000000000
--- a/.changeset/spec-refresh-17-2-0-5668.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-'@object-ui/console': patch
----
-
-Refreshes the lockfile so every `@objectstack/*` package resolves at `17.2.0` — `spec`, `client`, `core`, `formula`, `lint` and `sdui-parser` move in lockstep (a split resolution is what produced the dual-version spec graph that reddened `check:spec-symbols` in this repo's history), and no `17.1.0` resolution remains.
-
-**The docs-site and console builds stop pulling a Postgres connection-string parser toward the browser bundle.** `@objectstack/spec@17.1.0` imported `pg-connection-string` at the top level of `dist/index.mjs` with no `browser` export condition, so `apps/site`'s production build failed with `Module not found: Can't resolve 'fs'` on every route that reaches `@object-ui/components` from a client component — red on `main` since 2026-08-22 (objectui#5668). `17.2.0` ships the objectstack#11072 fix: `.`, `./data`, `./system`, `./kernel` and `./cloud` now carry `browser` conditions pointing at schema-free `dist/browser/**` bundles, and the site build is back to `Tasks: 29 successful, 29 total`.
-
-The refresh is lockfile-only — every manifest already declared `^17.0.0`, which admits `17.2.0`, so no dependency range changed. No shipped source moves: the two in-repo adaptations are a drift-guard test and a CI gate, both forced by `17.2.0` retiring the spec's theme module (objectstack#10485) exactly as the objectui#5716 localization predicted — its `Theme`/`ThemeMode`/`ColorPalette` ALLOW entries in `check:spec-symbols` went stale and were deleted, and the parity test now pins the vacancy (the spec re-publishing a theme name is a loud collision) instead of a spec leg that no longer exists.
diff --git a/.changeset/spotty-pianos-shave.md b/.changeset/spotty-pianos-shave.md
deleted file mode 100644
index a32380b233..0000000000
--- a/.changeset/spotty-pianos-shave.md
+++ /dev/null
@@ -1,4 +0,0 @@
----
----
-
-Test-only change: removed two `eslint-disable-next-line react-hooks/static-components` directives that the rule no longer needs in the record-picker i18n test files. No published behaviour changes.
diff --git a/.changeset/stale-4163-pointers-5591.md b/.changeset/stale-4163-pointers-5591.md
deleted file mode 100644
index 7b77930b57..0000000000
--- a/.changeset/stale-4163-pointers-5591.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-'@object-ui/i18n': patch
----
-
-`setLocalized`'s published docblock states the single-locale write rule that is
-actually in force, instead of deferring the multi-locale-authoring question to a
-closed card (objectui#5591).
-
-The docblock read "is not a multi-locale authoring UI (objectui#4163)". objectui#4163
-closed as completed on 2026-08-15 with that product question still unanswered, so the
-parenthetical pointed at nothing — and it read as though the question had been settled
-somewhere a reader could go and check. This is the failure mode objectui#5428
-demonstrated is not harmless: there, a dangling deferral of exactly this shape let an
-expired justification sit unread for a release cycle at two surfaces.
-
-The remedy is objectui#5428's, not a re-pointing at a successor card: state the rule in
-force (`setLocalized` reaches only the entry for the locale the author is in), keep the
-open product question open **in place**, and record why there is deliberately no tracker
-reference — so the next reader cannot restore one. Re-pointing is how the class
-regenerates, because the next card closes too. The same wording form already landed in
-`plugin-designer`'s `writeWidgetTitle` and `DashboardWidgetInspector`.
-
-Prose only. No behaviour, no signature, no test changes — `setLocalized`'s pairing with
-`pickLocalized` is unchanged and still pinned by `src/__tests__/setLocalized.test.ts`.
-
-Declared as a `patch` for `@object-ui/i18n` alone because the emit was measured per
-package rather than assumed, and the two packages this change touches differ:
-
-- `@object-ui/i18n` — the docblock sits on the **exported** `setLocalized`, so it reaches
-  the published artifacts. Rebuilt with `tsconfig.tsbuildinfo` cleared first (the build is
-  `composite`, which otherwise skips emit), and compared by SHA-256 rather than byte count:
-  `dist/pickLocalized.d.ts` `1e2170ad…` -> `124a1c07…` and `dist/pickLocalized.js`
-  `06eb88bd…` -> `568cb703…`. A consumer reads this text on hover and in the API docs, so
-  it publishes something.
-- `@object-ui/plugin-dashboard` — the two comments changed there are a `//` banner between
-  declarations and a test docblock, neither attached to an exported declaration.
-  `dist/WidgetConfigPanel.d.ts` is **byte-identical** across the rebuild
-  (`93252e8cdf5a6faa…` both sides). The only artifact that moved is
-  `dist/WidgetConfigPanel.d.ts.map`, whose mappings shift because lines were added above
-  the declarations; no declaration text changed. Nothing user-visible publishes from that
-  package, so it is not named here.
diff --git a/.changeset/standing-pending-drafts-bar-5694.md b/.changeset/standing-pending-drafts-bar-5694.md
deleted file mode 100644
index f1d669f659..0000000000
--- a/.changeset/standing-pending-drafts-bar-5694.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-'@object-ui/app-shell': minor
----
-
-AI build surface gains a standing 「未发布改动」 bar (#5694): while the conversation's bound package has pending drafts, a bar floats above the composer — surviving scrolling — counting the unpublished changes and publishing them through the same governed `publish-drafts` route as the inline card button, with probe findings surfaced instead of a blind success toast. Renders nothing when the count is zero or the conversation is unbound.
diff --git a/.changeset/studio-metadata-form-ux-5416.md b/.changeset/studio-metadata-form-ux-5416.md
deleted file mode 100644
index 551450b9e7..0000000000
--- a/.changeset/studio-metadata-form-ux-5416.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-Studio's metadata authoring path stops greeting the author with errors they did not cause, English help text in a Chinese console, and a toast on top of the publish button.
-
-Three defects measured on a 17.1.0 dogfood walkthrough (objectui#5416), all on
-the first surfaces a new author sees.
-
-**Validation no longer runs on mount.** `新建软件包` opened with both required
-fields already red: the create draft is `{ version, type }`, so
-`ManifestSchema.safeParse` reported `name` and `id` missing on the very first
-render, and the dialog then jumped a line height per field as each error
-cleared. `SchemaForm` now defers the error *line* until the row has been
-touched — first focusout anywhere in it, or the field's own first edit — for
-create forms only. The rule itself did not move: `issues` still reaches the host
-unchanged, so the submit button is gated on exactly the same validation, and
-edit/view forms still report from mount, where the issues describe stored values
-rather than something half-typed.
-
-**The package form's help text is translated.** The labels came from the
-metadata-admin i18n bundle and the help line under each one came straight from
-`ManifestSchema`'s English `.describe()`, so a zh console rendered 显示名称 over
-"Human-readable package name". `getPackageForm` now reads each field's help
-through the same bundle as its label, via a new `tOptional` that returns
-`undefined` rather than echoing the key back. Only zh entries exist: an en-US
-console finds nothing and keeps falling through to the spec's own sentence, so
-the English keeps exactly one producer — `@objectstack/spec` in the framework
-repo — and this repo never holds a copy of it to drift.
-
-**The publish panel's primary button opens clear of the toast stack.** The
-console mounts its toaster bottom-right and `DraftChangesPanel` is a
-`side="right"` sheet with an `mt-auto` footer, so a save toast raised on the way
-there (`对象「…」已存为草稿`, 4s default) sat directly on 全部发布 until it timed
-out. Opening the panel now clears the stack the surface the author just left had
-raised. Repositioning the toaster was measured and rejected: the draft preview
-bar is `sticky top-0` and carries its own publish actions, `NotificationSnackbar`
-anchors bottom-centre and the nav rail owns the left edge, so a move only
-relocates the same collision onto a different primary control.
-
-Not fixed here, and not fixable here: the other strings the card names are
-produced outside this repo. `Owning Business Unit` (`packages/spec`),
-`Search Index` (`packages/objectql`) and the `Revise Window` flow node's name
-and description (`packages/plugins/plugin-approvals`) all come from the
-framework, which owns their translation catalogue; patching them in the console
-would create a second source of truth that diverges at the next framework
-release.
diff --git a/.changeset/studio-nav-canonical-keys.md b/.changeset/studio-nav-canonical-keys.md
deleted file mode 100644
index 73ce02c260..0000000000
--- a/.changeset/studio-nav-canonical-keys.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-Studio Interfaces: the nav-leaf binding reads the canonical target key only
-
-`resolveSurface` fell back to the bare spellings `page` / `object` /
-`dashboard` / `report`, and carried a `case 'view'`. Every
-`NavigationItemSchema` member is a `strictObject`, none of those bare
-spellings is in any variant's shape or in `NAV_ITEM_ALIASES`, and `view` is
-not one of the union's nine members — so all of them are keys `AppSchema`
-answers with `unrecognized_keys`, and every one of those branches could only
-fire on an app that cannot be saved. The Studio nav item inspector's object
-picker likewise read `node.object ?? node.objectName`, preferring the rejected
-spelling over the canonical one; it now reads the canonical key first.
-
-No shape that parses today stops parsing: this narrows the designer back to
-what the contract already declares.
diff --git a/.changeset/studio-new-object-asks-for-owd-5418.md b/.changeset/studio-new-object-asks-for-owd-5418.md
deleted file mode 100644
index 05f2f1e0cc..0000000000
--- a/.changeset/studio-new-object-asks-for-owd-5418.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-'@object-ui/app-shell': minor
-'@object-ui/i18n': minor
----
-
-Studio's `新建对象` asks for the record-sharing baseline, and an unauthored one is reported before Publish rather than by it.
-
-Creating an object through Studio collected exactly two things — display name and
-identifier — and saved a draft that declared no `sharingModel`. The draft saved
-happily, the form designer worked, and the object was then refused at 发布 →
-全部发布 by `security-owd-unset`: a required decision the surface never asked
-for, delivered by failing, as English ADR prose in a toast that then vanished on
-a timer. The one actionable word in it named a control three clicks away that
-nothing routed to.
-
-The publish gate is correct and is unchanged — an org-wide default has to be an
-authored decision, not an accident. What changes is when the console asks and
-when it answers:
-
-- **The create dialog asks.** A third field collects the baseline, pre-selected
-  to `private` and glossed with the Settings tab's own strings, so a new object
-  is publishable by construction. `buildObjectSkeleton` now takes the value as a
-  required parameter — a future create path cannot omit the baseline without
-  failing to type-check. `controlled_by_parent` is deliberately not offered at
-  creation: it derives access from a master relation a brand-new object does not
-  have yet, so offering it would trade one publish refusal for another.
-- **The review sheet reports it.** The pending-changes panel now runs the
-  framework's own `validateSecurityPosture` over the pending object drafts and
-  names any blocking finding, with its fix-it hint, next to the Publish button.
-  It mirrors the producer's rule rather than re-deriving it, and it reports
-  without blocking — the server door stays the authority.
-- **The Settings tab stops calling an unset baseline safe.** It described unset
-  as "defaults to Private", which answers what the runtime does and not whether
-  the object can ship. It now reads as the publish-blocking problem it is,
-  styled like the external-wider warning beside it.
diff --git a/.changeset/studio-route-entry-capability-5519.md b/.changeset/studio-route-entry-capability-5519.md
deleted file mode 100644
index bed8579047..0000000000
--- a/.changeset/studio-route-entry-capability-5519.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-'@object-ui/console': patch
----
-
-The Console now gates the `/studio/*` routes on the `studio.access` ENTRY
-capability, not just on the backend's refusal of the writes behind them
-(objectui#5519).
-
-`/_console/studio/` rendered the full Studio pillar builder — Data /
-Automations / Interfaces / Access, with Publish and Save draft — to any
-authenticated principal who typed the URL, on deployments where the Studio nav
-tile is deliberately absent and every metadata write is refused. A plain tenant
-user was walked through the entire "new package" form and only refused at
-submit (403). The lockdown criterion for that deployment shape is two-part — UI
-entry hidden AND API refused — and only the API half was met; what stood on
-this side was a write-level gate where an entry-level one belongs.
-
-The whole `/studio` subtree now hangs off one route element that reads
-`systemPermissions[]` from `GET /api/v1/auth/me/permissions` (the endpoint this
-app already consumes) and admits only a principal whose LOADED set carries
-`studio.access` — the capability declared as "Enter the Studio metadata-design
-surfaces", which a tenant org owner does not hold by design. Everyone else is
-sent to `/home` without the builder ever mounting.
-
-The fail direction is deliberately inverted from this app's other capability
-gates: those fail OPEN on an unknown answer because their bad outcome is a
-holder losing a button, whereas a route gate's bad outcome is a non-holder
-seeing the builder. So the loading window renders the console splash (never the
-builder), an outright fetch failure renders the retryable error splash, and a
-`200` that carries no `systemPermissions` at all is refused rather than waved
-through. The server-side refusals are untouched.
diff --git a/.changeset/studio-simplify-5813.md b/.changeset/studio-simplify-5813.md
deleted file mode 100644
index c5860b40c1..0000000000
--- a/.changeset/studio-simplify-5813.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-'@object-ui/app-shell': minor
----
-
-Studio simplification, first cut (#5813): the Data pillar's object sub-tabs collapse to 记录/表单 with the five power panels (验证/钩子/操作/API/设置) behind one 「高级」 menu (the open panel's name wears the active pill, so the collapsed default never hides where you are); drafts now AUTO-save (debounced 1.5s, CEL-blocking gates the timer per the objectui#4306 rule, a failed save waits for the next edit) and the four 保存草稿 buttons are retired in favor of a quiet saving/last-saved hint; the 权限 pillar moves from the top-level row into a 「更多」 overflow whose items carry the same dirty-guard as the primary pillars — the /studio/:pkg/access route and every page behind it are untouched.
diff --git a/.changeset/submithandler-variant-forms.md b/.changeset/submithandler-variant-forms.md
deleted file mode 100644
index 84007e9a29..0000000000
--- a/.changeset/submithandler-variant-forms.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-"@object-ui/plugin-form": patch
----
-
-Honour the declared `submitHandler` seam in every form variant, not just the simple one.
-
-`ObjectFormSchema.submitHandler` is documented as the seam a host uses to own persistence: the form validates and hands the collected values over instead of calling `dataSource.create` / `dataSource.update`. `ObjectForm` forwarded the key into every variant it routes to, but only `SimpleObjectForm` read it — `TabbedForm`, `WizardForm`, `SplitForm`, `DrawerForm` and `ModalForm` persisted directly.
-
-**Behaviour change on a persistence path.** A master-detail parent half rendered `tabbed` (or `split`) now commits through the atomic `batchTransaction` together with its child collections, instead of writing the parent independently through `dataSource.create`. Previously the child leg was never attempted on those layouts: the parent was committed alone, the entered line items were silently discarded, no compensation ran, and a success toast confirmed the save. A failing child leg now leaves no committed parent, on every layout that renders the parent half inline.
-
-`WizardForm` additionally skips its own default success toast / redirect arms when a `submitHandler` is present, matching `ObjectForm`, so a host that owns the write also owns the outcome.
-
-The `object-master-detail-form.formType` vocabulary is unchanged and stays `simple | tabbed`.
diff --git a/.changeset/surface-context-send-1610.md b/.changeset/surface-context-send-1610.md
deleted file mode 100644
index 0b92a22514..0000000000
--- a/.changeset/surface-context-send-1610.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-'@object-ui/app-shell': minor
-'@object-ui/plugin-chatbot': patch
-'@object-ui/i18n': patch
----
-
-The Studio copilot tells the agent WHAT the user is discussing (cloud#1610 send half): `ChatPane` accepts a `surfaceContext` and sends it as `context.surface` on every turn (the transport reads the body per send, so it stays fresh); the Studio copilot derives it from the URL alone — the `:tab` pillar segment plus the `?surface=type:name` deep-link the pillars already mirror, so the artifact carries its type discriminator (page/object/dashboard/report). A display chip above the composer (「正在讨论：…」, new `console.ai.discussing` key in all ten packs) makes the sent context visible instead of invisible grounding.
diff --git a/.changeset/surface-deeplink-live-channel-5476.md b/.changeset/surface-deeplink-live-channel-5476.md
deleted file mode 100644
index 9515eb71b3..0000000000
--- a/.changeset/surface-deeplink-live-channel-5476.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-Studio's pre-publish security block can now take you to the object it names.
-
-The pending-changes sheet reports what the publish door would refuse — as
-`object/crmext_visit`, with the rule's fix-it hint and "Fix it on the object under
-Settings → Record sharing". Naming it was the half that shipped; reaching it was not.
-The `?surface=<type>:<name>` deep-link that would have carried the author there
-captures the URL exactly ONCE, at mount, and the sheet is opened over an
-already-mounted pillar — so writing the param changed the URL and moved nothing.
-
-That mount-time capture is deliberate and stays exactly as it was: the mirror half
-rewrites the param on every in-pillar selection, so a capture that followed the URL
-would re-trigger its restore on each one. What was missing is a third half — a live
-target delivered BESIDE the URL, which is what a producer already inside the pillar
-needs. `surfaceDeepLinkChannel` adds it: producers ask for a surface by identity
-(`{type, name}`), the host routes cross-pillar requests back through the URL (that
-pillar is unmounted, so its capture is the right mechanism) and vetoes the ones the
-author declines over unsaved edits, and the mounted pillar applies the rest.
-
-Applied AT MOST ONCE, by a monotonic id. A standing request re-resolved on the next
-rail reload would drag the author back off whatever they had since selected — the
-regression the mount-time ref exists to prevent — so `DataPillar.surfaceRequest.test`
-pins a hand-picked object surviving a package switch, and
-`surfaceDeepLinkChannel.test` pins the capture itself as an unchanged control: it
-still ignores every URL change after mount, and a live request never moves it.
-
-The sheet's other home is the Home / draft-preview bar, where the Studio object editor
-is not a reachable destination at all. Reachability is answered structurally — the
-producer hook returns `null` when no host published the channel — so off-Studio the
-item name stays the prose #5418 shipped rather than becoming a link to nowhere. Both
-directions are assertions in `DraftChangesPanel.securityLink.test`, not a comment.
-
-Nothing the other three pillars observe changed: `useSurfaceDeepLink` keeps its
-signature, its return and its behaviour, and only the Data pillar subscribes to the
-new channel. The channel is its own React-only module on purpose — importing the hook
-into the sheet would have pulled `nav-selection` and the App-nav inspector into the
-console's eager graph.
diff --git a/.changeset/sweep-store-per-key-try-5763.md b/.changeset/sweep-store-per-key-try-5763.md
deleted file mode 100644
index 615b71b68f..0000000000
--- a/.changeset/sweep-store-per-key-try-5763.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-'@object-ui/auth': patch
----
-
-`sweepStore()` — the walk that drops the previous user's `localStorage`/`sessionStorage`
-state on a change of session user (objectui#5664 part 3) — now costs one key when a
-single `removeItem` throws, instead of aborting the rest of the sweep (objectui#5763).
-
-The `try` wrapped the WHOLE loop, not each removal. A `removeItem` that threw on key
-`n` aborted the walk, so keys `n+1..end` were never swept, and the failure was
-swallowed — `purgePreviousUserClientState()` returned normally and `SessionUserScope.adopt`
-believed the sign-in purge had completed. This is an ALLOWLIST sweep precisely so the
-next un-namespaced key — one nobody has written yet — cannot re-open the cross-user
-pollution class #5664 fixed; a partial sweep is a partial allowlist, and which keys
-survived depended on `Object.keys` iteration order rather than on anything bounded. The
-previous user's org id, recents, favourites, or a `sessionStorage` metadata seed (their
-permission-filtered app list, a cross-principal disclosure per objectui#5198) could all
-land on the wrong side of the abort.
-
-`Object.keys(store)` — the reason a guard exists here at all — stays guarded on its
-own; only the per-key guard is new, so one uncooperative key now costs exactly that key.
-
-Unlike `ActiveOrganizationStorage.clear()` (objectui#5731), a failed removal here is
-NOT verified by read-back and NOT quarantined: `clear()` owns every future read of its
-one key through `ActiveOrganizationStorage.get()`, so a "still readable" verdict and a
-quarantine are what keep a failed `clear()` from handing the value straight back.
-`sweepStore` walks keys it does not own reads for — another package's recents cache, a
-metadata seed — so there is no `get()` here to guard and nothing to quarantine; adding
-read-back verification for keys this function does not otherwise touch would be a
-general storage-error-handling refactor of the module, which this card is scoped away
-from. What IS mirrored is the reporting channel: a key whose `removeItem` throws is
-named in a `console.warn`, the same channel `clear()` uses, so a partial sweep is
-discoverable instead of silent. The caller (`SessionUserScope.adopt`, on the sign-in
-path, inside an `AuthProvider` effect) still cannot act on the failure and must not
-throw either.
-
-A working `localStorage`/`sessionStorage` behaves exactly as before: every
-non-device-scoped key is removed, nothing is reported, and the device-scoped allowlist
-(`auth-session-token`, `auth-session-user-id`, `vite-ui-theme`) is unaffected.
diff --git a/.changeset/switch-org-declared-reresolve-5750.md b/.changeset/switch-org-declared-reresolve-5750.md
deleted file mode 100644
index 0a76461413..0000000000
--- a/.changeset/switch-org-declared-reresolve-5750.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-'@object-ui/auth': patch
----
-
-`switchOrganization` now re-resolves identity for the organization it just switched
-to by its own explicit decision, instead of depending on an accidental
-`TokenStorage` side effect to notice the switch (objectui#5750).
-
-`AuthProvider.switchOrganization` has never called `loadSession()` itself. Identity
-re-resolved across a switch only because `POST /organization/set-active` happens to
-return the SIGNED `token.signature` spelling in `set-auth-token`, which differs from
-the UNSIGNED `session.token` spelling `getSession()` normally stores — so
-`TokenStorage.set` reads the flip as a rotation and the objectui#4467 subscription
-calls `loadSession()` for it (measured and pinned in objectui#5749/#5719). That
-signed spelling is deterministic on the raw session token, not on the organization:
-two switches with no `get-session` landing in between produce the identical signed
-value, so the SECOND `TokenStorage.set` sees no change, never notifies, and identity
-is left answering for whichever organization the FIRST switch targeted even though
-`activeOrganization` already reads as the new one.
-
-Reachable in the console via `OrganizationLayout`'s slug-driven effect (the "Manage"
-link on an org card, plus its own "Back to organizations" button) — ordinary
-client-side navigation with no full-page reload and nothing debouncing repeat
-switches. `WorkspaceSwitcher` and `OrganizationsPage`'s own card click were not
-reachable paths for this: both force `window.location.href` immediately after a
-successful switch, and the resulting fresh `AuthProvider` mount always performs an
-authoritative `loadSession()` regardless of how the race above resolved.
-
-`switchOrganization` now tracks the organization it last resolved to itself and
-re-resolves explicitly whenever a switch's target differs from that, while
-suppressing the (now redundant) rotation notification for its own `set-active`
-call — so the common single-switch path still spends exactly one `get-session`, not
-two. A generation guard discards a still-in-flight, now-superseded switch's answer
-rather than let it clobber a later switch's fresher one.
diff --git a/.changeset/switch-org-identity-reresolve-5719.md b/.changeset/switch-org-identity-reresolve-5719.md
deleted file mode 100644
index 48c7be0598..0000000000
--- a/.changeset/switch-org-identity-reresolve-5719.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
----
-
-Tests only — this publishes nothing, declared explicitly with an empty frontmatter
-rather than left undeclared. No package `src/` behaviour moves; the only files added are
-`packages/auth/src/__tests__/switchOrgIdentityReresolve-5719.test.tsx` and this changeset.
-
-Pins that console identity **re-resolves across an organization switch**, and pins the
-mechanism that actually provides it.
-
-objectui#5719 observed that `AuthProvider.switchOrganization` never calls `loadSession()`,
-while the framework derives `user.positions[]` inside `customSession` from
-`session.activeOrganizationId` — so leg 3 of `useWorkspaceAdminStatus` would keep answering
-for the PREVIOUS organization, and because that hook is `leg1 || leg2 || leg3` with
-`isResolved` short-circuited to true on any positive leg, a stale `org_owner` reads as a
-CONFIRMED admin in the new organization. The card was filed as an observation because its
-last step could not be settled from this repo.
-
-Measured against better-auth 1.6.28 driven standalone with the organization and bearer
-plugins the framework always enables: `POST /organization/set-active` **does** hand back a
-`set-auth-token`, so the objectui#4467 rotation subscription already re-resolves identity
-and there is no defect. The mechanism, however, is an accident worth naming: the switch does
-not mint a new session — `updateSession` writes only `activeOrganizationId` — it hands back
-the **signed** `token.signature` spelling, while `createAuthClient.getSession()` stores the
-**unsigned** `session.token`. Two spellings of one session, and `TokenStorage.set` notifies
-on a value change.
-
-Nothing declared that. Normalising either lane onto a single spelling — a reasonable-looking
-tidy-up — would silently stop identity re-resolving across an org switch, with the
-over-permissive consequence #5719 described and no test anywhere to catch it. These cases
-are that test, including the owner-of-both control (so the pin cannot pass on code that
-merely stopped reporting admin) and a counterfactual that fixes what the guarantee rests on.
-
-No explicit `refreshSession()` was added: the rotation path already spends exactly one
-`get-session` per switch, so an explicit call would make every org switch cost two.
diff --git a/.changeset/table-renderer-declared-column-contract-5350.md b/.changeset/table-renderer-declared-column-contract-5350.md
deleted file mode 100644
index a405857ba3..0000000000
--- a/.changeset/table-renderer-declared-column-contract-5350.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-'@object-ui/components': minor
----
-
-The static `table` renderer reads only the declared `TableColumn` contract, and its published reference page teaches that spelling.
-
-`renderers/complex/table.tsx` resolved a heading as `col.header || col.label` and a
-cell as `row[col.accessorKey || col.name]`. Neither `label` nor `name` is declared
-on `TableColumn`, which declares `header` and `accessorKey` — both required
-(`packages/types/src/data-display.ts`). This was the fourth site of the
-column-alias family, after `data-table`, `ObjectDataTable` and `ObjectGrid`
-(objectui#5350).
-
-Both aliases are retired. The ruling recorded on objectui#5120 (2026-08-20) is the
-family direction — *retire the consumer-side alias; unify the producers* — and it
-names this site: the declared `header`/`accessorKey` contract wins.
-
-What makes this site different from its three siblings is that the alias was not
-merely tolerated, it was **published**. `content/docs/api/schema-reference.md`
-§TableSchema shipped a copyable `{ "name": "id", "label": "#" }` example and a
-property row reading *"Column definitions with `name`, `label`, …"*, while
-`packages/types` declared the opposite pair. Docs and type disagreed about one
-type they both call `TableColumn`, each internally consistent. Retiring the alias
-without correcting the page would have turned a documented, working example into a
-silently broken one, so both halves land together: the page now authors
-`accessorKey`/`header`. The same row also advertised a `render` property that
-`TableColumn` has never declared — the renderer's hook is `cell` — and that claim
-is dropped rather than re-spelled.
-
-The failure mode of a now-unresolvable column is worth stating, because it is
-quiet: the column keeps its slot and its neighbours are unaffected, the header or
-the cells simply render empty, and nothing throws. This renderer keys its cells by
-index rather than by accessor, so unlike `data-table` it does not even produce
-React's generic missing-key warning — a retired-spelling column is fully silent.
-Whether that silence should become an authoring diagnostic is objectui#5349's
-question; no diagnostic is added here.
-
-The two `columns.map` callbacks are typed `TableColumn` instead of `any`, so
-re-introducing an undeclared alias on this renderer is now a type error rather
-than a reviewer's catch.
diff --git a/.changeset/tall-tools-shake.md b/.changeset/tall-tools-shake.md
deleted file mode 100644
index 7c4cfb5558..0000000000
--- a/.changeset/tall-tools-shake.md
+++ /dev/null
@@ -1,4 +0,0 @@
----
----
-
-Test-only change: drop eight unused schema imports from `packages/types/src/__tests__/phase2-schemas.test.ts`, so an import-based coverage census no longer reads them as pinned by that suite. No published behaviour changes.
diff --git a/.changeset/tenant-header-edge-contract-5279.md b/.changeset/tenant-header-edge-contract-5279.md
deleted file mode 100644
index 3ba15b9414..0000000000
--- a/.changeset/tenant-header-edge-contract-5279.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-'@object-ui/auth': patch
----
-
-Document the `X-Tenant-ID` edge contract that `createAuthenticatedFetch` stamps, and the
-unstamped-first-request window in which it is not sent (objectui#5279). Documentation
-only — no behaviour changes.
-
-The header had no written contract anywhere, and the shape of the missing information was
-actively misleading: its only non-CORS consumer lives in the **cloud** repository, so a
-search confined to this repo and the framework (`objectstack`) returns zero readers and
-reads as "nothing consumes this stamp". #5279 was filed on exactly that reading, and was
-held until a cloud-side reading came back non-empty. Without the contract written down,
-the next person to grep reaches the same false conclusion and deletes a live routing
-input.
-
-`packages/auth/README.md` gains "The `X-Tenant-ID` edge contract": what the header means
-(a routing hint carrying the better-auth `activeOrganizationId` — not an identity claim,
-not an authorization input, not what scopes rows), who stamps it and under exactly which
-condition, who reads it, and what a reader may and may not assume. The framework half is
-stated as a negative with its pin — `resolveAuthzContext` takes `tenantId` from the
-API-key principal or `session.activeOrganizationId` and from no header — alongside
-`plugin-sharing`'s record that trusting `x-tenant-id` as identity *was* a vulnerability.
-The configuration half is quoted from the contract this package can actually resolve,
-`TenantRoutingConfigSchema` in `@objectstack/spec/cloud`, where `X-Tenant-ID` is the
-default of a configurable `tenantHeaderName` and `header` ranks second of six
-identification sources behind `subdomain`.
-
-The unstamped-first-request gap gets its own section: `ActiveOrganizationStorage` is
-filled only after `AuthProvider`'s async `getSession` -> `listOrganizations` ->
-`getActiveOrganization` chain resolves, so early-boot requests carry no tenant header at
-all. What a reader observes is documented as **absent, never present-and-empty**, with the
-five situations that open the window and the instruction to fall through to the next
-identification source rather than fail closed. The gap is recorded, deliberately not
-closed: the cloud readers observe today's behaviour, so changing when the header first
-appears is its own decision.
-
-Three cases in `createAuthenticatedFetch.test.tsx` pin the statements the prose makes
-about the wire — no active organization means no header at all, the stamp is not gated on
-`/api/` the way `Authorization` is, and the active organization overwrites a caller-set
-`X-Tenant-ID` — so the documentation cannot drift away from the behaviour unnoticed.
diff --git a/.changeset/text-input-description-aria-describedby-5735.md b/.changeset/text-input-description-aria-describedby-5735.md
deleted file mode 100644
index af1dc6abe2..0000000000
--- a/.changeset/text-input-description-aria-describedby-5735.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-'@object-ui/components': patch
----
-
-`element:text_input` now ties its authored `description` to the field with
-`aria-describedby`, so assistive tech announces the helper text as the input's
-accessible description instead of leaving it as an unassociated paragraph
-beside the field (objectui#5735).
-
-Before this the paragraph and the input were siblings with no programmatic
-relationship: a screen reader moving to the field announced the label and the
-value and never the helper text. The `label` half of the same block was already
-wired (`htmlFor` against the input's `id`), which is what made the gap specific
-to `description` rather than a general absence of a11y wiring — and the
-identical key authored on a field INSIDE `renderers/form/form.tsx` has been
-announced all along, so one authoring key behaved two ways depending on which
-container the author reached for. It no longer does.
-
-The paragraph's id is minted per instance with `React.useId()` — the same source
-`FormItem` mints the form renderer's description id from — and deliberately not
-derived from `schema.id`. The two associations in this block need ids on
-opposite ends: `htmlFor` names the INPUT, whose id only the author can supply,
-so that wiring still holds only when they gave the node an `id`; `aria-describedby`
-names the PARAGRAPH, which the renderer owns, so the description association
-holds unconditionally and cannot collide when two nodes share an authored id.
-The attribute is emitted only when a paragraph is actually rendered — an absent
-or empty `description` leaves the input with no `aria-describedby` rather than a
-dangling reference.
-
-The key's published `ComponentInput` description, which documented this gap in
-so many words, is rewritten in the same change. Its closing advice — prefer
-`label` for an instruction a user must not miss — is kept rather than deleted,
-on a new basis: a description is announced after the field's name and screen
-readers gate description text behind verbosity settings a user can turn down, so
-it remains the half of the announcement most likely to go unheard.
diff --git a/.changeset/text-input-i18n-label-arms-5717.md b/.changeset/text-input-i18n-label-arms-5717.md
deleted file mode 100644
index f8cbd403a3..0000000000
--- a/.changeset/text-input-i18n-label-arms-5717.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-'@object-ui/components': patch
----
-
-`element:text_input` now DECLARES the inline-translation arm on `label`,
-`placeholder` and `description`, so the manifest gate stops reporting
-`type-mismatch` on a locale map its own renderer has always resolved correctly
-(objectui#5717).
-
-`@objectstack/spec` types all three keys as the `I18nLabel` union
-(`string | Record<string, string>`) — measured on the installed 17.1.0 pin, per
-key, from the schema's own verdicts — and `text-input.tsx` has resolved all
-three through `pickLocalized` at their read sites since it was written. Only the
-`ComponentMeta` entries stayed at a single `'string'` arm. Driven through the
-same `manifestFromConfigs` + `validateTree` pair the JSX-page compiler and the
-save gate use, an author writing `{ en: 'Owner', 'zh-CN': '负责人' }` got three
-warnings on a write that renders correctly in the viewer's language:
-
-```
-<element:text_input> prop "label" expected a string
-<element:text_input> prop "placeholder" expected a string
-<element:text_input> prop "description" expected a string
-```
-
-That is the INVERSE of the direction the rest of this family moved in.
-`element:record_picker.emptyText` (objectui#5590) and that block's `label` /
-`placeholder` (objectui#5637) each held one arm for exactly as long as their
-render site dropped the map, and gained the object arm in the change that taught
-the render site to resolve it — never declare an arm the renderer drops. Here
-the render site was never behind, so the same rule's other half applies:
-withholding an arm the renderer resolves is the false declaration in the other
-direction, and noise on legal writes trains authors (AI authors included) to
-dismiss the `unknown-prop` and `type-mismatch` reports that are real.
-
-Per-key, not blanket. `defaultValue` on this same block keeps `['string',
-'number']` — its contract has no object arm, measured the same way — and the
-console specimen file keeps asserting that an `I18N_MAP` there still reports
-`type-mismatch`. That control is what makes this a widening of three keys rather
-than of a component.
-
-All three keys also gain a `description` written from what the renderer does
-rather than from restating the contract: where each one lands in the rendered
-output (a `<label>` above the field, the native `placeholder` attribute inside
-it, a `<p>` below it), when each is omitted, and the locale fallback chain the
-read site follows. No renderer behaviour changed.
diff --git a/.changeset/theme-clientvalidation-dead-entry-5715.md b/.changeset/theme-clientvalidation-dead-entry-5715.md
deleted file mode 100644
index 0f5648934d..0000000000
--- a/.changeset/theme-clientvalidation-dead-entry-5715.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-Removed the dead `theme:` entry from `clientValidation.ts`'s `LOADERS` table, which
-read `ThemeSchema` off `@objectstack/spec/ui` — a symbol the spec retired upstream
-(objectstack#10485 / PR objectstack#10695, which deleted the whole `ui/theme.zod.ts`
-module). `theme` was never a registered metadata type, so metadata-admin never asked
-for it (objectui#5715).
-
-This is dead-code hygiene, not a bug fix, and it changes nothing an author can
-observe. Two measurements say why, and both cut against the more dramatic reading:
-
-- The entry is not broken *today*. objectui's own `@objectstack/spec` pin (17.1.0)
-  still publishes `ThemeSchema` as a working strict Zod schema — measured by
-  importing the `ui` subpath and by ablation, where restoring the entry made
-  `validateMetadataDraft('theme', ...)` actively reject a draft. The skew is with
-  objectstack's `main`, not with what objectui installs, which is exactly why no
-  gate here ever went red.
-- It could never have crashed. `getSchemaForType` duck-checks the loader's result
-  (`typeof schema.safeParse === 'function'`) and wraps the call in `try/catch`, so an
-  `undefined` export degrades to a silent no-op validator, never a throw. After a
-  future spec bump past the retirement that is the branch it would have taken.
-
-The one thing that was genuinely off: `hasClientValidator` answers from key presence
-alone, so it returned `true` for `theme` while the validator behind it would have
-judged nothing. Per its own docblock that combination makes `ResourceEditPage` treat
-live client issues as the error source and suppress the server's `_diagnostics` — a
-stored item rendering as clean. Unreachable in practice, but it is the reason the
-entry is worth removing rather than leaving inert.
-
-The line is replaced by an absence note in the shape the file already uses for
-`workflow` and `approval`, because re-adding this entry from the spec would
-type-check and go green against the current pin. A metadata-admin theme editing
-surface remains a separate capability decision.
diff --git a/.changeset/theme-schema-doc-rewrite-5648.md b/.changeset/theme-schema-doc-rewrite-5648.md
deleted file mode 100644
index 52c05730ce..0000000000
--- a/.changeset/theme-schema-doc-rewrite-5648.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
----
-
-Docs-only: rewrite `content/docs/core/theme-schema.mdx` around the retained theme
-system (`Theme` from `@object-ui/types`, `ThemeEngine`, `ThemeProvider`) and delete
-the page's three `check-doc-component-types.mjs` exemption entries (objectui#5648).
-No published package changes.
diff --git a/.changeset/theme-types-localized-5716.md b/.changeset/theme-types-localized-5716.md
deleted file mode 100644
index 85b3fede0e..0000000000
--- a/.changeset/theme-types-localized-5716.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-'@object-ui/types': minor
-'@object-ui/providers': minor
----
-
-Localize the theme document types: `@object-ui/types` now owns `Theme`, `ThemeMode` and `ColorPalette` (objectui#5716 ruling, 2026-08-23). The spec retired its theme module (objectstack#10485) while ObjectUI retained the theme system, so the types are hand-written from the last-published `@objectstack/spec` 17.1.0 shapes instead of re-exported — a spec dependency refresh past the retirement no longer breaks these packages.
-
-Published-name REMOVALS from `@object-ui/types` (zero in-repo readers, deleted under the same ruling's rider):
-
-- `Typography` — the shape lives on as the inline `Theme['typography']` member.
-- `BorderRadius` — lives on as inline `Theme['borderRadius']`.
-- `Shadow` — lives on as inline `Theme['shadows']`.
-- `ThemeDefinition` — the deprecated alias of `Theme`; use `Theme`.
-
-Also added: `THEME_MODES`, a runtime tuple witness of the theme mode vocabulary (`['auto', 'light', 'dark']`).
-
-The `UI` protocol namespace (`import { UI } from '@object-ui/types'`) now resolves `UI.Theme` / `UI.ThemeMode` / `UI.ColorPalette` to the local owners, so they survive the upcoming spec refresh; the rest of the namespace continues to track `@objectstack/spec/ui`. After that refresh, retired spec/ui members (`UI.ThemeSchema`, `UI.ThemeModeSchema`, `UI.ThemeParsed`, `UI.Typography`, `UI.BorderRadius`, `UI.Shadow`, `UI.defineTheme`) drop out of the namespace.
-
-`@object-ui/providers`: `ThemePreference` is now derived from `@object-ui/types`' `ThemeMode` instead of the retired spec `ThemeModeSchema` (same union: `'auto' | 'light' | 'dark' | 'system'`).
diff --git a/.changeset/theme-zod-retired-spec-reexports.md b/.changeset/theme-zod-retired-spec-reexports.md
deleted file mode 100644
index 68023be60c..0000000000
--- a/.changeset/theme-zod-retired-spec-reexports.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-'@object-ui/types': minor
----
-
-Remove the six retired `@objectstack/spec/ui` theme-schema re-exports from `@object-ui/types/zod` — `ColorPaletteSchema`, `TypographySchema`, `BorderRadiusSchema`, `ShadowSchema`, `ThemeModeSchema`, `ThemeDefinitionSchema` (the spec's `ThemeSchema`) — plus their `…SchemaType` inference helpers, and the `theme` / `mode` props of `ThemePreviewSchema` (zod and interface) that consumed them.
-
-objectstack#10485 (ADR-0049 enforce-or-remove, PR objectstack#10695) retired the spec's whole `ui/theme.zod.ts` module, and the maintainer's ruling on objectstack#10856 (Options A + C) has objectui remove the dangling imports first so the Console Pin Gate can build objectui against the framework tree; restoring the spec exports (Option B) was explicitly not taken. Breaking in effect for anyone importing those six names from `@object-ui/types/zod`: there is no replacement — the validators retired upstream with no successor. The theme TYPE surface (`Theme`, `ThemeMode`, `ColorPalette`, … re-exported from `@object-ui/types`) and the ThemeEngine/ThemeProvider runtime are unchanged.
diff --git a/.changeset/tidy-donkeys-attack.md b/.changeset/tidy-donkeys-attack.md
deleted file mode 100644
index a7314fd9e4..0000000000
--- a/.changeset/tidy-donkeys-attack.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-"@object-ui/plugin-form": patch
----
-
-`navigateOnSuccess` now honours a mounted host, and says so when its destination is refused
-
-`ObjectForm` and `WizardForm` consume `navigateOnSuccess` through
-`resolveSuccessNavigate`, and both arms travelled to an accepted destination with a bare
-`window.location.assign`. A rooted path such as `/apps/x/o/record/{id}` assigned that way
-resolves against the ORIGIN root, so under a host mounted at a sub-path (the framework CLI
-configures one for every embedded deployment) an authored in-app destination left the
-application. Both arms now route an app-relative destination through the injected
-navigation seam both components already held for `submitBehavior.url`, so a mounted host's
-basename is applied. With no host seam the behaviour is byte-for-byte what it was — a host
-with no router has no basename, so origin-rooted resolution is already correct there. A
-same-origin ABSOLUTE destination also keeps browser-level navigation: the seam's declared
-input is an application-relative path, and an author who spelled out a whole address asked
-for that address.
-
-A declared `navigateOnSuccess` whose destination is refused — a mistyped value, or a written
-record carrying no usable id — used to produce a success toast identical to the one a form
-with no `navigateOnSuccess` produces, so the navigation failed with nobody told. That toast
-now carries a note that the declared navigation did not happen, and the template the author
-wrote is logged for them. The write genuinely succeeded, so this stays a success rather than
-becoming an error state.
-
-Which destinations are ACCEPTED is unchanged: the same-origin guard, the `{id}` /
-`{recordId}` dialect and the unescaped interpolation are the subject of an open contract
-question and are deliberately untouched here.
diff --git a/.changeset/tidy-forms-carry-spec-keys.md b/.changeset/tidy-forms-carry-spec-keys.md
deleted file mode 100644
index 5cb3c5052c..0000000000
--- a/.changeset/tidy-forms-carry-spec-keys.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-'@object-ui/react': patch
----
-
-fix(react): stop the form-view bridge silently dropping 18 spec keys
-
-`spec-bridge/bridges/form-view.ts` promised (#2545) that "every serializable
-spec key is either mapped onto the `object-form` node or listed here with an
-explicit reason for being ignored". Measured against `@objectstack/spec` 17.2.0
-the promise was false for 18 keys, because the conformance test enforcing it ran
-its completeness loop over its own hand-written fixture rather than the
-contract's key set.
-
-Seventeen of them now reach the node, at the destinations the receiving layer
-already reads:
-
-- `FormViewSchema.buttons` / `.defaults` — `ObjectFormSchema` declares both and
-  `ObjectForm` folds them at render (action-button visibility/labels, and
-  create-mode initial values).
-- `FormSection.pane` — explicit split-pane placement; without it a spec-authored
-  split form fell back to the positional rule, so reordering sections moved them
-  across the divider.
-- `FormSection.visibleOn` — the deprecated spelling now folds onto `visibleWhen`,
-  matching the contract's own parse-time normalisation and the field path.
-- Thirteen `FormFieldSchema` keys — `maxLength`, `minLength`, `min`, `max`,
-  `precision`, `scale`, `multiple`, `immutable`, `span`, `language`, `keyField`,
-  `disclosure`, `fields` — so authored constraints, composite config and field
-  width survive the bridge instead of ending there.
-
-`publicPicker` is deliberately not carried and now says so: it is a server-side
-public-lookup authorization opt-in with no client destination.
-
-The conformance test's key set is now derived from the contract's own shape at
-all three levels, so a spec key that is neither mapped nor explained fails the
-suite by construction.
diff --git a/.changeset/tidy-forms-refuse-target-less-submit.md b/.changeset/tidy-forms-refuse-target-less-submit.md
deleted file mode 100644
index 2a4f20ce58..0000000000
--- a/.changeset/tidy-forms-refuse-target-less-submit.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-'@object-ui/plugin-form': patch
----
-
-Variant forms refuse a submit that has nowhere to go, instead of reporting success
-
-`TabbedForm`, `WizardForm`, `SplitForm`, `DrawerForm` and `ModalForm` each opened
-`handleSubmit` with `if (!dataSource) { await schema.onSuccess?.(data); return data; }`
-— a success signal emitted without consulting a declared `submitHandler` and without
-persisting anything. Through `MasterDetailForm`, whose parent schema declares both
-`submitHandler: submitViaBatch` and `onSuccess: handleSaved`, that produced a success
-toast and, in create mode, a form reset clearing values nobody wrote.
-
-All five now answer the question the same way `SimpleObjectForm` and the `object-form`
-element gate already do. A form has a submit target when it has a `dataSource` or a
-declared `submitHandler`; with neither, the one legitimate shape is inline fields —
-a non-empty `customFields`, or `sections` whose fields are all inline runtime
-`FormField` objects — whose `onSuccess` is the write. Anything else throws
-`DataSource is required for form submission (inline mode not configured)`, which
-reaches `schema.onError` and is rethrown. A declared `submitHandler` is consulted
-first, so a host that owns the write is never bypassed for want of an adapter it
-never needed.
diff --git a/.changeset/tidy-jars-confirm.md b/.changeset/tidy-jars-confirm.md
deleted file mode 100644
index d0e53b6461..0000000000
--- a/.changeset/tidy-jars-confirm.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
----
-
-Comment-only change in `@object-ui/core`: `ConfirmationHandler`'s declaration now
-names the out-of-runner producer of its `options` bag, so a runner-scoped liveness
-sweep no longer reads the parameter as declared-but-never-produced. No behaviour,
-no type surface and no published output changes.
diff --git a/.changeset/timeline-shared-safe-field-label-5623.md b/.changeset/timeline-shared-safe-field-label-5623.md
deleted file mode 100644
index 58af0449fb..0000000000
--- a/.changeset/timeline-shared-safe-field-label-5623.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
----
-
-Internal dedup: `ObjectTimeline` now uses the shared `useSafeFieldLabel` from
-`@object-ui/react` instead of its own local `useSafeObjectLabel` wrapper /
-`OBJECT_LABEL_FALLBACK` (objectui#5623). No exported symbol changed and the
-timeline's `fieldOptionLabel` call site behaves identically on both the
-bound and unbound i18n paths — no published behaviour changes.
diff --git a/.changeset/unbundled-node-boundary-5384.md b/.changeset/unbundled-node-boundary-5384.md
deleted file mode 100644
index cefdbb0617..0000000000
--- a/.changeset/unbundled-node-boundary-5384.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-'@object-ui/plugin-dashboard': patch
-'@object-ui/plugin-map': patch
-'@object-ui/app-shell': patch
----
-
-Each package's README now states, up front, that it needs a bundler: importing it from plain Node ESM fails, and that is a supported-configuration boundary rather than a defect.
-
-`@object-ui/plugin-dashboard` imports `react-grid-layout/css/styles.css` at module
-scope and `@object-ui/plugin-map` imports `maplibre-gl/dist/maplibre-gl.css`;
-`@object-ui/app-shell` reaches the first of those through the static
-`@object-ui/plugin-dashboard` imports in `DashboardView` and `ReportView`. Node has
-no loader for `.css` at all, so all three resolve and then die during evaluation:
-
-```
-TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".css"
-  for .../react-grid-layout/css/styles.css
-```
-
-Nothing about how these packages load has changed — every supported host bundles
-them (Vite, webpack, or Next with the package in `transpilePackages`), and that is
-still the only supported way to consume them. What changed is that the boundary is
-now written where a consumer meets it, instead of being learned from a red import.
-
-objectui#5384 ruled unbundled Node consumption **unsupported** for style-carrying
-plugin packages — permanently, over the three packages as a group — rather than
-moving the stylesheet imports out of module scope. No unbundled-Node consumer
-exists, and buying permanent machinery to close a capability gap nobody is pulling
-on was the trade the ruling declined. A real consumer request reopens it as a
-design question, not as a defect: the READMEs say so and name the issue.
diff --git a/.changeset/unified-pending-drafts-5801.md b/.changeset/unified-pending-drafts-5801.md
deleted file mode 100644
index 126a5442a5..0000000000
--- a/.changeset/unified-pending-drafts-5801.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-'@object-ui/app-shell': minor
----
-
-One pending-drafts source of truth (#5801): `usePendingDrafts` / `fetchPendingDrafts` replace the five hand-rolled `GET /api/v1/meta/_drafts` copies behind the home banner, Studio topbar 变更/待发布 buttons, chat pending-drafts bar, chat draft-card resolver, and the preview watermark bar. Every successful publish path (`usePublishAllDrafts`, Studio `doPublish`, the chat bar) now emits the assistant bus's metadata-refresh pulse, and a chat turn that staged or replayed drafts emits it on completion — so a publish or an agent-staged draft anywhere converges every surface at once, and the home banner no longer needs its post-publish `window.location.reload()`. An errored drafts read now uniformly reports UNKNOWN (null), never a fake zero.
diff --git a/.changeset/uniqueness-deprecation-jsdoc-4765.md b/.changeset/uniqueness-deprecation-jsdoc-4765.md
deleted file mode 100644
index 64fc315d67..0000000000
--- a/.changeset/uniqueness-deprecation-jsdoc-4765.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-'@object-ui/types': patch
----
-
-Corrects the `@deprecated` prescription on `UniquenessValidation` in
-`packages/types/src/data-protocol.ts`, which pointed authors at spellings the platform
-no longer accepts (objectui#4765).
-
-Comment-only — no runtime behaviour changes. `patch` rather than an empty frontmatter
-because the JSDoc sits on an **exported** declaration and therefore ships to consumers:
-measured with the package's own build (`tsc`, and `tsconfig.base.json` deliberately sets
-`removeComments: false`), `dist/data-protocol.d.ts` goes 40218 → 41781 bytes and the new
-prose is present in the emitted `.d.ts`. What a consumer reads on hover changes, so it
-is declared. The emitted `dist/data-protocol.js` is byte-identical (sha256
-`a3de34c5…`, 207 bytes both ways) — that file is a types-only module whose entire JS
-output is the license banner plus `export {}`, so a comment on an erased `interface`
-reaches the declaration file and nothing else.
-
-Two of the three spellings it prescribed were wrong, measured against the installed
-`@objectstack/spec@17.0.0` (the report was written against `17.0.0-rc.6`):
-
-- **`indexes[].partial`** was retired in spec 17.0.0 under ADR-0049. It is a tombstone
-  (`z.never()`) that the parse rejects at any value, so "`partial` for a scoped
-  constraint" named a key that cannot be declared. A predicated unique constraint is
-  built at the database layer by a runtime migration issuing
-  `CREATE UNIQUE INDEX … WHERE`; the prescription now says so.
-- **`{ fields, unique: true }`** on `ObjectSchema.indexes` is the deprecated positional
-  spelling of `unique: 'global'` under ADR-0120 — lint `unique/unscoped-declared-index`
-  warns in 17.x and protocol 18 rejects it. The prescription now states the scope:
-  `unique: 'global' | 'organization'`.
-
-The measurement also refined the report, and the refinement is the reason the rewrite is
-not a uniform find-and-replace. The third spelling — **field-level** `unique: true` — is
-NOT deprecated. `unique` is scope vocabulary shared by two surfaces on which the same
-bare `true` means different things: at index level it stays verbatim (`isGlobalUnique`
-and `isOrganizationUnique` both return `false`), which is why it is the positional
-spelling of `'global'` and is being retired; at field level it is the positional spelling
-of `'organization'` and, in the spec's own words, "stays valid indefinitely … no trap".
-Rewriting both occurrences the same way would have replaced one piece of false guidance
-with another, so the comment now names the per-surface difference explicitly.
-
-The interface's own deprecation is untouched and remains correct: `ValidationRuleSchema`
-rejects `type: 'unique'` at the discriminator (accepted discriminants are `script`,
-`state_machine`, `format`, `cross_field`, `json_schema`, `conditional`), so a rule in
-this shape cannot reach the server.
-
-The replacement closes with what would falsify it — `UniqueScopeSchema` and
-`IndexSchema` in `@objectstack/spec` — so the next reader checks the schemas rather than
-trusting the paragraph. This is the fourth piece of false guidance found in this
-campaign (strictness ledger finding 18), and prose that cannot be checked is how the
-first three survived.
diff --git a/.changeset/unknown-component-type-case-suggestion-5247.md b/.changeset/unknown-component-type-case-suggestion-5247.md
deleted file mode 100644
index 0bfd69d29f..0000000000
--- a/.changeset/unknown-component-type-case-suggestion-5247.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-"@object-ui/react": patch
-"@object-ui/cli": patch
----
-
-Name the case-only spelling when a component type misses the registry.
-
-Registry lookup is exactly case-sensitive, so a node typed `Page` misses a registered `page` and falls through to the OBJUI-001 "Unknown component type" panel. Because the mistake is usually uniform across a document, the symptom is not one broken widget — it is the whole page rendering as error panels, with nothing in the message pointing at the cause.
-
-Both surfaces that report the miss now name the spelling that would have resolved. `SchemaRenderer`'s panel reads `Unknown component type: Page — did you mean 'page'?`, and `objectui check` reports `Unknown schema type "Page" in <file> — did you mean "page"?`. When no known type differs by case alone, neither says anything extra — `zzz` gains no bogus suggestion, and this is case matching, not an edit distance, so `pge` suggests nothing either.
-
-**Lookup itself does not change.** `Page` still misses, still fails, and still renders the panel; only the message teaches. Normalising the lookup was considered and rejected (objectui#5247, maintainer ruling 2026-08-19): it would make two spellings valid everywhere, permanently, and legalise the typo class (`PAGE`, `pAge`) along with the PascalCase convention.
-
-Each surface reads its candidates from the set it can actually trust — the renderer from the live `ComponentRegistry` (including pending lazy stubs), the CLI from the registration-derived `KNOWN_SCHEMA_TYPES` snapshot — so neither can suggest a type nothing registers.
diff --git a/.changeset/utilities-index-phantom-provider-5360.md b/.changeset/utilities-index-phantom-provider-5360.md
deleted file mode 100644
index 4c7a34666a..0000000000
--- a/.changeset/utilities-index-phantom-provider-5360.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
----
-
-Docs and gate ledger only — this publishes nothing, declared explicitly with an empty
-frontmatter rather than left undeclared.
-
-`content/docs/utilities/index.md`'s "Data Integration" section taught
-`import { ObjectStackProvider } from '@object-ui/data-objectstack'`, a React context
-provider on a package that is headless and exports no such thing. Compiled against the
-built `dist/index.d.ts` by the same harness `scripts/check-doc-snippet-types.mjs` uses,
-the block read
-`TS2724: '"@object-ui/data-objectstack"' has no exported member named 'ObjectStackProvider'`,
-so a reader who copied it did not get a runtime bug — they got a compile error. #4124 had
-already established the finding and PR #4129 fixed it on the sibling page
-`content/docs/utilities/data-objectstack.mdx`; the identical phantom survived one file
-over, in the utilities index, outside that card's file surface.
-
-The section now teaches the same shape PR #4129 established: `createObjectStackAdapter`
-returning a plain `DataSource`, injected at the renderer boundary through
-`@object-ui/react`'s `SchemaRendererProvider`. The block is also self-contained — it
-imports every name it uses and types its schema literal as the real `ObjectGridSchema` —
-so it compiles exactly as a reader who copies that one block experiences it.
-
-Because that was the page's only `ts`/`tsx` block and it now produces zero diagnostics,
-`content/docs/utilities/index.md` LEAVES `check-doc-snippet-types.mjs`'s `UNGATED_DOCS`
-ledger instead of getting a re-measured reason: the page is compiled by the gate from
-here on, and no entry on that ledger names a missing export any more.
diff --git a/.changeset/vacuous-dts-justification-5673.md b/.changeset/vacuous-dts-justification-5673.md
deleted file mode 100644
index 37fe29375b..0000000000
--- a/.changeset/vacuous-dts-justification-5673.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-'@object-ui/core': patch
----
-
-Withdraw the entry-surface justification on core's `SchemaNode` re-export, and put
-the gauge that can actually fail in its place (objectui#5673).
-
-`packages/core/src/types/index.ts` carried, as the justification for the #4580
-re-export convergence, *core's own entry surface is unchanged (`dist/index.d.ts` is
-byte-identical across the change — measured, both rounds)*. The reading was real and
-it certified nothing. `core/dist/index.d.ts` is emitted from a barrel that only
-FORWARDS the symbol, and forwarding never restates a shape — not `export *`, and not
-the `export type { … }` line that names this one. Only the module that DECLARES the
-symbol can move, so that file is byte-identical under any change to a re-exported
-declaration's shape, and it could not have failed for the change class it was quoted
-against.
-
-Measured for this change rather than argued. One optional key was injected into
-`BaseSchema` — the shape `SchemaNode` publishes — both packages were rebuilt from a
-cleared `dist/` and a cleared `tsconfig.tsbuildinfo`, then the probe was dropped and
-both rebuilt again:
-
-| emitted file | base | with probe | probe dropped |
-|---|---|---|---|
-| `@object-ui/types` `dist/base.d.ts` — declares the shape | `31b5a01d…` | `8487500e…` **moved** | `31b5a01d…` |
-| `@object-ui/core` `dist/types/index.d.ts` — forwards it | `0e64c8c6…` | `0e64c8c6…` | `0e64c8c6…` |
-| `@object-ui/core` `dist/index.d.ts` — entry barrel, names it | `5cca207a…` | `5cca207a…` | `5cca207a…` |
-
-The corrected block states that calibration as a recipe with its failure mode, so the
-next reader inherits a gauge that can be checked instead of a sentence that cannot.
-The `ComponentRendererProps` block below it already reached the right verdict, but
-gave a narrower reason for it — that core's entry is an `export *` barrel — which is
-not the mechanism, and is wrong for a symbol the barrel names on its
-`export type { … }` line; it now states the forwarding rule.
-
-Documentation only, in a published declaration file: these docblocks sit on export
-specifiers, so `core/dist/types/index.d.ts` carries them into the tarball, while
-`core/dist/index.d.ts` does not move for them either — the same insensitivity,
-demonstrated once more on this very change. No type moves and no runtime behaviour
-changes.
diff --git a/.changeset/view-column-io-canonical-identity-5725.md b/.changeset/view-column-io-canonical-identity-5725.md
deleted file mode 100644
index 51eab73b65..0000000000
--- a/.changeset/view-column-io-canonical-identity-5725.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-'@object-ui/app-shell': minor
----
-
-The metadata designer's View **column list** now reads a column's identity —
-row label and bound field name — in the ObjectStack canonical spelling only:
-`field` and `label`. The legacy TanStack aliases `accessorKey` / `header` are no
-longer consulted (objectui#5725). This is the editor-side half of the read
-objectui#5344 retired in the column inspector one file over; the two surfaces
-render inside the **same panel** and until now gave the author two different
-answers about what a column is called.
-
-Why this is a behaviour change and not a tidy-up: `ListColumn` refuses both
-legacy keys by name (`unrecognized_keys`), so a column carrying them has no
-field key and no label the spec recognises. Two consequences the list surface
-had that the inspector did not:
-
-- **The label chain was inverted, not merely tolerant.** It read
-  `label ?? header ?? field ?? accessorKey`, preferring the undeclared `header`
-  **over** the declared `field`. A perfectly canonical column that also carried
-  a stray `header` key displayed the alias' value *instead of* its own declared
-  identity.
-- **The field-name read backs more than a label.** It feeds `usedFieldNames()`,
-  which the Add-field picker consults, so a spec-refused column reserved a field
-  name and the picker tagged that field "Added" — for a column no accepted
-  document actually binds.
-
-**What an author sees:** a stored column shaped `{ accessorKey, header }` is now
-named positionally in the list (`col 1`) rather than by its refused spelling,
-and the row stays selectable exactly as before — the positional fallback already
-existed at the end of that chain. The Add-field picker no longer reports such a
-column's field name as taken. Canonical `{ field, label }` columns and
-bare-string columns are untouched, and a declared `label` / `field` now outranks
-any stray alias beside it.
-
-**What is deliberately NOT changed:** the write path. These helpers still
-reorder and splice the raw `columns` array without normalising it, so no stored
-document is rewritten by the act of viewing or editing it — the same fence
-objectui#5344 held.
diff --git a/.changeset/view-overlay-write-patch-only-5233.md b/.changeset/view-overlay-write-patch-only-5233.md
deleted file mode 100644
index 427d2ae8a1..0000000000
--- a/.changeset/view-overlay-write-patch-only-5233.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-'@object-ui/app-shell': patch
----
-
-A view personalization overlay now stores **only the patch** — a column drag no
-longer freezes the source view's filter into it (objectui#5233).
-
-`ObjectView`'s `persistViewPatch` wrote `{ ...baseViewDef, ...patch }`, so an
-overlay written by a mere sort/density/column change copied the view's *current
-effective* `filter` — along with its `columns`, `label`, `type`, `isDefault` —
-into the stored row. The display merge is `{ ...source, ...override }`, so that
-copy then outranked the source view forever: an admin edited the view's filter
-and every user who had once resized a column silently kept the old filter, with
-nothing anywhere reporting it.
-
-The write now goes through the exported seam `buildPersistedViewBody`. For a
-**system view's overlay** the body is the patch plus `viewKind` when the active
-tab carries one — identity, not content, and the same line the read side already
-draws (`VIEW_OVERLAY_IDENTITY_KEYS`); `object`, `name` and the overlay marker are
-stamped by the adapter. A **saved view's own row** is deliberately still written
-whole: for it the body *is* the view, there is no source underneath it for a
-copied key to shadow, and the write is a whole-document PUT — narrowing it would
-delete the user's view rather than narrow it.
-
-This is the write half of the maintainer's 2026-08-12 ruling (objectstack#7494).
-It was blocked until `columnState` was admitted to the view-metadata surface as
-an explicitly runtime-only overlay key (objectstack#9933, released in
-`@objectstack/spec` 17.1.0) — before that a `columnState`-only patch was refused
-`422 INVALID_METADATA`, and the fat copy was the only thing supplying a
-recognized key. The read half (`narrowPersonalizationOverlay`) shipped earlier
-and stays: rows written before this land are still tolerated on read, and because
-the write replaces the whole document, the next toolbar toggle also strips such a
-row at rest. No migration.
diff --git a/.changeset/view-switcher-chart-gantt-icons-5586.md b/.changeset/view-switcher-chart-gantt-icons-5586.md
deleted file mode 100644
index 257d32d34d..0000000000
--- a/.changeset/view-switcher-chart-gantt-icons-5586.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-'@object-ui/plugin-view': patch
----
-
-`ViewSwitcher` draws an icon for `chart` and `gantt` views again, and both
-icon maps in the package now name only spellings lucide still resolves
-(objectui#5586).
-
-`ViewSwitcher.resolveIcon` turns an icon NAME into a component by looking it up
-in lucide's runtime `icons` record. lucide retires a spelling by dropping it
-from that record while KEEPING it as a deprecated named export, so a retired
-name still imports, still type-checks and still renders as a component — and
-silently resolves to nothing as a string. `ObjectView` composes the switcher
-from names, and two of them had been retired on lucide-react 1.31.0:
-`chart: 'bar-chart-3'` and `gantt: 'gantt-chart'`. Both view types rendered as a
-label with no icon at all while every sibling type had one, and nothing went red
-because no lucide symbol appears in that map for the compiler to check. Measured
-against the installed package: `BarChart3` and `GanttChart` are absent from
-`icons`, while `ChartColumn` and `ChartGantt` are present.
-
-- `ObjectView`'s `iconMap`: `bar-chart-3` → `chart-column`,
-  `gantt-chart` → `chart-gantt`.
-- `ViewSwitcher`'s `DEFAULT_VIEW_ICONS`: the adjacent entries that named
-  deprecated aliases move to the names the record carries —
-  `BarChart3` → `ChartColumn`, `GanttChartSquare` → `ChartGantt`,
-  `Grid` → `Grid3x3`. `ChartColumn`/`Grid3x3` are the same components the
-  aliases already pointed at, so those two glyphs are unchanged; the `gantt`
-  default picks up the plain gantt glyph, which is what `iconMap` now supplies
-  for that view type.
-
-The regression pin widens from `tree` alone to EVERY name both maps supply: a
-pin scoped to the two names that broke would not have caught this and would not
-catch the next lucide bump.
diff --git a/.changeset/viewcolumn-identity-canonical-read-5344.md b/.changeset/viewcolumn-identity-canonical-read-5344.md
deleted file mode 100644
index 4a7fcd06eb..0000000000
--- a/.changeset/viewcolumn-identity-canonical-read-5344.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-'@object-ui/app-shell': minor
----
-
-The metadata designer's View column inspector now reads a column's identity —
-field key and label — in the ObjectStack canonical spelling only: `field` and
-`label`. The legacy TanStack aliases `accessorKey` / `header` are no longer
-consulted (objectui#5344).
-
-Why this is a behaviour change and not a tidy-up: `ListColumn` refuses both
-legacy keys by name (`unrecognized_keys`), so a column carrying them has no
-field key the spec recognises. The inspector nevertheless read them and
-displayed `accessorKey`'s value in the field-key box, presenting a spec-refused
-key as though it were a valid column identity — the same consumer-side
-tolerance alias `ObjectGrid` retired in objectui#5068, surviving one layer up in
-the authoring tool, which is the surface that is supposed to teach the correct
-shape.
-
-**What an author sees:** a stored column shaped `{ accessorKey, header }` now
-shows an EMPTY field key and an empty header, and is re-authored rather than
-silently carried. Canonical `{ field, label }` columns and bare-string columns
-are untouched.
-
-**What is deliberately NOT changed:** the writeback. `patchIdentity` still
-re-emits whichever spelling it was handed, so no stored document is rewritten
-by the act of editing it. Normalising on write was ruled out once the
-maintainer confirmed there is no population of legacy stored documents to
-migrate; such a column stays unsaveable against the spec both before and after
-an edit, exactly as it did before this change. What this removes is the
-invisibility of that state, not the state itself.
diff --git a/.changeset/visiblewhen-record-binding-5454.md b/.changeset/visiblewhen-record-binding-5454.md
deleted file mode 100644
index 8cf9b2e4b5..0000000000
--- a/.changeset/visiblewhen-record-binding-5454.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-'@object-ui/react': minor
----
-
-Bind `record` into the node-level visibility evaluator, and stop a hoisted
-`properties.visible` swallowing a declared `visibleWhen`.
-
-`@objectstack/spec` has declared since ADR-0089 that a page component's
-`visibleWhen` binds the row — `ui/page.zod.ts`: *"Binds `record`,
-`current_user`, `page.<var>`"*. `SchemaRenderer` bound no `record` at all. Its
-evaluator was built from the ambient predicate scope, `data: dataSource` (the
-connector **adapter**, not the row) and `page: pageVariables`; the row lives in
-`RecordContext`, which that evaluator never read.
-
-Because the surface is fail-soft, a `record.*` predicate did not misfire — it
-resolved to **shown**. Both polarities of the same predicate returned the same
-verdict, so a visibility gate silently did not gate, on every block on every
-record page. Measured on `record:alert`, `record:path`, `page:card` and
-`element:text`.
-
-Three changes, all in `SchemaRenderer`'s evaluation memo:
-
-- **`record` is bound**, as the `record` root only — the three roots the
-  describe promises and nothing more. Not as bare fields, and never over
-  `data`, which is what `${data.*}` in a props bag resolves against. Bound
-  conditionally, so "no row" binds nothing rather than shadowing a `record` a
-  host supplied through the ambient scope.
-- **`visibleWhen` is tested before `visible`.** The memo hoists `properties.*`
-  onto the node, so a node carrying `properties.visible` short-circuited the
-  declared node predicate — the one key the spec tells authors to write was the
-  one key that could be silently ignored. The two deprecated aliases
-  (`visibleOn` / `visibility`) deliberately keep their rank: they normalize into
-  `visibleWhen` at parse, so a spec-parsed page never reaches them.
-- **An unresolvable predicate is loud** (dev builds). Fail-soft answered "this
-  predicate is broken" and "this predicate said yes" with the same word. The
-  verdict is unchanged on every path — `evaluateCondition` already returned
-  `true` for every unevaluable predicate, including the non-negated `hidden` /
-  `hiddenOn` legs where that `true` means HIDE — so only the silence moved.
-
-**Behaviour change, stated plainly:** a shipped page whose node-level
-`record.*` predicate was previously inert now evaluates. A block that was
-permanently visible may begin to hide — which is the point, but it is a verdict
-change, not a no-op. `properties.visible` is unaffected in verdict: an
-in-tree census found **zero** node-level `record.*` predicates on page
-components, so nothing in this repository changes verdict.
diff --git a/.changeset/vitest-invocation-guard-package-cwd-coverage-5406.md b/.changeset/vitest-invocation-guard-package-cwd-coverage-5406.md
deleted file mode 100644
index 61e50a177f..0000000000
--- a/.changeset/vitest-invocation-guard-package-cwd-coverage-5406.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
----
-
-Test tooling only — this publishes nothing, declared explicitly with an empty frontmatter
-rather than left undeclared.
-
-`assertCanonicalVitestInvocation` refuses a package-cwd Vitest run because such a run uses
-a different config than CI does, so its green says nothing about CI. Its docstring claimed
-that "every per-package `vitest.config.ts` re-exports the root config, and a package
-without one resolves upward to it, so no package-level path skips this file". Measured, by
-running `pnpm exec vitest run` from every directory that carries a config: 8 package
-configs import the root config and were refused, 2 packages carry no config and resolve
-upward and were refused, and **11 standalone configs never mention the root file at all**
-(`plugin-calendar`, `-charts`, `-detail`, `-form`, `-gantt`, `-grid`, `-kanban`, `-list`,
-`-map`, `-timeline`, `-view`) — nothing imported the guard from there, so it never ran.
-From `packages/plugin-grid`, one such run printed `Test Files 1 passed (1)` /
-`Tests 5 passed (5)` and exited 0, under a config carrying no `@object-ui/*` alias table
-at all where the root config maps ~40 specifiers at sibling `src/`. The guard's hole sat
-exactly where the divergence — and therefore the false-green risk — was largest.
-
-Those 11 configs now call the guard themselves, through a new
-`repoRootFrom(import.meta.url)` landmark search rather than a hand-counted `../..` (which
-resolves to a real directory when the count is wrong, so the guard would keep issuing
-verdicts computed against the wrong root). The docstring and the root config's call-site
-comment now describe the three routes a config can take instead of asserting one of them,
-and the claim is enforced rather than restated: the guard's own test walks every
-`vitest.config.*` in the repo and fails on any that takes neither route.
-
-No package `src/` is touched and the configs' test semantics are unchanged, so no
-`@object-ui/*` package changes behaviour and there is nothing here for a consumer to
-upgrade to.
diff --git a/.changeset/widget-config-panel-locale-map-5301.md b/.changeset/widget-config-panel-locale-map-5301.md
deleted file mode 100644
index 511b33d162..0000000000
--- a/.changeset/widget-config-panel-locale-map-5301.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-'@object-ui/plugin-dashboard': patch
-'@object-ui/i18n': minor
----
-
-`WidgetConfigPanel` reads an inline-locale-map title, and a save no longer destroys the other locales.
-
-The dashboard widget config panel carried a private `resolveLabel` documented as
-resolving an `I18nLabel` while reading `defaultValue || key` — the key-reference
-form `@objectstack/spec` retired at 17.0.0-rc.6 (objectstack#5055). The inline
-per-locale map `I18nLabelSchema` actually admits has neither limb, so
-`{ en: 'Revenue', zh: '收入' }` resolved to `''`. It was the fourth private copy
-of that resolver; objectui#4032 swept the other three out of `DashboardRenderer`,
-`MetricWidget` and `MetricCard`.
-
-This was not a display bug. The resolved value seeds the panel's editable draft,
-so a widget whose stored title was a map opened with an **empty** Title field and
-the next save wrote `''` over the author's map — on the ordinary path, not an
-exotic one: open the widget, change anything, save.
-
-Both halves are fixed, per the maintainer's 2026-08-20 ruling on objectui#5301:
-
-- **Reading** goes through `pickLocalized(value, language)`, so the panel shows
-  the active locale like every sibling surface post-objectui#4032.
-- **Writing** replaces only the active locale's entry and carries every other
-  locale across. A title the author never touched round-trips the stored object
-  itself through an unrelated config edit; an edited one merges into the entry
-  that was displayed. The live-update callback (`onFieldChange`) forwards the
-  merged map for the same reason — hosts feed it back into the widget the panel
-  re-opens from, so a bare string there dropped the map before a save ever ran.
-
-`@object-ui/i18n` gains `setLocalized(value, language, next)`, the write-side
-inverse of `pickLocalized`, so the rule is stated once instead of re-derived per
-panel. It follows `pickLocalized`'s first three limbs — exact tag, base language,
-region-qualified sibling — and deliberately stops there: the `default` / `en` /
-first-value limbs are display fallbacks that hand back *another* locale's string,
-and writing to one would let an author editing in `fr` overwrite English. With no
-entry for the active locale the edit adds one. The pairing
-`pickLocalized(setLocalized(map, lang, s), lang) === s` is pinned, because a
-write that lands where the read does not look is how a "saved" string disappears.
-
-A full multi-locale editing UI remains out of scope (objectui#4163).
diff --git a/.changeset/widget-input-control-vocabulary-5675.md b/.changeset/widget-input-control-vocabulary-5675.md
deleted file mode 100644
index 43d23f920d..0000000000
--- a/.changeset/widget-input-control-vocabulary-5675.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-'@object-ui/types': patch
----
-
-`WidgetInput.type` now uses the shared arm vocabulary `ComponentInputControlType`
-instead of restating its eleven literals inline (objectui#5675).
-
-That vocabulary has had a name since objectui#3832, and objectui#4972 converged the
-last structural copy of the surrounding `ComponentInput` interface onto one
-declaration. `WidgetInput` was the remaining site spelling the arms out — a third
-copy of one list, with nothing tying it to the other two.
-
-**No value a widget author may write changes.** The inline restatement was measured
-member-equal to the shared declaration in both directions before it was replaced
-(eleven arms each, same set, and in the same order), so this is a convergence rather
-than a widening or a narrowing. `WidgetInput.type` also stays the SINGLE-kind form:
-`ComponentInput.type` additionally accepts an array of arms for a union-typed key
-(objectui#3832), and importing that capability here would have been a widening, so
-it was deliberately left out — the same disposition objectui#4972 recorded when it
-left this face alone.
-
-What the convergence buys is that one of the two drift directions was **silent**.
-`WidgetRegistry.load()` in `@object-ui/core` translates each `WidgetInput` into a
-`ComponentInput` and passes `type` straight through, so an arm REMOVED from the
-shared vocabulary would have broken that assignment loudly at compile time — but an
-arm ADDED to it produced no error anywhere. Widget authoring would just have stayed
-narrower than component registration, with nothing in the tree saying so. After this
-change neither direction is expressible.
-
-The pin is source-text, deliberately: a TS type alias erases at runtime, so a
-member-identical restatement is indistinguishable from the derived type by any
-assignability or runtime check. Both kinds of assertion are kept in
-`__tests__/widget-input-control-vocabulary.test.ts`, and the ablation showing the
-value assertions stay green on the defect while the identity pin turns red is quoted
-in the PR body.
-
-Two divergences between `WidgetInput` and `ComponentInput` are deliberately **not**
-repaired here, and are now recorded in `WidgetInput`'s doc block instead of living
-only in a closed card's body: the enum slot is spelled `options` on one face and
-`enum` on the other (adapted at the `WidgetRegistry` seam, so nothing fails to
-arrive), and `ComponentInput` carries five keys — `inputType`, `min`, `max`, `step`,
-`placeholder` — that a widget manifest cannot express. Both are surface questions
-about published keys and are raised on objectui#5675 rather than answered by this
-change.
diff --git a/.changeset/wild-donkeys-shake.md b/.changeset/wild-donkeys-shake.md
deleted file mode 100644
index e50f7c70c5..0000000000
--- a/.changeset/wild-donkeys-shake.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-"@object-ui/plugin-map": patch
----
-
-`ObjectMap` no longer serializes its data config on every render.
-
-`getDataConfig(schema)` was called bare in the render body and its result
-re-serialized with `JSON.stringify` on every render, purely to give `dataConfig`
-the stable identity its fetch effect depends on. `getDataConfig` is a pure
-function of `schema`, so `useMemo(() => getDataConfig(schema), [schema])` gives
-the same identity with no serialize and no per-render rebuild.
-
-This also fixes a crash. `JSON.stringify` throws on a value it cannot serialize,
-and the config's passthrough branch returns the author's own `schema.data`
-object verbatim — inline rows included. A map handed inline records carrying a
-back-reference (an `$expand`-ed lookup) or a `BigInt` id threw from the render
-body and took the whole map subtree down with it. Comparing identities never
-serializes, so the config no longer has to be serializable at all.
diff --git a/.changeset/wise-pandas-pin.md b/.changeset/wise-pandas-pin.md
deleted file mode 100644
index 0a9ba4fdbc..0000000000
--- a/.changeset/wise-pandas-pin.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
----
-
-Test-only: pin that `record:alert`'s CTA honours an action's `resultDialog` through the
-surrounding provider's shared `ActionRunner`, and that with no provider the CTA falls back
-to a local, unwired runner that discards the value and warns. No published behaviour changes.
diff --git a/.changeset/zod-base-schema-mirror-parity-4605.md b/.changeset/zod-base-schema-mirror-parity-4605.md
deleted file mode 100644
index 1d0ba8c9fe..0000000000
--- a/.changeset/zod-base-schema-mirror-parity-4605.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-'@object-ui/types': minor
----
-
-The zod `BaseSchema` mirror now accepts everything its TypeScript declaration
-declares — five keys had drifted narrower (objectui#4605).
-
-`@object-ui/types/zod` is a published runtime validator hand-written to mirror the
-`BaseSchema` interface. As the interface widened, the mirror did not, so five keys
-refused at parse time a spelling the published types invite and the renderer
-implements — "declared = enforced" inverted. `.passthrough()` rescued none of them:
-passthrough admits UNDECLARED keys, and all five are explicitly declared, so the
-narrow declaration won.
-
-Measured against the unmodified mirror before the change, these were the refusals:
-
-| key | authored input | old mirror said |
-|---|---|---|
-| `visible` | `'${data.status === "open"}'` | `expected boolean, received string` |
-| `disabled` | `'${data.status === "locked"}'` | `expected boolean, received string` |
-| `ariaLabel` | `{ key, defaultValue }` | `expected string, received object` |
-| `label` | `{ en: 'Owner', 'zh-CN': '负责人' }` | `expected string, received object` |
-| `description` | `{ en: 'The record owner' }` | `expected string, received object` |
-
-`visible`/`disabled` now take `boolean | string` — what `evaluateCondition` accepts,
-no wider. `ariaLabel` takes the KEYED reference through a new exported
-`KeyedI18nLabelSchema`; `label`/`description` take the spec's own `I18nLabelSchema`
-BY REFERENCE, so a change to the spec's label contract is picked up rather than
-re-typed. Every spelling that parsed before still parses.
-
-The two i18n vocabularies are kept apart rather than merged into "some object".
-`label`/`description` are the spec's INLINE locale map (resolved by
-`resolveI18nLabel(label, locale)`); `ariaLabel` is the KEYED reference (resolved by
-`resolveKeyedI18nLabel`, which returns `undefined` for a locale map and would render
-an EMPTY aria-label). Widening both slots to accept either shape would have
-reproduced objectui#4167's confusability hazard inside the validator that exists to
-catch it, so each slot admits only its own vocabulary and both cross pairings are
-pinned as rejections.
-
-The new pin is DERIVED rather than a hand-written key list: it reads the mirror's own
-`.shape` and compares each key against the declaration, so the next widening of
-`base.ts` that forgets this file turns it red with no list to maintain. It reads
-`.shape` and not `keyof z.input<…>` because that spelling was measured vacuous —
-`.passthrough()` collapses the inferred key union to bare `string`, and a pin written
-over it resolved `never` while five keys were demonstrably narrow. Two guards pin the
-derivation against both degenerations (`never` and `string`).
diff --git a/.changeset/zod-internals-reader-confinement.md b/.changeset/zod-internals-reader-confinement.md
deleted file mode 100644
index 4fc9998c3e..0000000000
--- a/.changeset/zod-internals-reader-confinement.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
----
-
-Test-only change. Four spec-parity suites each carried a byte-for-byte identical
-hand-written walk into Zod's internals to read a key's enum vocabulary; they now
-import one `shapeEnumOptions` reader from the private, never-published
-`@object-ui/test-support`. No published package's runtime behaviour changes —
-the only edits to released packages are a `devDependencies` entry each.
diff --git a/.changeset/zod-mirror-parity-population-5684.md b/.changeset/zod-mirror-parity-population-5684.md
deleted file mode 100644
index e1b81105b1..0000000000
--- a/.changeset/zod-mirror-parity-population-5684.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
----
-
-Test-infrastructure only, no shipped code touched: the derived anti-drift parity
-construction that objectui#5680 built for `BaseSchema` now covers every hand-written
-zod mirror in `@object-ui/types`'s `src/zod/` directory instead of that one schema.
-
-A mirror restates a TypeScript declaration by hand, and when the declaration widens
-and the mirror does not follow, the published validator refuses a spelling the
-published types invite — `declared !== enforced` on a shipped surface. Two instances
-were found independently before anything looked for them (objectui#4605, #5186);
-nothing detected the class itself.
-
-`packages/types/src/__tests__/zod-mirror-parity.test.ts` registers 164 mirror/declaration
-pairs and applies one construction to all of them: it reads each mirror's own `.shape`
-and compares every key against the declaration, so a widening that forgets a mirror
-turns red with no key list to maintain. A runtime census reads the directory off disk
-and fails when an exported const is in neither the registry nor the reasoned exclusion
-list, so a mirror added later cannot join the population silently. 18 pairs carry
-measured drift today and are pinned to their exact drifted key sets as a ratchet — new
-drift fails, and so does a stale entry once the drift is fixed.
-
-`base-schema-zod-mirror-parity.test.ts` keeps its objectui#4605 runtime pins and no
-longer restates the type-level construction; `BaseSchema` is one registered row.
diff --git a/QUICK_REFERENCE.md b/QUICK_REFERENCE.md
index 4097a911b4..daa660fee3 100644
--- a/QUICK_REFERENCE.md
+++ b/QUICK_REFERENCE.md
@@ -121,7 +121,7 @@ release path runs the sync itself: `changeset:version` bumps every manifest and
 this block in the same commit, so a release can no longer leave the block a version
 behind (objectui#5394 — that had happened once per release, three times).
 
-- **Version:** 17.6.0 (the version every `@object-ui/*` manifest carries — they are one
+- **Version:** 17.7.0 (the version every `@object-ui/*` manifest carries — they are one
   `fixed` group in `.changeset/config.json`, so a release moves all of them together)
 - **Spec:** `@objectstack/spec` ^17.0.0 (declared by the root `package.json` and by
   `apps/console/package.json`)
diff --git a/apps/console/CHANGELOG.md b/apps/console/CHANGELOG.md
index 8ef1818ba4..f1aff2a46d 100644
--- a/apps/console/CHANGELOG.md
+++ b/apps/console/CHANGELOG.md
@@ -1,5 +1,939 @@
 # @object-ui/console
 
+## 17.7.0
+
+### Minor Changes
+
+- 26fbe09: Console telemetry can now be hard-disabled on an already-built artifact
+  
+  `/api/v1/runtime/config` gained `telemetry.allowClientErrorReporting`
+  (objectstack#11382), and the Console now reads it. The Sentry decision becomes a
+  conjunction of two independent grants — a DSN injected at **build** time AND a
+  positive permission from the **runtime** — so the single pre-built SPA that both
+  the hosted SaaS console and the on-premises / air-gapped EE images embed can be
+  silenced by the deployment it lands in, with no rebuild and without editing files
+  inside a published bundle. That was the half objectui#5522 could not close before:
+  every other input to the gate is a Vite build-time variable frozen into the bundle
+  as a literal, which is how an air-gapped EE Console came to send 14 Sentry
+  envelopes per session to `sentry.io` carrying IP + User-Agent PII with no way for
+  the customer to turn it off (objectstack-ai/cloud#1508).
+  
+  The permission fails **closed** in every direction: absent key, `telemetry` block
+  absent, malformed payload, failed fetch, or a runtime predating the key all read as
+  *do not send* — which is precisely the set of runtimes leaking today. It is a
+  permission and never a source: the server supplies no DSN and cannot turn telemetry
+  on for a build that carries none. Only a real boolean `true` grants; `'true'`, `1`
+  and other truthy lookalikes do not.
+  
+  Behaviour change for deployments that already inject a DSN: reporting now also
+  requires the runtime to grant permission, via
+  `OS_TELEMETRY_CLIENT_ERROR_REPORTING_ENABLED` (or `RuntimeConfigPlugin`'s
+  `allowClientErrorReporting`). A build that opted in but whose runtime says nothing
+  will go quiet — deliberately, since that is the same artifact an air-gapped
+  customer runs.
+  
+  `@object-ui/app-shell` additionally exports `isClientErrorReportingAllowed()` and
+  the `RuntimeTelemetry` type, so consumers read the permission through the one
+  fail-closed accessor instead of writing their own optional-chain against the
+  payload.
+- 5173a5e: ⚠️ **Behaviour change: `current_user` predicates that have been doing nothing on
+  the console form routes and in the wizard's submit gate now TAKE EFFECT.** Read
+  this before upgrading if any of your form metadata gates on the session user.
+  
+  objectui#6010 bound the host predicate scope on the five authored-predicate call
+  sites in the components form renderer, so `current_user` (plus the ADR-0068
+  `user` / `ctx.user` / `os.user` aliases) resolves on `visibleWhen` / `visibleOn`
+  there. Two other authored-predicate evaluators were still passing `undefined`
+  for that argument, so the same authored text meant two different things
+  depending on which surface opened the form (objectui#6110):
+  
+  - **`apps/console`'s form renderer**, on the authed internal route
+    `/forms/:name`. The internal route is a runtime record surface by ADR-0089
+    D1's own words (*"runtime record surfaces bind `record` + `current_user`"*),
+    and its `visibleWhen` metadata is the same `*.view.ts` FormView the
+    object-view chain renders — so a role gate authored once behaved differently
+    depending on which route opened the form.
+  - **`WizardForm`'s submit-time required re-check** (`missingRequiredByStep`),
+    the gate that re-checks the whole declared field set at final submit because
+    `allowSkip` can jump past a step. Its docstring promises *"the same verdict
+    from all three rather than a second, divergent dialect"*, and since #6010 it
+    was the divergent one.
+  
+  **Why nobody noticed, and why the fix is felt as a change.** `visibleWhen` fails
+  OPEN: a field on screen is what you get when the predicate resolves TRUE, when
+  the scope was never bound so the predicate faulted, *and* when the predicate is
+  broken. Those worlds were indistinguishable, so an app that authored a
+  `current_user` gate saw the field render and had no way to tell the rule was
+  inert. After this change the predicate is evaluated for real, and fields and
+  sections that have always been visible will disappear for the users the rule
+  excludes. `requiredWhen` fails the other way (CLOSED), so a `current_user`
+  requiredWhen that has been silently not applying will now start holding submits.
+  
+  In the wizard the change is a fix in the user's favour as well: a required field
+  the wizard HID from this user was still counted as visible by the submit gate,
+  so the submit was refused on a control the submitter could neither see nor fill
+  in.
+  
+  **Before upgrading**, audit any `visibleWhen` / `visibleOn` / `requiredWhen` in
+  your form-view and object metadata that names `current_user`, and confirm each
+  predicate says what you actually want evaluated against `record` +
+  `current_user`.
+  
+  **The public anonymous form `/f/:slug` is deliberately unchanged.** It is
+  mounted outside `ProtectedRoute` so an anonymous visitor can submit it, there is
+  no authenticated principal, and no provider is mounted above it — so its scope
+  is empty and a `current_user` predicate authored on a public form still faults
+  and still fails open, exactly as before. Nothing new is declared to say so: the
+  two routes are told apart by which component mounts them.
+  
+  `@object-ui/app-shell` exports `buildExpressionUser`, the `ExpressionProvider`
+  user normalisation, so every console surface that mounts the provider publishes
+  the same `current_user` shape rather than re-deriving it.
+- c8da8b3: Stop showing an access-denied screen to a real administrator while their
+  adminship is still resolving.
+  
+  `useIsWorkspaceAdmin()` returned a bare `boolean`, so "the inputs have not
+  arrived yet" and "resolved: not an admin" were the same answer. One of its three
+  sources — the active organization member row — is fetched some round trips after
+  the session (`listOrganizations` → `getActiveOrganization` → `getActiveMember`),
+  so an administrator whose adminship lives only in that row rendered at least
+  once as a non-admin, and every gate downstream acted on it: the two marketplace
+  surfaces painted `MarketplaceAccessDenied`, the console chrome dropped and
+  re-added its admin nav entry, and `AppContent` fired a `<Navigate to="/home"
+  replace>` that the later flip could not undo.
+  
+  **Breaking (published API, hence `minor` per this repo's version policy):**
+  `useIsWorkspaceAdmin(): boolean` is replaced by
+  `useWorkspaceAdminStatus(): { isAdmin: boolean; isResolved: boolean }`. The old
+  name is removed rather than kept alongside, so a call site that ignores the
+  third state fails to compile instead of silently refusing an administrator.
+  
+      -const isAdmin = useIsWorkspaceAdmin();
+      +const { isAdmin, isResolved } = useWorkspaceAdminStatus();
+  
+  `AuthProvider` gains `isMembershipResolved` on its context — the organization /
+  member pipeline has reached a terminal state — because `organizations`,
+  `activeOrganization` and `activeMember` read `[]` / `null` / `null` both before
+  the pipeline starts and after it finds nothing.
+  
+  No extra wait for administrators: `isResolved` is true the instant `isAdmin` is,
+  so an admin the session already identifies through `positions[]` never waits on
+  the member row.
+
+### Patch Changes
+
+- ff8587f: Setup's settings selects now follow the specifier's `valueDomain` declaration instead of
+  treating the curated `options` table as the domain (objectui#3719).
+  
+  Since objectstack#5712 / PR objectstack#6581 a settings specifier may declare
+  `valueDomain` (`iana_time_zone` | `iso_4217_currency` | `iso_3166_alpha2`), and when it
+  does the **standard's membership is the enforcement boundary** — the server accepts
+  `timezone: 'Europe/Zurich'` and `currency: 'CHF'`, neither of which is in the manifest's
+  list. The console kept drawing those keys as closed dropdowns, so an admin could author
+  only the 17 curated zones and 9 curated currencies while the contract took the whole
+  domain; every other legal value was reachable by API or `OS_LOCALIZATION_*` env only. The
+  keys' own descriptions had promised "IANA zone" / "ISO 4217 code" all along.
+  
+  `case 'select'` in `SettingsField` now keys the control off the declaration. Declared →
+  an editable combobox: the curated options stay on as suggestions (native `<datalist>`, the
+  same suggest-but-allow-anything affordance `FlowReferenceField` uses — no new dependency),
+  free text is committed verbatim, and an out-of-domain value is refused by the server with
+  `invalid_value` + `constraint: { valueDomain }` into the field-error slot that already
+  exists.
+  
+  **Undeclared → the closed dropdown is untouched**, which is half the change rather than a
+  caveat. Those `options` are still exhaustive under objectstack#5131 (the sms/mail provider
+  selects), and `localization.locale` had its domain declaration deliberately **rejected** in
+  objectstack#6515 because its options *are* the shipped catalogs. Widening those to free
+  input would be a regression wearing this fix's clothes, so the two branches are pinned
+  against each other from the specifier data rather than from a list of key names — a key
+  that gains a domain server-side joins the right side of the pin with no edit here.
+  
+  Root cause, because it will recur: `Specifier` in `pages/settings/types.ts` is a
+  hand-written **local mirror** of the server's shape, not an import, so nothing tells it when
+  the schema grows — and TypeScript reports nothing, because a narrower mirror is a
+  structurally valid reading of a wider object. `valueDomain` is added there and the file
+  header now says to check the mirror first when a settings feature "doesn't render".
+- baac3f4: Fix four `find()` calls that passed a query option without its `$`, and gate the shape.
+  
+  `QueryParams` declares every query option `$`-prefixed and `convertQueryParams` copies
+  exactly those keys, so an unprefixed spelling reaches no branch and is dropped — no throw,
+  no warning, and it type-checks because the type carries `[key: string]: any` for
+  adapter-specific params. For a dropped cap the result is an **unbounded** read rather than
+  a truncated one: the platform's GET list route has no default page size, so the query
+  returns the whole match set and stays invisible until the object is large.
+  
+  - `app-shell` `ObjectView` fetched the footer's record count with `{ limit: 0 }`. This one
+    **inverted** rather than widened — `$top: 0` is honoured end to end as "no records", so
+    the dropped key turned "count only, fetch nothing" into "fetch every row in the object",
+    on every mount and every refresh of every list view. It now sends `$top: 0` and reads
+    the count off `total` only; the row-counting fallbacks are gone rather than repointed,
+    because once zero rows are requested an empty `data` means "you asked for none", not
+    "the object is empty", and counting it would assert a confident `0`. With no total the
+    footer line is omitted instead.
+  - `app-shell` `AssignedUsersSection` looked a permission set up with `{ …, limit: 1 }`,
+    one line from three correct `$top` calls.
+  - `plugin-dashboard` `DashboardFilterBar` passed `fields` **and** `top` in one literal, so
+    a filter's option list read every row and every column of its source object while its
+    own comment described it as capped at 200. The same call read `records.items`, which is
+    not a `QueryResult` member, so against a real adapter the fallback produced no options
+    at all.
+  - `console` `sdui-workbench-preview` passed `{ top: 200 }` and read `.records` off the
+    result in its page-source metadata.
+  
+  A new `object-ui/no-unprefixed-query-params` ESLint rule rejects the shape at write time:
+  a known query-option name missing its `$` in the second argument of a `find`/`findOne`
+  call. It is narrow on purpose — a closed list of spellings, anchored to the call — because
+  the index signature exists so adapters can take adapter-specific params, and a rule that
+  flagged any unprefixed key would report the shape the type was written to allow. Its
+  sibling `no-query-params-under-options` (the `{ options: { $top } }` half) is unchanged.
+- 6630b37: The console boot no longer flashes a fully-white frame after the splash has painted
+  (objectui#6378).
+  
+  Cause, established by measurement before any fix was written — the card named
+  `LoadingScreen`'s unmount timing and `RouteFader` as suspects and both are exonerated.
+  A CDP `Page.startScreencast` frame ledger (every frame classified with the card's own
+  rule: white when no colour channel falls below 242) was correlated against a DOM-state
+  ledger on the same clock (`performance.timeOrigin`), against the production
+  `apps/console` bundle with the boot endpoints mocked. `RouteFader` never mounts on the
+  boot path at all, and `LoadingScreen` unmounts exactly when its own gate says to. What
+  is wrong is what REPLACES it: every readiness gate renders the splash while it waits and
+  a bare `<Navigate>` the moment it decides. `<Navigate>` renders `null` and react-router
+  runs the navigation as a transition, so the destination tree renders while the commit
+  that already dropped the splash is what the compositor is showing — 41–147 ms during
+  which `#root` holds no view and the viewport is the bare page background. The flash is
+  intermittent only because it depends on a frame being swapped inside that window; the
+  window itself was present on every measured boot.
+  
+  `RedirectWithSplash` (new, `@object-ui/app-shell`) pairs the same `<Navigate>` with the
+  same `LoadingScreen` the gate one line above was already rendering, so the handoff
+  changes no pixels and the transition runs underneath an unchanged screen. The console's
+  three boot redirects use it: the auth gate's `/login` bounce, the `/` landing resolver,
+  and the catch-all route. The nested organization `index` redirect deliberately does not —
+  it fires under an already-painted layout, where covering the screen would be the
+  regression.
+  
+  Acceptance campaign — same instrument on both sides, the two arms INTERLEAVED inside one
+  process and one browser so drift in this shared container's load lands on both equally.
+  102 paired boots per arm across five cells (signed-out `/`, signed-in `/`, an unmatched
+  entry, and the card's two throttled network profiles). The empty-viewport window: 102/102
+  pre-fix, 0/102 post-fix. The white frame itself, pooled over the three cells where the
+  pre-fix build actually flashed: 67/87 (77%) pre-fix, 0/87 post-fix — 95% upper bound on
+  the residual rate 3.4%, against a card-reported defect rate of ~1/3. The two throttled
+  cells are reported but NOT pooled: the pre-fix build flashed 0 times there, so before and
+  after agree and those cells prove nothing about the pixels (they still separate 15/15 vs
+  0/15 on the DOM window).
+  
+  `e2e/console-boot-indicator.spec.ts` gains the deterministic half as a gate — after
+  React's first commit the viewport centre must never stop being covered. That reading is
+  what makes an intermittent defect gateable: the flash needs a frame to be swapped inside
+  the window, but the window itself was present on every measured boot. Verified red-first,
+  6/6 red on the pre-fix bundle and 6/6 green on this one.
+- 9b9af8d: The Approvals Inbox stops remounting every row on every render.
+  
+  `ApprovalsInboxPage` declared `RequestCell`, `RecordCell` and `InlineActions`
+  inside its own component body. React identifies a component by the identity of
+  its function, so each render produced three brand-new component *types* and React
+  unmounted and remounted every row's subtree instead of updating it — and the page
+  holds its clock in state and ticks it every 60s, so this fired on a timer whether
+  or not anyone was touching the page (objectui#5348).
+  
+  Two consequences were reproduced against `origin/main` before the fix, in
+  `apps/console/src/pages/system/ApprovalsInboxPage.cellIdentity.test.tsx`:
+  
+  - **Transient subtree state is discarded.** Focus placed on a row's Approve
+    button moved to `<body>` on the next clock tick.
+  - **Input is silently swallowed.** A pointer sequence that spans a re-render —
+    press, tick, release — left the confirmation dialog unopened: the captured node
+    had been replaced, so React's delegated listener never saw the click. This is
+    the failure objectui#5211 hit and worked around at its call site
+    (`Unable to find role="alertdialog"`).
+  
+  The three cells are now at module scope beside `StatusBadge`, which was moved
+  there for the same reason and already carries the explanation. Everything they
+  closed over is passed in: `RequestCell` and `InlineActions` take the page's
+  scoped translator, and `RecordCell` takes `href: string | null` — one prop rather
+  than two, so the objectui#5211 readable/unreadable decision and the URL cannot be
+  handed in disagreeing with each other.
+  
+  The verification asserts the consequence, not the placement. A test that checks
+  the three functions now sit at module scope stays green for a refactor that moves
+  them and introduces a fourth inline component beside them; these cases compare
+  DOM-node identity for all three cells across a clock tick, which no remount can
+  pass, and re-drive the swallowed click.
+  
+  That guard is load-bearing because lint cannot supply one here.
+  `react-hooks/static-components` exists for exactly this class and is `error` in
+  this repo via the plugin's recommended set, yet it reports nothing on this page:
+  measured on `origin/main`, an arrow-form inner component injected into
+  `ApprovalsInboxPage` and used in JSX produced **zero** reports, while the same
+  shape in a ten-line file produced two. The rule's analysis bails out on this
+  component, which is how three of them shipped.
+- 9180fd1: Approvals inbox: the queue rows and the amount sort now honour each request
+  object's own `hidden: true` field declaration (objectui#6020).
+  
+  The `hidden: true` trim added for the drawer summary card reached only the
+  drawer — the desktop queue row, the mobile card and the amount comparator
+  still read the field, so an amount an app author declared hidden rendered
+  inline in the queue and ordered the list, which leaked its relative magnitude
+  even to a viewer who never saw the figure.
+  
+  The queue spans many objects, so the trim is a per-object lookup and every row
+  is answered about its own object; a row left with no renderable amount now
+  sorts with the other amount-less rows. `hidden` stays a UI contract
+  (objectstack#10749) and the filter still fails open: an unanswered or failed
+  metadata read renders today's figure.
+- 7c0e417: The Approvals Inbox no longer shows a business approver the submitted record's raw
+  row JSON.
+  
+  The detail drawer's "Raw data (JSON)" panel rendered on `payload != null` alone — no
+  principal check of any kind — so every approver could expand (and one-click copy) the
+  complete raw snapshot: `id`, `created_by`, `updated_by`, `owner_id`,
+  `organization_id`, bare lookup ids, and **the fields the object's metadata declares
+  `hidden: true`**. Reported from a live EHR deployment on 17.1.0
+  (objectstack-ai/objectstack#10734), where that declaration is a patient-data control.
+  The app author had no legitimate lever to remove the panel — field `hidden`, view
+  columns, app navigation, permission sets and env vars are all ineffective against it —
+  so the remedies available in the field were patching the shipped bundle or injecting
+  CSS.
+  
+  The panel is now gated on `holdsStudioAccess`, reused verbatim from the console's
+  `studioEntry` module: `studio.access` is a declared platform-scope capability that a
+  tenant org owner does not hold by design, and it already reaches the browser in
+  `systemPermissions[]` from `/api/v1/auth/me/permissions`. Nothing new is served,
+  computed or made authorable — no new config key, no new i18n copy, and the panel is
+  byte-for-byte unchanged for the platform operator it was written for. A business
+  approver keeps the structured record summary, the approval chain, the activity feed
+  and the decision actions; only the raw snapshot is gone.
+  
+  The gate reads the RAW `systemPermissions` signal and fails **CLOSED**, inverted from
+  `usePermissions().hasCapabilities`. That hook fails open on purpose — hiding a
+  holder's button while the server still refuses the write is the worse outcome for an
+  action. This panel has the opposite stake, since the measured defect is a non-holder
+  seeing it, so every not-a-reported-grant answer denies: no provider mounted, a backend
+  predating ADR-0066 that omits the field, the resolver's `catch` path that answers `200`
+  with no `systemPermissions` at all, and a reported empty array. A deployment whose
+  permission layer just failed must not be the one that leaks the snapshot.
+  
+  `ApprovalsInboxPage.rawPayloadGate.test.tsx` pins all four verdicts. Because the
+  acceptance condition is that something does *not* render — which an empty render
+  reproduces perfectly — every denial case also asserts the drawer it denies inside, and
+  the `studio.access` case drives the same fixture through the same helper and finds the
+  panel. `created_by` and `organization_id` are the witnesses: both are in the page's
+  `PAYLOAD_SYSTEM_KEYS`, so the summary card already drops them and their values can
+  reach the DOM only through the raw panel. Ablating the gate (restoring the bare
+  `payload != null` condition) turns the three denial cases red on exactly that
+  assertion and leaves the holder case green.
+  
+  Out of scope, tracked separately: trimming the summary by object metadata, and the
+  server-side residual that sends the unfiltered snapshot to the client at all.
+- ac73c24: The approval step progress bar is a vertical stepper, so long flows stop
+  clipping their tail steps.
+  
+  Both occurrences were a single non-wrapping flex row whose steps were each
+  `shrink-0`. A flex row's min-content width is the sum of its non-shrinkable
+  items, so the bar's intrinsic width grew without bound with step count and
+  label length. On a live 17.1.0 project a real 6-step flow with ordinary CJK
+  step names measured **1070px inside a 527px container** (objectui#5554).
+  
+  The two hosts failed differently, and neither failure was recoverable by the
+  reader:
+  
+  - **`ApprovalsInboxPage`** (the inbox detail drawer) — the bar itself was not
+    scrollable, so the nearest scroller was the drawer *panel*. Reaching steps
+    4-6 meant dragging the drawer's own horizontal scrollbar, which pushed the
+    record card, the activity timeline and the action buttons off-screen and left
+    a near-blank panel.
+  - **`RecordApprovalsPanel`** (the record page's approvals panel) — this one
+    carried `overflow-x-auto`, so it scrolled itself rather than its container.
+    Better, but the tail steps still sat behind a scroll gesture with no visible
+    affordance.
+  
+  In both, readers took the clipped bar for the end of the data; the reporting
+  customer acceptance tester said so verbatim. Widening the window does not help:
+  the drawer is fixed-width, and clipping was identical at 1440x900 and 1920x1000.
+  
+  Both now render as a column: one row per step, a badge-and-rail gutter, and a
+  label that may wrap. Width is capped by the container at every step count and
+  every label length, which also suits both hosts' tall-and-narrow aspect. The
+  rail segment below each step keeps the tint rule the horizontal connector used
+  — it is coloured by the step it leads *into*.
+  
+  **Always vertical, with no step-count or measured-width threshold**, because
+  the overflow is driven by intrinsic content width (labels x count), not by
+  count alone: three 16-character CJK labels already crowd a 527px drawer, so any
+  count threshold picks a cutoff that is wrong for some real flow, and a measured
+  one reintroduces a viewport-dependent branch. The card's requirement is a fix
+  that cannot break at an untested viewport or flow length, and a layout with no
+  breakpoint and no measurement is the form that satisfies it. Horizontal-with-
+  scroll was ruled out for both occurrences: it leaves steps behind a gesture.
+  
+  Pinned in `ApprovalsInboxPage.stepProgressVertical.test.tsx` and
+  `RecordApprovalsPanel.stepProgressVertical.test.tsx`. "The stepper renders" is
+  green against the broken code too — every step was always in the DOM, and the
+  clipping was layout — so the suites assert the property the defect names
+  instead: no row is `shrink-0`, every label is `min-w-0` and none is
+  `whitespace-nowrap`, nothing in the subtree is an `overflow-x` scroller, and no
+  axis, overflow or width-pinning class carries a breakpoint prefix (so there is
+  no viewport with untested behaviour). The reported failing regime is exercised
+  directly with the reporter's own six CJK labels, and a 2/5/6/12-step sweep pins
+  that the layout classes are byte-identical across all four, so no count
+  threshold can put some other flow length back on the old path.
+  
+  The two steppers are kept identical by hand rather than extracted to a shared
+  component: they live in different packages, and deduplicating them is a
+  refactor with its own surface. Filed separately.
+- 7e89836: fix(approvals): derive approver identities from `positions`, not the retired `user.roles` (objectui#5424)
+  
+  Framework ADR-0090 D3 renamed the session's `roles` key to `positions` with no
+  deprecation window, and the protocol-17 session face emits no `roles` key at
+  all. Three client sites still read it:
+  
+  - **`sharedUserFeeds.approverIdentities`** — the bell badge, the bell's
+    Approvals tab and Home's To-do card. It read nothing else, so it sent **no
+    `role:` identity at all**: an approval addressed to a position rather than to
+    a person matched nothing and vanished from all three surfaces, silently.
+  - **`approvalsApi.buildApproverIdentities`** — "My Pending" and the
+    Approve/Reject enablement. It also splits the scalar `user.role`, so it
+    degraded rather than dying: it still yielded `role:user` while dropping every
+    business position name (`manager`, `finance_approver`, …).
+  - **`AppContent`'s expression user** — forwarded a `roles` key that was always
+    `undefined` into every CEL predicate context. Removed; `positions` and
+    `isPlatformAdmin` were already forwarded correctly beside it.
+  
+  The retired spelling is **not** kept as a fallback — pairing the two is what
+  ADR-0090 D3 forbids, and `packages/auth/src/types.ts` says so on the
+  declaration.
+  
+  `AuthGuard`'s `requiredRoles` gate (the fourth surviving reader) is deliberately
+  untouched: it is a semantics decision, not a rename, and is deferred to a
+  maintainer ruling.
+- 0e05aac: The console's cold load no longer asks `/api/v1/runtime/config` or
+  `/auth/me/localization` twice (objectui#5544).
+  
+  Two pairs of boot callers were racing each other for the same URL, with no shared
+  provider between them, so no guard inside either component could see the other:
+  
+  - `GET /api/v1/runtime/config` — the pre-React branding script inlined in
+    `apps/console/index.html` (it runs during HTML parse so the tab title and
+    favicon are the operator's before the bundle is fetched) and
+    `initRuntimeConfig()`. Measured ×2 on prod and on staging. This is the
+    expensive one: the console `await`s `initRuntimeConfig()` before
+    `createRoot().render()`, so the duplicate sat on the critical path to first
+    paint, and at the control plane's ~0.5–1.4 s for this endpoint it also pushed
+    boot concurrency further past the server's pool knee.
+  - `GET /api/v1/auth/me/localization` — `seedTenantLanguage()` on a device's true
+    first visit and `LocalizationFetchProvider` on every boot. The seed keeps
+    running past its 500 ms race by design and the provider mounts the moment that
+    race resolves, so on a first visit the two overlap. Measured ×2 on staging.
+  
+  `@object-ui/types` gains `sharedGetJson()`: callers that ask for the same GET
+  while one is already in flight join that request instead of starting another. It
+  shares the in-flight promise and nothing else — the entry is deleted the instant
+  the request settles, so there is no cache, no TTL and no stale window, and a
+  caller arriving after settle fetches fresh exactly as before. Rejections fan out
+  to every sharer with the status intact (`LocalizationFetchProvider`'s retry
+  policy still sees its own 503), each caller receives its own copy of the parsed
+  body, and only GETs are eligible — a non-GET is refused rather than quietly
+  rewritten.
+  
+  Requests that differ in credentials mode or headers keep separate identities, so
+  the console's two deliberate `auth/get-session` calls — one Bearer-only with the
+  cookie omitted to detect a stale token, then one through the cookie — stay two
+  requests. Collapsing those would have destroyed the signal the first one exists
+  to read.
+  
+  No component receives anything different: same payloads, same errors, one fewer
+  round trip.
+- 631d81d: fix(console): paint a boot indicator during the pre-React white frame
+  
+  The console's `index.html` shipped an empty `<div id="root">`, so a hard
+  navigation showed a pure-white page until the module graph had downloaded,
+  evaluated and resolved the two round trips `main.tsx` awaits before
+  `createRoot().render()`. Measured on this repository's production build with
+  Playwright + CDP screencast (frames classified pixel-by-pixel, corroborated by
+  the Paint Timing API): 1224-2016 ms of pure white on an unthrottled localhost,
+  2289-2297 ms at 20 Mbps/80 ms RTT, and 5808-6167 ms on a Fast-4G profile.
+  
+  The document now carries the indicator itself — an inline style block and the
+  same gradient tile `LoadingScreen` opens with — so it paints from the HTML
+  parser, before the first chunk is requested. It is removed on React's first
+  commit into `#root`, so it never doubles up with `LoadingScreen`, which
+  continues to own the init screen and its ten-language copy.
+- 71ee495: The two form CONTAINER contracts now have ONE declaration each, derived from
+  `@objectstack/spec`, and the console reads them instead of its own copies.
+  
+  objectui#5542 converged the LEAF of this contract — the field spec — and left the
+  two containers above it untouched, because converging them was a bigger call than a
+  mechanical import. `FormSectionSpec` and `FormViewSpec` were each hand-declared
+  twice under the same names, once in `packages/app-shell`'s `SchemaForm.tsx` and once
+  in `apps/console`'s `FormPage.tsx`. Unlike the leaf — whose console copy was a clean
+  subset — these two had **already drifted, in both directions**, so neither copy was a
+  subset of the other and there were two live answers to "what may an author write":
+  
+  - `FormSectionSpec` — app-shell declared `description` / `visibleWhen` / `visibleOn`;
+    the console declared none of them. The console's `columns` admitted the string arm
+    (`'1' | '2' | '3' | '4'`); app-shell's took numbers only.
+  - `FormViewSpec` — the console declared `label` / `groups` / `sharing` /
+    `submitBehavior`; app-shell stopped at `type` plus `sections`.
+  
+  The drift is decided by asking the **contract**, not by picking a side. `columns`
+  does admit the string arm (`FormSectionSchema.columns` unions `z.enum(['1','2','3','4'])`
+  with the four numeric literals, folded to a number by its own transform), so
+  app-shell's numbers-only declaration was rejecting metadata the platform accepts —
+  objectui#5040's own symptom, not a deliberate narrowing. `label` on the form view is
+  the opposite answer: `FormViewSchema` **rejects** it (`unrecognized_keys`, measured
+  against the installed `@objectstack/spec` 17.0.0), because a form config is titled,
+  not labelled. The value that read actually finds is the VIEW's identity label, which
+  arrives on the `ExpandedViewItem` envelope or beside the config on a flattened
+  runtime overlay — so it is declared on `FormPage.tsx`'s own `FormViewBody`, next to
+  the body it unwraps, rather than smuggled onto the form contract.
+  
+  Both types are therefore **derived from the spec's own `FormSection` / `FormView`
+  with named narrowings** — the repo's sanctioned form for a spec-shaped local type
+  (`scripts/check-spec-symbol-derivation.mjs`) — rather than restated. Every key the
+  two layers agree on comes from the spec and cannot fall behind it; the four positions
+  where this layer is deliberately narrower are each named in an `Omit` list and
+  restated once next to its reason: `fields` keeps the converged 26-key leaf (deriving
+  it would silently re-open #5542), and `label` / `description` / `visibleWhen` /
+  `visibleOn` keep the shapes this repo's renderers and evaluators actually consume
+  rather than the spec's `I18nLabel` and `ExpressionInput`. `apps/console`'s
+  `submitBehavior` union — previously hand-written under the comment "Mirrors the spec
+  FormView.submitBehavior union" — is now read back off the shared type, making the
+  mirror structural. `@object-ui/app-shell` re-exports both names from its package root
+  (type-only, erased at build — nothing is added to the bundle), because a type that
+  cannot be imported is a type that gets retyped.
+  
+  The pins are what make future drift loud, and each half is pinned on both sides.
+  `form-spec.containers.test.tsx` and `FormPage.viewSpec.test.ts` compare the
+  non-narrowed half of each type against the spec's own symbol, so re-hand-writing
+  either declaration fails `type-check` the day the spec moves rather than years later
+  when someone reads two files side by side — and the console's pins read both types
+  back out of the **exported** `buildSections` signature rather than naming them, so a
+  re-inlined local copy fails even if it agrees on every key on the day it is written.
+  Their liveness controls are what stop them being phantom checks: the removed copies
+  are pinned NOT equal to the shared types (proving the `Equal` helper still
+  discriminates), the renderer's honoured `RenderableSection` is pinned not equal
+  either (so the authored-document and honoured-row types cannot be collapsed again),
+  and an undeclared key is still rejected (so the derivation smuggled in no index
+  signature or `any`). Every narrowing carries a matching negative pin, so "derived"
+  cannot quietly become "widened to whatever the spec says".
+  
+  Behaviour is unchanged — the runtime always accepted these keys. The vitest halves
+  prove it: a section spelling its column count as the string `'3'` lays out identically
+  to the numeric `3` on both sides, and a section carrying the keys only one side used
+  to declare builds the same rows.
+- cebdfe7: The form-field authoring contract now has ONE declaration, and the console reads it
+  instead of its own copy.
+  
+  objectui#5040 was not a missing key. It was that **two hand-written descriptions of
+  one contract drifted**, and nothing could notice, because each was only ever checked
+  against itself. PR #5537 converged the two app-shell descriptions into
+  `views/metadata-admin/form-spec.ts`. A **third** survived in `apps/console`:
+  `FormPage.tsx` declared its own nine-key `interface FormFieldSpec`, under the same
+  name, in a different package — so the same failure mode stayed fully available.
+  
+  Measured key by key before choosing a route, because the two honest outcomes are
+  "same contract, import it" and "genuinely narrower layer, rename it and pin the
+  subset". The console's copy was a strict subset — 9 of the shared type's 26 keys,
+  every one identical in type, none console-only — and it sat in a position that
+  describes an **authored document**: `FormSectionSpec.fields`, read straight off the
+  `/meta/view/:name` payload, the same spec `FormView` metadata-admin renders (both
+  files even spell the same six-member `type` union and call the element type
+  `FormFieldSpec`). The narrow, renderer-honoured shape is a different type that
+  already exists in that file, `RenderableField`. So this was one contract described
+  twice, and the console's description was wrong about the document: legal metadata —
+  `visibleWhen`, `dependsOn`, `type`, `options`, `immutable`, the recursive `fields`,
+  and ten more keys — was undeclared there. That is #5040's own symptom, "the type
+  rejects the configuration the runtime accepts", which no runtime test can see.
+  
+  `@object-ui/app-shell` therefore re-exports `FormFieldSpec` from its package root
+  (type-only, erased at build — nothing is added to the bundle), and `FormPage.tsx`
+  imports it and deletes the local declaration. Reachability is the load-bearing half:
+  a type that cannot be imported is a type that gets retyped, and retyped copies drift.
+  `form-spec.ts` itself is untouched.
+  
+  `FormPage.fieldSpec.test.ts` is the pin that makes future drift loud. It reads the
+  field-spec type back out of the **exported** `buildSections` signature rather than
+  naming it, so re-inlining a local `interface FormFieldSpec` fails `type-check` even
+  if the copy agrees on every key on the day it is written — which is exactly what did
+  not happen to the copy this change removes. Its liveness controls are what stop it
+  being a phantom check: the removed nine-key shape is pinned NOT equal to the shared
+  type (so the `Equal` helper is proven to still discriminate), `RenderableField` is
+  pinned not equal to it either (so the honoured-row and authored-document types cannot
+  be collapsed again), and an undeclared key is still rejected (so the import did not
+  smuggle in an index signature). Behaviour is unchanged: the runtime always accepted
+  these keys, and the vitest half proves the same rows are built.
+- 07cd685: The console's form routes no longer seed a RUNTIME `defaultValue` into the
+  control, so the server-side resolution the declaration asks for actually happens
+  (objectui#5727).
+  
+  `readPrefill` in `apps/console/src/components/FormPage.tsx` seeded every declared
+  default unconditionally. A `defaultValue` may be a literal, or an *instruction*
+  the server resolves per insert — a `DEFAULT_VALUE_TOKENS` token (`NOW()`,
+  `current_user`) or a CEL Expression envelope. Seeding one of those literally put
+  the text `NOW()` into a datetime input on both `/forms/:name` and the public
+  `/f/:slug` route, and submitting it sent that string as the field's value —
+  which is neither absent nor null, so `ObjectQL.applyFieldDefaults` never resolved
+  the declared default and the column stored the token text instead of a timestamp.
+  
+  The seed is now guarded by `isRuntimeDefault` from `@object-ui/core` — the same
+  published classifier `@object-ui/plugin-form`'s `schemaDefaults.ts` guards its
+  seeding with, and the one this renderer already reads once removed (through
+  `isServerOwnedValue`) for the create-mode `required` carve-out. A runtime default
+  leaves the key ABSENT rather than empty, because absent is precisely the case the
+  engine resolves.
+  
+  Nothing else about the prefill precedence moves: a literal default still seeds, a
+  stored record value still wins over a default, and an explicit `prefill_<field>=`
+  param still wins over both — including for a field whose default is a runtime
+  token, since a value a producer supplies is not a declaration awaiting
+  resolution.
+- b63a9a3: The console's standalone form renderer now evaluates conditional field visibility.
+  
+  `apps/console/src/components/FormPage.tsx` is a **second, independent form renderer**
+  — its own `buildSections`, its own JSX — and it serves both the public
+  `/f/:slug` route and the internal `/forms/:name` route. It read neither spelling of
+  the FormView field visibility predicate: a repo-wide grep for a `visibleWhen` /
+  `visibleOn` *read* inside that file returned zero. So a field an author conditioned on
+  `record.priority == 'urgent'` — legal, spec-strict metadata that `@objectstack/spec`
+  normalises to `visibleWhen` (ADR-0089), and that the metadata-admin designer both
+  authors and honours — rendered unconditionally on both routes. Fail-open and silent:
+  the author saw the field always, with no diagnostic.
+  
+  objectui#2212 recorded this exact symptom and PR #2214 fixed it — in a **different
+  chain**: `ModalForm` → `resolveFormViewLayout` → `@object-ui/plugin-form`
+  `sectionFields.ts` → `@object-ui/components` `renderers/form/form.tsx`. `FormPage.tsx`
+  is on that chain at no point, and #2212's regression pin lives with the chain it fixed,
+  so nothing in the suite could see this copy. One contract, two implementations, each
+  only ever checked against itself.
+  
+  The wiring is **#2212's ruling applied verbatim** rather than a second predicate
+  semantics invented for this renderer, because two form renderers disagreeing about what
+  `visibleWhen` *means* would be a worse defect than one renderer ignoring it. The
+  predicate goes through the canonical engine — `evalFieldPredicate` (`@object-ui/core`,
+  `evaluator/fieldRules.ts`) — so the accepted wire shapes (bare CEL string and
+  `{ dialect, source }`), the bound scope (`record.*` = the live input values, `previous.*`
+  = the stored record an edit form started from), and the fail-open-but-loud behaviour on
+  an unevaluable predicate are the shared ones by construction. Resolution is
+  canonical-first, `visibleWhen ?? visibleOn`, matching both sibling readers:
+  `sectionFields.ts` and app-shell's `readVisibility`.
+  
+  Two things deliberately did **not** change. A field hidden by its predicate still
+  submits its value — conditional visibility is a rendering rule in both renderers, and
+  making it a submit-payload rule would be a new contract decided once for both, not
+  invented in the second one. And `FormPage` is **not** folded onto the plugin-form chain:
+  the second-renderer question is real, but it belongs with the #5596 convergence track,
+  not with a predicate that is dead today.
+  
+  `FormPage.visibleWhen.test.tsx` is the regression pin, and it lives next to *this*
+  renderer on purpose — a pin that cannot see the second copy is how the first gap
+  survived. With the fix reverted and the pin in place the suite reports
+  `11 failed | 1 passed (12)`; the one green is the control that has to be green (a field
+  with no predicate still renders), without which every "the field is absent" assertion
+  would be equally satisfied by a renderer that draws nothing at all.
+- fb934fb: The console's `/docs` portal is code-split for real: its four pages leave the eager closure instead of only pretending to.
+  
+  `AppContent.tsx` lazy-imports `DocsLayout` / `DocsSlug` / `DocPage` for the
+  app-scoped `/apps/:packageId/docs` tree (ADR-0048). `App.tsx` imported the same
+  three statically for the platform portal at `/docs` (ADR-0046 section 6), so all
+  of them sat in the eager graph regardless and the `import()` moved nothing —
+  three `INEFFECTIVE_DYNAMIC_IMPORT` warnings on every `vite build`
+  (objectui#5467). A static import on either side silently defeats the split for
+  both, and the only signal is a build warning that fails nothing.
+  
+  `App.tsx` now reaches all four docs pages through `lazy()` behind `Suspense`,
+  matching the pattern `AppContent.tsx` already uses. `DocsIndex` joins them even
+  though it carried no warning: `AppContent` renders `AppDocsIndex` at that slot,
+  so nothing imported `DocsIndex` dynamically, but left static it alone would keep
+  `DocShell`, `use-book-data` and `book-nav` eager and the portal would only
+  half-leave the closure.
+  
+  Measured on this branch with the `dist/eager-closure.json` gauge added by
+  objectui#5324, both builds exiting 0:
+  
+  | | before | after |
+  |---|---|---|
+  | `INEFFECTIVE_DYNAMIC_IMPORT` warnings | 46 | 44 |
+  | eager closure, gzipped | 3,881,609 B | 3,870,058 B |
+  | eager chunks | 58 | 52 |
+  
+  Six chunks leave the eager closure: `plugin-markdown` (4,212 B gz),
+  `CreateViewDialog` (3,617 B), `use-book-data` (1,966 B), `DocShell` (476 B),
+  `componentRegistry` (99 B), and `src` (129,555 B), the last of which rolldown
+  folds into the entry chunk rather than dropping — which is why the entry chunk
+  grows from 25,910 to 154,378 B gzipped while the closure as a whole shrinks by
+  11,551 B. The entry stays far under that budget's 350 KB line, and the eager
+  closure is the number a page load actually pays.
+  
+  What does NOT move is `vendor-markdown`, 164,708 B gzipped and the reason this
+  looked like a bigger win than it is. Three eager chunks import it statically,
+  and only one of them was this portal: `plugin-chatbot` reaches it directly, and
+  `packages/fields`' `MarkdownContent` — lazy in source — is folded into the
+  eagerly imported `ui-components` chunk by the `advancedChunks` group that claims
+  every `packages/fields` module. That is objectui#5325's mechanism, not this
+  card's, and it is why the saving here is 0.30% rather than 4%.
+- 8549453: The console's pre-boot branding script now resolves its server origin from
+  `VITE_SERVER_URL` — the same variable every module-side consumer reads — instead of
+  `window.__CONSOLE_SERVER_URL`, a global nothing in this repository ever set
+  (objectui#5660).
+  
+  The two callers of `GET /api/v1/runtime/config` share one in-flight request, and
+  that sharing keys on the FULL URL. So the origin was half of the contract: the
+  inline script in `index.html` read one spelling and `src/main.tsx` read another, and
+  whenever they disagreed the two never found each other. A same-origin production
+  build hid it completely — both spellings collapse to `''` — so the split surfaced
+  only in a dev pointing the console at a separate server, where it cost two requests
+  to two different servers and let pre-boot branding paint from the wrong one.
+  
+  The pre-boot fetch is kept, not deleted: it is the request the module side JOINS.
+  `sharedGetJson()` can only hand an earlier request to a later caller, and this
+  script is the earlier one by construction — it runs during HTML parse, before the
+  bundle is fetched, while `initRuntimeConfig()` is awaited before
+  `createRoot().render()`. Deleting it would not remove a request; it would move the
+  single remaining one later, onto the critical path to first paint, and leave the
+  page's empty `<title>` and favicon unbranded until React mounts.
+  
+  Vite substitutes its HTML env token only when the variable is set and leaves it
+  verbatim otherwise, so the unset case is read as same-origin `''` rather than
+  allowed to reach the URL as a path segment.
+- 7493bff: `registerStudioComponents.tsx` no longer claims a code split it never had: `studio:builder` imports `BuilderLanding` directly instead of through a `lazy()` that deferred nothing.
+  
+  The registration wrapped `import('@object-ui/app-shell')` in `lazy()` behind a
+  `Suspense` fallback — naming the same barrel the line above it imports
+  statically for `registerAppComponent`, and the same barrel `App.tsx` pulls
+  `BuilderLanding` from to render the standalone `/studio` landing full-screen.
+  Either reason alone makes the `import()` unable to move a module into another
+  chunk (objectui#5486).
+  
+  **This moves no modules and is not a bundle improvement.** `BuilderLanding` was
+  already in the eager graph via `App.tsx` and still is. Measured on
+  `dist/eager-closure.json`, both builds exiting 0: the eager closure holds the
+  same 52 chunks with the same names, and the only difference is 130 B gzipped
+  (413 B raw) off the entry chunk — the deleted `lazy()`, `Suspense` and fallback
+  text themselves, 0.003% of a 3,875 KB closure. Nothing leaves the closure,
+  because nothing could.
+  
+  What it does fix is honesty. The old code told every reader the builder was
+  deferred, and it emitted an `INEFFECTIVE_DYNAMIC_IMPORT` warning on every
+  console build — the console's count of those drops from 44 to 43, with the 43
+  remaining ones all belonging to the `packages/fields` barrel (objectui#5325).
+  A permanent warning that fails nothing is how a team learns to skim past build
+  warnings, and a decorative `lazy()` is how the next reader learns something
+  false about the chunk graph.
+  
+  The `lazy()` shape is not the mistake. The sibling `registerAccountComponents.tsx`
+  lazy-imports `./pages/system/ProfilePage`, a specifier nothing else pulls in
+  statically, and is genuinely deferred; it is untouched. Making the *builder*
+  genuinely lazy would mean taking `App.tsx` off the static import too, changing
+  how `/studio` mounts, and it only pays if app-shell's own graph cleaves behind
+  the barrel — a separate measured card, not folded in here.
+- d8afbe5: `FormPage` — the console's own form renderer, serving both the public `/f/:slug`
+  route and the internal `/forms/:name` one — now honours the three conditional-rule
+  surfaces it still dropped after objectui#5594: section-level `visibleWhen` /
+  `visibleOn`, and the object-level field rules `visibleWhen` / `readonlyWhen` /
+  `requiredWhen` (objectui#5627).
+  
+  This is the second form renderer in the repo, and it honoured exactly one of the
+  four surfaces the sibling chain does. A section an author conditioned away rendered
+  in full — heading and every control — on both routes including the anonymous one.
+  The object-level half was worse than fail-open hiding: `readonly` was whatever the
+  static flag said, so a field a `readonlyWhen` should have locked stayed editable and
+  paired with the server's fail-closed unbound-scope behaviour into "the user edits,
+  the save reports success, and the value never lands".
+  
+  Both halves evaluate through the SHARED machinery rather than a fourth consumer-side
+  copy of the rule semantics: `@object-ui/core`'s `resolveFieldRuleState` for the three
+  field rules — which brings the settled rulings with it, including the `serverOwnedValue`
+  carve-out that keeps a create form from requiring a producer-owned control (#4069 /
+  #4085) — and its `evalFieldPredicate` for the section predicate, with the canonical-first
+  `visibleWhen ?? visibleOn` read every sibling reader spells.
+  
+  Visibility stays a RENDERING rule at both granularities: a hidden section's fields
+  still submit their values, exactly as a hidden field's have since #5594.
+- cdda37a: `buildSections` now honours a FormView field's `maxLength` override instead of always
+  taking the object's ceiling (objectui#5595).
+  
+  The function merges a form's field overrides with the target object's field definitions,
+  and its own docstring states the rule: *"Field-level FormField overrides take precedence
+  over object defaults."* Every key in the loop is built that way — `override.label ??
+  def.label`, `override.required ?? def.required`, `override.placeholder ?? def.placeholder`
+  — except one, which read `def.maxLength` unconditionally. So an author who set a tighter
+  per-form limit (a short public intake form over a column whose object-level ceiling is
+  generous) got the generous one.
+  
+  The failure was silent in the worst direction: no diagnostic, no warning, and the form
+  still submits, so the symptom is a value the author believed the input refused being
+  accepted. It is load-bearing rather than cosmetic — the merged row reaches the DOM at two
+  `maxLength={field.maxLength}` sites, the `textarea` arm and the default `input type="text"`
+  arm.
+  
+  `override.maxLength ?? def.maxLength` — `??` rather than `||`, matching the sibling keys,
+  so an explicitly declared `0` stays a value the author wrote rather than falling through
+  to the column's ceiling. This narrows only what the input allows; the object's storage
+  ceiling still decides at submit time, so nothing that was accepted before is now rejected
+  anywhere but at the keyboard.
+  
+  Why it survived: the console's local `FormFieldSpec` did not declare `maxLength` at all
+  until objectui#5542, so no one typing a spec in this app could write the override in the
+  first place, and the inert merge branch was never exercised. #5542 converged that type
+  onto the shared app-shell declaration, which does declare the key — making the gap
+  expressible, and therefore findable.
+  
+  The pin `#5542` left behind — `expect(row.maxLength).toBeUndefined()` in
+  `FormPage.fieldSpec.test.ts`, which recorded the old answer explicitly rather than
+  assuming it — is **inverted** to `toBe(40)` rather than deleted. It was the pre-registered
+  evidence for this fix, and it is what made the gap findable in the first place, so it
+  keeps its place and names the honoured answer.
+- 60b2211: Console form pages no longer submit a cleared server-owned field as a blank.
+  
+  A field whose declared `defaultValue` is an instruction the server resolves per
+  insert (a `NOW()` / `current_user` token, or a CEL expression envelope) opens
+  with an empty control on a create form, and its key stays out of the payload
+  while nothing touches it. But a submitter who typed into that control and then
+  cleared it put the key back holding `''` — and `ObjectQL.applyFieldDefaults`
+  resolves a declared default only for a field arriving absent or null, so the
+  blank was stored and the declaration silently defeated.
+  
+  Such a key is now dropped from a CREATE submit on both the internal
+  `/forms/:name` and the anonymous `/f/:slug` route. A blank cleared from a field
+  with no runtime default — or with a static one — is still submitted, because
+  that is the user removing a value; and an edit submit is untouched, where a
+  cleared column is a deliberate removal.
+- 343c598: The active organization id is now stored per user, and a change of session user drops the
+  previous user's client state wholesale (objectui#5664).
+  
+  `auth-active-organization-id` was a single un-namespaced `localStorage` key while its
+  siblings were already user-scoped (`objectui-recent-items:u:`, `objectui-favorites:u:`,
+  `flow-palette-recents:u:`). On a browser handed from one account to another — a shared
+  machine, a kiosk, a handover, a support session — the arriving user's console read the
+  PREVIOUS user's organization id. The header workspace chip rendered the previous user's
+  workspace for a user whose `organization/list` was empty, and the consequence past the
+  cosmetics is the one worth stating: the polluted org context suppressed
+  `RequireOrganization`'s routing into the guided "Create your workspace" first-run flow, so
+  a brand-new user on that browser silently never got the new-user flow at all.
+  
+  Nothing about row visibility rode on this. With the stale id the server answers
+  `403 USER_IS_NOT_A_MEMBER` on `get-full-organization` and `set-active`, and lists zero
+  environments; the damage was entirely in what the client believed about itself.
+  
+  Three changes, and the third is the one that closes the class rather than the instance:
+  
+  - The key is per-user (`auth-active-organization-id:u:$userId`), matching the convention
+    its siblings already use.
+  - It can no longer be written un-namespaced at all. Where no session user is known yet the
+    value lives in memory for that page-load only — a namespacing that kept a bare-key
+    fallback would re-open the defect the first time a write happened before the user id
+    resolved.
+  - **A change of session user drops the previous user's client state wholesale.** This is an
+    allowlist sweep of both `localStorage` and `sessionStorage`, not a list of known keys, so
+    the NEXT storage key someone adds without a `:u:` scope is covered before it is written.
+    Only device-scoped entries survive: the arriving session's own bearer token, the pointer
+    recording whose state the browser holds, and the UI theme.
+  
+  Both properties objectui#5703 established are preserved and still pinned: `get()` prefers a
+  non-null `localStorage` read and falls back to the in-memory value, and the memory value is
+  nulled BEFORE storage is touched — by `clear()` as before, and now by the user-change purge
+  too, so the outgoing user's org id cannot outlive their persisted key on the sign-out-then-
+  sign-in path that never reloads the page.
+  
+  Existing browsers are not migrated. A value sitting under the retired bare key is
+  unattributable — nothing recorded whose org id it is — so migrating it is precisely the
+  defect it would be migrating away from, and it is deleted instead. A signed-in user loses
+  nothing durable: the active organization is a server-owned fact that
+  `AuthProvider.refreshOrganizations` re-asks for whenever the list is non-empty and no
+  active org is held, including the ADR-0081 single-membership repair. One boot re-supplies
+  it; users with no organization land on the guided first-run flow, which is the outcome this
+  card is about.
+  
+  `apps/console`'s pre-render auth preflight purges every spelling of the active-org key —
+  the retired bare one and each `:u:` scope — when it finds a dead bearer token, and
+  deliberately leaves the session-user pointer in place so the next sign-in can still tell
+  that the browser changed hands.
+- 9093de8: Approvals drawer: the business summary card no longer renders a field the object
+  declares `hidden: true`.
+  
+  `payloadSummary` built the card from the request's `payload_json` snapshot behind
+  five filters (system keys, the lead amount key, null/object/empty values,
+  unresolved opaque ids, a six-field cut) and no field-visibility filter, so a
+  hidden field that survived to the first six survivors rendered in the card,
+  labelled. The drawer now reads the open request's object metadata and drops the
+  declared-hidden keys before the six-field cut, so the next business field is
+  promoted into the freed slot rather than the card silently shrinking. The lead
+  amount figure at the top of the same card takes the same trim.
+  
+  Per the platform ruling, `hidden: true` is a UI-only contract and `internal: true`
+  is the serialization primitive, so this is the UI enforcing the only contract
+  `hidden` has — not a client-side compensation. Field-level security is unchanged
+  and remains the server's answer. The metadata read is the same cached
+  `GET /meta/object/:name` the record form already performs, once per object per
+  page visit, and an unanswered read leaves the card exactly as it renders today.
+- 0935a43: Console builds no longer carry a live Sentry DSN, and `sendDefaultPii` is now opt-in
+  (objectui#5522).
+  
+  `@object-ui/console` publishes a pre-built SPA, so ONE artifact — built once from
+  `apps/console/.env.production` — is what the hosted SaaS console and the on-premises /
+  air-gapped EE images all embed. Vite inlines every `VITE_*` from that file into the
+  bundle as a frozen object literal, so the DSN committed there was a live third-party
+  telemetry endpoint compiled into artifacts that land inside customer networks. It could
+  not be switched off afterwards either: the `VITE_SENTRY_ENABLED` kill switch is read off
+  that same frozen literal, so on a shipped bundle it is `undefined` forever and editing
+  env vars on the deployed host does nothing. An air-gapped deployment was measured
+  sending 14 envelopes per session to sentry.io with IP + User-Agent PII, unstoppable by
+  the customer.
+  
+  - `apps/console/.env.production` no longer defines `VITE_SENTRY_DSN`,
+    `VITE_SENTRY_ENVIRONMENT` or `VITE_SENTRY_SEND_DEFAULT_PII`. A build with no DSN never
+    imports `@sentry/react`, so the `vendor-sentry` chunk is not even fetched.
+  - `sendDefaultPii` changed from opt-out (`!== 'false'`) to **opt-in** (`=== 'true'`), so
+    IP address and User-Agent are never the inherited default of a build that did not ask
+    for them.
+  - The gate now fails **closed**: an absent, empty or whitespace-only DSN means do not
+    send. The direction is deliberately inverted from the usual — an unreported error is
+    recoverable, PII leaving an air-gapped deployment is not.
+  
+  **Action required for deployments that want error reporting** (the hosted SaaS/demo
+  console): inject `VITE_SENTRY_DSN` from your build environment, the same way
+  `VITE_SERVER_URL` is already injected, plus `VITE_SENTRY_SEND_DEFAULT_PII=true` if you
+  still want IP/User-Agent on events. Nothing else changes for builds that opt in.
+- e067173: Refreshes the lockfile so every `@objectstack/*` package resolves at `17.2.0` — `spec`, `client`, `core`, `formula`, `lint` and `sdui-parser` move in lockstep (a split resolution is what produced the dual-version spec graph that reddened `check:spec-symbols` in this repo's history), and no `17.1.0` resolution remains.
+  
+  **The docs-site and console builds stop pulling a Postgres connection-string parser toward the browser bundle.** `@objectstack/spec@17.1.0` imported `pg-connection-string` at the top level of `dist/index.mjs` with no `browser` export condition, so `apps/site`'s production build failed with `Module not found: Can't resolve 'fs'` on every route that reaches `@object-ui/components` from a client component — red on `main` since 2026-08-22 (objectui#5668). `17.2.0` ships the objectstack#11072 fix: `.`, `./data`, `./system`, `./kernel` and `./cloud` now carry `browser` conditions pointing at schema-free `dist/browser/**` bundles, and the site build is back to `Tasks: 29 successful, 29 total`.
+  
+  The refresh is lockfile-only — every manifest already declared `^17.0.0`, which admits `17.2.0`, so no dependency range changed. No shipped source moves: the two in-repo adaptations are a drift-guard test and a CI gate, both forced by `17.2.0` retiring the spec's theme module (objectstack#10485) exactly as the objectui#5716 localization predicted — its `Theme`/`ThemeMode`/`ColorPalette` ALLOW entries in `check:spec-symbols` went stale and were deleted, and the parity test now pins the vacancy (the spec re-publishing a theme name is a loud collision) instead of a spec leg that no longer exists.
+- 7d0143c: The Console now gates the `/studio/*` routes on the `studio.access` ENTRY
+  capability, not just on the backend's refusal of the writes behind them
+  (objectui#5519).
+  
+  `/_console/studio/` rendered the full Studio pillar builder — Data /
+  Automations / Interfaces / Access, with Publish and Save draft — to any
+  authenticated principal who typed the URL, on deployments where the Studio nav
+  tile is deliberately absent and every metadata write is refused. A plain tenant
+  user was walked through the entire "new package" form and only refused at
+  submit (403). The lockdown criterion for that deployment shape is two-part — UI
+  entry hidden AND API refused — and only the API half was met; what stood on
+  this side was a write-level gate where an entry-level one belongs.
+  
+  The whole `/studio` subtree now hangs off one route element that reads
+  `systemPermissions[]` from `GET /api/v1/auth/me/permissions` (the endpoint this
+  app already consumes) and admits only a principal whose LOADED set carries
+  `studio.access` — the capability declared as "Enter the Studio metadata-design
+  surfaces", which a tenant org owner does not hold by design. Everyone else is
+  sent to `/home` without the builder ever mounting.
+  
+  The fail direction is deliberately inverted from this app's other capability
+  gates: those fail OPEN on an unknown answer because their bad outcome is a
+  holder losing a button, whereas a route gate's bad outcome is a non-holder
+  seeing the builder. So the loading window renders the console splash (never the
+  builder), an outright fetch failure renders the retryable error splash, and a
+  `200` that carries no `systemPermissions` at all is refused rather than waved
+  through. The server-side refusals are untouched.
+- Updated dependencies [8d58f46]
+- Updated dependencies [0b1326d]
+- Updated dependencies [305205a]
+  - @object-ui/sdui-parser@17.7.0
+  - @object-ui/react-runtime@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/apps/console/package.json b/apps/console/package.json
index 0d050ae94a..23cb4fb0e1 100644
--- a/apps/console/package.json
+++ b/apps/console/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/console",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "description": "ObjectStack Console — opinionated, fork-ready runtime console built on @object-ui/app-shell with the full plugin set wired up. Ships as a Hono UI plugin serving a pre-built SPA.",
   "license": "MIT",
   "type": "module",
diff --git a/packages/app-shell/CHANGELOG.md b/packages/app-shell/CHANGELOG.md
index c3876b79ac..16e206f7ad 100644
--- a/packages/app-shell/CHANGELOG.md
+++ b/packages/app-shell/CHANGELOG.md
@@ -1,5 +1,3157 @@
 # @object-ui/app-shell — Changelog
 
+## 17.7.0
+
+### Minor Changes
+
+- 053fdc8: Console half of `ActionSchema.onSuccess` post-success navigation.
+  
+  `@objectstack/spec` declares `onSuccess` as a closed strict object
+  `{ navigate: string, openIn: 'self' | 'newTab' }`, refine-scoped to `type: 'api'` and
+  `type: 'script'` — the two action types whose success event carries a server response.
+  Nothing in this renderer read it, so an action declaring the hop navigated nowhere: the
+  block fell into `ActionRunner`'s older `ActionDef.onSuccess` chained-callback channel,
+  was dispatched as an action, and failed inside `executeNavigation` with "No URL provided
+  for navigation action" — a red toast and no jump. The motivating report is a clone action
+  that leaves the user sitting on the record they cloned from.
+  
+  `ActionRunner.handlePostExecution` now performs the declared hop through
+  `navigationHandler` — the same SPA seam every other navigator in that file uses, which
+  the console wires to react-router's `navigate`, so `openIn: 'self'` is a real in-place
+  route hop rather than a full-page load. `interpolateTarget` gains a `${result.*}` scope
+  alongside `${param.*}` and `${ctx.*}`, resolved against the handler's own return value
+  (the level `readActionPayload` reads, one below the action envelope) and supplied only by
+  this call site, so a target interpolated before its request still has no `result` to
+  name. `openIn` is read as the one member that changes the branch and no default is
+  written here — the spec materialises `.default('self')`, so parse output always carries a
+  resolved member — and the two `openIn` spellings stay apart: this reads
+  `onSuccess.openIn` (`'self' | 'newTab'`), never the top-level `type: 'url'` switch
+  (`'self' | 'new-tab'`), each of which spec refuses in the other's position.
+  
+  The console's server-action wrapper gains the matching handler-return half: a handler may
+  now return `openIn: 'self'` next to its `redirectUrl` to ask for the same-tab jump, while
+  a `redirectUrl` **without** `openIn` keeps its shipped new-tab behaviour unchanged. When
+  an action declares an `onSuccess` block, the wrapper defers to the runner and only tidies
+  its pre-opened tab, so one navigation happens rather than two.
+  
+  The pre-existing `ActionDef.onSuccess` chained-callback channel is unchanged. It is told
+  apart by the spec's own declaration — a non-array object whose `navigate` is a string —
+  and keeps running for every other shape.
+- 41b7ce3: **View configuration is explicitly org-wide, and its write path is now gated (objectstack#7494's
+  ruling, maintainer 2026-08-12).** The `sort` / `hiddenFields` / `columnState` / `rowHeight` that a
+  list toolbar persists were never per-user: they are one shared row on the view, so an ordinary user
+  dragging a column or cycling density was re-styling that view for the entire organization. Nothing
+  in the console said so, and nothing stopped it. A per-user scope stays parked (objectstack#7611,
+  v18) and is deliberately not built here — which is precisely why the write has to be gated rather
+  than narrowed: there is no second, private store for it to fall back to.
+  
+  `ObjectStackAdapter.updateViewConfig` now refuses when the session's **reported** ADR-0066 capability
+  set does not contain `manage_metadata`, throwing the new `ViewConfigPermissionDeniedError`
+  (`VIEW_CONFIG_PERMISSION_DENIED`, with `isViewConfigPermissionDeniedError` and the
+  `VIEW_CONFIG_CAPABILITY` constant alongside it). The gate is the **first** statement in the method —
+  before `connect()`, before the payload is assembled — so a refused call puts nothing on the wire.
+  It is on the write rather than on the toolbar button on purpose: withholding the affordance would
+  leave the method still accepting the call from anything else holding the adapter, whereas a gate on
+  the write is inherited by every caller, present and future.
+  
+  `manage_metadata` is not a newly minted name. It is the capability this repo already treats as
+  metadata-authoring authority — `HomePage`'s `AUTHORING_CAPABILITY`, the one the server itself
+  refuses metadata writes without — and the gated write goes through `client.meta.saveItem`, the very
+  same ADR-0005 metadata door, so this applies the authority the server is already applying instead of
+  inventing a parallel one.
+  
+  **Unknown fails open, by doctrine.** A capability set that was never reported (a backend predating
+  ADR-0066, or no permission provider mounted) is not a denial: the server enforces regardless, so a
+  client-side refusal on missing data cannot protect anything and can only break a permitted user. A
+  *reported* empty grant gates strictly. Hosts push the session's capabilities in with the new
+  `setSystemCapabilities`; `ObjectView` wires it from `usePermissions()`.
+  
+  The refusal is also **said out loud**. `ObjectView`'s persist path previously swallowed every failure
+  into `console.error`, which for a debounced toggle whose UI has already moved would have left the
+  operator looking at a density they did not get; a denied write now raises a toast. And the "View
+  settings" popover — where density and field visibility are actually changed — now states the scope
+  before the operator acts: *"Grouping, color, density, and visible fields. Applies to everyone who
+  uses this view."*, translated in all ten packs.
+- 26fbe09: Console telemetry can now be hard-disabled on an already-built artifact
+  
+  `/api/v1/runtime/config` gained `telemetry.allowClientErrorReporting`
+  (objectstack#11382), and the Console now reads it. The Sentry decision becomes a
+  conjunction of two independent grants — a DSN injected at **build** time AND a
+  positive permission from the **runtime** — so the single pre-built SPA that both
+  the hosted SaaS console and the on-premises / air-gapped EE images embed can be
+  silenced by the deployment it lands in, with no rebuild and without editing files
+  inside a published bundle. That was the half objectui#5522 could not close before:
+  every other input to the gate is a Vite build-time variable frozen into the bundle
+  as a literal, which is how an air-gapped EE Console came to send 14 Sentry
+  envelopes per session to `sentry.io` carrying IP + User-Agent PII with no way for
+  the customer to turn it off (objectstack-ai/cloud#1508).
+  
+  The permission fails **closed** in every direction: absent key, `telemetry` block
+  absent, malformed payload, failed fetch, or a runtime predating the key all read as
+  *do not send* — which is precisely the set of runtimes leaking today. It is a
+  permission and never a source: the server supplies no DSN and cannot turn telemetry
+  on for a build that carries none. Only a real boolean `true` grants; `'true'`, `1`
+  and other truthy lookalikes do not.
+  
+  Behaviour change for deployments that already inject a DSN: reporting now also
+  requires the runtime to grant permission, via
+  `OS_TELEMETRY_CLIENT_ERROR_REPORTING_ENABLED` (or `RuntimeConfigPlugin`'s
+  `allowClientErrorReporting`). A build that opted in but whose runtime says nothing
+  will go quiet — deliberately, since that is the same artifact an air-gapped
+  customer runs.
+  
+  `@object-ui/app-shell` additionally exports `isClientErrorReportingAllowed()` and
+  the `RuntimeTelemetry` type, so consumers read the permission through the one
+  fail-closed accessor instead of writing their own optional-chain against the
+  payload.
+- 6d63cd0: An auto-derived related list now orders its rows by the CHILD object's default list view
+  `sort`, instead of falling to the server's primary-key order (objectui#5795). A task
+  version's "check items" tab whose child object declares `sort: [{ field: 'seq_no' }]`
+  renders 10/20/30/40; before this it rendered whatever order the ids happened to give —
+  20/30/10/40 in the reported case — while the child object's own list page obeyed the
+  declaration.
+  
+  **Declared as user-visible, deliberately, even though no key was added.** The contract
+  question ("where does a derived related list's sort declaration live?") was ruled on
+  objectstack#11345 (maintainer, 2026-08-23) as **direction 1**: inherit the child's list
+  view sort, and add **no** new spec key — the field-level `relatedListSort` the issue also
+  proposed was explicitly not approved. So there is nothing new to author, and
+  `record:related_list.sort` was already declared, parsed and consumed; this fills it. What a
+  host observes is nonetheless new: a derived related-list descriptor gains a populated
+  `sort` where it had none, and the query it issues gains an `$orderby`. An app whose child
+  objects declare a default list order will see those tabs re-order on upgrade — which is the
+  point of the change, and is why this is not a patch.
+  
+  Nothing is inherited where nothing was declared: a child object with no default list-view
+  sort produces the same descriptor, the same node and the same `$orderby`-free query as
+  before.
+  
+  The two `sort` surfaces declare the same union and mean different things by its string arm
+  — a `ListView` string is the legacy space-separated `'seq_no desc'`, while the related
+  list's own reader takes `'field'` / `'-field'` — so the inherited value is normalized to
+  the array arm once, at the derivation, through `@object-ui/core`'s
+  `convertSortToQueryParams` (the repo's single definition of both authored dialects). An
+  un-normalized inherit would have ordered by a field literally named `seq_no desc`.
+  
+  Known and unchanged: `$orderby` is only assembled while the related list is in windowed
+  (server-paged) mode, so a declared *or* inherited sort still disappears while the built-in
+  client text filter is active. That hole pre-dates this change and affects the authored prop
+  identically; it is now pinned as a recorded fact in
+  `plugin-detail/src/__tests__/RelatedList.sortDroppedOutsideWindowed.test.tsx` rather than
+  fixed here.
+- 864154e: The Field Designer no longer offers a formula-expression textarea, and no designer write
+  path emits a `formula` key (objectui#6043).
+  
+  **This is a behaviour change on an authoring surface: a control is removed.** A field's
+  `type` may still be set to `formula` — that is a valid spec `FieldType` and stays in the
+  palette — but the expression itself is no longer authored here. Authors write formula
+  expressions in metadata-admin's field inspector, where they are checked.
+  
+  The control wrote `formula`, which is not in `FieldSchema`'s accept set. Measured against
+  the installed `@objectstack/spec` 17.2.0:
+  
+  ```
+  FieldSchema.safeParse({ type:'formula', label:'Tax', formula:'price * quantity' })
+    => success = false
+    => unrecognized_keys ['formula']   "Did you mean `formula` -> `expression`?"
+  ```
+  
+  so `PUT /api/v1/meta/object/:name` returned a hard 422 `INVALID_METADATA` — and because
+  the key was then stored, it blocked **every later save of that object**, not just the one
+  that introduced it.
+  
+  **The key was deliberately NOT renamed to the spec's `expression`.** `FieldSchema` judges
+  the key name and never the expression LANGUAGE — measured, it accepts
+  `expression: 'price * quantity'` and even `expression: '!!!not cel at all!!!'`; only the
+  empty string is refused. Spec `expression` is CEL rooted at `record`
+  (`record.amount * 0.1`), whereas this control's own placeholder taught `price * quantity`
+  — bare field refs, which under the scope formulas bind evaluate to null silently. A rename
+  would therefore have converted a loud, immediate 422 into a formula that saves clean and
+  then quietly computes nothing, which is strictly worse than the bug it appears to fix.
+  
+  Making refusals loud *in the control* would need CEL lint, autocomplete and `returnType`
+  inference — that is `CelPredicateField`, which lives in `@object-ui/app-shell`, and
+  app-shell depends on `@object-ui/plugin-designer`, so it cannot be imported back without a
+  dependency cycle. Growing a second formula-authoring surface inside plugin-designer is a
+  feature, not this fix. `returnType` is likewise not authored here: it is only derivable by
+  inferring the CEL result type, and with no expression control there is nothing to infer
+  from.
+  
+  `formula` joins the retired-key tombstone in `MetadataFieldsPage`, so an object already
+  carrying the key is stripped clean on its next save instead of staying blocked forever —
+  which matters more than usual here, because with the control gone an author would
+  otherwise have no way left to clear it. It is dropped rather than migrated to `expression`,
+  for the same reason the rename was refused. A `expression` authored in metadata-admin is
+  **not** touched: it is a real `FieldSchema` key and rides through the designer's
+  round-trip untouched.
+  
+  Also removes the now-unreachable `formula` read/write from
+  `views/metadata-admin/previews/object-fields-bridge.ts`, which was a third emit site for
+  the key that neither the card nor the parity gate named.
+  
+  The `formula` entry is removed from `check-designer-field-key-parity.mjs`'s
+  `KNOWN_UNPARSEABLE_KEYS` ledger, which ratchets in both directions — a resolved key that
+  left a stale entry behind would be as red as a new offender.
+- b023625: The field metadata payload no longer emits `sortOrder`, the key `FieldSchema` refuses by
+  name (objectui#6045). Field-level sibling of objectui#6223, same objectui#5761 family.
+  
+  Measured against the installed `@objectstack/spec` 17.2.0, whose `FieldSchema` accept set
+  is 71 keys:
+  
+  ```
+  FieldSchema.safeParse({ type:'text', label:'L' })                  => success = true   (control)
+  FieldSchema.safeParse({ type:'text', label:'L', sortOrder: 3 })    => unrecognized_keys ["sortOrder"]
+  
+  FieldSchema.safeParse({ type:'text', label:'L', sortable: true })  => success = true   (control)
+  FieldSchema.safeParse({ type:'text', label:'L', sortable: 3 })     => success = false
+  ```
+  
+  The control is what makes that a key-by-key result rather than a schema refusing
+  everything, and the `sortable` pair is what shows the near-spelling is a *different
+  concept* — a boolean ("whether field is sortable in list views"), not this key's spec
+  name.
+  
+  **The resolution was deletion, not a rename**, which is objectui#4687's shape rather than
+  objectui#6041's. The spec has no field-level ordering key at all: it models field order by
+  **declaration order** in the object's `fields` record, so a designer that wants explicit
+  ordering reorders that record rather than carrying an index. There was nothing to map onto,
+  and nothing was invented to map onto.
+  
+  **It was latent, and that is confirmed on today's tree.** Neither of the two sites that
+  construct a `DesignerFieldDefinition` — `FieldDesigner`'s create/update handlers and
+  `MetadataFieldsPage.toDesignerField` — ever named the key, so `toFieldPayload` emitted
+  `sortOrder: undefined` and `JSON.stringify` dropped it. The key never reached the wire. It
+  was one reorder feature away from doing so, which is the objectui#4644 shape: a hard 422
+  `INVALID_METADATA` that blocks every subsequent save of the object, with nothing in the UI
+  to say which key caused it.
+  
+  Removed in one go from the wire shape (`FieldMetadataPayload`), its writer
+  (`toFieldPayload`) and the UI model (`DesignerFieldDefinition`), so no declaration is left
+  behind that no writer fills and no schema accepts.
+  
+  **Breaking for TypeScript consumers**: `sortOrder` is gone from `DesignerFieldDefinition`
+  (`@object-ui/types`) and from `FieldMetadataPayload` (app-shell), so code that set either
+  stops compiling.
+  
+  Two keys share this spelling and are untouched, which is why the census was on the *shape*
+  — a field-metadata payload key `FieldSchema` refuses — rather than on the identifier: the
+  **object-level** `sortOrder` (`ObjectSchema`'s, removed from the object wire shape by
+  objectui#6223 and deliberately kept on the `ObjectDefinition` UI model) and the
+  **saved-view** `sortOrder` in `ObjectView`, which is per-view display order on a different
+  document entirely.
+  
+  The `KNOWN_UNPARSEABLE_KEYS` entry in `scripts/check-designer-field-key-parity.mjs` goes
+  with the fix — that ledger ratchets in both directions, so an entry left behind for a
+  resolved key is as red as a missing one.
+- 5173a5e: ⚠️ **Behaviour change: `current_user` predicates that have been doing nothing on
+  the console form routes and in the wizard's submit gate now TAKE EFFECT.** Read
+  this before upgrading if any of your form metadata gates on the session user.
+  
+  objectui#6010 bound the host predicate scope on the five authored-predicate call
+  sites in the components form renderer, so `current_user` (plus the ADR-0068
+  `user` / `ctx.user` / `os.user` aliases) resolves on `visibleWhen` / `visibleOn`
+  there. Two other authored-predicate evaluators were still passing `undefined`
+  for that argument, so the same authored text meant two different things
+  depending on which surface opened the form (objectui#6110):
+  
+  - **`apps/console`'s form renderer**, on the authed internal route
+    `/forms/:name`. The internal route is a runtime record surface by ADR-0089
+    D1's own words (*"runtime record surfaces bind `record` + `current_user`"*),
+    and its `visibleWhen` metadata is the same `*.view.ts` FormView the
+    object-view chain renders — so a role gate authored once behaved differently
+    depending on which route opened the form.
+  - **`WizardForm`'s submit-time required re-check** (`missingRequiredByStep`),
+    the gate that re-checks the whole declared field set at final submit because
+    `allowSkip` can jump past a step. Its docstring promises *"the same verdict
+    from all three rather than a second, divergent dialect"*, and since #6010 it
+    was the divergent one.
+  
+  **Why nobody noticed, and why the fix is felt as a change.** `visibleWhen` fails
+  OPEN: a field on screen is what you get when the predicate resolves TRUE, when
+  the scope was never bound so the predicate faulted, *and* when the predicate is
+  broken. Those worlds were indistinguishable, so an app that authored a
+  `current_user` gate saw the field render and had no way to tell the rule was
+  inert. After this change the predicate is evaluated for real, and fields and
+  sections that have always been visible will disappear for the users the rule
+  excludes. `requiredWhen` fails the other way (CLOSED), so a `current_user`
+  requiredWhen that has been silently not applying will now start holding submits.
+  
+  In the wizard the change is a fix in the user's favour as well: a required field
+  the wizard HID from this user was still counted as visible by the submit gate,
+  so the submit was refused on a control the submitter could neither see nor fill
+  in.
+  
+  **Before upgrading**, audit any `visibleWhen` / `visibleOn` / `requiredWhen` in
+  your form-view and object metadata that names `current_user`, and confirm each
+  predicate says what you actually want evaluated against `record` +
+  `current_user`.
+  
+  **The public anonymous form `/f/:slug` is deliberately unchanged.** It is
+  mounted outside `ProtectedRoute` so an anonymous visitor can submit it, there is
+  no authenticated principal, and no provider is mounted above it — so its scope
+  is empty and a `current_user` predicate authored on a public form still faults
+  and still fails open, exactly as before. Nothing new is declared to say so: the
+  two routes are told apart by which component mounts them.
+  
+  `@object-ui/app-shell` exports `buildExpressionUser`, the `ExpressionProvider`
+  user normalisation, so every console surface that mounts the provider publishes
+  the same `current_user` shape rather than re-deriving it.
+- d18a0d3: Object-level metadata payloads no longer emit the three keys `ObjectSchema` refuses by
+  name — **group**, **sortOrder** and **relationships** (objectui#6223).
+  
+  Measured against the installed `@objectstack/spec` 17.2.0, whose `ObjectSchema` accept set
+  is 42 keys:
+  
+  ```
+  const base = { name: 'account', label: 'Account', fields: { n: { type: 'text', label: 'N' } } };
+  
+  ObjectSchema.safeParse(base)                              => success = true    (control)
+  ObjectSchema.safeParse({ ...base, isSystem: true })       => success = true    (control)
+  ObjectSchema.safeParse({ ...base, pluralLabel: 'A' })     => success = true    (control)
+  
+  ObjectSchema.safeParse({ ...base, group: 'Sales' })       => unrecognized_keys ["group"]
+  ObjectSchema.safeParse({ ...base, sortOrder: 3 })         => unrecognized_keys ["sortOrder"]
+  ObjectSchema.safeParse({ ...base, relationships: [ … ] }) => unrecognized_keys ["relationships"]
+  ```
+  
+  The two controls are what make that a key-by-key result rather than a schema refusing
+  everything. Each key was resolved on its own, as the objectui#5761 family ruling requires:
+  
+  - **group** — the Object Manager's grouping is a UI-only display category. The spec has no
+    object-level grouping key (`fieldGroups` groups the fields *inside* one object), so the
+    grouping control and its column stay, and the value is now DERIVED from the spec key that
+    is accepted (`isSystem`) instead of round-tripped. `MetadataObjectsPage` also strips a
+    `group` already stored by an earlier build, because its save-back spreads the server
+    document verbatim and would otherwise keep re-sending it forever.
+  - **sortOrder** — what populated it was the array index the converter happened to be at,
+    i.e. the order the list was already in. The declaration is removed from the object
+    payload. The field-level `sortOrder` is a different key with a different card
+    (objectui#6045) and is untouched.
+  - **relationships** — the spec models relationships on the FIELD (`reference` /
+    `master_detail`, plus object-level `indexes`). The object payload stops declaring and
+    sending an object-level relationship array; what the designer should author for a
+    relationship is a data-model question this change does not settle.
+  
+  **Breaking for TypeScript consumers of `ObjectMetadataPayload`** (exported from app-shell):
+  the three properties are gone from the published type, so code that set them stops
+  compiling. That is the point — setting any of them produced a payload the metadata route
+  refuses. `ObjectDefinition` (the designer's UI model) is unchanged and still carries all
+  three.
+  
+  The parity gate built for objectui#5761 now has a **second oracle**: every shape in
+  `PAYLOAD_SHAPES` names the schema that judges it, `ObjectSchema` alongside `FieldSchema`,
+  and reach is resolved within an oracle rather than across one — `group` is a legal
+  `FieldSchema` key and a refused `ObjectSchema` key at the same time. That extension found a
+  fourth object-level key (`enabled`, objectui#6238) and a value-level rejection the key-name
+  check cannot see (`fields` sent as an array where the spec wants a map, objectui#6240);
+  both are filed and ledgered rather than fixed here.
+- 622f33c: `MetadataService`'s two delete methods no longer PUT a hand-written tombstone. They call
+  the metadata API's own delete door instead, and the latent `enabled?: boolean` on
+  `ObjectMetadataPayload` is gone with it (objectui#6238). Object-level member of the
+  objectui#5761 family, surfaced by the `ObjectSchema` oracle objectui#6223 added to
+  `scripts/check-designer-field-key-parity.mjs`.
+  
+  **What the tombstone actually did.** `deleteObject` and `deleteMetadataItem` wrote
+  `{ name, enabled: false, _deleted: true }` through `client.meta.saveItem`, i.e.
+  `PUT /api/v1/meta/:type/:name`. Measured against the installed `@objectstack/spec` 17.2.0
+  using `getMetadataTypeSchema` — the registry the framework's own `saveMetaItem` resolves a
+  PUT's validator from — across all 26 registered overlay schemas:
+  
+  ```
+  ObjectSchema.safeParse({ name, label, fields })                        => success = true   (control)
+  ObjectSchema.safeParse({ name, label, fields, isSystem: true })        => success = true   (control)
+  ObjectSchema.safeParse({ name, enabled: false, _deleted: true })       => unrecognized_keys ["enabled","_deleted"]
+  
+  25 of 26 registered overlay schemas refuse `enabled` and/or `_deleted` BY NAME
+   1 of 26 (`view`) tolerates them; 4 kinds have no registered schema at all
+   0 of 26 strip them
+  ```
+  
+  So there were two failure modes, not one. Where the type has a strict schema — `object`
+  among them — the delete was a hard `422 INVALID_METADATA`, so nothing was ever recorded.
+  Where the schema is tolerant or absent, the framework stores the request item **verbatim**
+  (it deliberately persists the body rather than `parsed.data`), and `_deleted` has no reader
+  anywhere on the platform — so the "soft delete" was a silent no-op that left the item live
+  carrying two junk keys. Neither outcome deleted or disabled anything.
+  
+  **The resolution is a mechanism change, not a rename**, and there was nothing to rename to.
+  `ObjectSchema`'s 42-key accept set has no on/off flag; the near-spelling `enable` is
+  `ObjectCapabilities`, a system-features *module object*, so `enabled: false` → `enable:
+  false` fails on the value where it passes on the name. No wire key was invented: a metadata
+  soft-delete convention would be a `@objectstack/spec` contract addition, and the platform
+  does not have one.
+  
+  **Both sites now call `client.meta.deleteItem(type, name)`** — `DELETE
+  /api/v1/meta/:type/:name`, the same request `MetadataClient.reset` issues, which is the
+  mechanism `MetadataObjectsPage.handleObjectsChange` and `ResourceEditPage` already used for
+  deletes. Two mechanisms for one operation had disagreed; now there is one. The delete route
+  is generic over `:type` on the same route family and capability gate as the PUT, so this
+  holds for every category the generic `deleteMetadataItem` serves, not just `object`. The
+  doc comment claiming the API "exposes `saveItem` but no dedicated `deleteItem`" was stale:
+  `@objectstack/client` 17.2.0 declares `meta.deleteItem` on the very client this service
+  already holds.
+  
+  `reset` semantics are the overlay's, and that is the governed answer rather than a
+  shortfall: it removes the customization row — which *is* deletion for an object the
+  designer authored — and restores the artifact for one a package declares, an object you are
+  not allowed to delete. Which of the two an item is, is what the API's own `deletable` /
+  `resettable` verdicts report, not something a client-side flag should decide.
+  
+  **No published type changed.** `ObjectMetadataPayload` is exported from its module but that
+  module is not re-exported by `packages/app-shell/src/index.ts`, the package's only entry, so
+  the removed `enabled?: boolean` was never on the published surface and no `**/src/index.ts`
+  is touched. What consumers *can* observe is behaviour: `MetadataService` is reachable
+  through the published `useMetadataService()` hook, both method signatures are unchanged
+  (`Promise<void>`), and the HTTP request they issue changes from a `PUT` with a body to a
+  `DELETE`.
+  
+  The `KNOWN_UNPARSEABLE_KEYS` entry in `scripts/check-designer-field-key-parity.mjs` goes
+  with the fix — that ledger ratchets in both directions, so an entry left behind for a
+  resolved key is as red as a missing one. It is now empty for the first time, which is the
+  ratchet arriving where it was pointed; the self-test's non-vacuity guard moved onto a
+  fixture accordingly, so an empty ledger reads as success rather than as a demand that some
+  key stay unresolved.
+- b362c1b: Setup gains a **Packaged automation** page — the operational surface for the flows an
+  installed package ships (ADR-0126 §7.4, objectui#6301). Reached the way every other
+  framework-contributed Setup surface is: the page registers the component-registry ref
+  `automation:packaged`, so app navigation names the ref and `ComponentNavView` resolves it
+  at `/apps/<app>/component/automation/packaged`. No bespoke route is added — a second way
+  in would be a URL the app metadata does not know about.
+  
+  Per packaged flow the page does exactly two things:
+  
+  - **on/off for this scope** — reads the activation state the engine reports
+    (`GET /api/v1/automation/_status`, backed by the ADR-0126 §7.2 `sys_metadata_activation`
+    ledger) and flips it through `POST /api/v1/automation/<name>/toggle`;
+  - **clone** — `POST /api/v1/automation/<name>/clone` with a mandatory new machine name and
+    label (§7.1). The carried-over definition is never offered as editable form fields; the
+    copy is edited in Studio like any other flow.
+  
+  Authoring stays in Studio. The list is scoped to packaged flows by the server's own
+  three-clause provenance test (`isCodeArtifactBody`, ADR-0029 D9.6) rather than the
+  `_packageId`-only shortcut, which classifies a tenant overlay bound to a package as
+  packaged — the cloud#970 misread, and here it would put a tenant's own flow behind an
+  install-wide switch.
+  
+  **Server refusals reach the operator verbatim** — no client-side softening or rewording.
+  Three shapes are relayed as sent: the §5 posture gate (403 `PERMISSION_DENIED`, whose
+  message names the tenancy posture *and* the sanctioned clone path), the §7.3 subflow guard
+  (409 `DELETE_RESTRICTED`, which names the packaged callers that would break mid-run — a
+  list nothing on the client could reconstruct), and the §7.1 clone name conflict (409).
+  
+  ⛔ **No drift or ancestry surface** (§9): no diff-vs-base, no "customized" badge, no
+  base-moved notice, no link from a clone back to its source. Cloned-without-disabled and
+  disabled-without-clone are ordinary states, shown plainly. Tests pin the absence, including
+  the case where a response carries a `clonedFrom` key anyway — the platform does not track
+  that lineage, so a page that displayed it would be displaying something it invented.
+  
+  `@object-ui/i18n` gains the `packagedAutomation` key group — 24 keys in `en` and real
+  translations in all nine other packs, matching each pack's existing vocabulary for "flow"
+  and "package" (zh 流程/软件包, ja フロー/パッケージ, ko 플로우/패키지, de Flow/Paket,
+  fr Flux/Package, es Flujo/Paquete, pt Fluxo/Pacote, ru Поток/Пакет, ar التدفق/الحزمة) and
+  each one's quotation convention. The group deliberately carries no drift or ancestry
+  wording, and no server refusal text: those arrive as server-authored prose and are
+  rendered verbatim.
+- 9602dc8: Setup › **Packaged automation** gains a packaged **actions** section beside its flows one —
+  the surface half of ADR-0126 §8 item 2 (objectui#6412; the engine, ledger and both dispatch
+  doors landed in objectstack#12348). The maintainer's pull, verbatim and untranslated:
+  「动作 可能是需要开关的，因为有的 action 我不想启用。」
+  
+  Per packaged action the section does exactly **one** thing: **on/off for this scope**. That
+  is all the `sys_metadata_activation` ledger knows about an action, and the section claims
+  nothing more.
+  
+  - **State** comes from the ledger's `metadata_type: 'action'` rows, read through the generic
+    data API list the object itself sanctions for exactly this
+    (`apiMethods: ['get', 'list']` — *"Reads stay open so operability surfaces can answer
+    'what is disabled here?'"*). **Absence of a row means active**, so a stock boot shows
+    everything armed.
+  - **Discovery** mirrors the runtime's own `collectActionDeclarations`: object-embedded
+    `actions[]` from `GET /meta/object` **plus** standalone items from `GET /meta/action`, with
+    the object-embedded declaration winning a `<object>:<action>` key clash. Listing only the
+    first source would leave an administrator with no off-switch for a packaged standalone
+    action.
+  - **Flips** invoke the L6 write door `POST /actions/_activation/:object/:action` with exactly
+    the one key its body declares (`{ enabled }`); `global` is the object segment for an
+    object-less action, the same spelling both dispatch doors take.
+  
+  **⛔ No clone for actions.** The flows section keeps its own (§7.1); amendment ruling 3
+  charters the *switch* for actions and nothing else, and §8 keeps the clone half pre-chartered
+  until real pull appears. A clone control here would advertise machinery that does not exist —
+  which is also why the server's §5 refusal for actions recommends the platform operator and an
+  ordinary sibling action where the flow refusal recommends a clone.
+  
+  **⛔ No drift or ancestry surface** (§9): no "customized" badge, no diff-vs-base, no
+  base-moved notice. The platform tracks no such lineage, so a surface showing it would be
+  showing something it had to invent. The absence is pinned against a response that smuggles
+  `clonedFrom` / `baseVersion` in, so it is enforced at the renderer and not merely by the wire.
+  
+  Server refusals reach the operator **verbatim** — no client-side softening, no retry loop.
+  Three shapes are reachable in tests, each transcribed character-for-character from the
+  runtime's own message builders: the §5 posture gate (403 `PERMISSION_DENIED`, naming the
+  posture *and* the sanctioned path), the ambiguous-name refusal (409 `RESOURCE_CONFLICT`,
+  naming the objects a machine name collides across — a list nothing on the client could
+  reconstruct) and the no-ledger outage (503 `SERVICE_UNAVAILABLE`).
+  
+  One further refusal is the section's own and it points the same way: a `hasMore` on the
+  ledger read is treated as a **load failure** rather than rendered. A dropped row reads as
+  "active", so a partial ledger would show a switched-off action as armed — the one direction
+  this section must not fail in.
+  
+  The flows section is unchanged in behaviour. It gains a heading beside the new one, and the
+  page subtitle now says "Flows and actions" — that string moved in all ten packs together.
+  Nine new `packagedAutomation.*` keys land in `en` **and in all nine other packs** as real
+  translations; the two toggle-failure keys are artifact-neutral by wording and are reused
+  rather than duplicated.
+- c71e14d: **The unresolvable-visibility-predicate report now names the roots of the tier the
+  predicate was actually evaluated against** (objectui#6487). An app-shell author
+  whose nav, area or field `visible` faulted was told to check `record` and
+  `page.<var>` — two roots that tier does not bind at all.
+  
+  `formatUnresolvableVisibilityMessage` and `reportUnresolvableVisibilityPredicate`
+  (both exported from `@object-ui/react`) take a new **optional sixth argument**, a
+  `PredicateScopeTier` — also exported — selecting the closing advice paragraph.
+  Everything above that paragraph is unchanged on every surface, and so is every
+  verdict: this is diagnostics copy only.
+  
+  **The published signature grew; nothing existing breaks.** The argument defaults
+  to `'page-component'`, so a five-argument call keeps printing the bytes it
+  printed before. All three in-repo call sites pass their tier explicitly rather
+  than lean on that default.
+  
+  Each tier's root set was derived from the code that builds the bag, not from the
+  prose that described it:
+  
+  - **`'page-component'`** — `SchemaRenderer`'s node gate and `page:tabs` item
+    predicates. Both bind `record`, `current_user` and `page.<var>` (the roots
+    `@objectstack/spec`'s `ui/page.zod.ts` declares for the tier). Its paragraph is
+    byte-for-byte what it was.
+  - **`'app-shell'`** — the chrome gate `ExpressionProvider.evaluateVisibility`
+    runs, wired onto this reporter by objectui#6443. Its evaluator is built from
+    `{ current_user, user, ctx: { user }, os: { user }, app, data, features }`, so
+    the line now names `current_user` with its three ADR-0068 alias spellings,
+    `app`, and `features` — the deployment-flag root that provider documents for
+    exactly this kind of predicate — and states outright that `record` and
+    `page.<var>` do not exist there.
+  
+  **Why not generalise the copy instead.** Dropping the concrete root names would
+  have made one paragraph true everywhere at the cost of making it useful nowhere:
+  an author who mistyped a root needs to know which roots exist *at their tier*,
+  which is the whole reason the paragraph is read.
+  
+  `data` is bound at the app-shell tier but is deliberately not advertised there —
+  every mount of `ExpressionProvider` in this repo passes `data={{}}` or omits it,
+  so naming it would point an author at a root that answers nothing.
+- 08c3da9: ⚠️ **Behaviour change: `current_user` and `features` gates on an object field's
+  `visible` that have been doing nothing on the record form page and in the
+  console's record modal now TAKE EFFECT.** Read this before upgrading if any of
+  your object metadata gates a field on the session user or on a deployment flag.
+  
+  objectui#6010 and objectui#6110 bound the host predicate scope on the form
+  renderer and on the console form routes. `evaluateVisibility` was still being
+  reached with a THIRD and FOURTH evaluator that neither of those touched:
+  `RecordFormPage` and `AppContent` each built a private
+  `new ExpressionEvaluator({ user, app, data })` for the field-visibility filter,
+  beside — not from — the `ExpressionProvider` each of them mounts. Those bags
+  bound `user`, but not the canonical `current_user` nor the ADR-0068 `ctx.user` /
+  `os.user` spellings of that same object, and not `features` at all. So one
+  authored predicate meant two different things depending on which evaluator
+  reached it: `current_user` resolved on a nav item and was unbound on a field.
+  Both sites now build their scope with the same `buildExpressionScope` the
+  provider uses, which is the only declaration of what an app-shell predicate may
+  name.
+  
+  **Why nobody noticed, and why the fix is felt as a change.** A field `visible`
+  predicate fails OPEN: a field on screen is what you get when the predicate says
+  TRUE, when the root was never bound so the predicate faulted, *and* when the
+  predicate has a typo. Those worlds are indistinguishable, so an app that
+  authored a `current_user` gate saw the field render and had no way to tell the
+  rule was inert. After this change the predicate is evaluated for real, and
+  **fields that have always been visible will disappear for the users the rule
+  excludes** — and a `features` gate whose flag is off will hide its field once
+  `/api/v1/auth/config` resolves.
+  
+  `AppContent`'s bag also hand-rolled its user as `{ name, email, role }`, without
+  `positions`. It now uses the same `buildExpressionUser` normaliser every other
+  console surface publishes, so `'sales' in current_user.positions` — the gate the
+  server enforces on write — reaches the same verdict client-side instead of
+  faulting open.
+  
+  **Before upgrading**, audit any `visible` predicate in your object metadata that
+  names `current_user` (or `user` / `ctx.user` / `os.user`) or `features`, and
+  confirm each says what you actually want evaluated. Measured on the metadata
+  shipped in this repo and in the framework at the time of the change: **nothing
+  in it authors such a gate**, so no shipped surface changes behaviour today —
+  the audit is for your own object metadata, which this cannot see.
+  
+  **The error path is deliberately unchanged.** A predicate that throws still
+  fails open, exactly as objectui#6443 / objectui#6487 left it. This change is
+  about which roots are BOUND, not about what happens when evaluation fails.
+- d06fba8: The console record page and the `record:activity` block read ONE `sys_activity`
+  type table, so a scheduled meeting no longer appears on one and vanishes on the
+  other.
+  
+  `RecordDetailView`'s `sys_activity` merge carried a hand-written copy of the
+  table that `record:activity` exports as `ACTIVITY_TYPE_TO_FEED_TYPE`. Neither
+  file imported the other and nothing compared them, so the two could drift
+  silently — and they had. objectui#5840 added `scheduled` -> `event` to the
+  exported table, because a shipped producer (HotCRM's `schedule_meeting`) writes
+  that value and the row was being dropped before any filter ran. The copy here
+  was left untouched, so the same row rendered on a hand-authored record page and
+  was dropped on the console record page: same record, same row, two answers.
+  
+  `RecordDetailView` now imports the exported table, and the copy is gone. The
+  table is re-exported from `@object-ui/plugin-detail`'s entry point, which is
+  what makes a single reading possible at all — it was previously reachable only
+  from inside the plugin. No module enters the eager closure: the module holding
+  it was already pulled in by the renderer beside it.
+  
+  Adding an activity type is now one edit, in one place, that both surfaces see.
+  A re-fork is caught rather than merely discouraged: the new pins spy on the
+  shared object and inject a member into it at runtime, so a private copy holding
+  today's members exactly — the failure this change removes — fails, where a
+  value comparison would pass on the defect.
+  
+  Only the table converges. The row-to-`FeedItem` construction around it is still
+  written twice, so an unmapped activity type is still dropped silently on the
+  console surface where the block warns once; that mirror is filed separately.
+- 77f846a: The approval panel identifies the pending approver by name, not by a truncated raw id.
+  
+  A record waiting on a position rendered its approver as `positi…ager` — the
+  engine reference `position:sales_manager`, 22 characters, past the identity
+  formatter's 14-character truncation arm and middle-truncated to fit its chip. The
+  step names beside it were human prose; the one line answering *who is holding
+  this record* was an internal identifier, and not even a complete one. The same
+  reference reached the admin-override confirm dialog un-truncated, so a paragraph
+  of plain governance prose ended `— position:sales_manager` (objectui#5414).
+  
+  Both surfaces now resolve the reference before rendering, in three tiers, most
+  authoritative first. The server's own `pending_approver_names` wins whenever it
+  answers, and a backend that resolves its own slate costs the record page no extra
+  request. Otherwise the console reads the directory row the spec's approver
+  binding names — `sys_position.label` gives `Sales Manager` / `销售经理` — and,
+  for a position, who fills the seat (`Sales Manager · Zhang Wei, Li Na`). With no
+  adapter and no row, the machine name still prettifies into prose rather than
+  truncating. The raw reference stays on hover, which is where an internal
+  identifier belongs.
+  
+  An unstaffed position is surfaced rather than hidden: `销售经理（暂无在岗人员）`
+  is actionable where `positi…ager` is not, and it is the motivating rescue case
+  for the admin-override path. Staffing is deliberately tri-state — a
+  `sys_user_position` read the viewer is not permitted to make leaves the seat's
+  staffing UNKNOWN and says nothing, because "I could not look" is a different
+  claim from "nobody holds it" and only one of them is safe to print on a
+  governance surface.
+  
+  Two locale keys are added across all ten packs: `approvalsInbox.approverUnstaffed`
+  and `approvalsInbox.approverNameSeparator`. The separator is a translated
+  punctuation key rather than `Intl.ListFormat`, which was measured on this tree
+  joining `['张伟','李娜']` into `张伟李娜` for `zh` — two names run together with
+  no separator, reading as one person's name.
+  
+  The directory-backed kinds and their value columns are read from
+  `@objectstack/spec`'s `APPROVER_VALUE_SOURCES` rather than restated, so a new
+  approver type is covered the day the spec publishes it. Id-valued kinds
+  (`user` / `team` / `department`) keep the existing middle-truncation: a row id
+  has no prose to recover, and that arm is objectui#3461's answer, not this card's
+  defect.
+- 6bd343d: The built-moment transition (#5799): a build conversation that has produced a WHOLE-APP build auto-routes to `/studio/<pkg>/interfaces` — on live completion and on reopening the conversation — after idempotently re-keying the thread under the `app:<pkg>:build` cache key the Studio dock resolves, so the workbench's right rail continues the SAME conversation. Cold start keeps the full-page surface; the dock's 以完整页面打开 door carries a sticky per-conversation opt-out so the one sanctioned way back is never bounced straight to Studio.
+- 1939c96: 设计⇄运行 on the Interfaces canvas (#5800): a two-state switch in the canvas header flips the SAME renderer between design (selection + inspector + design overlays) and an interactive runtime (click 新建, enter records) — ADR-0080's design=run pivot made visible; selection context survives the round trip. The topbar's 打开应用 teleport is retired (run mode is the in-workbench way to try the app), and the topbar's app detection now matches the pillar's (draft-app fallback, re-resolved on draft saves and the metadata-refresh pulse) so a deep-link to /access can no longer claim the package has no app while /data shows one.
+- b470e91: The metadata designer states its package on the publish step, not only on the save (#5420)
+  
+  Studio's designer save→publish loop bound the draft to a software package on the
+  save (`PUT ?mode=draft&package=<id>`) and then sealed it with a publish that named
+  no package at all. `objectstack#10354` (shipped in `@objectstack/rest` 17.2.0) taught
+  `POST /meta/:type/:name/publish` to accept `?package=<id>`, so the second call can now
+  state the same binding the first one already states.
+  
+  - `MetadataClient.publish()` accepts `packageId` and sends `?package=<id>`, the same
+    wire spelling and the same `encodeURIComponent` treatment `save()` gives it.
+  - `MetadataResourceEditPage` reads the binding for BOTH steps from one derivation
+    (`readActivePackageBinding`), so the two calls of one loop cannot drift apart. The
+    `?package=all` "show everything" scope keeps folding to "no package".
+  
+  The parameter is **omitted**, never sent empty, when the designer holds no binding.
+  Empty and absent are the same to the framework's normaliser today, but absent is the
+  shape the save door already followed, and the framework's promotion path branches on
+  the key being present downstream.
+  
+  What this buys is **reachability**, not speed: it lets `#9612`'s package-closure
+  narrowing at the runtime publish gate fire on an HTTP-driven promotion at all. That
+  narrowing has a second, independent gate this does not touch — objects carrying no
+  `_packageId` provenance are kept unconditionally — so on a tenant-authored overlay
+  corpus stating the package still narrows nothing.
+- c40f3b8: A screen flow's resume result reaches the user — on both outcomes (objectui#5417).
+  
+  A dogfood walkthrough reported that a refused `resume` and a successful one
+  "render identically: the dialog closes and the page is unchanged", leaving no
+  gesture that distinguishes "created" from "rejected". Re-measured against `main`
+  before any change, one half of that was already fixed — `interpretFlowResponse`
+  reads the ADR-0112 envelope, and `FlowRunner`'s `toast.error` has carried its
+  prose since the `400 FLOW_FAILED` classification landed in `17.6.0`, five minors
+  after the version the report was measured on. There was no interpreter bug and
+  no un-consolidated fourth call site. Three gaps in the RUNNER's disposition were
+  real, and they are what changed:
+  
+  - **A terminal failure no longer closes the dialog.** The reason it closed is
+    unchanged and is not reversed: on a `FLOW_FAILED` the engine has already
+    consumed the suspension, so a resubmit can only reach "No suspended run" and
+    must not be offered. Closing was one way to withhold that dead retry and the
+    expensive one — the user had just typed a form they could no longer see, and
+    the engine's sentence names a value that left the screen with it. The dialog
+    now stays open with the submit affordance withdrawn: the flat footer swaps
+    Submit for Close, and an `object-form` step drops its Save (which also stops a
+    second click from duplicating the record it had already persisted).
+  - **The refusal has a second, non-expiring carrier.** The toast stays — it is
+    viewport-fixed, so it still reaches a user scrolled past a tall step's header
+    — and an inline destructive `Alert` (`role="alert"`) now holds the same
+    sentence inside the dialog, beside the values that produced it. A retryable
+    refusal (`INVALID_SCREEN_INPUT`, transport, 5xx) keeps Submit live as before,
+    and its banner clears as soon as the user starts editing.
+  - **A successful run invalidates what the flow WROTE, not just what the user is
+    looking at.** Both hosts answered `onComplete` with
+    `notifyDataChanged({ objectName: <this page's object> })`, so a flow that
+    created a quote from an Opportunity page never told the related list that
+    would now contain it — the record did not appear until a manual reload. The
+    runner cannot know which objects a flow touched, so it emits
+    `{ objectName: '*' }`: the same scope, for the same stated reason, that the
+    record page's manual ⟳ already uses. Everything mounted refetches in place
+    over the invalidation bus, with no remount.
+  
+  The runner's copy now goes through `@object-ui/i18n` instead of being hardcoded
+  English: a new `flowRunner` namespace (`title`, `submitting`, `saveAndContinue`,
+  `nextStep`, `completed`) in all ten packs, plus reuse of
+  `common.{loading,cancel,close,submit}` and `wizard.missingRequired`. The
+  server's own refusal sentence is still passed through untranslated — it is prose
+  the automation engine composed for a human, not copy with a key.
+- f4becce: Console Home stops offering the metadata-authoring front door on a deployment
+  whose own runtime config says authoring is not offered there (objectui#5521).
+  
+  The "Build an app" cover card is now withheld when
+  `GET /api/v1/runtime/config` reports `features.aiStudio: false`. On the composed
+  hosted-SaaS shape that card led a plain tenant into the full authoring flow
+  behind a runtime whose `/api/v1/meta/*` answers `403` and whose ToolRegistry
+  holds zero authoring handlers — the entry was offered and the refusal arrived at
+  submit. The lockdown criterion for that shape is two-part, UI entry hidden AND
+  API refused; only the backend half was green.
+  
+  - The card is **hidden, not dimmed**, because that is the flag's own declared
+    meaning on both sides of the wire: `RuntimeFeatures.aiStudio` documents "when
+    false, the SPA hides the AI authoring affordances", and the serving plugin
+    documents "set false to force-hide the authoring UI".
+  - `features.marketplace` keeps the different presentation objectui#5504 gave it
+    — a dimmed card plus a visible localized reason. That flag means a route is
+    reachable; this one means force-hide. "Start with a template" is untouched:
+    installing a marketplace package is not AI metadata authoring and answers to
+    its own flags.
+  - No reason line is rendered in its place. `home.build.noCapability` says the
+    *account* lacks "Manage Metadata"; on a runtime with no authoring at all the
+    surface is absent for everyone, and pointing a viewer at a permission that
+    would not help them is the misdirection objectui#5557 is about.
+  - Unknown fails **OPEN** (`!== false`), the doctrine `isMarketplaceEnabled()`
+    already encodes: a runtime predating the flag, or one whose config fetch
+    failed, keeps the card exactly as visible as before.
+  
+  No new authorable config key, no new server surface, and no new copy — the flag
+  was already being served and already reaches the browser.
+- c8da8b3: Stop showing an access-denied screen to a real administrator while their
+  adminship is still resolving.
+  
+  `useIsWorkspaceAdmin()` returned a bare `boolean`, so "the inputs have not
+  arrived yet" and "resolved: not an admin" were the same answer. One of its three
+  sources — the active organization member row — is fetched some round trips after
+  the session (`listOrganizations` → `getActiveOrganization` → `getActiveMember`),
+  so an administrator whose adminship lives only in that row rendered at least
+  once as a non-admin, and every gate downstream acted on it: the two marketplace
+  surfaces painted `MarketplaceAccessDenied`, the console chrome dropped and
+  re-added its admin nav entry, and `AppContent` fired a `<Navigate to="/home"
+  replace>` that the later flip could not undo.
+  
+  **Breaking (published API, hence `minor` per this repo's version policy):**
+  `useIsWorkspaceAdmin(): boolean` is replaced by
+  `useWorkspaceAdminStatus(): { isAdmin: boolean; isResolved: boolean }`. The old
+  name is removed rather than kept alongside, so a call site that ignores the
+  third state fails to compile instead of silently refusing an administrator.
+  
+      -const isAdmin = useIsWorkspaceAdmin();
+      +const { isAdmin, isResolved } = useWorkspaceAdminStatus();
+  
+  `AuthProvider` gains `isMembershipResolved` on its context — the organization /
+  member pipeline has reached a terminal state — because `organizations`,
+  `activeOrganization` and `activeMember` read `[]` / `null` / `null` both before
+  the pipeline starts and after it finds nothing.
+  
+  No extra wait for administrators: `isResolved` is true the instant `isAdmin` is,
+  so an admin the session already identifies through `positions[]` never waits on
+  the member row.
+- e2e8e68: **Behaviour change:** the spec's view-level `map` block on a list view is now read at
+  runtime. `ListMapConfigSchema` (objectstack#9340) has been authorable and validated since
+  the `@objectstack/spec` 17.1.0 pin — it flows into this repo's own `ListViewSchema` by
+  reference — but nothing consumed it: `ListView`'s `case 'map'` forwarded only the legacy
+  `schema.options.map` bag, so declaring `map: { titleField: 'title', locationField:
+  'location' }` on a view changed nothing and marker titles fell back to the renderer's
+  placeholder.
+  
+  The block now reaches `plugin-map` and drives every one of its seven reads — coordinate
+  extraction, marker title and description, and the initial camera. Precedence follows the
+  convention the sibling visualization blocks in the same file already set: the view-level
+  block wins over `options.map`, per key, exactly as `kanban` / `calendar` / `gallery` /
+  `timeline` / `gantt` each merge their spec config over the legacy bag. Both sources go
+  through the existing objectui#5177 key whitelist, and the branch still emits the flat
+  form, so `getMapConfig`'s objectui#5018 precedence rule ("neither flattener emits a `map`
+  key at all") stays true.
+  
+  The visualization switcher had the same gap with a sharper consequence: the capability
+  gate that decides which visualizations are offered also read `options.map` alone, so a
+  view binding its coordinates in the spec block was filtered out of its own
+  `appearance.allowedVisualizations` and fell back to `['grid']`. The gate now asks the same
+  merged config the render seam forwards, so the two cannot disagree — including for a
+  binding split across the two sources.
+  
+  `InterfaceListPage` (ADR-0047 interface pages) forwards the referenced view's `map` block
+  for the same reason. It is passed alongside the auto-derived `options.map` rather than
+  replacing it, so a partial authored block — `map: { titleField: 'title' }` — keeps the
+  derived coordinate binding instead of dropping it.
+  
+  No defaults are introduced for `zoom` / `center`: an undeclared camera stays undeclared,
+  so the fit-to-queried-records behaviour ruled in objectui#5000 is unchanged.
+- 20e317c: Marketplace-less runtimes now say so instead of erroring: `OS_CLOUD_URL=off` is a
+  first-class disabled state, and the load-failure hint describes the control plane
+  the runtime was actually pointed at (objectui#5504).
+  
+  `apps/objectos-ee/deploy/.env.example` ships `OS_CLOUD_URL=off` as its factory
+  default, so a stock self-hosted stack has no marketplace at all. The Console still
+  recommended one: Home led with "Start with a template" and "Browse App
+  Marketplace", and the click landed on a red **Failed to load marketplace / Not
+  found** card whose hint claimed this runtime "points at the public ObjectStack
+  cloud by default" and advised setting `OS_CLOUD_URL`. Both claims were false for
+  exactly the deployment reading them — the operator had not left the default, and
+  the advice pointed back at the template that told them to set `off`. "Marketplace
+  disabled by configuration" is a configuration conclusion, not a load failure.
+  
+  - `isMarketplaceEnabled()` (`runtime-config`) reads the server's own
+    `features.marketplace`, which `RuntimeConfigPlugin` derives per request from the
+    serving app's route table (objectstack#8356). It is never inferred from the shape
+    of a failed request: a control plane that is merely DOWN leaves the flag `true`,
+    so an outage still renders as an outage. Unknown fails OPEN.
+  - The marketplace page renders an informational "App Marketplace is turned off"
+    state — muted, not `destructive` — and issues no request it knows will 404.
+  - Home's "Start with a template" cover greys out with a visible localized reason,
+    and the "Browse App Marketplace" shortcut is withheld, exactly as they already
+    are for the `manage_metadata` capability gate.
+  - `marketplace.load.failedHint` is replaced by `failedHintConfigured` (naming the
+    configured control plane) and `failedHintSameOrigin`. The "points at the public
+    cloud by default" sentence is gone: it was rendered unconditionally, including on
+    every runtime whose operator had overridden `OS_CLOUD_URL`.
+  
+  All ten locale packs carry the new keys.
+- 8b1a8f3: **The page-editor palette now offers the canonical `record:discussion` instead of the `record:chatter` alias.**
+  
+  The two spellings are one renderer under two names — `@object-ui/plugin-detail` registers both against `RecordChatterRenderer` — and the palette deliberately carries one entry per renderer. It carried the wrong one. `record:discussion` is the canonical spelling: `@object-ui/core`'s `public-blocks.ts` records `record:chatter` as that same block "under a Salesforce-familiar name, kept for schemas", app-shell's own page synthesiser (`buildDefaultPageSchema`) has emitted the canonical name all along, and the console's AI block vocabulary already leaves the alias uncurated for exactly this reason. The palette was the last surface still pointing at the alias, and it did so only because the `@objectstack/spec` build pinned when the entry was written had no canonical member to offer; the currently pinned build declares both. The author-facing label moves **"Chatter feed" → "Discussion"**. Maintainer ruling 2026-08-22 on objectui#5495.
+  
+  **The alias keeps rendering — this changes what Studio advertises, not what works.** `record:chatter` moves from `BLOCK_TYPE_META` into `PALETTE_EXCLUSIONS`, which is the palette's ledger of "renders, but is not offered". Every page schema in the wild that spells the block the Salesforce way renders exactly as before, and both halves are now pinned by a test (`palette-discussion-alias.test.tsx`) that asserts the registry resolves the alias to the *same renderer function* as the canonical name and that an alias schema still produces the discussion panel — so "no longer offered" cannot quietly drift into "no longer rendered".
+  
+  One knock-on worth knowing when you open an existing page: the block-editor canvas draws a node's icon and colour tone from the palette entry, so an existing `record:chatter` node now shows the generic unknown-block icon in the outline instead of the message icon. This is the pre-existing behaviour for any renderable-but-unoffered type — until this change it was the *canonical* `record:discussion` that read this way, including in every page the platform generates itself, so the affected spelling is now the rarer one.
+- 60d452e: `ReportView` reads a report's data binding through the one key the contract declares — `dataSource.object`.
+  
+  The view accepted `resource` as a second spelling of `object`, in two places, and
+  named that spelling in a warning the user could read:
+  
+  ```
+  :171  liveReport?.objectName || liveReport?.dataSource?.object
+                               || liveReport?.dataSource?.resource
+  :273  dataFetchSource.dataSource.object || dataFetchSource.dataSource.resource
+  :275  console.warn('ReportView: dataSource missing object/resource property')
+  ```
+  
+  `resource` is not on this binding. `ElementDataSourceConfig` declares `object`,
+  `view?`, `filter?`, `sort?` and `limit?`; its `@objectstack/spec` twin
+  `ElementDataSourceSchema` is a strict object, so an extra `resource` key is
+  *rejected* there rather than ignored; and the binding's own predicate
+  `isElementDataSourceConfig` decides on `object`. A `resource`-only binding
+  therefore was never a binding on any other renderer in the system — it rendered
+  here and silently produced nothing anywhere else, with neither end reporting a
+  problem. That divergence is what a consumer-side alias buys: one renderer
+  answering a question the contract says has no answer.
+  
+  `resource` is a real key on other surfaces — `CRUDSchema.resource`, the
+  `DataSource` adapter's first parameter, `LiveExportOptions.resource` — and all
+  three are untouched. None of them is this one.
+  
+  Behaviour, measured by rendering each input shape before and after. Only the
+  `resource`-only shape moves:
+  
+  | binding | before | after |
+  | --- | --- | --- |
+  | `object` only | queries that object | unchanged |
+  | `resource` only | queries it as if declared | not queried; named warning, no rows, fallback field list |
+  | both | queries `object` | unchanged |
+  | neither | not queried; warning | unchanged |
+  
+  So off-spec report metadata that used to render now fails loudly instead of
+  appearing to work. A producer census found nothing that would notice: no site in
+  this repository, and none in the `objectstack` framework repository, writes
+  `resource` onto a report `dataSource`. The limb was speculative in the commit
+  that introduced it, and per AGENTS.md #0.1 an off-spec spelling is corrected at
+  the producer, never taught a second dialect by the renderer.
+  
+  The `:275` wording now names only `object`. A diagnostic that lists a key the
+  contract does not declare is not a small thing: it is the system telling an
+  author — increasingly, an author's code generator — that the wrong spelling is
+  supported.
+- 2d36552: Pins `@objectstack/spec`, `@objectstack/client`, `@objectstack/formula` and `@objectstack/lint` to `17.1.0`, and adapts the two consumer surfaces the new build moves.
+  
+  The pin itself is a lockfile refresh — every manifest already declared `^17.0.0`, which admits `17.1.0`, so no dependency range changed. All four move together: a split resolution is what produced the dual-version spec graph that reddened `check:spec-symbols` in this repo's history.
+  
+  **A `icontains` filter now reaches the driver as a filter.** `icontains` is a canonical `VIEW_FILTER_OPERATORS` member as of `17.1.0`, so an author can declare it on a `ViewFilterRule` and the spec validates it — but `@object-ui/data-objectstack`'s alias table had no row for it, and an unmapped operator is how this adapter shipped an unfiltered query before (objectstack#3948). It is an identity row like `contains`: `icontains` is itself a member of `VALID_AST_OPERATORS`, so the spelling the author writes is the spelling the AST takes, and no case-sensitivity is translated away. Declared rather than left to the table's `?? op` fall-through, on the rule its own parity test states — the AST gate accepting a spelling is not the driver compiling it into a `WHERE` clause.
+  
+  The same operator reaches the list view's own bridge: `@object-ui/plugin-list`'s `mapOperator` gains an explicit `icontains` arm. The emitted spelling is identical to the input, but the arm is written out rather than left to the `default` passthrough — `icontains` is its own member of `VALID_AST_OPERATORS`, so a raw passthrough is accepted *today*, and depending on that coincidence is what the bridge's own parity test records as how it once stopped discriminating.
+  
+  `@object-ui/core` adds `onSuccess` to its spec key inventory, so an author writing the key `17.1.0` now declares is no longer warned that it is unknown. That is a diagnostic statement only — the four declared action surfaces still drop the key before it reaches the runner, which is tracked separately.
+  
+  **A stored view filtering case-insensitively still shows that operator when it is reopened.** `@object-ui/plugin-view`'s canonical-to-builder table is keyed by `ViewFilterOperator`, so `17.1.0` adding `icontains` failed to compile rather than letting the operator reach the FilterBuilder as a raw spelling its dropdown cannot select. It maps to the builder's `containsCaseInsensitive` — the id that authors the spec's `$icontains` — and deliberately not to `contains`, which would quietly rewrite a case-insensitive filter into a case-sensitive one the next time the view was saved.
+  
+  **The page-editor palette keeps one entry per renderer.** `17.1.0` retires `element:filter` from `PageComponentType` and adds `record:discussion`, leaving the member count at 34 either side — so the swap is invisible to any count-based reading. The stale `element:filter` exclusion is dropped, and `record:discussion` is excluded because it is the *same renderer* as the already-offered `record:chatter`, not because it is unauthorable. Nothing the palette offers changes.
+  
+  **The console eager-closure ceiling is re-baselined, by maintainer ruling.** The release is roughly 930 KB larger uncompressed and nearly all of it lands in `vendor-objectstack-*.js`, which put the closure past a ceiling that was deliberately sized to catch a 89 KiB regression — the gate refused the bump, correctly. Raising it was escalated rather than taken locally, because gate-strength policy had been ruled the maintainer's; the ruling on objectui#5531 authorised the raise. `MAX_EAGER_CLOSURE_GZIP_BYTES` and the `BASELINE` it is derived from move together in one commit, keeping headroom at 2.00% and below the 91,136-byte regression size the gate must still catch. The gate's *sensitivity* is untouched: a repeat of that regression from the new baseline still fails. No behaviour ships from this file — it is CI policy, recorded here because the version it governs is the one this changeset publishes.
+- 8e32da7: AI build surface gains a standing 「未发布改动」 bar (#5694): while the conversation's bound package has pending drafts, a bar floats above the composer — surviving scrolling — counting the unpublished changes and publishing them through the same governed `publish-drafts` route as the inline card button, with probe findings surfaced instead of a blind success toast. Renders nothing when the count is zero or the conversation is unbound.
+- 7a90afd: Studio's `新建对象` asks for the record-sharing baseline, and an unauthored one is reported before Publish rather than by it.
+  
+  Creating an object through Studio collected exactly two things — display name and
+  identifier — and saved a draft that declared no `sharingModel`. The draft saved
+  happily, the form designer worked, and the object was then refused at 发布 →
+  全部发布 by `security-owd-unset`: a required decision the surface never asked
+  for, delivered by failing, as English ADR prose in a toast that then vanished on
+  a timer. The one actionable word in it named a control three clicks away that
+  nothing routed to.
+  
+  The publish gate is correct and is unchanged — an org-wide default has to be an
+  authored decision, not an accident. What changes is when the console asks and
+  when it answers:
+  
+  - **The create dialog asks.** A third field collects the baseline, pre-selected
+    to `private` and glossed with the Settings tab's own strings, so a new object
+    is publishable by construction. `buildObjectSkeleton` now takes the value as a
+    required parameter — a future create path cannot omit the baseline without
+    failing to type-check. `controlled_by_parent` is deliberately not offered at
+    creation: it derives access from a master relation a brand-new object does not
+    have yet, so offering it would trade one publish refusal for another.
+  - **The review sheet reports it.** The pending-changes panel now runs the
+    framework's own `validateSecurityPosture` over the pending object drafts and
+    names any blocking finding, with its fix-it hint, next to the Publish button.
+    It mirrors the producer's rule rather than re-deriving it, and it reports
+    without blocking — the server door stays the authority.
+  - **The Settings tab stops calling an unset baseline safe.** It described unset
+    as "defaults to Private", which answers what the runtime does and not whether
+    the object can ship. It now reads as the publish-blocking problem it is,
+    styled like the external-wider warning beside it.
+- 19479a3: Studio simplification, first cut (#5813): the Data pillar's object sub-tabs collapse to 记录/表单 with the five power panels (验证/钩子/操作/API/设置) behind one 「高级」 menu (the open panel's name wears the active pill, so the collapsed default never hides where you are); drafts now AUTO-save (debounced 1.5s, CEL-blocking gates the timer per the objectui#4306 rule, a failed save waits for the next edit) and the four 保存草稿 buttons are retired in favor of a quiet saving/last-saved hint; the 权限 pillar moves from the top-level row into a 「更多」 overflow whose items carry the same dirty-guard as the primary pillars — the /studio/:pkg/access route and every page behind it are untouched.
+- eddc1dd: The Studio copilot tells the agent WHAT the user is discussing (cloud#1610 send half): `ChatPane` accepts a `surfaceContext` and sends it as `context.surface` on every turn (the transport reads the body per send, so it stays fresh); the Studio copilot derives it from the URL alone — the `:tab` pillar segment plus the `?surface=type:name` deep-link the pillars already mirror, so the artifact carries its type discriminator (page/object/dashboard/report). A display chip above the composer (「正在讨论：…」, new `console.ai.discussing` key in all ten packs) makes the sent context visible instead of invisible grounding.
+- 4697234: One pending-drafts source of truth (#5801): `usePendingDrafts` / `fetchPendingDrafts` replace the five hand-rolled `GET /api/v1/meta/_drafts` copies behind the home banner, Studio topbar 变更/待发布 buttons, chat pending-drafts bar, chat draft-card resolver, and the preview watermark bar. Every successful publish path (`usePublishAllDrafts`, Studio `doPublish`, the chat bar) now emits the assistant bus's metadata-refresh pulse, and a chat turn that staged or replayed drafts emits it on completion — so a publish or an agent-staged draft anywhere converges every surface at once, and the home banner no longer needs its post-publish `window.location.reload()`. An errored drafts read now uniformly reports UNKNOWN (null), never a fake zero.
+- f471b4f: The metadata designer's View **column list** now reads a column's identity —
+  row label and bound field name — in the ObjectStack canonical spelling only:
+  `field` and `label`. The legacy TanStack aliases `accessorKey` / `header` are no
+  longer consulted (objectui#5725). This is the editor-side half of the read
+  objectui#5344 retired in the column inspector one file over; the two surfaces
+  render inside the **same panel** and until now gave the author two different
+  answers about what a column is called.
+  
+  Why this is a behaviour change and not a tidy-up: `ListColumn` refuses both
+  legacy keys by name (`unrecognized_keys`), so a column carrying them has no
+  field key and no label the spec recognises. Two consequences the list surface
+  had that the inspector did not:
+  
+  - **The label chain was inverted, not merely tolerant.** It read
+    `label ?? header ?? field ?? accessorKey`, preferring the undeclared `header`
+    **over** the declared `field`. A perfectly canonical column that also carried
+    a stray `header` key displayed the alias' value *instead of* its own declared
+    identity.
+  - **The field-name read backs more than a label.** It feeds `usedFieldNames()`,
+    which the Add-field picker consults, so a spec-refused column reserved a field
+    name and the picker tagged that field "Added" — for a column no accepted
+    document actually binds.
+  
+  **What an author sees:** a stored column shaped `{ accessorKey, header }` is now
+  named positionally in the list (`col 1`) rather than by its refused spelling,
+  and the row stays selectable exactly as before — the positional fallback already
+  existed at the end of that chain. The Add-field picker no longer reports such a
+  column's field name as taken. Canonical `{ field, label }` columns and
+  bare-string columns are untouched, and a declared `label` / `field` now outranks
+  any stray alias beside it.
+  
+  **What is deliberately NOT changed:** the write path. These helpers still
+  reorder and splice the raw `columns` array without normalising it, so no stored
+  document is rewritten by the act of viewing or editing it — the same fence
+  objectui#5344 held.
+- 0e00da3: The metadata designer's View column inspector now reads a column's identity —
+  field key and label — in the ObjectStack canonical spelling only: `field` and
+  `label`. The legacy TanStack aliases `accessorKey` / `header` are no longer
+  consulted (objectui#5344).
+  
+  Why this is a behaviour change and not a tidy-up: `ListColumn` refuses both
+  legacy keys by name (`unrecognized_keys`), so a column carrying them has no
+  field key the spec recognises. The inspector nevertheless read them and
+  displayed `accessorKey`'s value in the field-key box, presenting a spec-refused
+  key as though it were a valid column identity — the same consumer-side
+  tolerance alias `ObjectGrid` retired in objectui#5068, surviving one layer up in
+  the authoring tool, which is the surface that is supposed to teach the correct
+  shape.
+  
+  **What an author sees:** a stored column shaped `{ accessorKey, header }` now
+  shows an EMPTY field key and an empty header, and is re-authored rather than
+  silently carried. Canonical `{ field, label }` columns and bare-string columns
+  are untouched.
+  
+  **What is deliberately NOT changed:** the writeback. `patchIdentity` still
+  re-emits whichever spelling it was handed, so no stored document is rewritten
+  by the act of editing it. Normalising on write was ruled out once the
+  maintainer confirmed there is no population of legacy stored documents to
+  migrate; such a column stays unsaveable against the spec both before and after
+  an edit, exactly as it did before this change. What this removes is the
+  invisibility of that state, not the state itself.
+
+### Patch Changes
+
+- f66072d: Inline `t(key, { defaultValue })` strings are now held to the one placeholder spelling a
+  provider-less host can resolve, and five of them are pinned to the pack value for the first
+  time (objectui#4905).
+  
+  `check:i18n-keys`' `default-value-drift` class pins an inline default byte-identical to its
+  `en` row, and objectui#3512 holds `en` to the one spelling `createSafeTranslation`'s
+  `fallbackT` interpolates — so most inline defaults were covered transitively. Re-measured
+  on this tree, 66 of 1003 were not: three literal defaults on dynamic keys, and 63 written
+  as a computed expression. A new `unresolvable-default-spelling` class in
+  `scripts/check-i18n-call-site-keys.mjs` now judges the text every inline default carries —
+  the folded sentence, or a template literal's static segments — so `{{ name }}`,
+  `{{count, number}}`, `{{- name}}` and `$t(key)` are refused wherever they are written,
+  rather than only inside a copy table.
+  
+  Four call sites gain a real pin because their default carries no placeholder at all: the
+  record-form submit button now falls back to `Update`/`Create` (the pack's wording) instead
+  of `Save`/`Create` via a nested `t('common.save')`, the context selector's package label
+  and the approvals separator now state their literal. One more (`detail.showEmptyFields`)
+  is behind a `createSafeTranslation` hook, whose fallback does interpolate, so it can safely
+  say what the pack says.
+  
+  The other 61 are deliberately left computed, and the measurement behind that is the useful
+  part: react-i18next's not-ready `t` returns `options.defaultValue` **verbatim, without
+  interpolating it**. At a call site bound to a bare `useObjectTranslation()`, a default
+  written as `` `Signed in as ${user.email}` `` is therefore the only form that renders
+  correctly with no provider — rewriting it to `'Signed in as {{email}}'` would put literal
+  braces in front of the user, which is the exact defect this family of cards exists to
+  prevent. Those sites keep their template literals and are covered by the spelling class
+  instead.
+- baac3f4: Fix four `find()` calls that passed a query option without its `$`, and gate the shape.
+  
+  `QueryParams` declares every query option `$`-prefixed and `convertQueryParams` copies
+  exactly those keys, so an unprefixed spelling reaches no branch and is dropped — no throw,
+  no warning, and it type-checks because the type carries `[key: string]: any` for
+  adapter-specific params. For a dropped cap the result is an **unbounded** read rather than
+  a truncated one: the platform's GET list route has no default page size, so the query
+  returns the whole match set and stays invisible until the object is large.
+  
+  - `app-shell` `ObjectView` fetched the footer's record count with `{ limit: 0 }`. This one
+    **inverted** rather than widened — `$top: 0` is honoured end to end as "no records", so
+    the dropped key turned "count only, fetch nothing" into "fetch every row in the object",
+    on every mount and every refresh of every list view. It now sends `$top: 0` and reads
+    the count off `total` only; the row-counting fallbacks are gone rather than repointed,
+    because once zero rows are requested an empty `data` means "you asked for none", not
+    "the object is empty", and counting it would assert a confident `0`. With no total the
+    footer line is omitted instead.
+  - `app-shell` `AssignedUsersSection` looked a permission set up with `{ …, limit: 1 }`,
+    one line from three correct `$top` calls.
+  - `plugin-dashboard` `DashboardFilterBar` passed `fields` **and** `top` in one literal, so
+    a filter's option list read every row and every column of its source object while its
+    own comment described it as capped at 200. The same call read `records.items`, which is
+    not a `QueryResult` member, so against a real adapter the fallback produced no options
+    at all.
+  - `console` `sdui-workbench-preview` passed `{ top: 200 }` and read `.records` off the
+    result in its page-source metadata.
+  
+  A new `object-ui/no-unprefixed-query-params` ESLint rule rejects the shape at write time:
+  a known query-option name missing its `$` in the second argument of a `find`/`findOne`
+  call. It is narrow on purpose — a closed list of spellings, anchored to the call — because
+  the index signature exists so adapters can take adapter-specific params, and a rule that
+  flagged any unprefixed key would report the shape the type was written to allow. Its
+  sibling `no-query-params-under-options` (the `{ options: { $top } }` half) is unchanged.
+- 7c96c94: Four more private copies of the reference-bearing field family converge onto
+  `@object-ui/core`'s `EXPANDABLE_FIELD_TYPES`, and the "fourth and last private copy" claim
+  that `paramToField` still stated is corrected (objectui#5874, objectui#5875).
+  
+  Each copy diverged from the published family in BOTH directions, so this is a behaviour
+  change on every face and not a refactor:
+  
+  - **`user` and `tree` are now treated as relations.** Both carry the same foreign-key
+    storage as `lookup` and resolve through the same expand path (objectui#2032), and each
+    face's own stated reason for special-casing `lookup` applied to them verbatim — so
+    gaining them restores the rule each face already meant. A `user` / `tree` field is now
+    read-only in the quick-look drawer (`RecordDetailDrawer`), where the drawer wires no
+    relation picker and a plain text input let a user overwrite the relation with a
+    free-form string; it gets the wide layout basis in the record header's highlights strip
+    (`HeaderHighlight`), whose inline editor is a record picker; and a field-backed action
+    param over one now inherits the picker config it needs (`resolveActionParams`).
+  - **`master_detail` is now treated as a relation by `resolveActionParams` too** — it was
+    the only face missing that member as well, so a field-backed `master_detail` action param
+    inherited no `referenceTo` at all and degraded to the unexplained "paste a record id"
+    text input that objectui#3405 exists to prevent.
+  - **The undeclarable `reference` spelling is gone from the three field-type faces.**
+    Measured against `@objectstack/spec`'s closed `FieldType` vocabulary with live controls
+    (`lookup` / `master_detail` / `user` / `tree`) and dead ones (the retired `owner`, plus a
+    nonsense spelling): `reference` is absent, so no spec-compliant object schema could
+    declare a field that reached those branches. It sat exactly where `owner` sat before
+    objectui#4814 retired it — dead weight that read as live capability.
+  
+  `resolveActionParams` keeps answering for `reference`, deliberately and by a different
+  route: it is refused by the spec's `ActionParamSchema` too, but the dialog still accepts it
+  from params already authored with it, and that acceptance belongs to the one alias table in
+  `paramToField` rather than to a hand-copied membership test. This face now asks the shared
+  family over the widget key that table produces — the same expression `paramToField`
+  evaluates one step later, so the half that populates a param's picker config and the half
+  that forwards it can no longer disagree.
+  
+  No face copies the set: each calls `.has()` on the object `@object-ui/core` exports, and
+  each carries an identity pin (a spy on that `has`) so a member-identical private copy fails
+  instead of quietly re-forking the table.
+- 2cf69e4: The field designer now reads and writes a lookup field's relationship target under the
+  spec's spelling `reference` (objectui#6041), in both directions.
+  
+  `referenceTo` is not in `FieldSchema`'s accept set. Measured against the installed
+  `@objectstack/spec` 17.2.0, through the whole object document that
+  `PUT /api/v1/meta/object/:name` validates:
+  
+  ```
+  ObjectSchema.safeParse({ …, fields: { rel: { type: 'lookup', label: 'Owner',
+                                              referenceTo: 'user' } } })
+    => success = false
+    => unrecognized_keys at ["fields","rel"] keys=["referenceTo"]
+       "Did you mean `referenceTo` -> `reference`?"
+  ```
+  
+  so authoring a lookup field through the designer returned a hard 422 `INVALID_METADATA`,
+  and — because the key is then stored — blocked **every subsequent save** of that object,
+  with nothing in the UI to say which key did it.
+  
+  The read direction was broken symmetrically and is the half that would have survived a
+  write-only fix: `toDesignerField` read `raw.referenceTo` while a spec-parsed server sends
+  `reference`, so every already-saved lookup field loaded into the designer with an **empty
+  reference box**. Both wire-bound payload shapes move — `FieldMetadataPayload`
+  (`MetadataService.toFieldPayload`) and `ServerFieldSchema`
+  (`MetadataFieldsPage.fromDesignerField`).
+  
+  `referenceTo` also joins `RETIRED_FIELD_KEYS`. Renaming the emit sites alone does not
+  unblock an object whose stored fields already carry the misspelling: `carryOver` spreads
+  the previous server def verbatim, so the key would ride straight back out to the same 422.
+  The designer's in-memory `DesignerFieldDefinition` keeps `referenceTo` — that is the
+  internal prop name every other UI surface in this repo already uses (`LookupField`,
+  `filter-builder`, `ObjectChart`, `ListView`, `UserFilters`), it reaches no wire-bound
+  shape, and the parity gate classifies it as `uiOnly` rather than a violation.
+  
+  No behavioural change for a half-filled draft: the spec's prose calls `reference`
+  "required for relationship types", but that is not enforced by the zod parse at 17.2.0 —
+  `{ type: 'lookup', label: 'L' }` parses green at field level and through `ObjectSchema`,
+  and `undefined` is dropped by `JSON.stringify` under either spelling, so the wire bytes
+  are identical before and after.
+- 79ebf30: Home renders one agreed label for an item kind that has no translation key.
+  
+  The rail (`HomeContinue`), `RecentApps` and `StarredApps` all resolve the same
+  `home.recentApps.itemType.*` label, and each spelled the lookup itself. They had
+  drifted: the rail fell back to the bare kind (`report`) where both card surfaces
+  fell back to the capitalised one (`Report`) — two spellings of the same word on
+  one screen. All three now resolve through a single `recentItemTypeLabel` helper,
+  so the fallback cannot drift apart again.
+  
+  User-visible: the rail's label for an unkeyed kind changes from `report` to
+  `Report`. Every kind shipping today carries a key, so no label changes for them;
+  this is about the next kind added, and any host passing a kind the locales do
+  not carry.
+- 9ea4cde: `MetadataService`'s object writers PUT `fields` as the name-keyed MAP `ObjectSchema`
+  requires, not an array (objectui#6240). Both of the designer's write paths were affected,
+  and `saveFields` ran the conversion in the wrong direction outright: the server's own
+  document arrives with `fields` as a map, and `fields.map(toFieldPayload)` turned it into an
+  array on every field save.
+  
+  Measured against the installed `@objectstack/spec` 17.2.0 and against the framework's own
+  write door. `ObjectSchema.fields` is a required record: an array — empty or not — is
+  refused `invalid_type @ fields`, a map parses. `metadata-protocol`'s `saveMetaItem`
+  resolves metadata type `object` to that same `ObjectSchema`, `safeParse`s the whole item
+  and throws `422 INVALID_METADATA` **before** persisting, so the array was refused rather
+  than stripped or stored: every designer object save and every designer field save that went
+  through this service was a 422 that wrote nothing.
+  
+  This is the value-level half of the objectui#5761 parity family and is invisible to that
+  family's key-name gate — `fields` sits in the accept set under either shape, which is the
+  gate's own coverage note 4. The pins are runtime assertions on the captured request bytes.
+  
+  The conversion refuses, loudly, what it cannot key: a field with a missing or blank `name`
+  throws instead of writing a `{ undefined: … }` entry (measured: the spec ACCEPTS that
+  document, so nothing downstream would have caught it), and a duplicate name throws instead
+  of letting the later field silently replace the earlier — a loss an array does not have.
+  `saveFields` keeps preserving unknown keys of the fetched server document, which now
+  actually reaches storage. `saveObject` with no `existingFields` still omits the key rather
+  than writing `{}`: a PUT is an upsert, so `{}` would delete every field of an object on a
+  save that only meant to rename it.
+  
+  `saveObject(obj, existingFields)` keeps its `FieldMetadataPayload[]` parameter type — the
+  array is converted inside — so no caller's call site changes.
+- 944a929: The flow designer's node inspector no longer offers a **Description** field, and strips a
+  stored `description` off a node the first time an author edits it (objectui#6287).
+  
+  `FlowNodeSchema` is `.strict()` (objectstack#4001) and refuses that key by name — measured
+  on the installed `@objectstack/spec@17.2.0`:
+  
+  ```
+  FlowNodeSchema.safeParse({ id, type, label, description, config })
+    -> unrecognized_keys: ["description"]
+  ```
+  
+  By this package's own reading of that mechanism, the cost is not untidiness but an
+  unsavable draft: the key "surfaces as `unrecognized_keys` in the live client validation and
+  as a 422 on save" (`flow-canvas-layout.withCanonicalGeometry`, on the identical retired `ui`
+  case). So the field was not merely describing a shape the contract refuses — it was
+  producing one, on every keystroke, and nothing anywhere read the value back. The spec's flow
+  node has eleven keys and no note key of any spelling, so there was no reader to grow into.
+  
+  Stored flows heal on the author's first edit, the same migrate-on-write boundary the retired
+  `ui` geometry gets, and for the same reason: with the field gone there would otherwise be no
+  way left to clear a `description` an author had already saved.
+  
+  The three hand-written copies of the node and edge shapes that let this drift go unseen are
+  now one declaration each — `FlowNodeInspector`'s node and edge types alias the canonical
+  `FlowNodeLike` / `FlowDesignerEdge`, and `flow-decision-edges`' fourth edge copy aliases the
+  same canvas edge instead of restating it with a `condition?: unknown` that had already
+  outlived objectui#3202's narrowing by months.
+- 780efc0: `ConditionBuilder`'s row mode now compiles a value that is plainly a **reference** as one,
+  instead of quoting it into a string literal (objectui#6293).
+  
+  `fmtValue` quoted anything that was not a number / `true` / `false` / `null`, and the value
+  box is free text — so an author building "this field differs from its prior value", the idiom
+  that *defines* a change-detection predicate, got `previous == 'previous.status'`. That is
+  syntactically valid CEL, `previous` is a declared root, and a string literal's contents are
+  deliberately not scanned for references by `flow-ref-check` or by the server-side validator.
+  The predicate parsed, registered, evaluated — and was always false, with no author-time signal
+  at any layer, at all five surfaces that mount this builder.
+  
+  A value matching a **declared root prefix** now emits as the reference: `record`, `previous`,
+  `parent`, `user`, `current_user`, `org`. That set is this builder's own vocabulary — `record`
+  / `user` / `org` are exactly what its subject dropdown offers one control to the left,
+  `previous` and `parent` are bound by `evalFieldPredicate` and by the server-side hook /
+  validation evaluators, and `current_user` is the ADR-0068 spelling of the same identity object
+  `user` names. Roots this builder never offers (`data`, `os`, `app`, `features`, `input`,
+  `vars`, `page`) are deliberately excluded: `data.csv` is a plausible literal and `data` *is*
+  bound, so capturing it would trade one silently-false predicate for another rather than for a
+  loud one. Declaring which roots a mounting surface actually binds is caller-supplied
+  vocabulary and belongs to objectui#6296.
+  
+  The test is "a dotted path under a declared root", not "contains a dot" — a version string
+  (`1.2.3`), a filename, and a path under an unbound root all stay literal text. The literal and
+  number controls are unchanged: `done` still compiles to `'done'`, `42` still to `42`.
+  
+  **Nothing already stored is rewritten.** A persisted `previous == 'previous.status'` no longer
+  round-trips byte-for-byte, so the builder's existing safety rule hands it to the raw CEL editor
+  rather than reinterpreting it — the author sees both readings and decides. In the other
+  direction a hand-authored `record.status != previous.status` now round-trips *into* the row
+  builder, which it could not before.
+  
+  The repair is at the authoring surface, where the ambiguity is: no consumer-side tolerance is
+  added, and the emitted reference is now an identifier the existing reference checkers can see,
+  where a string literal's contents were invisible to them.
+- dddb942: Delete the dead `metadata-admin/previews/object-fields-bridge.ts` module, and the three
+  prose references that still described it as wired.
+  
+  The module exported `bridgeFromDraft`, `commitToDraft` and `FieldsBridgeResult` and had
+  **zero importers** — re-measured on the merged base, not inherited from the filing. Nothing
+  in the repository could reach it either: `@object-ui/app-shell`'s `exports` map declares
+  only `.` and `./styles.css`, so the file was not addressable as a deep import even from
+  outside the workspace.
+  
+  Removing it is not the whole change. Three comments — in `types/src/designer.ts`, `types`'
+  `designer-field-types.test.ts` (twice) and `fields`' `richtext-cell-renderer-5452.test.tsx`
+  — cited the bridge as a live corroborating source. Left behind, they would have swapped
+  dead code for false documentation: three in-repo pointers telling a future reader that this
+  bridge mediates between the framework field record and `FieldDesigner`, and nothing telling
+  them it is unreachable. The two that named it as the consumer deriving an editable-subset
+  check from `DESIGNER_FIELD_TYPES` now name `MetadataFieldsPage`, which does exactly that
+  with the same idiom and the same `objectui#3017` anchor. The third cited the bridge's
+  `richtext` → `html` mapping as one of three corroborations that `richtext` stores HTML; the
+  other two (the showcase seed and the field-type decision tree) are live and carry the point
+  on their own, so that clause is dropped rather than repointed.
+  
+  No behaviour changes: nothing imported the module, so there is nothing to migrate.
+- 11f23e9: `ActionParam` has one authority again (objectui#6329). The name was declared three times,
+  not twice as the card counted: `@object-ui/types` publishes it — derived from the spec's
+  `ActionParamSchema` input, with its own parity suite — and `ActionDefaultInspector.tsx` and
+  `ActionPreview.tsx` each carried a module-local `interface` of the same name. app-shell
+  already read the published one elsewhere (`utils/resolveActionParams.test.ts`), so both
+  locals were shadows. They are deleted, not reconciled against each other, under the
+  2026-08-25 family ruling 甲A1.
+  
+  Neither shadow needed a member the published type lacks, so nothing was added to the
+  published surface. What the shadows got wrong was the DECLARATION, in the direction that
+  lets wrong metadata compile:
+  
+  - The inspector's copy carried `[k: string]: unknown`. An index signature admits every key
+    at type `unknown`, so a commit of a key `ActionParamSchema` rejects by name — `.strict()`,
+    and `referenceTo` is listed in its alias map — type-checked here and failed on save. It
+    also made the two copies look compatible when they were describing different authoring
+    surfaces: `options` / `helpText` / `defaultValue` were declared outright on one side and
+    swallowed as `unknown` on the other.
+  - The preview's copy declared `label?: string | { en?: string }`, admitting the `en` tag and
+    no other, while its own `localize` helper has always read `Object.values(o)[0]`. An inline
+    locale map keyed `fr-FR` rendered correctly and failed `tsc`. The published `I18nLabel`
+    admits both authorized forms, so the type now matches what the code already did — this
+    widens the declaration, not the runtime's acceptance.
+  
+  Two behaviour-visible consequences, both of them the local `type?: string` being withdrawn
+  in favour of the published `ResolvableParamFieldType` (the spec's 49-member `FieldType` plus
+  objectui's three declared param aliases):
+  
+  - `ActionPreview.renderFieldMock` no longer branches on `long_text` or `integer`. Neither is
+    in that vocabulary — `long_text` belongs to the console form-builder dialect and `integer`
+    to JSON Schema — so a param spelled either way is a parse rejection on the server and
+    could never have reached the preview. The two comparisons compiled only because the local
+    copy typed `type` as `string`.
+  - The inspector's param-type dropdown narrows its commit through the runtime witnesses
+    `@object-ui/types` exports (`ACTION_PARAM_FIELD_TYPES` + `OBJECTUI_LOCAL_PARAM_FIELD_TYPES`)
+    rather than writing the raw DOM string. An unrecognised spelling clears the key instead of
+    being written into metadata the server would refuse; the eight offered spellings are
+    unaffected, and are now checked against the vocabulary at compile time.
+- 2eb8cae: `StarredApps` now filters out `nav`-type favorites before rendering (objectui#6335).
+  
+  `FavoritesProvider` has always documented `nav` favorites (sidebar entries pinned via
+  the in-tree pin toggle) as "Excluded from Home/Starred and from the generic sidebar
+  Favorites list so it doesn't render twice" — but `StarredApps` filtered nothing by type,
+  so a `nav` favorite handed to it rendered anyway. `FavoriteItem['type']` also has no
+  `nav` key under `home.recentApps.itemType.*` (only five of its six members do), so a
+  `nav` card that reached `StarredApps` fell through to the raw `"nav"` label instead of a
+  translated one.
+  
+  `StarredApps` now filters `items` to `type !== 'nav'` before rendering — the same
+  exclusion already applied to the sidebar Favorites list in `AppSidebar.tsx` and
+  `UnifiedSidebar.tsx` — restoring declared-equals-enforced behaviour and making the
+  missing locale key correct by construction. No locale packs were touched, and the
+  `FavoriteItem` / `RecentItem` union types are unchanged.
+- 6630b37: The console boot no longer flashes a fully-white frame after the splash has painted
+  (objectui#6378).
+  
+  Cause, established by measurement before any fix was written — the card named
+  `LoadingScreen`'s unmount timing and `RouteFader` as suspects and both are exonerated.
+  A CDP `Page.startScreencast` frame ledger (every frame classified with the card's own
+  rule: white when no colour channel falls below 242) was correlated against a DOM-state
+  ledger on the same clock (`performance.timeOrigin`), against the production
+  `apps/console` bundle with the boot endpoints mocked. `RouteFader` never mounts on the
+  boot path at all, and `LoadingScreen` unmounts exactly when its own gate says to. What
+  is wrong is what REPLACES it: every readiness gate renders the splash while it waits and
+  a bare `<Navigate>` the moment it decides. `<Navigate>` renders `null` and react-router
+  runs the navigation as a transition, so the destination tree renders while the commit
+  that already dropped the splash is what the compositor is showing — 41–147 ms during
+  which `#root` holds no view and the viewport is the bare page background. The flash is
+  intermittent only because it depends on a frame being swapped inside that window; the
+  window itself was present on every measured boot.
+  
+  `RedirectWithSplash` (new, `@object-ui/app-shell`) pairs the same `<Navigate>` with the
+  same `LoadingScreen` the gate one line above was already rendering, so the handoff
+  changes no pixels and the transition runs underneath an unchanged screen. The console's
+  three boot redirects use it: the auth gate's `/login` bounce, the `/` landing resolver,
+  and the catch-all route. The nested organization `index` redirect deliberately does not —
+  it fires under an already-painted layout, where covering the screen would be the
+  regression.
+  
+  Acceptance campaign — same instrument on both sides, the two arms INTERLEAVED inside one
+  process and one browser so drift in this shared container's load lands on both equally.
+  102 paired boots per arm across five cells (signed-out `/`, signed-in `/`, an unmatched
+  entry, and the card's two throttled network profiles). The empty-viewport window: 102/102
+  pre-fix, 0/102 post-fix. The white frame itself, pooled over the three cells where the
+  pre-fix build actually flashed: 67/87 (77%) pre-fix, 0/87 post-fix — 95% upper bound on
+  the residual rate 3.4%, against a card-reported defect rate of ~1/3. The two throttled
+  cells are reported but NOT pooled: the pre-fix build flashed 0 times there, so before and
+  after agree and those cells prove nothing about the pixels (they still separate 15/15 vs
+  0/15 on the DOM window).
+  
+  `e2e/console-boot-indicator.spec.ts` gains the deterministic half as a gate — after
+  React's first commit the viewport centre must never stop being covered. That reading is
+  what makes an intermittent defect gateable: the flash needs a frame to be swapped inside
+  the window, but the window itself was present on every measured boot. Verified red-first,
+  6/6 red on the pre-fix bundle and 6/6 green on this one.
+- a672ae9: `app-shell`'s two action runtimes now reset `ActionParamDialog` the same way when it closes
+  (objectui#6431). `useConsoleActionRuntime` closed with `setParamState({ open: false, params: [] })` —
+  replacing the whole state object, emptying `params` and dropping `title`, `description` and
+  `resolve` — while `RecordDetailView`, which mounts a second runtime into the same dialog,
+  closed with `setParamState(s => ({ ...s, open: false }))`. The console runtime moves onto the
+  field-preserving shape.
+  
+  The user-visible effect is in the fade-out. `DialogContent` carries
+  `duration-200 data-[state=closed]:animate-out`, so Radix keeps the content mounted through
+  its exit animation and the dialog goes on rendering off `state` for the whole ~200ms. Under
+  the blanking shape a params form the user had just filled in re-titled itself from the
+  action's own label to the generic "Action parameters", swapped the action's description for
+  the generic one, and dropped every param row — an empty, generically-labelled box fading out
+  where a form had been. The confirm pair converged on the same shape for the same reason in
+  objectui#6034; this is that ruling re-measured on this dialog rather than inherited, because
+  `ParamDialogState` carries a form rather than display text and "blank it on close" could have
+  been deliberate here.
+  
+  It was not, and nothing else changes for the user. The values a user types are not in
+  `paramState` at all — they live in `ActionParamDialog`'s own `values` state, which its
+  `useEffect` reseeds from the param defaults on every `state.open` false→true edge, so a
+  reopened dialog starts blank under either reset shape. The retained `resolve` is inert: the
+  dialog settles the promise before it asks for the close, and the open path replaces the whole
+  state object.
+- 7fdf74e: A nav / area / field `visible` predicate that FAULTS now says so, in both builds, once per
+  distinct predicate source (objectui#6443). Observability only — no verdict moves.
+  
+  `ExpressionProvider.evaluateVisibility` is the gate behind a navigation item's `visible`,
+  an area's derived visibility, and the field list `RecordFormPage` renders. It is fail-open:
+  a predicate that cannot be evaluated returns `true`, so a menu entry whose role gate has
+  stopped working renders **for everyone — including the role it was written to exclude** and
+  looks exactly like an entry the author meant to show.
+  
+  That fault was swallowed one layer down. `evaluateCondition` is fail-soft: it answers an
+  unevaluable predicate with `true` from its own `catch` and does not throw, so this site's
+  `try/catch` never saw a predicate fault at all. Measured per dialect at this site before the
+  fix — the bare-string dialect, the one a live gate was measured breaking on, printed
+  **nothing at all**:
+  
+  | dialect | console at this site, before | after |
+  |---|---|---|
+  | bare string | nothing | one named line |
+  | `{ dialect: 'cel' }` envelope | one generic line | one named line (the generic one is *replaced*, not added to) |
+  | `${…}` template | one generic line **per evaluation** | one named line, deduped |
+  
+  The fix wires `EvaluationOptions.onFault` (the seam objectui#6038 landed) to
+  `reportUnresolvableVisibilityPredicate`, exported from `@object-ui/react` — the same
+  reporter, message, severity, dedupe `Set` and rate limit the node gate and `page:tabs`
+  already use, so one authored predicate is entitled to one line rather than one line per
+  package. It costs no extra engine call: the evaluator hands back the reason at the point it
+  already knows the predicate faulted, with no `throwOnError` double evaluation.
+  
+  A nav item is not a schema node, so the reporter's `type` slot — which, with the gate key
+  and the predicate source, is the dedupe key — is the constant `app-shell:visible`. The rate
+  limit is therefore **one line per distinct authored predicate source**, not one per menu
+  entry: a broken role gate copy-pasted across eight entries is one authoring mistake, in one
+  string, fixed in one edit.
+  
+  **Fail-open is unchanged.** The item still renders for everyone on a fault. Flipping that to
+  fail-closed is a permission-boundary change, not a diagnostic, and is not this change's to
+  make; the change makes the silence stop and nothing else.
+- 830ed58: The record page's approval band offers its **Recall** button to the approval's submitter
+  only (objectui#6464).
+  
+  Field report on `@objectstack/*@17.2.0`: user A submits a record into a 4-level approval;
+  user B — not the submitter, read access, not an admin — opens the record and the band still
+  lights a clickable recall button. The click cannot succeed. The recall endpoint authorizes
+  on submitter identity and refuses everyone else, so the only outcome available to that
+  button was a failure toast. Record state was never at risk; this was purely a
+  writability-feedback mismatch, the same family as objectui#3794.
+  
+  The button's only gate was `dataSource.cancelPendingApproval` — "can this adapter recall at
+  all" — which is a question about the DataSource, not about the viewer. Identity now joins
+  it, threaded the way every other signal on that band already travels: the HOST resolves it
+  and passes it through `InlineEditProvider`, so the renderer stays DataSource-agnostic and
+  never re-derives who submitted what.
+  
+  - `@object-ui/react` — `InlineEditProvider` accepts `approvalIsSubmitter`, surfaced on
+    `InlineEditContextValue`. Additive and optional; no existing prop changes.
+  - `@object-ui/plugin-detail` — the band's recall button is withdrawn when that signal is a
+    resolved `false`.
+  - `@object-ui/app-shell` — `RecordDetailView` resolves the verdict from its existing
+    approvals read and threads it.
+  
+  **The signal is tri-state, and the third state is the load-bearing one.** `true` offers
+  recall, `false` withdraws it, and **`undefined` — a host that resolves no approval identity
+  — renders exactly as it did before this release.** Omission preserving prior behaviour
+  mirrors how `approvalPending` falls back to `locked`. Defaulting the unknown case to "hide"
+  would have traded a cosmetic defect for a functional loss: every host whose band runs off
+  the record's `approval_status` mirror alone would silently lose its submitter's only way to
+  unlock their own record.
+  
+  **Withdrawn rather than disabled-with-reason.** The card offered either. For a
+  non-submitter this control is never actionable on any pending record, so a permanently
+  disabled button is standing clutter rather than a lesson; and the two sibling submitter
+  levers already hide — the approvals panel's Remind button, and the declared
+  `approval_recall` action's `visible` predicate. The band, its quorum tally and the
+  approvals timeline still tell a non-submitter exactly what state the record is in. Only the
+  lever they can never pull is gone.
+  
+  **This changes no permission.** Nothing about what the server allows moves, `canEdit` and
+  the approval lock are untouched, and nothing downstream reads `approvalIsSubmitter` as an
+  authorization verdict — the recall endpoint remains the sole authority, and it refused
+  these callers before this change and refuses them after. There is deliberately **no admin
+  carve-out** (the reporter ruled that case out, cf. objectstack#9464).
+  
+  The derivation itself is now one function, `isSubmitterOf` — server-resolved
+  `viewer.is_submitter` first (framework#3310), an id comparison as the fallback for backends
+  that predate it, joined with `??` so a server that resolved `false` is believed rather than
+  re-litigated client-side. The approvals panel's Remind gate, which already carried that
+  expression inline and whose behaviour is unchanged, now reads the same answer: two copies
+  would have been two definitions of who submitted.
+  
+  The **untranslated refusal text** the reporter also saw ("No pending approval request found
+  for this record", concatenated after a localized prefix) is a separate defect and is not
+  addressed here; it is tracked on objectstack#11993.
+- 586cfc2: The metadata-admin type-action param dialog no longer blanks itself while it closes
+  (objectui#6473).
+  
+  `MetadataTypeActions` is the **third** consumer of `ActionParamDialog` in this package,
+  after `useConsoleActionRuntime` and `RecordDetailView` — and it was the last one still
+  writing `setParamState({ open: false, params: [] })` on close, replacing the whole state
+  object. `DialogContent` carries `duration-200 data-[state=closed]:animate-out`, so Radix
+  holds the content mounted through its exit animation and the dialog goes on rendering off
+  `state` for the whole fade-out: a user who cancelled "Test connection" or a datasource
+  sync watched the heading revert from the action's own label to the generic
+  `actionDialog.title` and every param row disappear, for 200ms, on the way out. Close now
+  flips `open` and keeps every other field, which is the shape objectui#6431 converged the
+  other two consumers on.
+  
+  Not a user-data change: the values typed into the dialog never lived in `paramState` —
+  they live in `ActionParamDialog`'s own `values`, reseeded from the param defaults on every
+  open — so a reopen still starts from the defaults, pinned as a control.
+  
+  The pre-reset `paramState.resolve?.(null)` is dropped as well, on an enumeration rather
+  than on "resolving twice is a no-op": `onOpenChange` is reachable from exactly three places,
+  all inside `ActionParamDialog`, and every one settles the promise before asking for the
+  close — `handleSubmit`, `handleCancel`, and the Radix root handler that delegates to
+  `handleCancel` (the single route Escape, an overlay click and the header close button all
+  take). All four routes are driven in the new test, with a census over
+  `ActionParamDialog.tsx` so a later call site that skipped the settle is red there instead
+  of leaving a promise pending forever.
+- 16aa044: `MetadataService.saveFields` no longer PUTs the framework's own read decorations back (objectui#6480).
+  
+  `saveFields` fetches the current object and spreads it verbatim (`...existingObject`) so that every key the service does not model survives a field save. That spread does not distinguish keys the **author** owns from keys the **framework** adds on the way out: `@objectstack/spec` declares `_diagnostics` and `_draft` as `METADATA_READ_DECORATIONS` — stamped onto served metadata documents by the read path — and `ObjectSchema` refuses both **by name**. A served document carrying either one was therefore spread straight back into the body of `PUT /api/v1/meta/object/:name`.
+  
+  The body now passes through the spec's own exported `stripReadDecorations` before it is sent, so the list of decorations stays the spec's rather than a local copy that goes stale the next time the framework adds one. This is the strip-on-write shape `MetadataObjectsPage.handleObjectsChange` already uses for `group`, applied where the spread is — simply not writing the key is not enough when the spread is verbatim.
+  
+  The strip is deliberately bounded to those two keys and is not a general "remove whatever the schema refuses" pass: an off-spec key the author owns still goes out and is still refused loudly, where someone can see it. Nothing is lost by dropping the decorations even though a PUT is an upsert — `_diagnostics` is the read-path validation verdict, recomputed on every read, and `_draft` reflects the row's `state` column and the `mode` parameter, never the body. The ADR-0010 protection envelope (`_lock`, `_provenance`, …) *is* write-path state the server merges back, and the spec deliberately keeps it out of the decoration list, so it is untouched.
+- 28ed9ce: `MetadataService.saveFields` carries the server's per-FIELD keys through a field save
+  instead of rebuilding every entry from the designer model (objectui#6488).
+  
+  The method preserved unknown keys of the OBJECT document by spreading it, but that spread
+  is object-level and said nothing about keys INSIDE a field. Every entry was rebuilt by
+  `toFieldPayload`, so every key the server sent inside a field that the designer does not
+  model was dropped on every field save: `expression` (a formula authored in metadata-admin),
+  `precision`, `scale`, `system`, `sortable`, and anything a plugin registered. Measured
+  against the installed `@objectstack/spec` 17.2.0, `FieldSchema` accepts all five — the
+  designer's model is a subset of what a field may hold, and the difference was being
+  deleted.
+  
+  The loss is not new but was UNREACHABLE. While `fields` went out as an array the whole
+  body was refused `422 INVALID_METADATA` before persistence, so nothing `saveFields`
+  dropped ever reached storage; objectui#6240 made the body parse, and a PUT is an upsert,
+  so from that fix onward the drop lands.
+  
+  `toFieldPayload` now merges onto the previous SERVER entry, read from the document
+  `saveFields` already fetches for the object-level spread — the form
+  `MetadataFieldsPage.fromDesignerField` has used one writer over all along, and no extra
+  request.
+  
+  Two properties keep the fix from becoming its own mirror image, both pinned in
+  `MetadataService.fieldKeyCarryOver.test.ts`:
+  
+  - **A property the author CLEARED stays cleared.** Every modelled key is still written
+    unconditionally, so a cleared property arrives as an explicit `undefined` that overrides
+    the carried value and is dropped by `JSON.stringify` — absent from the body, which on an
+    upsert is the deletion. A conditional merge would leave the server's old value standing
+    and fail the author's deletion silently.
+  - **Retired designer keys do not ride back out.** `indexed`, `referenceTo`, `formula`,
+    `isSystem` and `sortOrder` are refused BY NAME by `FieldSchema`; a stored document can
+    still carry them, and echoing one back is a hard 422 that blocks every later save of the
+    object with no UI path to clear it. Everything else the server sent still survives — the
+    strip is keyed to those tombstones, not a blanket unknown-key purge.
+- b1a732b: Keep the boot splash painted across seven more console redirects (objectui#6507)
+  
+  Every readiness gate on the console boot path renders `LoadingScreen` while it
+  waits and a bare `Navigate` the moment it decides. `Navigate` renders null and
+  react-router runs the navigation as a transition, so the destination tree
+  renders while the commit that already dropped the splash is what the compositor
+  shows — measured at 41-147 ms of empty `#root` on the three sibling gates
+  objectui#6506 fixed.
+  
+  Converted to `RedirectWithSplash`, which pairs the same navigation with the same
+  `LoadingScreen` so the handoff changes no pixels:
+  
+  - `RequireOrganization` — both decisions (orgs exist but none active; no org at
+    all with multi-org enabled)
+  - `RequireAiSurface` — a runtime that serves no agent
+  - `AuthenticatedRoute` — the signed-out fallback (published for consumers;
+    `apps/console` converted its own `ProtectedRoute` copy under objectui#6506)
+  - `RootRedirect` — byte-for-byte the shape that measured the widest window
+  - `SetupRedirect` — the `/setup` deep link
+  - `AppContent` — the no-accessible-app bounce, which returns above the single
+    `ConsoleLayout` mount
+  
+  `SystemRedirect` is deliberately left as a bare `Navigate`. It carries the same
+  shape on a first navigation, but it is the only site in this set that also fires
+  with the console already painted (`SettingsView` navigates to `/system/settings`
+  from a button; `AppSidebar` links to `/system`), and a redirect firing under an
+  already-painted layout must keep that layout rather than gain a splash. The five
+  URL-rewrite redirects in `AppContent` are excluded for the same reason.
+- d4a9a55: Field- and action-visibility gates on the full-screen record form page now see the same
+  `current_user` every other console surface sees (objectui#6515). `RecordFormPage` built its
+  own descriptor — `{ name, email, role, positions }` — instead of calling the shared
+  `buildExpressionUser` normaliser, so `id` and `isPlatformAdmin` were simply absent from the
+  predicate scope that page publishes.
+  
+  An absent key is not `false`. A predicate naming one of them FAULTS, and a faulting
+  visibility predicate fails OPEN, so the gate silently did not bite: a field gated on
+  `ctx.user.isPlatformAdmin == true` (the shape `sys_environment`'s "Change Plan (admin)"
+  action uses) rendered for every user on this page, and an id comparison against
+  `ctx.user.id` (the shape `sys_user`'s own gates use throughout `platform-objects`) did the
+  same. Nothing on screen distinguished that from a gate that had said yes. The signed-out
+  branch diverged on its own account too — it carried no `isPlatformAdmin` key at all, where
+  `buildExpressionUser(null)` carries `false`.
+  
+  Fail-open on a genuine evaluation error is deliberately unchanged (objectui#6443 / #6487 /
+  #6445); what changed is that these predicates no longer fault in the first place.
+  
+  The normaliser moved from `console/AppContent.tsx` to `providers/expressionUser.ts`, beside
+  the `ExpressionProvider` it feeds. That move is what made the fix available: `RecordFormPage`
+  is `lazy()`-loaded BY `AppContent`, so importing the normaliser from its old home would have
+  put a static edge from the split chunk back into the module it was split out of. Both
+  `console/AppContent.js` and the package entry re-export the name, so `buildExpressionUser`
+  is published exactly as before.
+- c18acb0: The object designer's field-IO read door now strips `referenceTo` and `isSystem` alongside
+  `indexed`, so a draft authored before those controls were retired can be edited and saved
+  again (objectui#6519).
+  
+  `previews/object-fields-io.ts` is the single read door for `draft.fields` across the whole
+  object designer — inspector, form designer, design surface, settings / validations / API
+  panels — and `writeFields` writes each def back verbatim. Its strip set named one key while
+  `FieldSchema` refuses five by name, so a stored field carrying any of the others
+  round-tripped straight back out to `PUT /api/v1/meta/object/:name`. Measured on the
+  installed `@objectstack/spec` 17.2.0, through the whole document that endpoint validates:
+  
+  ```
+  ObjectSchema.safeParse({ name:'account', label:'Account',
+                           fields: { amount: { type:'number', label:'A', referenceTo: 1 } } })
+    => unrecognized_keys at ["fields","amount"]
+  ```
+  
+  which is the hard `422 INVALID_METADATA` that blocks EVERY later save of that object, with
+  the control that wrote the key retired and no UI path left to clear it. This is the shape
+  objectui#4644 closed in this same file for `indexed`, applied to the siblings that were
+  left open.
+  
+  Both added keys were verified to be reachable rather than assumed: `referenceTo` was
+  emitted by both designer writers until objectui#6041 (`MetadataService.toFieldPayload` and
+  `MetadataFieldsPage.fromDesignerField`), and `isSystem` was a declared server-field key the
+  designer read back until objectui#6044. Neither loses anything — the spec spellings
+  `reference` and `system` are separate, accepted keys and ride through untouched.
+  
+  Two keys `FieldSchema` also refuses are deliberately NOT stripped, each for its own
+  measured reason, and the tombstone on `RETIRED_FIELD_KEYS` carries both in full:
+  
+  - `formula` (objectui#6043) — `ObjectFieldInspector` seeds its linting CEL editor from
+    `def.expression ?? def.formula` and the first edit commits `expression` and clears the
+    alias. Stripping at the read door empties that editor and the authored source is gone on
+    the next save; objectui#6043 refused a blind rename precisely because that migration
+    surface exists. Dropping the text anyway is a maintainer call, raised on objectui#6519.
+  - `sortOrder` (objectui#6045) — no writer on this tree ever populated a FIELD-level one, so
+    no draft this door reads can carry one; a strip would be dead code that reads like a
+    measurement.
+  
+  Unifying the three retired-key lists on this seam is deliberately not part of this change:
+  it spans `plugin-designer/src/MetadataFieldsPage.tsx`, which objectui#6489 owns in flight.
+- c5037fd: `buildExpressionUser`'s signed-in cast declares `id`, `name` and `email` REQUIRED, so it is
+  no longer wider than the contract it mirrors (objectui#6551).
+  
+  The normaliser reads its input through a cast, and that cast wrote all three keys optional
+  (`{ id?: string; name?: string; email?: string; … }`) while the signed-in branch forwards
+  exactly those three RAW. So the declaration said `buildExpressionUser({ name: 'B', email:
+  'b@c.d' })` was a legitimate input, and the code answered `{ id: undefined, … }` for it —
+  present-and-always-`undefined`, which is the shape objectui#5424 removed `roles` from this
+  same object for ("the shape that teaches the wrong thing") and the one objectui#6534
+  refused for the anonymous branch, one key over. The three keys BELOW them already defended
+  with `??`; the asymmetry sat inside one object literal.
+  
+  The contract disagreed with the cast. Every production input is `useAuth().user`, typed as
+  `@object-ui/auth`'s `AuthUser`, which extends the spec's `AuthUser`
+  (`@objectstack/spec/contracts`): `id: string; email: string; name: string`, with only
+  `positions` and `tenantId` optional. `name` and `email` are narrowed alongside `id` because
+  that same interface declares them required too — the same answer from the same authority,
+  not a widened scope. `role` stays optional (it is `@object-ui/auth`'s display-only
+  addition, not a spec key), and the index signature stays (better-auth projects an app's
+  custom user columns onto this object, and it is how `isPlatformAdmin` / `positions` are
+  read).
+  
+  NOTHING REACHABLE CHANGES, and deliberately so. The only production producer is a
+  better-auth principal that always carries `id`, which is why this was graded a latent shape
+  hazard rather than a bug, and why the fix moved a declaration and no runtime behaviour: the
+  defect was that the cast LIED about the contract. `id: u.id ?? null` was the rejected shape
+  (triage, 2026-08-26) — a lenient default in the consumer is what AGENTS.md #0.1 forbids and
+  what objectui#6534 shipped a scope fence against, and it silently equates "signed in, no
+  id" with "signed out". A producer without an `id` is wrong at the producer.
+  
+  Because `id?: string` and `id: string` produce byte-identical output for every input a
+  producer can supply, no runtime assertion can pin this; the new
+  `expressionUser.sessionContract.types.test.ts` drives `tsc` itself over the real
+  declarations and carries its own discrimination leg — the same cases compiled a second time
+  against the pre-fix optionality, with the five that flip named by index.
+  
+  No fault-handling path moved. Fail-open on a predicate that DOES fault stays deliberate
+  policy (objectui#6443 / #6487 / #6445).
+- 12402a9: Drop the undeclared object-level `titleField` from the object page's five
+  remaining view-config seams, and from the record-search memo key
+  
+  `ObjectView` resolves a title field for seven view kinds. Two of them —
+  calendar and gantt — already read `viewDef.<kind>?.titleField || 'name'`. The
+  other five (timeline, kanban, map, gallery, tree) carried a three-rung chain
+  with `objectDef.titleField` in the middle, so one file answered the same
+  question two different ways. This converges the five on the shape the two
+  siblings already had; it is a convergence, not a removal.
+  
+  The middle rung could never fire for legal metadata. `@objectstack/spec`'s
+  object schema is a `strictObject`, so
+  `ObjectSchema.safeParse({ …, titleField: 'x' })` is rejected with
+  `unrecognized_keys` — the same issue code a nonsense key gets — while
+  `nameField`, `displayNameField` and `titleFormat` all parse (measured against
+  `@objectstack/spec@17.2.0`, the dist this repo installs). objectui#6531
+  established that measurement and dropped the twin read inside
+  `getRecordDisplayName`. Reading a key no producer can ship is the
+  consumer-side alias AGENTS.md Commandment #0.1 bans.
+  
+  Behaviour for every legal config is unchanged, and both directions are pinned:
+  a view that declares its own `titleField` still wins on every kind, a view that
+  declares none still floors at `'name'`, and an object carrying the
+  contract-rejected key is now honoured by no kind. Re-pointing the middle rung
+  at the declared `nameField` was considered and rejected: it would have added a
+  rung calendar and gantt do not have — increasing the divergence — and, unlike
+  this change, it would have altered behaviour for legal configs.
+  
+  `useRecordSearch`'s candidate signature — the memo key that decides when the
+  cross-object fanout re-runs — appended `o?.titleField ?? ''` to every entry.
+  Because no legal object definition can carry the key, that half was permanently
+  `''`: a constant suffix in a cache signature, and the last thing in the repo
+  that read as evidence some producer supplies it. The signature is now the object
+  name alone, which is the only field of an object definition the effect actually
+  consumes. Change detection is unaffected — a changed candidate name still
+  re-runs the fanout, and a new array with identical content still does not.
+- 450f110: fix(app-shell): the Action designer's preview draws what the runtime dialog will draw
+  
+  `ActionDefaultInspector` offers eight param `type` spellings; `ActionPreview`'s
+  dialog mock switched on five of them over a private table, so three of the eight
+  previewed as a control `ActionParamDialog` does not render — `datetime` and a
+  targeted `lookup` as plain text boxes, and a `select` whose options were not
+  authored yet as a text box as well. A `text` param that happened to carry
+  `options` previewed as a select the runtime never draws, for the same reason in
+  the other direction.
+  
+  The mock now resolves each param through `paramToField`'s
+  `resolveParamWidgetType` / `paramDegradesWithoutTarget` — the same adapter the
+  dialog itself renders through — so the two panes cannot disagree about a
+  spelling again. `datetime` draws a date/time control, a `lookup` with a declared
+  `reference` draws a record picker, a targetless one draws the record-id text box
+  the dialog degrades to and says why, and a `select` always draws a picker.
+  
+  The per-param editor also gains an `options` control for `select` params. It had
+  none, and `params` is hidden from the collapsed "More fields" form, so the panel
+  that offered the type had nowhere to author the choices the type needs.
+- 1edbc2f: **Behaviour change:** a `master_detail` action param with no reference target now
+  receives the same "paste a record id" placeholder and help text a targetless
+  `lookup` param has had since objectui#3405. Previously it degraded to a plain
+  text input exactly like `lookup` did, but silently — the user was shown an
+  unexplained empty box that wanted a bare record id.
+  
+  The cause was two hand-maintained answers to one question. `paramToField()`
+  performs the degradation over RESOLVED widget keys (`lookup`, `master_detail`),
+  while `ActionParamDialog` decided who gets the hints with its own literal over
+  RAW param spellings (`'lookup' || 'reference'`). Neither set contained the
+  other: `master_detail` degraded with no hints, and `reference` was a copy of an
+  alias-table row the adapter folds to `lookup` before it tests membership.
+  
+  `paramToField` now exports `paramDegradesWithoutTarget(param)` and both the
+  adapter's own fallback branch and the dialog's two hint readers ask it, so "who
+  degrades" and "who gets hints after degrading" are one member set answered once
+  (objectui#5654; same convergence shape as objectui#4770 / #4790 / #4815).
+  
+  Params that already had the hints keep them, including the `reference` spelling;
+  a param that renders as text without having degraded (an unknown type) still
+  gets no picker hints.
+- 649f4a5: **Behaviour change:** the console action runtime (`useConsoleActionRuntime`) now
+  builds its authenticated fetch with `sameOriginOnly: true`, matching the
+  `provider: 'api'` data-source lane (`ConsoleShell`). A metadata `type: 'api'`
+  action whose resolved target is a different origin than the page is fetched
+  through the bare global fetch: the platform Bearer token, `X-Tenant-ID`, and
+  `Accept-Language` are no longer attached (objectui#5702, maintainer ruling
+  2026-08-22). Previously the Bearer rode to any off-origin target whose URL
+  contained `/api/`, and `X-Tenant-ID` rode to every off-origin target
+  unconditionally.
+  
+  Same-origin actions — including every relative target in a same-origin
+  deployment — are unchanged, and off-origin requests still execute (pass-through,
+  not a refusal). An off-origin integration that legitimately needs the platform
+  bearer declares itself explicitly or proxies same-origin.
+  
+  Note for split-host setups: `apiHandler` prefixes relative action targets with
+  `VITE_SERVER_URL`. When that is set to an origin different from the page's,
+  those action requests are off-origin and no longer carry credentials. The
+  committed dev and starter configurations are unaffected: since objectui#5745
+  they ship `VITE_SERVER_URL` empty and reach a split-host backend through the
+  Vite `/api` dev proxy, so their action requests are same-origin.
+- 169f6d2: `AiChatPage`'s public share-link base now resolves through the one console-mount
+  resolver instead of a private copy of it (objectui#4482).
+  
+  The page built `publicShareBase` itself — read the injected `<base href>`, take its
+  pathname, trim trailing slashes, concatenate `${origin}${base}/s` — which was the third
+  independent implementation of the mount resolution `resolveConsoleUrl` centralizes.
+  objectui#4472 had just deleted the other two on that rule; this was the surviving
+  sibling. Its output was correct, so nothing a user hits was broken and nothing a user
+  hits changes: measured over the base-href matrix, the deleted builder and
+  `resolveConsoleUrl('s')` return identical URLs for every shape the console is served in
+  — `/_console/` (the only href the framework CLI injects), `/` root mounts, `./` portable
+  builds, nested mounts, and no `<base>` at all.
+  
+  The `/s` resolution now lives beside its three siblings as `resolvePublicShareBase()`,
+  which keeps the one thing a bare `resolveConsoleUrl('s')` call would drop: with no DOM
+  it returns `undefined` rather than a URL built from an origin that does not exist, so
+  `ShareDialog` applies its own fallback. It deliberately takes no `baseURI` argument —
+  the mount is only ever carried by the injected `<base href>`, and a resolver with no
+  other input cannot be pinned by a test that steers something production never reads.
+  
+  `resolvePublicShareBase.browser.test.tsx` pins the resolved base against a real injected
+  `<base>` element for each deployment shape, plus a structural case asserting no other
+  app-shell file reads the `<base>` tag — so a fourth copy fails a test rather than
+  waiting for mount semantics to change under it.
+- aa3b810: `features.aiStudio` is now read through one `isAiStudioEnabled()` accessor instead
+  of being spelled inline at two call sites (objectui#5577).
+  
+  `features.marketplace` already had a documented accessor whose docblock is where the
+  fail-open doctrine is written down — *"Fails OPEN (`!== false`): a runtime predating
+  `/api/v1/runtime/config`, or one whose config fetch failed, keeps the default `true`"*,
+  plus the "never infer this from the shape of a failure" warning. `features.aiStudio`
+  had no such sibling: `ChatDock` read `getRuntimeConfig().features.aiStudio !== false`
+  and `HomePage` read `getRuntimeConfig().features?.aiStudio !== false`, so one doctrine
+  had two spellings and neither reader could cite it.
+  
+  The two spellings were not equivalent. `ChatDock`'s omitted the optional chain, and
+  against a runtime-config snapshot whose `features` is absent that read is a TypeError
+  rather than a fail-open — the exact shape that crashed 29 tests across four suites in
+  PR #5575 before it was corrected. Measured here: no live path can currently deliver
+  such a snapshot to `ChatDock` (the module's singleton constructs `features` on every
+  write and exports no setter, and no suite mounts the dock's default body under a
+  partial stand-in), so this closes a reachable-by-construction crash rather than a live
+  one — and it closes it at the source by leaving no inline read to get wrong.
+  
+  `isAiStudioEnabled()` is an internal module export, matching `isMarketplaceEnabled()`:
+  neither is re-exported from `src/index.ts`, so the package's published `exports` surface
+  is unchanged.
+- 0235ce7: The predicate identity bound for a signed-out visitor now carries `id: null`, so a
+  `ctx.user.id` visibility gate BITES instead of failing open (objectui#6534).
+  
+  `buildExpressionUser` has two branches, and only the signed-in one carried `id`.
+  So `'id' in buildExpressionUser(null)` was `false`, and an absent key is not
+  `false`: a CEL predicate naming `ctx.user.id` / `current_user.id` / `os.user.id`
+  hit an unbound key for a signed-out visitor and FAULTED. A faulting visibility
+  predicate fails OPEN (`evaluateVisibility`), so the gated field or action rendered
+  for exactly the principal it was written to exclude, with nothing on screen to say
+  the gate had not bitten — silently, for every signed-out visitor.
+  
+  Because the defect was in the shared normaliser rather than at a mount site, it
+  reached EVERY mount site, including `AppContent` and the console's
+  `InternalFormRoute`, both of which have always called the normaliser correctly.
+  This is the same fault-open mechanism objectui#6515 fixed one level up, where
+  `RecordFormPage` hand-rolled a descriptor missing `id` and `isPlatformAdmin`.
+  
+  `null` rather than `undefined`, and rather than leaving the key absent, is settled
+  by precedent on this exact object rather than chosen here. objectui#5424 removed
+  `roles` from it because a present-and-always-`undefined` key "is the shape that
+  teaches the wrong thing" — the context answers rather than being plainly absent,
+  and the answer is silently wrong; `undefined` here would reproduce that defect one
+  key over. Leaving it absent IS the defect. `null` is a VALUE a CEL author can
+  compare against, so `ctx.user.id == '…'` resolves to a clean FALSE. Measured, not
+  assumed: at a real mount site with `authState.user = null` and a field gated on
+  `ctx.user.id == 'u_admin'`, the field is now filtered OUT of the schema handed to
+  `ObjectForm`, where before it was present.
+  
+  This also closes the last asymmetry between the two branches. Both now advertise
+  the same six keys, which is the symmetry objectui#5424 was closing when it removed
+  `roles` — and the shape pin now asserts the key sets are equal, so a future edit
+  that adds a key to one branch and forgets the other fails whichever branch it
+  forgets.
+  
+  NOT CHANGED, deliberately: fail-open on a predicate that DOES fault. That is
+  shipped permission-boundary policy (objectui#6443 / #6487 / #6445) and remains
+  exactly as it was — an unevaluable `visible` still renders. This change removes a
+  REASON to fault; it does not touch what happens once a predicate has. No accept set
+  is widened, no gate is relaxed and no fallback is added: the only behavioural
+  movement is that an id-gated surface which used to render for anonymous visitors
+  now hides from them.
+- 9022bd5: Pin `module` / `moduleResolution` to `nodenext` in `@object-ui/app-shell`'s build config, matching the pins `@object-ui/react`, `@object-ui/fields` and five other packages already carry. This package builds with a bare `tsc`, which never rewrites import specifiers, so what the source writes is exactly what `dist` ships; under `nodenext` a missing relative extension is a compile error, so the extensionless-specifier defect that made published entries unloadable under plain Node cannot come back silently here.
+  
+  The lazy `@monaco-editor/react` imports in the metadata designer's source editors now read the package's named `Editor` export instead of its default. `@monaco-editor/react@4.7.0` is CommonJS and ships no `exports` map, so under `nodenext` the default resolves to the module namespace rather than to the component. The two names are one declaration in that package's own typings and the same object at runtime in both its CommonJS and ESM builds, so the editor that renders is unchanged.
+- 029e2fb: The console's `<PageHeader>` spells its secondary line `subtitle`, the same key the other `PageHeader` in this repo uses (objectui#4761).
+  
+  This repository has two components named `PageHeader`. `@object-ui/layout`'s is
+  the renderer for the authored `page:header` / `page-header` node and converged
+  on `subtitle` in objectui#3789, because `subtitle` is the key
+  `@objectstack/spec/ui`'s `PageHeaderProps` declares. `@object-ui/app-shell`'s —
+  the console's own title row, drawn by `ObjectView` and `ObjectDataPage` —
+  spelled the very same concept `description` and had no `subtitle` at all. Both
+  rendered correctly; the defect was one concept carrying two key names one
+  package apart, the objectstack#4115 shape moved up a layer. An author reading
+  one component to learn the other was being taught a key the contract does not
+  have.
+  
+  **Not a breaking change, measured rather than assumed.** The convergence is a
+  plain rename with no alias, because this component is not on the published
+  surface:
+  
+  | gauge | result |
+  |---|---|
+  | exports of `dist/index.d.ts`, through the TypeScript checker | 226 symbols; `PageHeader` and `PageHeaderComponentProps` are not among them (controls: `AppShell` reachable, a nonsense name not) |
+  | `exports` map | declares exactly `.` and `./styles.css` |
+  | Node resolving `@object-ui/app-shell/layout`, `…/dist/layout/PageHeader.js`, `…/src/layout/PageHeader.js` | `ERR_PACKAGE_PATH_NOT_EXPORTED` for all three, while the declared entry resolves |
+  | in-repo call sites | 2, both inside this package (`ObjectView.tsx`, `ObjectDataPage.tsx`) |
+  | emitted declarations that change | `dist/layout/PageHeader.d.ts` only — `dist/index.d.ts` and `dist/layout/index.d.ts` are byte-identical across the change (`8c886251…`, `f9f4862b…`, both legs) |
+  
+  No supported specifier reaches the prop, so there was nothing to keep
+  compatible, and a renderer-side `description` alias would have been exactly the
+  second dialect AGENTS.md #0.1 forbids — the layout side had just finished
+  retiring one. Out-of-repo consumers cannot be enumerated from this repository;
+  what can be, and is, is the set of import paths through which one could have
+  reached this component, which is empty.
+  
+  Rendered output is unchanged: same element, same classes, same position. The
+  patch tier is a declaration that the tarball moved, not a claim that a consumer
+  must act.
+  
+  `packages/app-shell/src/layout/__tests__/PageHeader.subtitle.test.tsx` is the
+  pin the card asked for. It asserts the subtitle on the DOM a reader gets (a
+  `<p>`, in the title block, after the `<h1>`), that `description` now draws
+  nothing and is rejected by the compiler, and — the assertion that actually goes
+  red if either side drifts again — that both packages' `PageHeaderComponentProps`
+  declare `subtitle`.
+- ac73c24: The approval step progress bar is a vertical stepper, so long flows stop
+  clipping their tail steps.
+  
+  Both occurrences were a single non-wrapping flex row whose steps were each
+  `shrink-0`. A flex row's min-content width is the sum of its non-shrinkable
+  items, so the bar's intrinsic width grew without bound with step count and
+  label length. On a live 17.1.0 project a real 6-step flow with ordinary CJK
+  step names measured **1070px inside a 527px container** (objectui#5554).
+  
+  The two hosts failed differently, and neither failure was recoverable by the
+  reader:
+  
+  - **`ApprovalsInboxPage`** (the inbox detail drawer) — the bar itself was not
+    scrollable, so the nearest scroller was the drawer *panel*. Reaching steps
+    4-6 meant dragging the drawer's own horizontal scrollbar, which pushed the
+    record card, the activity timeline and the action buttons off-screen and left
+    a near-blank panel.
+  - **`RecordApprovalsPanel`** (the record page's approvals panel) — this one
+    carried `overflow-x-auto`, so it scrolled itself rather than its container.
+    Better, but the tail steps still sat behind a scroll gesture with no visible
+    affordance.
+  
+  In both, readers took the clipped bar for the end of the data; the reporting
+  customer acceptance tester said so verbatim. Widening the window does not help:
+  the drawer is fixed-width, and clipping was identical at 1440x900 and 1920x1000.
+  
+  Both now render as a column: one row per step, a badge-and-rail gutter, and a
+  label that may wrap. Width is capped by the container at every step count and
+  every label length, which also suits both hosts' tall-and-narrow aspect. The
+  rail segment below each step keeps the tint rule the horizontal connector used
+  — it is coloured by the step it leads *into*.
+  
+  **Always vertical, with no step-count or measured-width threshold**, because
+  the overflow is driven by intrinsic content width (labels x count), not by
+  count alone: three 16-character CJK labels already crowd a 527px drawer, so any
+  count threshold picks a cutoff that is wrong for some real flow, and a measured
+  one reintroduces a viewport-dependent branch. The card's requirement is a fix
+  that cannot break at an untested viewport or flow length, and a layout with no
+  breakpoint and no measurement is the form that satisfies it. Horizontal-with-
+  scroll was ruled out for both occurrences: it leaves steps behind a gesture.
+  
+  Pinned in `ApprovalsInboxPage.stepProgressVertical.test.tsx` and
+  `RecordApprovalsPanel.stepProgressVertical.test.tsx`. "The stepper renders" is
+  green against the broken code too — every step was always in the DOM, and the
+  clipping was layout — so the suites assert the property the defect names
+  instead: no row is `shrink-0`, every label is `min-w-0` and none is
+  `whitespace-nowrap`, nothing in the subtree is an `overflow-x` scroller, and no
+  axis, overflow or width-pinning class carries a breakpoint prefix (so there is
+  no viewport with untested behaviour). The reported failing regime is exercised
+  directly with the reporter's own six CJK labels, and a 2/5/6/12-step sweep pins
+  that the layout classes are byte-identical across all four, so no count
+  threshold can put some other flow length back on the old path.
+  
+  The two steppers are kept identical by hand rather than extracted to a shared
+  component: they live in different packages, and deduplicating them is a
+  refactor with its own surface. Filed separately.
+- 7e89836: fix(approvals): derive approver identities from `positions`, not the retired `user.roles` (objectui#5424)
+  
+  Framework ADR-0090 D3 renamed the session's `roles` key to `positions` with no
+  deprecation window, and the protocol-17 session face emits no `roles` key at
+  all. Three client sites still read it:
+  
+  - **`sharedUserFeeds.approverIdentities`** — the bell badge, the bell's
+    Approvals tab and Home's To-do card. It read nothing else, so it sent **no
+    `role:` identity at all**: an approval addressed to a position rather than to
+    a person matched nothing and vanished from all three surfaces, silently.
+  - **`approvalsApi.buildApproverIdentities`** — "My Pending" and the
+    Approve/Reject enablement. It also splits the scalar `user.role`, so it
+    degraded rather than dying: it still yielded `role:user` while dropping every
+    business position name (`manager`, `finance_approver`, …).
+  - **`AppContent`'s expression user** — forwarded a `roles` key that was always
+    `undefined` into every CEL predicate context. Removed; `positions` and
+    `isPlatformAdmin` were already forwarded correctly beside it.
+  
+  The retired spelling is **not** kept as a fallback — pairing the two is what
+  ADR-0090 D3 forbids, and `packages/auth/src/types.ts` says so on the
+  declaration.
+  
+  `AuthGuard`'s `requiredRoles` gate (the fourth surviving reader) is deliberately
+  untouched: it is a semantics decision, not a rename, and is deferred to a
+  maintainer ruling.
+- 77c4ed3: `AppSidebar` is now `@deprecated` — use `UnifiedSidebar` instead.
+  
+  A census (objectui#5720) found `AppSidebar` has no in-repo mount point
+  (`ConsoleLayout` renders `UnifiedSidebar`, not this component) and no
+  downstream consumer visible anywhere across this org's GitHub-visible
+  repositories. It stays exported — from the package barrel and the published
+  `dist/index.d.ts` — because `@object-ui/app-shell` is a public npm package
+  (`publishConfig.access: "public"`) and an external consumer outside this org
+  is structurally invisible to that census; that is why it is deprecated
+  rather than deleted outright. No behavior change in this release — the
+  component still renders exactly as before. Its admin nav cluster is a
+  near-duplicate of `UnifiedSidebar`'s and has already drifted from it (it
+  gates only `sys-marketplace` on the workspace-admin flag, where
+  `UnifiedSidebar` gates the whole cluster); that divergence is not being
+  reconciled, since the component is scheduled for removal rather than kept
+  in parity — see objectui#5817 for the removal plan.
+  
+  Migration: replace any `AppSidebar` usage with `UnifiedSidebar` from the same
+  package.
+- cc3366b: The built-moment transition (#5799) now fires on auto-publish environments too: `detectBuiltAppPackage` reads the raw build envelope (`status:'drafted'` OR `'published'`, packageId + an `app` item), because an auto-publish posture rewrites apply_blueprint's envelope to `published` and the drafted-only `draftReview` lift never fired there — measured live on staging, where reopening a built conversation stayed on the full page.
+- 3a58149: A cloud-connection bind failure now reads in the user's language whichever clock
+  noticed it (objectui#5054).
+  
+  One abandoned device approval could be noticed by either of two clocks, and the
+  Cloud Connection panel had a different answer for each. When the panel's own
+  `expires_in` deadline fired first it rendered `cloudConnection.errors.expired` —
+  translated in all ten packs. When the SERVER noticed first, `/bind/poll` answered
+  HTTP 400 with `message: 'Device authorization failed: expired_token'`; `getJson`
+  threw a bare `Error` carrying only that sentence, and the catch rendered it
+  verbatim. Same user, same failure, two languages, decided by which clock got
+  there first — visible on a zh console as the same abandoned approval reading
+  Chinese or English depending on whether the tab sat open past `expires_in`.
+  
+  `getJson` now carries the envelope's `declaredCode` and `code` across its throw,
+  and a single closed map turns the two RFC 8628 outcomes a user can actually cause
+  into console copy: `expired_token` → the existing `cloudConnection.errors.expired`,
+  `access_denied` → a new `cloudConnection.errors.accessDenied` added to all ten
+  locale packs. `declaredCode` is read first, because ADR-0112 keeps the upstream
+  spelling there — `code` is `DEVICE_CODE_FAILED` for both.
+  
+  Every other code is unchanged: `invalid_grant`, and anything upstream invents
+  next, still render the wire `message`, which stays the single source of truth for
+  failures this console has no copy for. No API, export or resolver was widened.
+- 6ce89da: The 确认修改 (confirm changes) card now carries a UI-owned terminal state after approval (#5695): `detectReplayOutcome` lifts the confirm-replay envelope (`replay_*` tool results) into 应用中 / 已生效 / 已暂存为草稿（含内联发布）/ 未生效（含 publishError 首行）, rendered on the original card across the live, hydration/share, and localStorage-cache converters. A failed in-turn publish no longer rehydrates as an ordinary draft card with a live Publish button — the UI-rendered refusal is the layer a model cannot narrate over. New `console.ai.changesApplying/Applied/Drafted/Failed` keys in all ten locale packs.
+- fdefd4b: Console action runtime: closing an action confirm dialog now keeps the dialog's
+  text instead of blanking it mid-fade.
+  
+  `useConsoleActionRuntime` reset its confirm state by replacing the whole object
+  (`{ open: false, message: '' }`), which cleared `message` and dropped `options`.
+  Radix keeps `AlertDialogContent` mounted through its exit animation, so the
+  dialog's description went blank and its title and button labels reverted to
+  their defaults while it was still fading out. It now flips only `open` and keeps
+  every field, matching `RecordDetailView`'s second confirm runtime, which already
+  closed this way. Both runtimes feed one `ActionConfirmDialog`; the parity pin now
+  covers the close path as well as the open path.
+- 0e05aac: The console's cold load no longer asks `/api/v1/runtime/config` or
+  `/auth/me/localization` twice (objectui#5544).
+  
+  Two pairs of boot callers were racing each other for the same URL, with no shared
+  provider between them, so no guard inside either component could see the other:
+  
+  - `GET /api/v1/runtime/config` — the pre-React branding script inlined in
+    `apps/console/index.html` (it runs during HTML parse so the tab title and
+    favicon are the operator's before the bundle is fetched) and
+    `initRuntimeConfig()`. Measured ×2 on prod and on staging. This is the
+    expensive one: the console `await`s `initRuntimeConfig()` before
+    `createRoot().render()`, so the duplicate sat on the critical path to first
+    paint, and at the control plane's ~0.5–1.4 s for this endpoint it also pushed
+    boot concurrency further past the server's pool knee.
+  - `GET /api/v1/auth/me/localization` — `seedTenantLanguage()` on a device's true
+    first visit and `LocalizationFetchProvider` on every boot. The seed keeps
+    running past its 500 ms race by design and the provider mounts the moment that
+    race resolves, so on a first visit the two overlap. Measured ×2 on staging.
+  
+  `@object-ui/types` gains `sharedGetJson()`: callers that ask for the same GET
+  while one is already in flight join that request instead of starting another. It
+  shares the in-flight promise and nothing else — the entry is deleted the instant
+  the request settles, so there is no cache, no TTL and no stale window, and a
+  caller arriving after settle fetches fresh exactly as before. Rejections fan out
+  to every sharer with the status intact (`LocalizationFetchProvider`'s retry
+  policy still sees its own 503), each caller receives its own copy of the parsed
+  body, and only GETs are eligible — a non-GET is refused rather than quietly
+  rewritten.
+  
+  Requests that differ in credentials mode or headers keep separate identities, so
+  the console's two deliberate `auth/get-session` calls — one Bearer-only with the
+  cookie omitted to detect a stale token, then one through the cookie — stay two
+  requests. Collapsing those would have destroyed the signal the first one exists
+  to read.
+  
+  No component receives anything different: same payloads, same errors, one fewer
+  round trip.
+- 71ee495: The two form CONTAINER contracts now have ONE declaration each, derived from
+  `@objectstack/spec`, and the console reads them instead of its own copies.
+  
+  objectui#5542 converged the LEAF of this contract — the field spec — and left the
+  two containers above it untouched, because converging them was a bigger call than a
+  mechanical import. `FormSectionSpec` and `FormViewSpec` were each hand-declared
+  twice under the same names, once in `packages/app-shell`'s `SchemaForm.tsx` and once
+  in `apps/console`'s `FormPage.tsx`. Unlike the leaf — whose console copy was a clean
+  subset — these two had **already drifted, in both directions**, so neither copy was a
+  subset of the other and there were two live answers to "what may an author write":
+  
+  - `FormSectionSpec` — app-shell declared `description` / `visibleWhen` / `visibleOn`;
+    the console declared none of them. The console's `columns` admitted the string arm
+    (`'1' | '2' | '3' | '4'`); app-shell's took numbers only.
+  - `FormViewSpec` — the console declared `label` / `groups` / `sharing` /
+    `submitBehavior`; app-shell stopped at `type` plus `sections`.
+  
+  The drift is decided by asking the **contract**, not by picking a side. `columns`
+  does admit the string arm (`FormSectionSchema.columns` unions `z.enum(['1','2','3','4'])`
+  with the four numeric literals, folded to a number by its own transform), so
+  app-shell's numbers-only declaration was rejecting metadata the platform accepts —
+  objectui#5040's own symptom, not a deliberate narrowing. `label` on the form view is
+  the opposite answer: `FormViewSchema` **rejects** it (`unrecognized_keys`, measured
+  against the installed `@objectstack/spec` 17.0.0), because a form config is titled,
+  not labelled. The value that read actually finds is the VIEW's identity label, which
+  arrives on the `ExpandedViewItem` envelope or beside the config on a flattened
+  runtime overlay — so it is declared on `FormPage.tsx`'s own `FormViewBody`, next to
+  the body it unwraps, rather than smuggled onto the form contract.
+  
+  Both types are therefore **derived from the spec's own `FormSection` / `FormView`
+  with named narrowings** — the repo's sanctioned form for a spec-shaped local type
+  (`scripts/check-spec-symbol-derivation.mjs`) — rather than restated. Every key the
+  two layers agree on comes from the spec and cannot fall behind it; the four positions
+  where this layer is deliberately narrower are each named in an `Omit` list and
+  restated once next to its reason: `fields` keeps the converged 26-key leaf (deriving
+  it would silently re-open #5542), and `label` / `description` / `visibleWhen` /
+  `visibleOn` keep the shapes this repo's renderers and evaluators actually consume
+  rather than the spec's `I18nLabel` and `ExpressionInput`. `apps/console`'s
+  `submitBehavior` union — previously hand-written under the comment "Mirrors the spec
+  FormView.submitBehavior union" — is now read back off the shared type, making the
+  mirror structural. `@object-ui/app-shell` re-exports both names from its package root
+  (type-only, erased at build — nothing is added to the bundle), because a type that
+  cannot be imported is a type that gets retyped.
+  
+  The pins are what make future drift loud, and each half is pinned on both sides.
+  `form-spec.containers.test.tsx` and `FormPage.viewSpec.test.ts` compare the
+  non-narrowed half of each type against the spec's own symbol, so re-hand-writing
+  either declaration fails `type-check` the day the spec moves rather than years later
+  when someone reads two files side by side — and the console's pins read both types
+  back out of the **exported** `buildSections` signature rather than naming them, so a
+  re-inlined local copy fails even if it agrees on every key on the day it is written.
+  Their liveness controls are what stop them being phantom checks: the removed copies
+  are pinned NOT equal to the shared types (proving the `Equal` helper still
+  discriminates), the renderer's honoured `RenderableSection` is pinned not equal
+  either (so the authored-document and honoured-row types cannot be collapsed again),
+  and an undeclared key is still rejected (so the derivation smuggled in no index
+  signature or `any`). Every narrowing carries a matching negative pin, so "derived"
+  cannot quietly become "widened to whatever the spec says".
+  
+  Behaviour is unchanged — the runtime always accepted these keys. The vitest halves
+  prove it: a section spelling its column count as the string `'3'` lays out identically
+  to the numeric `3` on both sides, and a section carrying the keys only one side used
+  to declare builds the same rows.
+- cebdfe7: The form-field authoring contract now has ONE declaration, and the console reads it
+  instead of its own copy.
+  
+  objectui#5040 was not a missing key. It was that **two hand-written descriptions of
+  one contract drifted**, and nothing could notice, because each was only ever checked
+  against itself. PR #5537 converged the two app-shell descriptions into
+  `views/metadata-admin/form-spec.ts`. A **third** survived in `apps/console`:
+  `FormPage.tsx` declared its own nine-key `interface FormFieldSpec`, under the same
+  name, in a different package — so the same failure mode stayed fully available.
+  
+  Measured key by key before choosing a route, because the two honest outcomes are
+  "same contract, import it" and "genuinely narrower layer, rename it and pin the
+  subset". The console's copy was a strict subset — 9 of the shared type's 26 keys,
+  every one identical in type, none console-only — and it sat in a position that
+  describes an **authored document**: `FormSectionSpec.fields`, read straight off the
+  `/meta/view/:name` payload, the same spec `FormView` metadata-admin renders (both
+  files even spell the same six-member `type` union and call the element type
+  `FormFieldSpec`). The narrow, renderer-honoured shape is a different type that
+  already exists in that file, `RenderableField`. So this was one contract described
+  twice, and the console's description was wrong about the document: legal metadata —
+  `visibleWhen`, `dependsOn`, `type`, `options`, `immutable`, the recursive `fields`,
+  and ten more keys — was undeclared there. That is #5040's own symptom, "the type
+  rejects the configuration the runtime accepts", which no runtime test can see.
+  
+  `@object-ui/app-shell` therefore re-exports `FormFieldSpec` from its package root
+  (type-only, erased at build — nothing is added to the bundle), and `FormPage.tsx`
+  imports it and deletes the local declaration. Reachability is the load-bearing half:
+  a type that cannot be imported is a type that gets retyped, and retyped copies drift.
+  `form-spec.ts` itself is untouched.
+  
+  `FormPage.fieldSpec.test.ts` is the pin that makes future drift loud. It reads the
+  field-spec type back out of the **exported** `buildSections` signature rather than
+  naming it, so re-inlining a local `interface FormFieldSpec` fails `type-check` even
+  if the copy agrees on every key on the day it is written — which is exactly what did
+  not happen to the copy this change removes. Its liveness controls are what stop it
+  being a phantom check: the removed nine-key shape is pinned NOT equal to the shared
+  type (so the `Equal` helper is proven to still discriminate), `RenderableField` is
+  pinned not equal to it either (so the honoured-row and authored-document types cannot
+  be collapsed again), and an undeclared key is still rejected (so the import did not
+  smuggle in an index signature). Behaviour is unchanged: the runtime always accepted
+  these keys, and the vitest half proves the same rows are built.
+- 4db5989: A widget title stored as an inline per-locale map is editable again in both dashboard
+  authoring surfaces, and a save writes back only the active locale's entry
+  (objectui#5428).
+  
+  `@objectstack/spec` widened `I18nLabel` from `string` to `string | Record` at
+  17.0.0-rc.6, so a stored widget title may be an inline per-locale map while both
+  authoring panels edit a title in ONE single-line input. Writing the input's value back
+  as the whole value would collapse every other locale on the first keystroke, so both
+  surfaces took the same conservative branch: show a map-valued title resolved, and make
+  it READ-ONLY.
+  
+  That branch could not lose data, but it rested on a premise the spec had already
+  invalidated — "nothing can reach this path from stored metadata yet, `I18nLabel` was
+  plain `string` through rc.5" — stated sixty lines below a comment in the same file
+  documenting the rc.6 widening that makes a stored map reachable. Both could not hold.
+  The pinned spec is 17.0.0. What the read-only branch did in practice from rc.6 onward
+  was not protect an unreachable path: it denied an author the ability to edit a widget
+  title in their own locale.
+  
+  objectui#5301's maintainer ruling settled the write rule for the sibling surface — a
+  save replaces only the active locale's entry and preserves the others — and
+  `@object-ui/i18n` ships it as `setLocalized`, co-located with `pickLocalized` because
+  the read and the write have to agree. Both panels now adopt it:
+  
+  - `@object-ui/plugin-designer`'s `DashboardEditor` widget property panel;
+  - `@object-ui/app-shell`'s `DashboardWidgetInspector` in metadata-admin.
+  
+  A plain-string title keeps saving as a plain string, so the common path is unchanged.
+  An edit made in a locale the stored map does not carry ADDS an entry under that locale
+  rather than overwriting the entry the display fell back to.
+  
+  The pins are preservation pins, not "the input is editable" pins: at both surfaces a
+  keystroke on a map-valued title must leave every other locale's entry byte-identical.
+  Reverse-verified by mutating each write back to the flattening form and confirming those
+  assertions go red at both surfaces.
+  
+  Not a multi-locale editor: an author still reaches only the entry for the locale they
+  are in. Authoring every locale from one panel remains an open product question. The
+  stale deferrals both comments carried pointed at objectui#4163, which closed as
+  completed on 2026-08-15 while the placeholders were still in the tree; they are replaced
+  with the rule that is actually in force rather than re-pointed at another tracker.
+- f7e34ca: Close the dashboard widget `type` vocabulary, and admit `metric-card` as objectui's own component extension.
+  
+  `DashboardWidgetSchema.type` was `string` on the TypeScript interface and `z.string()` in the Zod twin — an unbounded hatch. A typo'd family, a chart type the spec retired, and a component type nothing registers all type-checked and validated, surfacing only as the renderer's red `OBJUI-001` panel at runtime.
+  
+  It is now the CLOSED `DashboardWidgetTypeName` / `DashboardWidgetTypeSchema`: the spec's own `ChartTypeSchema` families **by reference**, plus two named, closed objectui extension sets — `DASHBOARD_WIDGET_TYPE_EXTENSIONS` (`list`, `custom`: objectui-only widget families) and `DASHBOARD_COMPONENT_WIDGET_TYPES` (`metric-card`: an objectui SDUI **component** type the widget slot holds directly, per the maintainer ruling of 2026-08-14 — objectui's own component enum, explicitly not the spec widget enum).
+  
+  Three drifts the closure surfaced and this change fixes: the dashboard designer's palette offered `grid`, which is not a widget family in either contract and was refused at publish; the metadata-admin widget inspector and the designer both wrote an unvalidated `string` from their select boxes; and a `@object-ui/types` fixture pinned `bar-chart`, a `plugin-charts` component type, on a dataset-bound widget that could never render as one.
+- dc14bcb: Delete the dead `src/utils/metadataConverters.ts` module. It had zero importers, was not
+  re-exported from the package barrel, and no `exports` subpath reached it — `toObjectDefinition`,
+  `toFieldDefinition`, `MetadataObject` and `MetadataField` were never part of the published
+  surface, so nothing external can break. The module was removed rather than left alone because it
+  carried two patterns the live code no longer uses: a name-heuristic `isSystem` (the server's real
+  `system` flag is the source of truth) and a three-way `referenceTo` tolerance for a target the
+  spec spells `reference`. A dead copy that disagrees with the live one is what a future author
+  copies from.
+- ca2b409: Studio's form designer canvas now emits the namespaced `FormField.type` spelling
+  instead of passing `objectDef.fields[x].type` through raw (objectui#4838).
+  
+  Per the maintainer ruling on that card, a bare spec-type name (`markdown`,
+  `html`, `richtext`, …) is **not** a legal `FormField.type` — one widget, one
+  legal spelling, the namespaced widget id. `ObjectFormDesigner` was the measured
+  producer of the bare spelling: it handed a raw object-metadata type straight to
+  `isWideFieldType`, a helper whose vocabulary is `FormField.type`. It now
+  normalizes through `mapFieldTypeToFormType`, the one place that widget decision
+  is made.
+  
+  User-visible effect: a `repeater` field is finally laid out full-row on the
+  canvas, matching the runtime form. `repeater` is a spec `FieldType` that
+  resolves to the wide `field:grid` widget, but bare `repeater` is not one of
+  `WIDE_FIELD_TYPES`' bare members, so the raw pass matched nothing — the canvas
+  showed it at normal width while the real form spanned it. Fields whose spec name
+  doubles as a widget id (`textarea`, `markdown`, `html`, `richtext`, `grid`) are
+  unaffected; they matched under both spellings.
+  
+  The two tolerant consumers this makes look redundant are deliberately left
+  alone, each scheduled under its own follow-up with deprecation care: the
+  `field:`-prefix fallback in `renderFieldComponent`, and `WIDE_FIELD_TYPES`' dual
+  spellings. Removing a tolerance is the consumer-tightening half, and other
+  producers have not been normalized yet.
+- eba3a6e: metadata-admin: `FormFieldSpec` declares `dependsOn`, and the widget half reads
+  the same declaration instead of its own copy of it (objectui#5040)
+  
+  `FormFieldSpec` — the authoring type for a metadata-admin form layout, the
+  element type of `FormSectionSpec.fields[]` — did not declare `dependsOn`.
+  `widgets.tsx` held a second, inline description of the same object as
+  `WidgetProps.fieldSpec`, and that one did, because two registered widgets read
+  it as their primary configuration: `field-selector` resolves
+  `dependsOn || reference || 'objectName'` to decide whose field catalog to
+  offer, and `dynamic-config` uses it to pick a sub-schema out of
+  `WidgetContext.dynamicSchemas`. One value travelling down one channel,
+  described twice, disagreeing on the one key that decides what those widgets
+  show — so
+  
+  ```ts
+  { field: 'fields', widget: 'field-selector', dependsOn: 'objectName' }
+  ```
+  
+  the only configuration that makes `field-selector` work, was a `TS2353` for
+  anyone who typed their spec. It survived because in-repo specs reach the form
+  through `as any` / loose types, so the authoring type was never asked.
+  
+  No runtime behaviour changes: `MetadataField` already handed `dependsOn`
+  through and both widgets already read it. What changes is the type face — it
+  now admits what the runtime has always accepted. The two descriptions are one
+  declaration, extracted to a leaf module
+  (`views/metadata-admin/form-spec.ts`) that both halves import, because
+  `SchemaForm.tsx` imports `./widgets.js` and a back-edge would close a cycle.
+  `SchemaForm.tsx` re-exports `FormFieldSpec` and `VisibilityPredicate`, so every
+  existing importer is unaffected.
+  
+  `dependsOn` is `string | string[]` here, deliberately **not**
+  `@object-ui/types`' wider canonical `DependsOnInput`, which also admits
+  `{ field, param }` objects: both readers index `[0]` and use the result as a
+  field name, so the wider shape would be a type that lies. Converging the two is
+  its own decision, pinned as a refusal rather than taken silently.
+- 4334341: `MarketplacePackagePage`'s third fetch effect — `listLocalInstalls` — is now gated on
+  `marketplaceEnabled` and `isAdmin`, the same two predicates the page's other two fetch
+  effects already check, in addition to (not instead of) its existing
+  `features.installLocal` check (objectui#5620).
+  
+  `listLocalInstalls`'s only consumer is `localInstalls.find(...)` in the content branch,
+  which is unreachable whenever the page has already returned `MarketplaceDisabled` (no
+  marketplace on this runtime) or `MarketplaceAccessDenied` (a refused viewer) — both
+  decided ahead of the content branch since objectui#5533 and objectui#5583. Before this
+  fix, a runtime with `features.installLocal: true` still fired the request — and
+  discarded its answer — on a marketplace-off runtime and for a non-admin, the same
+  wasted-round-trip class objectui#5533 established the fix for on this page, on the flag
+  that card was not about.
+  
+  `features.installLocal` remains its own axis: a runtime can mount a local kernel install
+  path with no marketplace proxy at all, so the fix adds the two predicates as a
+  conjunction rather than replacing the existing check. The request still fires exactly
+  when it did before AND the viewer would actually see its answer.
+- 8140418: Studio 的记录网格只请求服务端真有的列——「添加字段」不再把整个网格打成「该视图的查询被拒绝」
+  
+  在 Data 支柱点一下「添加字段」，整片网格立刻变成错误态，并建议「清除筛选条件」——而现场根本没有筛选条件。
+  
+  根因是投影的来源错了。`gridColumns` 取的是**草稿**对象的字段名，而这个数组是下游取数的输入；`addField` 只往本地草稿推一个 `field_<N>`。于是列一变就重新取数，`select` 里带着服务端不存在的列，data API 按设计拒绝——它的错误信息还专门解释了为什么不能静默丢弃未知列：那会把窄投影悄悄答成宽投影。
+  
+  修法的边界是**实测**出来的，不是猜的：把字段存成草稿返回 200 且 `state=draft`，紧接着的 `select` 指名它**仍然** 400。物化发生在**发布**时，所以「有没有保存」是错的问题，「服务端有没有」才是——答案在 `layered().effective` 这条基线里。
+  
+  因此新增 `publishedFieldNames`（加载时取自基线），并让 `gridColumns` 只保留其中存在的列。新字段照常在右侧检查器里被选中和配置（那本来就是配置它的地方），发布之后它可查询了，才作为列出现在网格里。
+  
+  过滤放在列数组这一处、而不是取数那一侧，是为了让「网格要什么」只有一个真相源。
+  
+  回归测试 `DataPillar.gridProjection.test.tsx` 断言在**交给对象视图的列数组**上——那个数组就是投影本身；如果只监视取数调用，日后把数组在下游改一手也能过，缺陷就悄悄搬回来了。撤掉这一行过滤，第二条精确转红、第一条仍绿。
+- 3d8cab5: Interface-page maps: drop the derived marker-title binding, restoring the
+  object's own declaration as the authority
+  
+  `defaultMapFromObject` bound a `titleField` alongside `locationField`, derived
+  from the object's display field. That binding was added to route around a forge
+  in `ObjectMap` — `getMapConfig` filled an absent `titleField` with the literal
+  `'name'`, and the marker title was a plain `record[titleField]` read, so an
+  object whose display field was not `name` titled every popup `undefined`. The
+  forge is gone: `ObjectMap` now resolves marker titles through
+  `@object-ui/core#getRecordDisplayName`, the same ADR-0079 resolver the kanban,
+  calendar and gantt renderers already used — which is why none of them binds a
+  derived title either.
+  
+  What the binding did once the forge was gone was invert precedence. It reaches
+  the resolver as `options.titleField`, i.e. step 0 — ahead of `titleField` on the
+  object, ahead of the declared `nameField` pointer, and ahead of the legacy
+  `titleFormat` template. A field name derived by the page could therefore only
+  ever change the answer by out-ranking something the object itself declared; in
+  every other case it reproduced, at step 0, the string the resolver already
+  computes further down its ladder. The deriver now binds `locationField` and
+  nothing else, exactly like its kanban / calendar / gallery / gantt siblings.
+  
+  No authoring surface changes. An author's own `map.titleField` is untouched — it
+  travels as the view-level `map` block, `ListView` merges it per key, and the
+  resolver honours it at step 0 by design. Objects that declare nothing resolve to
+  the same field as before, now via the resolver's own type-aware derivation
+  rather than a binding forced ahead of it; objects that declare a `titleFormat`
+  template (or a `titleField`) now have that declaration honoured on the map, as
+  it already was on every other visualization.
+- f09c7bc: Interface-page maps: derive a marker-title binding from the object's display field
+  
+  An ADR-0047 interface page that whitelists `map` derives its map binding with
+  `defaultMapFromObject`, which bound only `locationField`. With no `titleField`
+  reaching `ObjectMap`, `getMapConfig` filled the gap with the literal `'name'`
+  and the marker title is a plain `record[titleField]` read — so on any object
+  whose display field is not `name` (for example one keyed by `title`), every
+  marker popup titled itself `undefined`.
+  
+  The derivation now also binds the object's display field, resolved with the
+  field-name half of ADR-0079's precedence: the declared `nameField` (and its
+  `displayNameField` / `NAME_FIELD_KEY` aliases), otherwise the shared
+  `deriveTitleField` scan from `@object-ui/core` — the same ranking the kanban,
+  calendar and gantt renderers resolve titles through, so a map and a board over
+  one object agree on what a record is called. When nothing resolves the key is
+  omitted rather than defaulted. A hand-declared `map` block still wins per key.
+- d524bde: The marketplace **catalog** page now tells a non-admin that the runtime has no
+  marketplace, instead of telling them they lack permission (objectui#5557).
+  
+  `MarketplacePage` ordered its two early returns admin-first, so on a runtime that
+  mounts no marketplace at all (`features.marketplace: false` — an `OS_CLOUD_URL=off`
+  deployment, the EE deploy template's factory default) an unprivileged member got
+  "access denied" for a surface that exists for nobody. That answer sends them to
+  ask an administrator for a grant that would not help them, and it left the
+  informational disabled state built in objectui#5504 unreachable for every
+  non-admin. The runtime check now answers first, because "this deployment has no
+  marketplace" is true regardless of who is asking.
+  
+  This restores the sibling-page invariant for the one class of viewer it still
+  failed for: `MarketplacePackagePage` was reordered the same way in objectui#5533,
+  so on a marketplace-off runtime the catalog page and the package detail page now
+  give a non-admin the same kind of answer.
+  
+  Scope, deliberately narrow:
+  
+  - **Admin-first ordering stays correct where a marketplace exists.** On a runtime
+    with `features.marketplace: true`, a non-admin still gets `MarketplaceAccessDenied`
+    — the catalog is an install surface, and a member who cannot install has nothing
+    to do with it. That boundary is pinned by an explicit test, not left to prose:
+    without it, a change that simply dropped the admin check would look correct.
+  - Nothing an admin sees changes, on either kind of runtime.
+  - No new i18n keys, and no change to `MarketplaceAccessDenied` or
+    `MarketplaceDisabled` themselves — only which of the two the page reaches for,
+    and in which order it decides.
+  - The disabled state is still the server's own answer (`features.marketplace`),
+    never inferred from a failed request, and it still fails open.
+- 13413f3: The marketplace package detail page decides "you are not an admin" before it fetches,
+  instead of after the load has already failed.
+  
+  `MarketplacePackagePage` ordered its early returns with the `!isAdmin` guard *after*
+  both the loading branch and the `error || !data` branch, and gated its two fetch
+  effects on `features.marketplace` alone. On a runtime that mounts a marketplace, a
+  non-admin who opened a package URL was therefore walked through the fetch and the
+  skeleton, and — when the load failed — was handed the destructive "Failed to load
+  package" card carrying the server's own error message. Whether that viewer was
+  refused or handed a diagnosis about a surface they are not allowed to use came down
+  to whether an unrelated request happened to succeed.
+  
+  The guard now sits ahead of both branches, and `getMarketplacePackage` and
+  `getCloudInstallationInfo` are gated on `isAdmin` as well, so the page stops issuing
+  requests on behalf of a viewer it has already decided to turn away. That is the
+  discipline objectui#5533 established on this same page for `features.marketplace`,
+  applied to the other predicate that decides the same thing. It is also the ordering
+  `MarketplacePage` carries after objectui#5557, so the two sibling pages now answer one
+  runtime the same way for every viewer. The server remains the authority on what a
+  non-admin may fetch; this only stops the client doing work it would discard.
+  
+  Unchanged for an admin, deliberately and under test: a failing load still produces the
+  destructive card with the server's message intact, and a successful one still renders
+  the package. A "fix" that hoisted the refusal unconditionally, or that deleted the
+  failure branch, would satisfy every non-admin assertion and fail those two.
+  
+  `loading` stays seeded from `marketplaceEnabled` alone rather than from
+  `marketplaceEnabled && isAdmin`. `isAdmin` reads `activeMember`, which `AuthProvider`
+  resolves asynchronously *after* the session settles, so an admin whose role comes from
+  the org member row renders once as a non-admin before the flag flips. Seeding `false`
+  there would leave that first admin render with `loading: false` and no data — the
+  destructive card, painted for a frame before the effect could raise the flag again.
+  `MarketplacePackagePage.guardOrder.test.tsx` pins the flip case for that reason, along
+  with the ordering, the skipped requests, and the marketplace-off boundary the guard
+  must not jump above.
+- 2573ff4: The marketplace **package detail** page now states that the marketplace is turned
+  off, instead of red-erroring, on a runtime that has none (objectui#5533).
+  
+  `MarketplacePackagePage` takes the same `isMarketplaceEnabled()` early return its
+  sibling catalog page took in objectui#5504, rendering the informational
+  `MarketplaceDisabled` state when the server reports `features.marketplace: false`
+  (an `OS_CLOUD_URL=off` deployment — the EE template's factory default). Until now
+  the same runtime answered a bookmarked or pasted package URL with a destructive
+  "Failed to load package / Not found." card, so the two sibling pages reached
+  opposite conclusions about one runtime: the catalog called it configuration, the
+  detail page called it a failure.
+  
+  Both requests the page fires for its own view are skipped in that state — the
+  package fetch and the cloud-installation probe — rather than fired and discarded:
+  a discarded request still reaches the server and can race the destructive card
+  onto the screen before the disabled state settles.
+  
+  Scope, deliberately narrow:
+  
+  - **Not** a "swallow all errors" change. With `features.marketplace: true` the page
+    behaves exactly as before, and a package that genuinely is not there still
+    renders the destructive card carrying the server's own message. The flag is the
+    runtime's own answer, never inferred from the shape of a failure, and it fails
+    open — a runtime that answers nothing keeps its detail page.
+  - The `installLocal` surfaces are untouched. That is a different capability flag,
+    and an air-gapped `OS_CLOUD_URL=off` runtime still has a working install-local
+    path.
+  - No new i18n keys: `marketplace.disabled.*` and `marketplace.action.backHome`
+    already ship in all ten locale packs.
+- 8d37efb: The metadata lock banner can no longer render an amber, padlocked box with no
+  title, and the ADR-0010 §3.6 lock vocabulary is declared once instead of three
+  times (objectui#5024).
+  
+  `MetadataLayered.lock` and `MetadataAuditEntry.lockState` each spelled the four
+  states out by hand, 42 lines apart in one file, compared by no gate. They are now
+  one exported `MetadataLockState` — derived from `GetMetaItemLayeredResponseSchema`'s
+  `z.enum` in `@objectstack/spec`, which already owns this vocabulary, so the copies
+  were restating a schema rather than filling a gap.
+  
+  The user-visible half is the banner. Its title was three independent `&&` branches
+  with no fallback, while the switch that opens the banner is true for any non-`none`
+  value — so a lock state outside the four opened the box and left the headline
+  empty. That is reachable without a fifth state ever being added here:
+  `MetadataClient.layered()` casts the wire value through unchecked, so a newer
+  server reaches this banner as-is. Measured, not assumed — feeding `no-publish`
+  through the page rendered the padlock, the border and an empty title. The title is
+  now a keyed lookup with a loud fallback that names the unrecognised token, so a
+  fifth state fails `type-check` here and, if one arrives from a server anyway, the
+  operator reads a sentence instead of a blank box.
+- b2ea297: `ObjectSchemaMetadata` is now derived from `@objectstack/spec`'s `ServiceObject`
+  instead of being a hand-written copy (objectui#5362; maintainer ruling
+  2026-08-20: the object document type belongs to the spec).
+  
+  What changes on the published type surface:
+  
+  - **Gained:** the full spec object-document surface, including the three keys
+    the runtime already reads but the old interface rejected as excess
+    properties: `icon`, `titleFormat`, `listViews` (plus `pluralLabel`,
+    `nameField`, `displayNameField`, `managedBy` as a spec key, and the rest of
+    the spec document).
+  - **Removed:** nine members the old interface declared that no objectui
+    runtime code reads and the spec document does not know: `extends`,
+    `triggers`, `primary_key`, `relationships`, `name_field` (the spec spelling
+    is `nameField`), `soft_delete`, `audit_trail`, `version`, `cache`.
+    `ObjectTrigger` and `ObjectRelationship` remain exported unchanged.
+  - **Kept:** `editMode` — the one measured client-side member the runtime reads
+    (`recordFormNavigation` / `AppContent`) — now declared on the new
+    `ObjectSchemaClientExtensions` interface, which the derivation intersects.
+    Note the spec's strict parse rejects `editMode` on published documents
+    (`unrecognized_keys`); it is a client-type member only.
+  
+  Spelling settlement: `listViews` (camelCase) is canonical — `list_views`
+  appears nowhere in `@objectstack/spec` 17.2.0. Runtime read sites in
+  `@object-ui/app-shell` and `@object-ui/react` keep a documented snake-spelling
+  READ fallback for stored pre-settlement documents (that stock has never been
+  censused — objectstack#7917); the CRUD guide and its pinned transcription now
+  author the canonical spelling.
+- 26ff2d6: `sanitizeViewOverride` now strips a half-filled `between` from a stored view
+  overlay, instead of handing it back to the merge (objectui#5025,
+  objectstack#8815).
+  
+  The overlay recovery pass asked "is this filter row filled in?" with the
+  shape-blind predicate objectstack#8815 retired — `value == null || value === ''
+  || (Array.isArray(value) && value.length === 0)`. That is correct for `scalar`
+  and `list` and blind to `pair`: a `between` carrying one bound is
+  `['2024-01-01', '']`, an array of length 2, so the pass read it as a real
+  condition and kept it. The two write paths (`plugin-list`'s `ListView` and
+  app-shell's `viewFilterFold`) were converted to the builder's arity-aware
+  `isFilterValueComplete`; this read path was the third verbatim copy, and the one
+  whose job was to clean up exactly the rows the other two used to write. Until
+  now a stored half-range survived the pass, reached the query, and the server
+  refused the whole view (`400 INVALID_FILTER`) for every user on every later
+  read.
+  
+  The pass now delegates to the same `isFilterValueComplete` the write paths use,
+  on both of the at-rest shapes it handles (the spec `ViewFilterRule` object and
+  the legacy runtime triple). A complete range — bounds of `0` and `false`
+  included — is untouched, and the `scalar` and `list` families read exactly as
+  before, since the retired predicate was already right for them. One shape is
+  newly stripped beyond the half-filled array: a `between` whose value is a bare
+  scalar, which `ViewFilterRuleSchema` itself refuses.
+  
+  Which operators want no value at all is unchanged and still answered by
+  app-shell's `VALUELESS_FILTER_OPERATORS` — that set is already derived from the
+  builder's `VALUELESS_FILTER_BUILDER_OPERATORS` rather than being a private copy,
+  and its parity is pinned.
+- 3211397: `ObjectSettingsPanel` now calls `isExternalWider` from `owd-sharing.ts` instead of
+  re-declaring `OWD_WIDTH` and the ADR-0090 D11 width comparison inline (objectui#5477).
+  
+  `owd-sharing.ts` states its own purpose — it is "the single home" for the pieces the
+  per-object Settings tab and the package-level OWD overview must agree on, the D11
+  "external ≤ internal" comparison among them — and the Settings tab was the one surface
+  not calling it. The two implementations were verified equivalent before the swap, over
+  the full domain of both dials plus `undefined`, the rejected legacy aliases and
+  prototype-chain keys: 144 input pairs, zero disagreements. The module's extra `!!`
+  truthiness guards are redundant at this call site, which already normalizes both dials
+  to `''`, and `'' in OWD_WIDTH` is false regardless. So no author-visible verdict
+  changes — the same three pairs warn, and the same twenty-two stay calm.
+  
+  The substantive half is the pin that keeps it that way. `ObjectSettingsPanel.owdAgreement.test.tsx`
+  drives BOTH surfaces over the full 5×5 cross-product of the values their dials offer and
+  requires all three legs — the Settings tab's rendered warning, the overview's per-row
+  error, and `isExternalWider` itself — to agree on every pair, with the violating pairs
+  pinned by name so the sweep cannot pass vacuously. Re-inlining a drifted copy into either
+  surface, swapping the `(internal, external)` argument order, or refining D11 in only one
+  place now fails a test instead of silently leaving the authoring surface enforcing the
+  old rule.
+- 76ceb1e: The console's param-collection dialog now titles itself from `action.label` alone —
+  the unreachable `|| action?.title` fallback beside it is removed (objectui#4282).
+  
+  `title` is declared on no action surface in the ecosystem: it is absent from
+  `@objectstack/spec`'s `ActionSchema` (44 keys walked at spec 17.0.0), from
+  `@object-ui/core`'s `ActionDef` and its pinned `ACTION_DEF_KEYS` / `SPEC_ACTION_KEYS`
+  inventories, and from `@object-ui/types`' renderer view (`ui-action.ts`) and `crud.ts`
+  `ActionSchema` / `BaseSchema`. None of the four action renderers — `action:button`,
+  `action:icon`, `action:group`, `action:menu` — forwards it either. So the right-hand
+  side of that `||` could not be reached by authored metadata: a fallback that cannot
+  fire, which is the "declared is not enforced" shape objectstack#4075 exists to reduce.
+  Nothing a user hits changes; the line now reads exactly one key, matching the
+  `description` line directly below it.
+  
+  `useConsoleActionRuntime.paramDialogTitle.test.tsx` pins the reader so the alias cannot
+  be reinstated silently: an action carrying `title` and no `label` must open an untitled
+  dialog rather than a dialog named by a key no producer sets.
+- 7e81168: `ActionParamDialog`'s "this param carries a reference target" rule now derives from the shared reference-field family instead of the last private copy of it.
+  
+  `packages/app-shell/src/utils/paramToField.ts` restated the rule inline as
+  `LOOKUP_WIDGET_TYPES.has(type) || type === 'user'` — the fourth and last
+  hand-maintained answer to one question ("does this widget resolve a foreign key,
+  so hand it `reference_to` / `display_field` / the rest of the picker config").
+  The other three converged on `@object-ui/core`'s `EXPANDABLE_FIELD_TYPES` in
+  objectui#4770 / #4790 / #4815; this face is now the fourth.
+  
+  No reachable behaviour change. The shared set is one member wider (`tree`), and
+  that member can never be a widget key on this surface: it is absent from
+  `fields`' widget map and `mapFieldTypeToFormType` sends it to `field:lookup`, so
+  every key the rule tests arrives as `lookup`. Both halves are pinned, so
+  registering a real `tree` widget surfaces the change instead of shipping it
+  silently.
+  
+  The module's second rule — which widget keys degrade to a text input for want of
+  a declared `referenceTo` — is a different set over overlapping types (`user`
+  defaults its target to `sys_user` and must never degrade) and was deliberately
+  left un-merged, matching the same split the plugin-grid twin keeps.
+  
+  Also retires a comment that claimed the disjunction "moves in lockstep with
+  plugin-grid's `bulkParamToField` twin — the two param faces are never split".
+  Measured on the tip before this change, that was false in both senses: the twin
+  had read core's Set since objectui#4815 while this line read a private literal,
+  so the two shared nothing and no gate could report a split; and the two member
+  sets already differed, by `tree`. Lockstep now holds mechanically — the pin is
+  on object identity (a spy on core's `has`), so a member-identical private copy
+  fails where a value check would pass.
+- c5200f0: Follow-up to #5696: the pending-drafts bar's strings live at `console.ai.pendingDrafts.*` with en+zh locale entries — the i18n call-site key gate and ratchet flagged the original root-level keys that existed nowhere.
+- 76ceb1e: `RecordDetailView`'s param-collection dialog now titles itself from `action.label`
+  alone — the unreachable `|| action?.title` fallback beside it is removed
+  (objectui#5610).
+  
+  This was the second copy of the limb objectui#4282 removed from
+  `useConsoleActionRuntime`. `RecordDetailView` builds its own action runtime rather
+  than routing through that hook, so the two near-identical `paramCollectionHandler`s
+  have drifted as a pair and the first fix could not reach this one.
+  
+  `title` is declared on no action surface in the ecosystem: it is absent from
+  `@objectstack/spec`'s `ActionSchema` (44 keys walked at spec 17.0.0), from
+  `@object-ui/core`'s `ActionDef` and its pinned `ACTION_DEF_KEYS` / `SPEC_ACTION_KEYS`
+  inventories, and from `@object-ui/types`' renderer view (`ui-action.ts`) and `crud.ts`
+  `ActionSchema` / `BaseSchema`. None of the four action renderers — `action:button`,
+  `action:icon`, `action:group`, `action:menu` — forwards it either. So the right-hand
+  side of that `||` could not be reached by authored metadata: a fallback that cannot
+  fire, which is the "declared is not enforced" shape objectstack#4075 exists to reduce.
+  Nothing a user hits changes; the line now reads exactly one key, matching the
+  `description` line directly below it.
+  
+  `RecordDetailView.paramDialogTitle.test.tsx` pins the reader so the alias cannot be
+  reinstated silently: an action carrying `title` and no `label` must open an untitled
+  dialog rather than a dialog named by a key no producer sets. A pin per reader is the
+  only shape that covers both handlers, since the hook's own pin cannot see this site.
+- 4ef29f0: Remove the inert `showRefresh` designer input from the `object-view` registration (objectui#5567).
+  
+  The `object-view` designer no longer offers a "Show Refresh Button" toggle, and the registration no longer defaults `showRefresh: true`. The key was declared, documented, and defaulted, but `ObjectView` never read it — an author who wrote `showRefresh: false` on an `object-view` node always got a no-op. **Behaviour is unchanged for every existing app**, because nothing ever consumed the key.
+  
+  Migration: nothing to do. If you wrote `showRefresh` on an `object-view` node, the key simply disappears from the designer's property panel; it never controlled anything. The live refresh channel is `userActions.refresh` (rendered by the list toolbar in `@object-ui/plugin-list`), which is unaffected. `showRefresh` on other surfaces (e.g. `CRUDToolbar`) is also unaffected.
+  
+  `@object-ui/app-shell` only drops its two producer writes of the dead key (the app `ObjectView` wrapper and the metadata-admin `ViewPreview`) — no user-visible change.
+- ad404e0: Confirm-replay dispatch errors (bare `{error: …}` envelopes) now resolve the 确认修改 card instead of leaving it on 应用中 forever: `detectReplayOutcome` classifies them as a provisional failure, and a later successful authoring result in the same turn (the model self-repairing, e.g. after an `object not found` on a blueprint-local name) supersedes it via `detectAuthoringVerdict` — so the card never says 未生效 over a change that actually landed. Real publish failures (`publishFailed` envelopes) are never superseded. Measured live on the local rig, 2026-08-24.
+- 1eb15c7: Page-block canvas: draw the real icon and colour tone for block types that render fine but are not offered in the palette.
+  
+  The canvas read its per-node icon and tone from `BLOCK_TYPE_META`, which is the palette's *offer* list ("what may an author drag in") — while the canvas is answering a different question ("what may an author already have in this page"). The two diverge for an alias pair: `record:discussion` and `record:chatter` are one renderer under two names, so exactly one spelling is always unoffered, and a page carrying it showed a plain unknown-block box and neutral grey instead of the message icon and the blue record tone its twin gets.
+  
+  `block-types.ts` now declares `BLOCK_RENDERER_ALIAS_GROUPS` — spellings that resolve to the same registered renderer — and the canvas resolves display chrome through `resolveBlockDisplayMeta()`, which falls back to an alias sibling's entry. Keyed on renderer identity, not on "is excluded": palette exclusions that genuinely are not page blocks (`element:text_input`, `element:record_picker`, `element:form`, `ai:chat_window`) keep the generic box, and nothing became draggable — the palette offer list is unchanged.
+- 0935a43: Console builds no longer carry a live Sentry DSN, and `sendDefaultPii` is now opt-in
+  (objectui#5522).
+  
+  `@object-ui/console` publishes a pre-built SPA, so ONE artifact — built once from
+  `apps/console/.env.production` — is what the hosted SaaS console and the on-premises /
+  air-gapped EE images all embed. Vite inlines every `VITE_*` from that file into the
+  bundle as a frozen object literal, so the DSN committed there was a live third-party
+  telemetry endpoint compiled into artifacts that land inside customer networks. It could
+  not be switched off afterwards either: the `VITE_SENTRY_ENABLED` kill switch is read off
+  that same frozen literal, so on a shipped bundle it is `undefined` forever and editing
+  env vars on the deployed host does nothing. An air-gapped deployment was measured
+  sending 14 envelopes per session to sentry.io with IP + User-Agent PII, unstoppable by
+  the customer.
+  
+  - `apps/console/.env.production` no longer defines `VITE_SENTRY_DSN`,
+    `VITE_SENTRY_ENVIRONMENT` or `VITE_SENTRY_SEND_DEFAULT_PII`. A build with no DSN never
+    imports `@sentry/react`, so the `vendor-sentry` chunk is not even fetched.
+  - `sendDefaultPii` changed from opt-out (`!== 'false'`) to **opt-in** (`=== 'true'`), so
+    IP address and User-Agent are never the inherited default of a build that did not ask
+    for them.
+  - The gate now fails **closed**: an absent, empty or whitespace-only DSN means do not
+    send. The direction is deliberately inverted from the usual — an unreported error is
+    recoverable, PII leaving an air-gapped deployment is not.
+  
+  **Action required for deployments that want error reporting** (the hosted SaaS/demo
+  console): inject `VITE_SENTRY_DSN` from your build environment, the same way
+  `VITE_SERVER_URL` is already injected, plus `VITE_SENTRY_SEND_DEFAULT_PII=true` if you
+  still want IP/User-Agent on events. Nothing else changes for builds that opt in.
+- add10d8: Studio's metadata authoring path stops greeting the author with errors they did not cause, English help text in a Chinese console, and a toast on top of the publish button.
+  
+  Three defects measured on a 17.1.0 dogfood walkthrough (objectui#5416), all on
+  the first surfaces a new author sees.
+  
+  **Validation no longer runs on mount.** `新建软件包` opened with both required
+  fields already red: the create draft is `{ version, type }`, so
+  `ManifestSchema.safeParse` reported `name` and `id` missing on the very first
+  render, and the dialog then jumped a line height per field as each error
+  cleared. `SchemaForm` now defers the error *line* until the row has been
+  touched — first focusout anywhere in it, or the field's own first edit — for
+  create forms only. The rule itself did not move: `issues` still reaches the host
+  unchanged, so the submit button is gated on exactly the same validation, and
+  edit/view forms still report from mount, where the issues describe stored values
+  rather than something half-typed.
+  
+  **The package form's help text is translated.** The labels came from the
+  metadata-admin i18n bundle and the help line under each one came straight from
+  `ManifestSchema`'s English `.describe()`, so a zh console rendered 显示名称 over
+  "Human-readable package name". `getPackageForm` now reads each field's help
+  through the same bundle as its label, via a new `tOptional` that returns
+  `undefined` rather than echoing the key back. Only zh entries exist: an en-US
+  console finds nothing and keeps falling through to the spec's own sentence, so
+  the English keeps exactly one producer — `@objectstack/spec` in the framework
+  repo — and this repo never holds a copy of it to drift.
+  
+  **The publish panel's primary button opens clear of the toast stack.** The
+  console mounts its toaster bottom-right and `DraftChangesPanel` is a
+  `side="right"` sheet with an `mt-auto` footer, so a save toast raised on the way
+  there (`对象「…」已存为草稿`, 4s default) sat directly on 全部发布 until it timed
+  out. Opening the panel now clears the stack the surface the author just left had
+  raised. Repositioning the toaster was measured and rejected: the draft preview
+  bar is `sticky top-0` and carries its own publish actions, `NotificationSnackbar`
+  anchors bottom-centre and the nav rail owns the left edge, so a move only
+  relocates the same collision onto a different primary control.
+  
+  Not fixed here, and not fixable here: the other strings the card names are
+  produced outside this repo. `Owning Business Unit` (`packages/spec`),
+  `Search Index` (`packages/objectql`) and the `Revise Window` flow node's name
+  and description (`packages/plugins/plugin-approvals`) all come from the
+  framework, which owns their translation catalogue; patching them in the console
+  would create a second source of truth that diverges at the next framework
+  release.
+- 6cc62e2: Studio Interfaces: the nav-leaf binding reads the canonical target key only
+  
+  `resolveSurface` fell back to the bare spellings `page` / `object` /
+  `dashboard` / `report`, and carried a `case 'view'`. Every
+  `NavigationItemSchema` member is a `strictObject`, none of those bare
+  spellings is in any variant's shape or in `NAV_ITEM_ALIASES`, and `view` is
+  not one of the union's nine members — so all of them are keys `AppSchema`
+  answers with `unrecognized_keys`, and every one of those branches could only
+  fire on an app that cannot be saved. The Studio nav item inspector's object
+  picker likewise read `node.object ?? node.objectName`, preferring the rejected
+  spelling over the canonical one; it now reads the canonical key first.
+  
+  No shape that parses today stops parsing: this narrows the designer back to
+  what the contract already declares.
+- d15a92d: Studio's pre-publish security block can now take you to the object it names.
+  
+  The pending-changes sheet reports what the publish door would refuse — as
+  `object/crmext_visit`, with the rule's fix-it hint and "Fix it on the object under
+  Settings → Record sharing". Naming it was the half that shipped; reaching it was not.
+  The `?surface=<type>:<name>` deep-link that would have carried the author there
+  captures the URL exactly ONCE, at mount, and the sheet is opened over an
+  already-mounted pillar — so writing the param changed the URL and moved nothing.
+  
+  That mount-time capture is deliberate and stays exactly as it was: the mirror half
+  rewrites the param on every in-pillar selection, so a capture that followed the URL
+  would re-trigger its restore on each one. What was missing is a third half — a live
+  target delivered BESIDE the URL, which is what a producer already inside the pillar
+  needs. `surfaceDeepLinkChannel` adds it: producers ask for a surface by identity
+  (`{type, name}`), the host routes cross-pillar requests back through the URL (that
+  pillar is unmounted, so its capture is the right mechanism) and vetoes the ones the
+  author declines over unsaved edits, and the mounted pillar applies the rest.
+  
+  Applied AT MOST ONCE, by a monotonic id. A standing request re-resolved on the next
+  rail reload would drag the author back off whatever they had since selected — the
+  regression the mount-time ref exists to prevent — so `DataPillar.surfaceRequest.test`
+  pins a hand-picked object surviving a package switch, and
+  `surfaceDeepLinkChannel.test` pins the capture itself as an unchanged control: it
+  still ignores every URL change after mount, and a live request never moves it.
+  
+  The sheet's other home is the Home / draft-preview bar, where the Studio object editor
+  is not a reachable destination at all. Reachability is answered structurally — the
+  producer hook returns `null` when no host published the channel — so off-Studio the
+  item name stays the prose #5418 shipped rather than becoming a link to nowhere. Both
+  directions are assertions in `DraftChangesPanel.securityLink.test`, not a comment.
+  
+  Nothing the other three pillars observe changed: `useSurfaceDeepLink` keeps its
+  signature, its return and its behaviour, and only the Data pillar subscribes to the
+  new channel. The channel is its own React-only module on purpose — importing the hook
+  into the sheet would have pulled `nav-selection` and the App-nav inspector into the
+  console's eager graph.
+- 3ece13e: Removed the dead `theme:` entry from `clientValidation.ts`'s `LOADERS` table, which
+  read `ThemeSchema` off `@objectstack/spec/ui` — a symbol the spec retired upstream
+  (objectstack#10485 / PR objectstack#10695, which deleted the whole `ui/theme.zod.ts`
+  module). `theme` was never a registered metadata type, so metadata-admin never asked
+  for it (objectui#5715).
+  
+  This is dead-code hygiene, not a bug fix, and it changes nothing an author can
+  observe. Two measurements say why, and both cut against the more dramatic reading:
+  
+  - The entry is not broken *today*. objectui's own `@objectstack/spec` pin (17.1.0)
+    still publishes `ThemeSchema` as a working strict Zod schema — measured by
+    importing the `ui` subpath and by ablation, where restoring the entry made
+    `validateMetadataDraft('theme', ...)` actively reject a draft. The skew is with
+    objectstack's `main`, not with what objectui installs, which is exactly why no
+    gate here ever went red.
+  - It could never have crashed. `getSchemaForType` duck-checks the loader's result
+    (`typeof schema.safeParse === 'function'`) and wraps the call in `try/catch`, so an
+    `undefined` export degrades to a silent no-op validator, never a throw. After a
+    future spec bump past the retirement that is the branch it would have taken.
+  
+  The one thing that was genuinely off: `hasClientValidator` answers from key presence
+  alone, so it returned `true` for `theme` while the validator behind it would have
+  judged nothing. Per its own docblock that combination makes `ResourceEditPage` treat
+  live client issues as the error source and suppress the server's `_diagnostics` — a
+  stored item rendering as clean. Unreachable in practice, but it is the reason the
+  entry is worth removing rather than leaving inert.
+  
+  The line is replaced by an absence note in the shape the file already uses for
+  `workflow` and `approval`, because re-adding this entry from the spec would
+  type-check and go green against the current pin. A metadata-admin theme editing
+  surface remains a separate capability decision.
+- cfcff30: Each package's README now states, up front, that it needs a bundler: importing it from plain Node ESM fails, and that is a supported-configuration boundary rather than a defect.
+  
+  `@object-ui/plugin-dashboard` imports `react-grid-layout/css/styles.css` at module
+  scope and `@object-ui/plugin-map` imports `maplibre-gl/dist/maplibre-gl.css`;
+  `@object-ui/app-shell` reaches the first of those through the static
+  `@object-ui/plugin-dashboard` imports in `DashboardView` and `ReportView`. Node has
+  no loader for `.css` at all, so all three resolve and then die during evaluation:
+  
+  ```
+  TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".css"
+    for .../react-grid-layout/css/styles.css
+  ```
+  
+  Nothing about how these packages load has changed — every supported host bundles
+  them (Vite, webpack, or Next with the package in `transpilePackages`), and that is
+  still the only supported way to consume them. What changed is that the boundary is
+  now written where a consumer meets it, instead of being learned from a red import.
+  
+  objectui#5384 ruled unbundled Node consumption **unsupported** for style-carrying
+  plugin packages — permanently, over the three packages as a group — rather than
+  moving the stylesheet imports out of module scope. No unbundled-Node consumer
+  exists, and buying permanent machinery to close a capability gap nobody is pulling
+  on was the trade the ruling declined. A real consumer request reopens it as a
+  design question, not as a defect: the READMEs say so and name the issue.
+- 286dd8d: A view personalization overlay now stores **only the patch** — a column drag no
+  longer freezes the source view's filter into it (objectui#5233).
+  
+  `ObjectView`'s `persistViewPatch` wrote `{ ...baseViewDef, ...patch }`, so an
+  overlay written by a mere sort/density/column change copied the view's *current
+  effective* `filter` — along with its `columns`, `label`, `type`, `isDefault` —
+  into the stored row. The display merge is `{ ...source, ...override }`, so that
+  copy then outranked the source view forever: an admin edited the view's filter
+  and every user who had once resized a column silently kept the old filter, with
+  nothing anywhere reporting it.
+  
+  The write now goes through the exported seam `buildPersistedViewBody`. For a
+  **system view's overlay** the body is the patch plus `viewKind` when the active
+  tab carries one — identity, not content, and the same line the read side already
+  draws (`VIEW_OVERLAY_IDENTITY_KEYS`); `object`, `name` and the overlay marker are
+  stamped by the adapter. A **saved view's own row** is deliberately still written
+  whole: for it the body *is* the view, there is no source underneath it for a
+  copied key to shadow, and the write is a whole-document PUT — narrowing it would
+  delete the user's view rather than narrow it.
+  
+  This is the write half of the maintainer's 2026-08-12 ruling (objectstack#7494).
+  It was blocked until `columnState` was admitted to the view-metadata surface as
+  an explicitly runtime-only overlay key (objectstack#9933, released in
+  `@objectstack/spec` 17.1.0) — before that a `columnState`-only patch was refused
+  `422 INVALID_METADATA`, and the fat copy was the only thing supplying a
+  recognized key. The read half (`narrowPersonalizationOverlay`) shipped earlier
+  and stays: rows written before this land are still tolerated on read, and because
+  the write replaces the whole document, the next toolbar toggle also strips such a
+  row at rest. No migration.
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [f66072d]
+- Updated dependencies [2d7304d]
+- Updated dependencies [062943f]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [53dc89d]
+- Updated dependencies [baac3f4]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [94e2fa7]
+- Updated dependencies [490d9a9]
+- Updated dependencies [a1c41c5]
+- Updated dependencies [1117414]
+- Updated dependencies [6d63cd0]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [7c96c94]
+- Updated dependencies [a100f77]
+- Updated dependencies [3e853c9]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [17ccec9]
+- Updated dependencies [8d3a529]
+- Updated dependencies [194fae1]
+- Updated dependencies [63d54dd]
+- Updated dependencies [beccf1c]
+- Updated dependencies [c5fbe0b]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [2cf69e4]
+- Updated dependencies [864154e]
+- Updated dependencies [2cf69e4]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [a76b18c]
+- Updated dependencies [44d075b]
+- Updated dependencies [b4393e5]
+- Updated dependencies [5173a5e]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [d3005f7]
+- Updated dependencies [c9a7252]
+- Updated dependencies [5f19b92]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [d18a0d3]
+- Updated dependencies [9caa7d4]
+- Updated dependencies [6f81384]
+- Updated dependencies [7d2a689]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [c38162d]
+- Updated dependencies [b362c1b]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [1c19722]
+- Updated dependencies [5961030]
+- Updated dependencies [faa863d]
+- Updated dependencies [129c7a9]
+- Updated dependencies [fd814d6]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [854222c]
+- Updated dependencies [e929c56]
+- Updated dependencies [3777538]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [7975f2d]
+- Updated dependencies [bd2f56a]
+- Updated dependencies [6a7893d]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [73e8c33]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [b49f9a1]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [ebfc3c2]
+- Updated dependencies [9a5d669]
+- Updated dependencies [d06fba8]
+- Updated dependencies [b2e85a9]
+- Updated dependencies [79a4b8f]
+- Updated dependencies [c7cd2b6]
+- Updated dependencies [b2065e7]
+- Updated dependencies [77f846a]
+- Updated dependencies [686d5d9]
+- Updated dependencies [cc3366b]
+- Updated dependencies [76ae729]
+- Updated dependencies [f47d94c]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [894d103]
+- Updated dependencies [a31adc6]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [3c9fca3]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [2e471a6]
+- Updated dependencies [3d79455]
+- Updated dependencies [cc5de5c]
+- Updated dependencies [84d2e98]
+- Updated dependencies [f24195a]
+- Updated dependencies [56f4e34]
+- Updated dependencies [1d9100e]
+- Updated dependencies [62c0fa1]
+- Updated dependencies [4db5989]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [b470e91]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [9a1fb41]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [9e22085]
+- Updated dependencies [b655a9d]
+- Updated dependencies [c574dfb]
+- Updated dependencies [02f48b6]
+- Updated dependencies [a865c73]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cad512f]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [0b12a33]
+- Updated dependencies [105f3c5]
+- Updated dependencies [32ef595]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [c8da8b3]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [15236e0]
+- Updated dependencies [ec9fdaa]
+- Updated dependencies [d6613a2]
+- Updated dependencies [e2e8e68]
+- Updated dependencies [e4e9557]
+- Updated dependencies [7a28e1e]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [6c1b105]
+- Updated dependencies [9d9040d]
+- Updated dependencies [20e317c]
+- Updated dependencies [425762e]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [8e00bfd]
+- Updated dependencies [8d37efb]
+- Updated dependencies [9850c6e]
+- Updated dependencies [9118a31]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [6c5ee71]
+- Updated dependencies [84d70bb]
+- Updated dependencies [cfc2c7a]
+- Updated dependencies [9e725e0]
+- Updated dependencies [6f017e9]
+- Updated dependencies [f1c27f0]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [343c598]
+- Updated dependencies [af3861f]
+- Updated dependencies [0ccbdc1]
+- Updated dependencies [515f171]
+- Updated dependencies [83ec618]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [4bb940b]
+- Updated dependencies [17fbbaf]
+- Updated dependencies [d8cf1cb]
+- Updated dependencies [0d1e702]
+- Updated dependencies [0068348]
+- Updated dependencies [641543f]
+- Updated dependencies [8a44390]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [23705b7]
+- Updated dependencies [f2158ec]
+- Updated dependencies [4ef29f0]
+- Updated dependencies [ad404e0]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [f1690d4]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [591bf27]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [2dd9443]
+- Updated dependencies [43ca9d5]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [ba306e3]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [ff2d547]
+- Updated dependencies [36918bf]
+- Updated dependencies [490f482]
+- Updated dependencies [934a532]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [26a2238]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [5d79faf]
+- Updated dependencies [cfcff30]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [6b348d2]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/fields@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/plugin-grid@17.7.0
+  - @object-ui/plugin-list@17.7.0
+  - @object-ui/plugin-detail@17.7.0
+  - @object-ui/plugin-kanban@17.7.0
+  - @object-ui/plugin-form@17.7.0
+  - @object-ui/data-objectstack@17.7.0
+  - @object-ui/plugin-view@17.7.0
+  - @object-ui/plugin-dashboard@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/plugin-calendar@17.7.0
+  - @object-ui/plugin-charts@17.7.0
+  - @object-ui/plugin-chatbot@17.7.0
+  - @object-ui/plugin-designer@17.7.0
+  - @object-ui/plugin-editor@17.7.0
+  - @object-ui/plugin-report@17.7.0
+  - @object-ui/providers@17.7.0
+  - @object-ui/react@17.7.0
+  - @object-ui/auth@17.7.0
+  - @object-ui/permissions@17.7.0
+  - @object-ui/layout@17.7.0
+  - @object-ui/collaboration@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/app-shell/package.json b/packages/app-shell/package.json
index 37335039eb..45d66f90b7 100644
--- a/packages/app-shell/package.json
+++ b/packages/app-shell/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/app-shell",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Minimal application shell for ObjectUI - framework-agnostic rendering engine",
diff --git a/packages/auth/CHANGELOG.md b/packages/auth/CHANGELOG.md
index 06a23c79be..ee9c706ada 100644
--- a/packages/auth/CHANGELOG.md
+++ b/packages/auth/CHANGELOG.md
@@ -1,5 +1,367 @@
 # @object-ui/auth
 
+## 17.7.0
+
+### Minor Changes
+
+- 686d5d9: `AuthGuard`'s `requiredRoles` now matches against `user.positions` — the one published spelling (framework ADR-0090 D3) — keeping the `user.role` scalar fallback only for sessions that carry no `positions` key at all (guest / legacy identities). This restores position-holder admission on protocol-17 deployments (where the retired `roles` key is never emitted) and closes the matching over-admission: a coarse scalar `role` no longer passes a gate whose position the server says the user lacks. Preview mode now emits `positions: [role]` instead of the retired `roles` key — it was the last producer — so preview identities are shaped like protocol-17 sessions for every `positions` consumer. The hand-copied `roles?: string[]` mirror key is removed from the client `AuthUser` type; breaking only for TypeScript consumers that compiled against `AuthUser['roles']` (read `positions` instead — no runtime payload ever carried `roles` at protocol 17). Maintainer ruling 2026-08-22 on objectui#5424.
+- c8da8b3: Stop showing an access-denied screen to a real administrator while their
+  adminship is still resolving.
+  
+  `useIsWorkspaceAdmin()` returned a bare `boolean`, so "the inputs have not
+  arrived yet" and "resolved: not an admin" were the same answer. One of its three
+  sources — the active organization member row — is fetched some round trips after
+  the session (`listOrganizations` → `getActiveOrganization` → `getActiveMember`),
+  so an administrator whose adminship lives only in that row rendered at least
+  once as a non-admin, and every gate downstream acted on it: the two marketplace
+  surfaces painted `MarketplaceAccessDenied`, the console chrome dropped and
+  re-added its admin nav entry, and `AppContent` fired a `<Navigate to="/home"
+  replace>` that the later flip could not undo.
+  
+  **Breaking (published API, hence `minor` per this repo's version policy):**
+  `useIsWorkspaceAdmin(): boolean` is replaced by
+  `useWorkspaceAdminStatus(): { isAdmin: boolean; isResolved: boolean }`. The old
+  name is removed rather than kept alongside, so a call site that ignores the
+  third state fails to compile instead of silently refusing an administrator.
+  
+      -const isAdmin = useIsWorkspaceAdmin();
+      +const { isAdmin, isResolved } = useWorkspaceAdminStatus();
+  
+  `AuthProvider` gains `isMembershipResolved` on its context — the organization /
+  member pipeline has reached a terminal state — because `organizations`,
+  `activeOrganization` and `activeMember` read `[]` / `null` / `null` both before
+  the pipeline starts and after it finds nothing.
+  
+  No extra wait for administrators: `isResolved` is true the instant `isAdmin` is,
+  so an admin the session already identifies through `positions[]` never waits on
+  the member row.
+
+### Patch Changes
+
+- ebfc3c2: `ActiveOrganizationStorage.clear()` now verifies that the persisted key is actually
+  gone and, when it is not, both reports the failure and stops `get()` answering from
+  the surviving value — instead of swallowing the failed removal (objectui#5731).
+  
+  `clear()` nulled `_memoryValue` and then removed the persisted key inside a
+  `try`/`catch` that discarded any failure. Since objectui#5703 `get()` prefers a
+  NON-NULL `localStorage` read and only falls through to `_memoryValue`, so the two
+  halves of `clear()` were not equally strong: nulling memory always sticks, while a
+  removal that did not stick left the key readable and the read order preferred it.
+  Sign-out is one of `clear()`'s five callers, so the failure mode was "sign-out does
+  not stick", and it was silent — the cleared organization went back on the wire as
+  `X-Tenant-ID` on every subsequent request.
+  
+  The removal is now judged by a READ-BACK rather than by catching the throw, which is
+  both narrower and wider in the right directions. Wider: a wrapped or proxied
+  `localStorage` whose `removeItem` is a silent no-op never throws and leaves identical
+  residue, and is now covered. Narrower: SSR and the partitioned-iframe browser where
+  every operation throws have nothing readable to resurrect, were already safe, and are
+  not reported as failures.
+  
+  A key whose removal could not be verified is quarantined in memory for the rest of the
+  page-load: `get()` skips the persisted branch for it and answers from `_memoryValue`,
+  which `clear()` has just nulled and which a later `set()` refills with the value that
+  write was meant to persist. The quarantine is released as soon as a removal on that key
+  sticks. An unstamped `X-Tenant-ID` is a documented state of the edge contract
+  (objectui#5279); a re-stamped signed-out organization is not.
+  
+  The failure is not thrown and not returned. All five call sites — sign-out's
+  `purgeSignedOutClientCaches`, `switchOrganization`, `deleteOrganization`,
+  `leaveOrganization`, and the session-user purge that runs on the SIGN-IN path — arrive
+  after the transition they follow up on has already happened, and none can act on a
+  storage failure; a `boolean` every caller ignores would read as handled when it is not.
+  So the invariant is restored inside `clear()` and the failure is reported to the
+  console.
+  
+  A working `localStorage` behaves exactly as before: the removal sticks, nothing is
+  quarantined, nothing is reported, and a non-null persisted read is still authoritative.
+  `set()`'s swallowed write failure is deliberately untouched — that swallow is
+  objectui#5703's memory fallback, and it is the correct kind, because the memory copy
+  upholds `set()`'s postcondition where nulling memory could not uphold `clear()`'s.
+- 9a5d669: `ActiveOrganizationStorage.get()` now prefers a non-null `localStorage` read and falls
+  back to the in-memory value otherwise, instead of returning the `localStorage` read
+  unconditionally — so the fallback is reachable in the browser state it was written for
+  (objectui#5703).
+  
+  `set()` already swallowed a failed `localStorage.setItem` into `_memoryValue`, but
+  `get()` only consulted `_memoryValue` when the READ itself threw. There is a real
+  browser state where the read does not throw and the fallback is nonetheless the only
+  copy: `localStorage` present and readable but rejecting writes — Safari private
+  browsing, and any quota-exhausted origin, where `setItem` throws `QuotaExceededError`.
+  In that state the active org was stored and could not be read back, measured as
+  `_memoryValue = org-42` alongside `get() = null`.
+  
+  The cost was silent and lasted the whole session rather than the documented first-boot
+  window: `createAuthenticatedFetch` reads `get()`, so `X-Tenant-ID` was never stamped on
+  any request. Per the edge contract documented on objectui#5279 that header is a routing
+  hint a reader falls through on — the framework scopes from the session — so no row
+  visibility rode on this; what was missing is the tenant-routing input, on every request.
+  `switchOrganization` also appeared to succeed while the client-side stamp never
+  followed.
+  
+  Sign-out is unaffected, and that is the half worth stating: the new fallback fires
+  exactly when the `localStorage` read is null, which is the state `clear()` leaves
+  behind. It answers `null` there because `clear()` nulls `_memoryValue` too. That
+  property is now pinned by test rather than relied upon, so a future `clear()` that only
+  removed the persisted key fails a test instead of quietly re-stamping a cleared org.
+  
+  A non-null persisted read still wins over the memory value, so a working `localStorage`
+  behaves exactly as before.
+- 32ef595: Restore platform-admin detection for permission-set-derived administrators.
+  
+  `useIsWorkspaceAdmin` decides Setup app + Studio visibility, App Marketplace
+  gating and the "Build an app" CTAs. Its third source read `user.roles`, a key
+  the protocol-17 session face no longer emits (framework ADR-0090 D3 renamed it
+  to `positions`). An administrator whose adminship comes from the
+  `admin_full_access` permission set — the single-tenant deployment shape, where
+  there is no organization member row and the server deliberately no longer
+  overwrites `user.role` — matched none of the three sources and read as **not an
+  administrator**: Setup and Studio simply disappeared for them.
+  
+  The hook now reads `user.positions[]`, the one spelling the session publishes.
+  Detection is restored for that path and unchanged everywhere else: an active
+  member row with an admin role, a stored `user.role` admin scalar, and
+  preview/no-auth mode all behave exactly as before, and nobody who was not an
+  administrator becomes one — pinned by four negative cases alongside the
+  positive one.
+  
+  Also corrects the now-stale documentation that described the removed spelling:
+  the hook's own docblock, the `roles?: string[]` declaration on the client
+  `AuthUser` (kept for one remaining compile-time reader; see objectui#5424), and
+  two comments in `@object-ui/app-shell`'s Home page. No behaviour change from the
+  comment corrections.
+- 343c598: The active organization id is now stored per user, and a change of session user drops the
+  previous user's client state wholesale (objectui#5664).
+  
+  `auth-active-organization-id` was a single un-namespaced `localStorage` key while its
+  siblings were already user-scoped (`objectui-recent-items:u:`, `objectui-favorites:u:`,
+  `flow-palette-recents:u:`). On a browser handed from one account to another — a shared
+  machine, a kiosk, a handover, a support session — the arriving user's console read the
+  PREVIOUS user's organization id. The header workspace chip rendered the previous user's
+  workspace for a user whose `organization/list` was empty, and the consequence past the
+  cosmetics is the one worth stating: the polluted org context suppressed
+  `RequireOrganization`'s routing into the guided "Create your workspace" first-run flow, so
+  a brand-new user on that browser silently never got the new-user flow at all.
+  
+  Nothing about row visibility rode on this. With the stale id the server answers
+  `403 USER_IS_NOT_A_MEMBER` on `get-full-organization` and `set-active`, and lists zero
+  environments; the damage was entirely in what the client believed about itself.
+  
+  Three changes, and the third is the one that closes the class rather than the instance:
+  
+  - The key is per-user (`auth-active-organization-id:u:$userId`), matching the convention
+    its siblings already use.
+  - It can no longer be written un-namespaced at all. Where no session user is known yet the
+    value lives in memory for that page-load only — a namespacing that kept a bare-key
+    fallback would re-open the defect the first time a write happened before the user id
+    resolved.
+  - **A change of session user drops the previous user's client state wholesale.** This is an
+    allowlist sweep of both `localStorage` and `sessionStorage`, not a list of known keys, so
+    the NEXT storage key someone adds without a `:u:` scope is covered before it is written.
+    Only device-scoped entries survive: the arriving session's own bearer token, the pointer
+    recording whose state the browser holds, and the UI theme.
+  
+  Both properties objectui#5703 established are preserved and still pinned: `get()` prefers a
+  non-null `localStorage` read and falls back to the in-memory value, and the memory value is
+  nulled BEFORE storage is touched — by `clear()` as before, and now by the user-change purge
+  too, so the outgoing user's org id cannot outlive their persisted key on the sign-out-then-
+  sign-in path that never reloads the page.
+  
+  Existing browsers are not migrated. A value sitting under the retired bare key is
+  unattributable — nothing recorded whose org id it is — so migrating it is precisely the
+  defect it would be migrating away from, and it is deleted instead. A signed-in user loses
+  nothing durable: the active organization is a server-owned fact that
+  `AuthProvider.refreshOrganizations` re-asks for whenever the list is non-empty and no
+  active org is held, including the ADR-0081 single-membership repair. One boot re-supplies
+  it; users with no organization land on the guided first-run flow, which is the outcome this
+  card is about.
+  
+  `apps/console`'s pre-render auth preflight purges every spelling of the active-org key —
+  the retired bare one and each `:u:` scope — when it finds a dead bearer token, and
+  deliberately leaves the session-user pointer in place so the next sign-in can still tell
+  that the browser changed hands.
+- 2dd9443: `purgeSignedOutClientCaches()` — the sweep that drops the signed-out user's
+  `objectui:metadata:*` seed cache on sign-out (objectui#5198) — now costs one key when a
+  single `removeItem` throws, instead of aborting the rest of the sweep (objectui#5777).
+  
+  The `try` wrapped the WHOLE loop, not each removal. A `removeItem` that threw on key `n`
+  aborted the walk, so keys `n+1..end` were never swept, and the failure was swallowed —
+  `AuthProvider`'s `signOut` believed the purge had completed. The entries this sweeps are
+  the previous principal's org-scoped, PERMISSION-FILTERED app list — objectui#5198
+  classifies a surviving entry as a cross-principal disclosure on a shared browser, not
+  mere staleness — so a partial sweep here is the sharper half of the same defect class
+  objectui#5763 fixed on the sign-in path (`sweepStore` in `ActiveOrganizationStorage.ts`).
+  
+  `Object.keys(sessionStorage)` — the reason a guard exists here at all — stays guarded on
+  its own; only the per-key guard is new. Same as `sweepStore`, a failed removal here is
+  not verified by read-back and not quarantined the way `ActiveOrganizationStorage.clear()`
+  (objectui#5731) quarantines a key: this function does not own reads for the metadata
+  seed cache (`MetadataProvider` in `@object-ui/app-shell` does), so there is no `get()` to
+  guard and nothing to quarantine — adding read-back verification would be a general
+  storage-error-handling refactor of the module, out of this card's scope. What is
+  mirrored is the reporting channel: a key whose `removeItem` throws is named in a
+  `console.warn`, the same channel `sweepStore` and `clear()` use, so a partial sweep is
+  discoverable instead of silent.
+  
+  Adds a partial-failure test: a `sessionStorage` whose `removeItem` throws on one metadata
+  key, asserting every other metadata key on both sides of it is still swept and unrelated
+  non-matching keys are untouched, plus a control that the warning fires only on an actual
+  failure.
+- ff2d547: `sweepStore()` — the walk that drops the previous user's `localStorage`/`sessionStorage`
+  state on a change of session user (objectui#5664 part 3) — now costs one key when a
+  single `removeItem` throws, instead of aborting the rest of the sweep (objectui#5763).
+  
+  The `try` wrapped the WHOLE loop, not each removal. A `removeItem` that threw on key
+  `n` aborted the walk, so keys `n+1..end` were never swept, and the failure was
+  swallowed — `purgePreviousUserClientState()` returned normally and `SessionUserScope.adopt`
+  believed the sign-in purge had completed. This is an ALLOWLIST sweep precisely so the
+  next un-namespaced key — one nobody has written yet — cannot re-open the cross-user
+  pollution class #5664 fixed; a partial sweep is a partial allowlist, and which keys
+  survived depended on `Object.keys` iteration order rather than on anything bounded. The
+  previous user's org id, recents, favourites, or a `sessionStorage` metadata seed (their
+  permission-filtered app list, a cross-principal disclosure per objectui#5198) could all
+  land on the wrong side of the abort.
+  
+  `Object.keys(store)` — the reason a guard exists here at all — stays guarded on its
+  own; only the per-key guard is new, so one uncooperative key now costs exactly that key.
+  
+  Unlike `ActiveOrganizationStorage.clear()` (objectui#5731), a failed removal here is
+  NOT verified by read-back and NOT quarantined: `clear()` owns every future read of its
+  one key through `ActiveOrganizationStorage.get()`, so a "still readable" verdict and a
+  quarantine are what keep a failed `clear()` from handing the value straight back.
+  `sweepStore` walks keys it does not own reads for — another package's recents cache, a
+  metadata seed — so there is no `get()` here to guard and nothing to quarantine; adding
+  read-back verification for keys this function does not otherwise touch would be a
+  general storage-error-handling refactor of the module, which this card is scoped away
+  from. What IS mirrored is the reporting channel: a key whose `removeItem` throws is
+  named in a `console.warn`, the same channel `clear()` uses, so a partial sweep is
+  discoverable instead of silent. The caller (`SessionUserScope.adopt`, on the sign-in
+  path, inside an `AuthProvider` effect) still cannot act on the failure and must not
+  throw either.
+  
+  A working `localStorage`/`sessionStorage` behaves exactly as before: every
+  non-device-scoped key is removed, nothing is reported, and the device-scoped allowlist
+  (`auth-session-token`, `auth-session-user-id`, `vite-ui-theme`) is unaffected.
+- 36918bf: `switchOrganization` now re-resolves identity for the organization it just switched
+  to by its own explicit decision, instead of depending on an accidental
+  `TokenStorage` side effect to notice the switch (objectui#5750).
+  
+  `AuthProvider.switchOrganization` has never called `loadSession()` itself. Identity
+  re-resolved across a switch only because `POST /organization/set-active` happens to
+  return the SIGNED `token.signature` spelling in `set-auth-token`, which differs from
+  the UNSIGNED `session.token` spelling `getSession()` normally stores — so
+  `TokenStorage.set` reads the flip as a rotation and the objectui#4467 subscription
+  calls `loadSession()` for it (measured and pinned in objectui#5749/#5719). That
+  signed spelling is deterministic on the raw session token, not on the organization:
+  two switches with no `get-session` landing in between produce the identical signed
+  value, so the SECOND `TokenStorage.set` sees no change, never notifies, and identity
+  is left answering for whichever organization the FIRST switch targeted even though
+  `activeOrganization` already reads as the new one.
+  
+  Reachable in the console via `OrganizationLayout`'s slug-driven effect (the "Manage"
+  link on an org card, plus its own "Back to organizations" button) — ordinary
+  client-side navigation with no full-page reload and nothing debouncing repeat
+  switches. `WorkspaceSwitcher` and `OrganizationsPage`'s own card click were not
+  reachable paths for this: both force `window.location.href` immediately after a
+  successful switch, and the resulting fresh `AuthProvider` mount always performs an
+  authoritative `loadSession()` regardless of how the race above resolved.
+  
+  `switchOrganization` now tracks the organization it last resolved to itself and
+  re-resolves explicitly whenever a switch's target differs from that, while
+  suppressing the (now redundant) rotation notification for its own `set-active`
+  call — so the common single-switch path still spends exactly one `get-session`, not
+  two. A generation guard discards a still-in-flight, now-superseded switch's answer
+  rather than let it clobber a later switch's fresher one.
+- 934a532: Document the `X-Tenant-ID` edge contract that `createAuthenticatedFetch` stamps, and the
+  unstamped-first-request window in which it is not sent (objectui#5279). Documentation
+  only — no behaviour changes.
+  
+  The header had no written contract anywhere, and the shape of the missing information was
+  actively misleading: its only non-CORS consumer lives in the **cloud** repository, so a
+  search confined to this repo and the framework (`objectstack`) returns zero readers and
+  reads as "nothing consumes this stamp". #5279 was filed on exactly that reading, and was
+  held until a cloud-side reading came back non-empty. Without the contract written down,
+  the next person to grep reaches the same false conclusion and deletes a live routing
+  input.
+  
+  `packages/auth/README.md` gains "The `X-Tenant-ID` edge contract": what the header means
+  (a routing hint carrying the better-auth `activeOrganizationId` — not an identity claim,
+  not an authorization input, not what scopes rows), who stamps it and under exactly which
+  condition, who reads it, and what a reader may and may not assume. The framework half is
+  stated as a negative with its pin — `resolveAuthzContext` takes `tenantId` from the
+  API-key principal or `session.activeOrganizationId` and from no header — alongside
+  `plugin-sharing`'s record that trusting `x-tenant-id` as identity *was* a vulnerability.
+  The configuration half is quoted from the contract this package can actually resolve,
+  `TenantRoutingConfigSchema` in `@objectstack/spec/cloud`, where `X-Tenant-ID` is the
+  default of a configurable `tenantHeaderName` and `header` ranks second of six
+  identification sources behind `subdomain`.
+  
+  The unstamped-first-request gap gets its own section: `ActiveOrganizationStorage` is
+  filled only after `AuthProvider`'s async `getSession` -> `listOrganizations` ->
+  `getActiveOrganization` chain resolves, so early-boot requests carry no tenant header at
+  all. What a reader observes is documented as **absent, never present-and-empty**, with the
+  five situations that open the window and the instruction to fall through to the next
+  identification source rather than fail closed. The gap is recorded, deliberately not
+  closed: the cloud readers observe today's behaviour, so changing when the header first
+  appears is its own decision.
+  
+  Three cases in `createAuthenticatedFetch.test.tsx` pin the statements the prose makes
+  about the wire — no active organization means no header at all, the stamp is not gated on
+  `/api/` the way `Authorization` is, and the active organization overwrites a caller-set
+  `X-Tenant-ID` — so the documentation cannot drift away from the behaviour unnoticed.
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [69a2163]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [e4559d1]
+- Updated dependencies [6f81384]
+- Updated dependencies [dddb942]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [d7acad6]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [100547e]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [0e05aac]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [199d31b]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [515f171]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [3c73d99]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/types@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/auth/package.json b/packages/auth/package.json
index 195443c692..332bff4412 100644
--- a/packages/auth/package.json
+++ b/packages/auth/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/auth",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Authentication system for Object UI with AuthProvider, useAuth hook, AuthGuard, and form components.",
diff --git a/packages/cli/CHANGELOG.md b/packages/cli/CHANGELOG.md
index f54db40eeb..fecc80cc08 100644
--- a/packages/cli/CHANGELOG.md
+++ b/packages/cli/CHANGELOG.md
@@ -1,5 +1,276 @@
 # @object-ui/cli
 
+## 17.7.0
+
+### Minor Changes
+
+- 7dc08a3: `objectui check` recognises a schema by validating it, and reports broken ObjectUI files instead of filing them as foreign ones.
+  
+  A file with a root `type` was judged only when its root carried an ObjectUI
+  structural key (`children`, `body`, `className`, …). Leaf schemas carry only
+  their own vocabulary, so nothing checked them: measured on this repository, 475
+  files were eligible, 166 were judged and 309 were skipped.
+  
+  The command now has a second recogniser arm — the document validates as an
+  ObjectUI component schema under `@object-ui/types`' own Zod union — which the
+  maintainer's 2026-08-25 ruling selected over shipping a JSON Schema artifact to
+  point a `$schema` URL at. It admits 209 of those 309 files. The structural arm
+  still runs first, so recognition costs nothing for files that already had a
+  marker, and `package.json` is still never judged: `"type": "module"` names no
+  component the protocol models.
+  
+  Validity alone would have answered two different questions with one word.
+  A broken ObjectUI schema fails validation exactly as a foreign file does, so a
+  two-bucket report would have filed it as "not ObjectUI" — and the symptom of
+  that is an absence: the file simply stops being mentioned. Measured, that bucket
+  is not empty: 54 files land in it and 53 of them are real corpus content.
+  
+  So files the recogniser refuses are split. When the root `type` names a
+  component this build registers, the file is **listed by name** as ObjectUI
+  content that did not validate, pointing at `objectui validate <file>` for the
+  reason — either the document is off-spec or its component type is not modelled
+  by `@object-ui/types`. Everything else is counted as skipped, as before. The
+  printed explanation now describes both arms, and only unreadable JSON still
+  makes the command exit non-zero.
+- 94021dd: `objectui check` judges a file's `type` only when the file is recognisable as an ObjectUI schema, and reports how many it declined to judge.
+  
+  A root `type` was treated as a component key wherever it appeared. `type` heads at
+  least seven unrelated JSON vocabularies, and the most common of them is
+  `package.json`'s `"type": "module"` — so the first line a user saw running
+  `objectui check` in their own project was a warning about their own package
+  manifest. Measured at this repository's root: 46 warnings, 45 of them
+  `package.json` (objectui#5127).
+  
+  A file now enters type judgement only when its root carries a structural key
+  declared on `BaseSchema` — `children`, `body`, `className`, `placeholder`,
+  `style`, the `visible`/`hidden`/`disabled` predicate family, `testId`,
+  `ariaLabel`. Every other root-`type` vocabulary — JSON Schema's `"array"`, an
+  `.eslintrc.json`'s `"commonjs"`, a package manifest's `"module"` — is simply
+  never judged. The key set is read out of the node contract rather than invented,
+  and it is closed: it grows only when `BaseSchema` grows.
+  
+  A list of filenames to exclude was the alternative and was rejected: it is a
+  second hand-maintained list of the shape objectui#5115 had just finished
+  deleting, and it can only ever enumerate the foreign vocabularies someone already
+  thought of. This is a positive marker instead.
+  
+  Because the marker narrows what is checked, the command now also reports the
+  count of files that had a root `type` and no marker, together with the marker
+  keys that opt one back in. That number is the coverage this gate gives up until
+  schema files are recognisable, and printing it is what keeps the loss visible
+  rather than silent. The `.yaml`/`.yml` half of the scan is unchanged — it was
+  never type-judged, before this change or after it. Exit codes are untouched: a
+  JSON parse failure remains the only thing that fails the run.
+  
+  No public `$schema` URL is introduced. An earlier revision also admitted a file
+  whose root `$schema` had an `objectui.org` host; the maintainer ruled against
+  minting that identifier (2026-08-20, objectui#5127), so the structural key is the
+  only marker. Because the matching was host-based rather than literal, that arm
+  can be added later without invalidating a single file.
+
+### Patch Changes
+
+- 05474af: Fix `objectui check` scanning build output because its ignore list only excluded a
+  root-level `dist/` / `node_modules/` (objectui#6320).
+  
+  `packages/cli/src/commands/check.ts` passed `ignore: ['node_modules/**', 'dist/**',
+  '.git/**']` to `globSync`. `glob` matches `ignore` patterns against the path relative to
+  `cwd`, so an unanchored `dist/**` / `node_modules/**` excludes only a directory of that
+  name at the scan root — every nested `packages/<name>/dist/`, `examples/<name>/dist/`,
+  `apps/<name>/dist/` (and their `node_modules/`) was still scanned. In a built workspace
+  this means `objectui check` re-reads the author's own schemas a second time from build
+  output, roughly doubling every count it reports (measured on this repository: 617 → 1047
+  files globbed after a full build) with nothing in the output explaining why.
+  
+  The ignore patterns are now anchored at every depth (`'**/dist/**'`, `'**/node_modules/**'`),
+  matching the fix's stated intent: exclude build output and installed dependencies wherever
+  they live, not only at the project root. A root-level `dist/` / `node_modules/` remains
+  excluded, unchanged.
+  
+  Confirmed before widening: no example, template, or docs fixture in this repository
+  authors a schema under a directory literally named `dist` — the widened pattern excludes
+  only generated content.
+- 854222c: `@object-ui/plugin-report` now registers its three components under namespace
+  **`plugin-report`**, the spelling its consumers already declare (objectui#6416).
+  
+  It used to register `report`, `spec-report` and `report-viewer` under namespace
+  `report`, while `apps/console` declared the lazy stubs for the same three short
+  names under `plugin-report` and the CLI's known-type whitelist shipped the
+  `plugin-report:*` spellings as renderable. Two things followed from the
+  disagreement:
+  
+  - **`plugin-report:report`, `plugin-report:report-viewer` and
+    `plugin-report:spec-report` could never be satisfied.** `Registry.register`
+    clears the lazy stub for the type IT registers, and that type was
+    `report:report`, so those three stubs were never cleared and no component was
+    ever stored under them: `get('report', 'plugin-report')` returned `undefined`
+    and `hasLazy('report', 'plugin-report')` stayed `true` forever. A schema
+    authored with any of the three whitelisted keys resolved to nothing — the
+    gate handed authors a green light for a key the runtime could not satisfy.
+  - **The bare `report` key was claimed twice under two different namespaces.**
+    `Registry.register` and `Registry.registerLazy` share the
+    `meta?.namespace && !meta?.skipFallback` branch, so what bare `report`
+    *declared* depended on whether the plugin chunk had loaded yet — the
+    objectui#6353 shape.
+  
+  **No authored metadata changes.** The direction was chosen by measurement:
+  nothing in this repository, and nothing in the sibling `objectstack` checkout,
+  authors a `report:*` spelling (0 hits), while the bare spellings are authored in
+  48 places. `type: 'report'`, `type: 'spec-report'` and `type: 'report-viewer'`
+  resolve exactly as before; the three unreachable `report:*` keys are retired and
+  the three `plugin-report:*` keys now name real components for the first time.
+  
+  `packages/cli/src/utils/known-schema-types.ts` is regenerated from the
+  registrations, dropping `report:report`, `report:report-viewer` and
+  `report:spec-report`.
+  
+  Two pins are the half that outlives the fix:
+  `packages/plugin-report/src/__tests__/report-bare-key-ownership.test.ts` replays
+  this package's real declared metadata and a console-shaped lazy stub into a
+  fresh `Registry` in **both** registration orders, checking the bare key's
+  declared namespace after every step, so order- and phase-independence are
+  properties under test rather than properties of the file the test imports.
+  `scripts/__tests__/report-namespace-agreement-6416.test.ts` re-derives both
+  sites from source and fails if the plugin, the console stubs and the generated
+  whitelist ever disagree again.
+- 100547e: `objectui validate` now refuses a form field whose widget id names a namespace
+  other than `field:`, matching the verdict `@object-ui/core`'s `validateSchema`
+  has given since objectui#5375 (objectui#5449).
+  
+  The CLI reaches `FormFieldSchema` through `safeValidateSchema`, and that schema
+  declared `type` and `widget` as bare optional strings — so a field typed
+  `ui:password` validated clean while the runtime validator rejected the same
+  document with `UNRESOLVABLE_FIELD_WIDGET_NAMESPACE`. The CLI is the surface an
+  author actually runs before shipping, so it was the one handing out the false
+  green: an author did exactly the diligence objectui#5375 asks for and still
+  shipped metadata that renders a secret into a plain text box.
+  
+  A `superRefine` on `FormFieldSchema` now states the rule, mirroring core's
+  precedence (`widget` before `type`), the key it blames, its error code and its
+  message verbatim, so the two entry points cannot describe one defect two ways.
+  
+  **This rejects documents that previously validated.** Only colon-qualified
+  field widget ids outside the `field:` namespace are affected — `field:`-prefixed
+  ids and bare names such as `password` still pass, registered or not. A field
+  carrying, say, `type: 'ui:password'` must be rewritten as `password` or
+  `field:password`; it never rendered as a password box in any case.
+  
+  Which of the repo's authoring-time validators is canonical remains open
+  (objectui#4631) — this states the rule on the zod side rather than unifying
+  them.
+- d91aed9: Name the case-only spelling when a component type misses the registry.
+  
+  Registry lookup is exactly case-sensitive, so a node typed `Page` misses a registered `page` and falls through to the OBJUI-001 "Unknown component type" panel. Because the mistake is usually uniform across a document, the symptom is not one broken widget — it is the whole page rendering as error panels, with nothing in the message pointing at the cause.
+  
+  Both surfaces that report the miss now name the spelling that would have resolved. `SchemaRenderer`'s panel reads `Unknown component type: Page — did you mean 'page'?`, and `objectui check` reports `Unknown schema type "Page" in <file> — did you mean "page"?`. When no known type differs by case alone, neither says anything extra — `zzz` gains no bogus suggestion, and this is case matching, not an edit distance, so `pge` suggests nothing either.
+  
+  **Lookup itself does not change.** `Page` still misses, still fails, and still renders the panel; only the message teaches. Normalising the lookup was considered and rejected (objectui#5247, maintainer ruling 2026-08-19): it would make two spellings valid everywhere, permanently, and legalise the typo class (`PAGE`, `pAge`) along with the PascalCase convention.
+  
+  Each surface reads its candidates from the set it can actually trust — the renderer from the live `ComponentRegistry` (including pending lazy stubs), the CLI from the registration-derived `KNOWN_SCHEMA_TYPES` snapshot — so neither can suggest a type nothing registers.
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [194fae1]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [3c76801]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [2c8474c]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [c86185e]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/types@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Patch Changes
diff --git a/packages/cli/package.json b/packages/cli/package.json
index 0ff445a08b..bf53a792e7 100644
--- a/packages/cli/package.json
+++ b/packages/cli/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/cli",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "description": "Standalone CLI for Object UI — scaffold, develop, build and validate JSON/YAML schema-driven applications.",
   "type": "module",
   "homepage": "https://www.objectui.org/docs/utilities/cli",
diff --git a/packages/collaboration/CHANGELOG.md b/packages/collaboration/CHANGELOG.md
index 85e1e442d7..9eeb883c6c 100644
--- a/packages/collaboration/CHANGELOG.md
+++ b/packages/collaboration/CHANGELOG.md
@@ -1,5 +1,87 @@
 # @object-ui/collaboration
 
+## 17.7.0
+
+### Patch Changes
+
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [594704f]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [69a2163]
+- Updated dependencies [8d3a529]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [6f81384]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [b362c1b]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [d7acad6]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [199d31b]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [20e317c]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [515f171]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [38a9568]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [3c73d99]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+
 ## 17.6.0
 
 ### Patch Changes
diff --git a/packages/collaboration/package.json b/packages/collaboration/package.json
index cacb880aff..8e8ded0c2a 100644
--- a/packages/collaboration/package.json
+++ b/packages/collaboration/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/collaboration",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Real-time collaboration for Object UI with presence tracking, live cursors, conflict resolution, and comment threads.",
diff --git a/packages/components/CHANGELOG.md b/packages/components/CHANGELOG.md
index d8a3eadc68..d9d0a3f563 100644
--- a/packages/components/CHANGELOG.md
+++ b/packages/components/CHANGELOG.md
@@ -1,5 +1,1492 @@
 # @object-ui/components
 
+## 17.7.0
+
+### Minor Changes
+
+- d2fb6ef: **BREAKING (authoring): `ui:icon` names its glyph with `icon`, not `name`**
+  
+  `{ "type": "icon", "name": "check" }` no longer renders an icon. Write
+  `{ "type": "icon", "icon": "check" }`. Stored metadata authored before this
+  release needs converting — see the migration below.
+  
+  Marked `minor` per AGENTS.md §版本号策略 (this repo never publishes `major`
+  outside an `@objectstack` major sync); the break is real and is stated here.
+  
+  **Why**
+  
+  `name` is the SDUI identity key every authored node carries, alongside `id` —
+  it is not `ui:icon`'s private prop. So an ordinary node like
+  `{ type: 'icon', id: 'save_icon', name: 'save_icon' }` asked lucide for a glyph
+  called `SaveIcon`, missed, and rendered **nothing at all**: silent to a human,
+  and clean to a DOM gate, because a renderer that renders nothing spreads no
+  attributes to find. `action:*` already reads `icon`, so this is the vocabulary's
+  existing answer, and it leaves no node type on which the identity key is
+  unusable.
+  
+  **What changed**
+  
+  - `IconSchema` (types + its zod mirror) declares `icon: string` **required**,
+    exactly as `name` was required before it — a key rename at constant
+    strictness. `name` reverts to the optional identity inherited from
+    `BaseSchema`. The mirror previously *required* `name`, which is why the
+    renderer could not be migrated on its own: the published contract refused the
+    correct shape.
+  - `ui:icon` resolves its glyph from `schema.icon`. There is deliberately **no**
+    `icon ?? name` fallback: a key meaning "identity" or "glyph" depending on
+    whether a lucide lookup happened to hit is the ambiguity being removed.
+  - The registry's `inputs` entry and `content/docs/components/basic/icon.mdx`
+    moved in the same change as the resolver.
+  - All 98 authored icon nodes in this repo are converted.
+  
+  **The break is loud in three places, never silent**
+  
+  1. `IconSchema` **refuses** a legacy node, with a message that names the rename
+     and points at the converter — not zod's default `expected string, received
+     undefined`.
+  2. A legacy node that reaches the renderer unvalidated draws the visible
+     placeholder shipped in the previous release, and its `console.warn` now
+     carries the exact rename (`icon: "save_icon"`) plus the converter's name.
+     Its accessible name says so too, and it gains a
+     `data-objectui-icon-legacy-name-key` marker so a gate can tell
+     "unmigrated node" from "glyph that does not resolve".
+  3. **Migration for stored metadata** — `migrateIconNodeKeys` from
+     `@object-ui/types`:
+  
+     ```ts
+     import { migrateIconNodeKeys } from '@object-ui/types';
+  
+     const { document, converted, warnings } = migrateIconNodeKeys(storedPage);
+     if (warnings.length) console.warn(warnings.map((w) => w.message).join('\n'));
+     if (document !== storedPage) await save(document);
+     ```
+  
+     It walks the whole document and lifts `name` to `icon` on every icon node.
+     It is a one-shot conversion a deployer runs over stored documents — **not** a
+     read-path fallback; nothing calls it during rendering or parsing. It
+     **reports rather than guesses** for the two cases it will not touch: a node
+     already declaring both keys (`icon` wins, `name` stays the identity it is),
+     and a node naming no glyph at all.
+- 7cd3987: `ui:icon`: an unresolvable glyph now renders a visible placeholder instead of nothing
+  
+  An icon whose name does not resolve to a lucide glyph used to `return null`.
+  That failed silently in two independent ways at once: invisible to a human (no
+  gap, no error boundary — just an absent glyph), and clean-looking to a gate (a
+  renderer that returns `null` spreads no attributes, so a DOM scan of it reports
+  no findings).
+  
+  It now renders a dashed-square placeholder on the same SVG host, keeping the
+  authored `className`, `size` and colour so the gap sits exactly where the icon
+  would have been, with `role="img"`, an accessible name identifying the icon
+  that failed, and a `data-objectui-icon-unresolved` marker. The `console.warn`
+  stays and now names the cause.
+  
+  Also fixed: a node with no `name` at all reached `toPascalCase(undefined)` and
+  threw, which the error boundary then swallowed — a third silent failure. It
+  renders the placeholder too.
+  
+  Not included: `ui:icon` still reads the SDUI identity key `name` as its glyph
+  name. Moving it to `schema.icon` is ruled but blocked on an authored-metadata
+  migration — see objectui#5631.
+- f8cdbf2: Route a `data-table`'s `emptyAction` node through `SchemaRenderer`, so a `visibleWhen`
+  authored on it is actually evaluated (objectui#5926 gap 1).
+  
+  `visibleWhen` is not a per-block concern in this platform. It is enforced **once,
+  generically**, in `packages/react/src/SchemaRenderer.tsx`: `shouldHide` tests `visibleWhen`
+  ahead of the hoisted `visible` (objectui#5454), sets `_hidden`, and the `_hidden` early
+  return fires **before** the registry dispatches. A block renderer cannot ignore the gate,
+  because it never sees the node.
+  
+  `emptyAction` was the one authored-node exception in the tree. The empty-state CTA slot
+  resolved the registry **directly** — `ComponentRegistry.get(node.type)` — and mounted the
+  result itself, so the node never passed through `SchemaRenderer` and its `visibleWhen` was
+  **never evaluated**. `@objectstack/spec` accepts the key (`SchemaNodeSchema` carries
+  `visibleWhen`, and `data-display.zod.ts` types `emptyAction` as a `SchemaNode`), so an
+  author wrote a gate, the platform took it, and nothing enforced it — declared-not-enforced,
+  the same class objectui#5401 / #5505 closed for `record:alert`, one level down.
+  
+  Measured on the branch point, mounting a `data-table` with no rows so the empty state is
+  actually reached: an `emptyAction` carrying
+  `visibleWhen: { dialect: 'cel', source: 'features.can_create == true' }` under an ambient
+  scope of `features.can_create = false` **rendered**, and so did the bare-string spelling of
+  the same predicate. Both now render nothing. The three must-show cases were pinned in the
+  same file and were green before and after — an `emptyAction` whose predicate resolves
+  **true**, one declaring **no** `visibleWhen`, and one whose predicate names an unbound root
+  (the central gate fails soft to visible, and this slot now gives the same answer as every
+  other node rather than a private one).
+  
+  The fix is a **route**, not a new check: no `visibleWhen` test was added to `data-table.tsx`.
+  A local check on this slot would have been a fourth evaluator, which is the drift
+  `page:tabs`' item-level predicate already records on this card. The slot now mounts its
+  authored node exactly the way the `empty` renderer's `action` slot always has.
+  
+  **Behaviour change worth declaring, beyond the gate itself.** No declaration moves and no
+  new key is accepted, but two host-observable answers change on this slot:
+  
+  - An `emptyAction` whose `visibleWhen` resolves false stops rendering. That is the fix.
+  - An `emptyAction` whose `type` is missing or names an unregistered component now gets the
+    platform's uniform "unknown component type" report instead of rendering as silent
+    nothing. Malformed metadata gets one answer across the tree rather than a private one
+    here — but a page that shipped a typo'd `emptyAction` type went from invisible to visibly
+    reported.
+- 6fd2cf7: `radio-group` now renders the `orientation` its own type has always declared (objectui#6158).
+  
+  `RadioGroupSchema.orientation` was declared in two layers and read by none. The shipped TS
+  type carries `orientation?: 'horizontal' | 'vertical'` with `@default 'vertical'`
+  (`packages/types/src/form.ts:383`) and the zod mirror carries the matching
+  `z.enum(['horizontal', 'vertical'])` (`packages/types/src/zod/form.zod.ts:282`), while
+  `packages/components/src/renderers/form/radio-group.tsx` contained neither the string
+  `orientation` nor `direction` and forwarded only `defaultValue`, `className`, the
+  form-control DOM whitelist and the designer props.
+  
+  The consequence was measurable rather than cosmetic: every radiogroup root the library
+  rendered came back byte-identical on that axis — no `data-orientation`, no
+  `aria-orientation` — so the docs page's `## Layout Options` section demonstrated a
+  distinction the product could not make, and its horizontal demo rendered vertically. An
+  author reading the shipped type had every reason to write `orientation: 'horizontal'` and
+  no way to discover it was inert.
+  
+  The key is now forwarded to the underlying Radix `RadioGroup`, which accepts it natively
+  with the same two-value vocabulary and puts it on the root as `aria-orientation` and
+  `data-orientation`; the layout utilities follow it so the visible difference the docs
+  promise is real. This restores declared = enforced **without widening the acceptance
+  set** — no new key is accepted, and no spelling outside the declared enum becomes legal.
+  
+  Two behaviour notes for anyone already shipping radio groups:
+  
+  - The declared `@default 'vertical'` is now actually applied instead of being left to
+    Radix's own `undefined`. A group that never authored the key keeps the vertical stack it
+    already rendered, and additionally announces `aria-orientation="vertical"` — the
+    announced orientation now agrees with the rendered one rather than being absent. Arrow
+    key roving focus narrows to Up/Down for those groups, which is the correct pairing for a
+    vertical stack.
+  - Author `className` still wins: the orientation layout utilities compose first and the
+    authored class last, so tailwind-merge resolves every conflict in the author's favour.
+  
+  Registry meta `inputs` for `radio-group` gains `orientation` in the same change — it was
+  the third surface that omitted the key, and leaving it out would have kept the designer
+  palette disagreeing with the type.
+- c71e14d: **The unresolvable-visibility-predicate report now names the roots of the tier the
+  predicate was actually evaluated against** (objectui#6487). An app-shell author
+  whose nav, area or field `visible` faulted was told to check `record` and
+  `page.<var>` — two roots that tier does not bind at all.
+  
+  `formatUnresolvableVisibilityMessage` and `reportUnresolvableVisibilityPredicate`
+  (both exported from `@object-ui/react`) take a new **optional sixth argument**, a
+  `PredicateScopeTier` — also exported — selecting the closing advice paragraph.
+  Everything above that paragraph is unchanged on every surface, and so is every
+  verdict: this is diagnostics copy only.
+  
+  **The published signature grew; nothing existing breaks.** The argument defaults
+  to `'page-component'`, so a five-argument call keeps printing the bytes it
+  printed before. All three in-repo call sites pass their tier explicitly rather
+  than lean on that default.
+  
+  Each tier's root set was derived from the code that builds the bag, not from the
+  prose that described it:
+  
+  - **`'page-component'`** — `SchemaRenderer`'s node gate and `page:tabs` item
+    predicates. Both bind `record`, `current_user` and `page.<var>` (the roots
+    `@objectstack/spec`'s `ui/page.zod.ts` declares for the tier). Its paragraph is
+    byte-for-byte what it was.
+  - **`'app-shell'`** — the chrome gate `ExpressionProvider.evaluateVisibility`
+    runs, wired onto this reporter by objectui#6443. Its evaluator is built from
+    `{ current_user, user, ctx: { user }, os: { user }, app, data, features }`, so
+    the line now names `current_user` with its three ADR-0068 alias spellings,
+    `app`, and `features` — the deployment-flag root that provider documents for
+    exactly this kind of predicate — and states outright that `record` and
+    `page.<var>` do not exist there.
+  
+  **Why not generalise the copy instead.** Dropping the concrete root names would
+  have made one paragraph true everywhere at the cost of making it useful nowhere:
+  an author who mistyped a root needs to know which roots exist *at their tier*,
+  which is the whole reason the paragraph is read.
+  
+  `data` is bound at the app-shell tier but is deliberately not advertised there —
+  every mount of `ExpressionProvider` in this repo passes `data={{}}` or omits it,
+  so naming it would point an author at a root that answers nothing.
+- dd19463: `stack` now reads its spacing from `gap` and nothing else — the undeclared
+  `spacing` key it also accepted is gone (objectui#4890).
+  
+  `StackSchema extends Omit<FlexSchema, 'type'>`, whose spacing key is `gap`.
+  `spacing` was declared by nothing: not the TypeScript interface, not the zod
+  mirror, not the renderer's own `inputs` registration. `stack.tsx` read it anyway,
+  as `schema.gap ?? (schema as any).spacing ?? 2` — and the `as any` is the whole
+  story, since it existed to get past the type system saying the key was not there.
+  A lenient consumer leg does not stay in the consumer: it becomes a second
+  de-facto contract that producers write to, and 135 nodes across 39 files of the
+  shipped schema catalog did exactly that. Every one of them rendered correctly, so
+  nothing ever pointed at it, while the examples went on teaching the key to every
+  author who copied them.
+  
+  The trap it was one edit away from springing: `flex` — semantically a `stack`
+  with a `direction` — never read `spacing`, so re-typing any of those nodes would
+  have dropped the spacing to the default silently. Fixed at the producer
+  (AGENTS.md #0.1): those nodes now author `gap`, carrying the same value, and the
+  alias is deleted rather than legalised into `StackSchema`, where it would only
+  have been a second name for `gap`.
+  
+  **If you author `spacing` on a `stack`**, rename it to `gap`; the value and the
+  rendering are unchanged. A `stack` still carrying `spacing` now renders the
+  default gap, exactly as a `flex` always did.
+  
+  Also in the same sweep, and visible only in the published example catalog rather
+  than in any package API: 140 catalog nodes that were already `flex` / `stack` /
+  `container` stopped hand-writing their own declared props in `className`
+  (`items-center` → `align`, `justify-between` → `justify`, `gap-2` → `gap`,
+  `flex-wrap` → `wrap`, `p-4` → a container's `padding`) — 231 tokens in all
+  (objectui#4891). Breakpoint-prefixed overrides and everything decorative stay in
+  `className`, because the props are not responsive. Both facts are ratcheted in
+  `examples/schema-catalog/test/layout-props-conversion.test.tsx`.
+- e719ebd: `data-table` reads the declared `header`; the producers translate `label` into it.
+  
+  `TableColumn` declares `header: string` and does not declare `label`. The
+  renderer's column normalization nonetheless read `header: col.header || col.label`,
+  so the same key had one spelling the type admits and one only the runtime did.
+  That alias is gone (objectui#5351), and the translation it used to perform happens
+  once at each producer instead: metadata vocabulary in, adapter vocabulary out.
+  
+  **This narrows what `data-table` accepts, so read this if you author `data-table`
+  nodes by hand.** A column spelled `{ label: 'Stage', accessorKey: 'stage' }` on a
+  directly authored `data-table` now renders a **headerless** column over live
+  cells. Spell it `header` — the key `TableColumn` has always declared. Columns
+  reaching `data-table` through `object-data-table`, `object-grid` or a related
+  list are unaffected: those producers resolve `header` for you from the spec's
+  `ListColumnSchema.label`, so every spelling they accepted before they still
+  accept.
+  
+  `@object-ui/core` gains `columnHeader()` alongside `columnIdentity()` — the reader
+  producers use to cross that boundary. It is adapter-first (`header` wins over
+  `label`), so an author who addressed the table directly is never overwritten.
+  
+  `object-data-table` also gains a fix from the same move: a column carrying a
+  `label` used to render a **blank** header there even while the alias existed,
+  because the widget's field-meta enrichment overwrote the authored `label` before
+  the adapter ever saw it. `{ field: 'stage', label: 'Stage' }` now renders "Stage".
+  
+  The sibling `accessorKey: col.accessorKey || col.name` alias is **unchanged** here
+  and still resolves. Retiring it is objectui#5120's remaining step, which is
+  gated on two published skill guides that teach that spelling.
+- fa429cf: The register-meta key `defaultChildren` is retired (objectui#5051).
+  
+  It was declared in four places, produced in eleven, and read in **none**. The designer's
+  drop path builds a new node from its twin key only — `PageDesigner.tsx`,
+  `props: paletteItem?.defaultProps ?? {}` — with no `children:` line, so a palette item
+  that declared `defaultChildren` dropped an **empty** node and the declared children never
+  materialised. Nothing rendered the wrong thing; an entire declaration surface was simply
+  inert, which is the declared-but-unenforced shape ADR-0049 targets. Per the maintainer
+  ruling of 2026-08-19, the key is removed rather than wired up; if designer
+  default-children UX is ever product-wanted it returns as its own designed card.
+  
+  **If you author plugins against the published register-meta table, drop the key.** It is
+  gone from `skills/objectui/guides/plugin-development.md`, which had been teaching it. A
+  meta that still declares it stays *valid*: `ComponentMetaSchema` is a plain `z.object`,
+  and measured on zod 4.4.3 that STRIPS unknown keys rather than rejecting them — so the
+  key is silently dropped from the parse output instead of failing validation. TypeScript
+  authors get the loud signal instead: all three `ComponentMeta` declarations
+  (`@object-ui/types` `base.ts` and `plugin-scope.ts`, `@object-ui/core` `Registry.ts`) no
+  longer offer it, so re-declaring it is now a compile error.
+  
+  **No runtime behaviour changes in either direction.** No code path read the key before
+  this change, and the eleven producers that set it (`sidebar.tsx` x10, `span.tsx`) were
+  feeding a reader that did not exist. Dropping a `span` or any of the ten sidebar types
+  into the designer produces exactly the node it produced yesterday.
+  
+  Two suites keep it retired, one per package: `packages/types` pins the zod twin (the key
+  is absent from the parse output, with a surviving sibling asserted present through the
+  same parse as the control) plus the two TS twins with `@ts-expect-error`, and
+  `packages/core` pins the registration surface the eleven producers were written against.
+  Both are compile-time-enforced through each package's chained `tsconfig.test.json`.
+- aefe428: **Behaviour change.** Form section and field `visibleWhen` predicates that silently failed
+  OPEN now actually evaluate — and a rule that resolves FALSE now hides the field
+  (objectui#6010).
+  
+  `current_user` was bound on two of the three `visibleWhen` surfaces and not the third. A
+  page component or app/nav gate got it (`ExpressionProvider` → `SchemaRenderer`), and a
+  per-option gate got it (`resolveCascadingOptions(…, predicateScope)`), but every
+  `resolveFieldRuleState` call in the form renderer passed `undefined` for the scope
+  argument, so a form SECTION or FIELD predicate saw `record` and `previous` and nothing
+  else. `'sales_manager' in current_user.positions` therefore named an **unbound root**
+  there, and the visibility fallback is fail-open — so the gate did not hide the field from
+  the people it named, it **showed the field to everyone**, with no signal beyond one
+  deduped `console.warn`.
+  
+  **What changes for you, in the direction that matters:** if you authored a form-field or
+  form-section `visibleWhen` naming `current_user`, saw the field render, and concluded the
+  rule was permissive — it was not permissive, it was broken, and it is now enforced. That
+  same field will now **hide** for every user the predicate resolves FALSE for. Audit any
+  `visibleWhen` on a form field or section that references `current_user` / `user` /
+  `ctx.user` / `os.user` before upgrading; a predicate that was quietly inert becomes live.
+  
+  Two things deliberately do **not** change:
+  
+  - **A genuinely unbound root still fails open.** A predicate the engine cannot evaluate at
+    all still logs one warning and leaves the element visible. Only *evaluated-and-false*
+    hides. `visibleWhen` remains presentation, not access control — use field-level security
+    or RLS to stop someone reading something.
+  - **The deprecated `visibleOn` alias** on a form field now binds the same scope, because
+    ADR-0089 D2 folds it into `visibleWhen` at parse; binding one scope for the canonical
+    spelling and another for its alias would have reproduced the same defect one spelling
+    over. The synthesised legacy `condition: { field, equals }` predicate is unaffected — it
+    is generated from a structured object and can only ever name `record.<field>`.
+  
+  This restores the contract both ADRs already declared: ADR-0068 D1 — *"a predicate authored
+  against any one form evaluates identically"* — and ADR-0089 D1 — *"runtime record surfaces
+  bind `record` + `current_user`"*. All five surfaces are now pinned against one authored
+  predicate text in
+  `packages/components/src/renderers/form/__tests__/predicate-scope-parity-6010.test.tsx`,
+  so the next divergence is loud instead of silent.
+- 3ccd9e8: Split the static `table` column type off the rich shared `TableColumn`
+  (objectui#5474, maintainer ruling 2026-08-22: Option C), so declared =
+  enforced holds per renderer.
+  
+  `TableColumn` is unchanged and remains the rich shape `data-table`,
+  `CRUDSchema` and detail-view relations honour. The static `table` renderer's
+  `TableSchema.columns` now declares the new narrow `StaticTableColumn`
+  (`header`, `accessorKey`, `className`, `cellClassName`, `width` — exactly the
+  keys that renderer reads). The eleven keys the static renderer never read are
+  retired from its surface as ADR-0049 tombstones: `hoverable` / `striped` on
+  `TableSchema`, and `minWidth` / `align` / `fixed` / `type` / `sortable` /
+  `filterable` / `resizable` / `editable` / `cell` on its columns.
+  
+  Breaking for authored metadata that wrote those keys on a `type: 'table'`
+  node: they were silently inert before and are now refused loudly — a tsc
+  error on the interface (`?: never`) and a parse rejection naming the key in
+  `@object-ui/types/zod`. That loud refusal is the ruled outcome. Migration:
+  nodes that wanted the interactive behaviour move to `type: 'data-table'`
+  (whose columns keep the rich `TableColumn`); right-aligned columns on the
+  static table use `cellClassName: 'text-right'`; alternate-row styling uses
+  Tailwind on `className`.
+- 72ffc34: Retire `ActionParamDialog`: the `custom` barrel's second action-param dialog is
+  removed, and the app-shell dialog is recorded as the surviving implementation
+  (objectui#5685, maintainer ruling of 2026-08-22).
+  
+  **Breaking for any out-of-repo host that imported it** (declared `minor` per the
+  repo's version-alignment rule — the major tracks `@objectstack`, never an
+  API-break count): `@object-ui/components` no longer exports `ActionParamDialog`
+  or `ActionParamDialogProps`. Measured at the branch point, the export had zero
+  production consumers — its only in-repo importers were its own five test files,
+  which retire with it, and no other repository in the organization imports the
+  symbol from this package.
+  
+  This file was the repo's SECOND implementation of the action-param surface, and
+  its audit trail is the reason it retires instead of being maintained: the last
+  close look (objectui#4758) found per-option `visibleWhen` not evaluated at all,
+  and the five hardcoded English strings this card originally recorded were the
+  next drift installment. A dormant second dialect of a governed surface is one
+  production import away from being live; removing it removes the whole drift
+  class.
+  
+  FROM → TO for an out-of-repo host:
+  
+  - `import { ActionParamDialog } from '@object-ui/components'` — no drop-in
+    replacement is published. The surviving implementation is
+    `@object-ui/app-shell`'s `ActionParamDialog` (`src/views/ActionParamDialog.tsx`),
+    rendered by app-shell's action runtime (`useConsoleActionRuntime`,
+    `RecordDetailView`) rather than exported standalone. A host that needs its own
+    param form builds on `@object-ui/fields`' shared field widgets
+    (`resolveFormWidgetType` / `getLazyFieldWidget`, ADR-0059) — the same seam the
+    surviving dialog renders through.
+  
+  The unreleased objectui#4758 changeset for this component (`select` options
+  through the shared option evaluator) is withdrawn in the same change: the
+  component retires before that fix ever ships, so the release notes carry the
+  removal rather than new behaviour of a surface this release does not contain.
+- 91783c4: Three more secret-field spellings no longer render a secret in clear text on the form's unregistered-widget branch.
+  
+  Measured on `main` at `f2e11ae6f`, the real `form` renderer on the built-in path
+  (no `registerAllFields()`), before and after objectui#5322's fix:
+  
+  ```
+  type            registry hit   rendered type
+  ui:password     true           text
+  secret          false          text
+  field:secret    false          text
+  ```
+  
+  Two halves, per the maintainer ruling of 2026-08-20:
+  
+  - **`@object-ui/core` — an unresolvable namespaced widget id is now an authoring
+    ERROR.** A form field's widget id (`widget`, else `type`) may name the
+    `field:` namespace or a bare name; any other namespace resolves no field
+    widget (objectui#5254) and used to degrade silently to a plain text box.
+    `validateSchema` now reports `UNRESOLVABLE_FIELD_WIDGET_NAMESPACE` and
+    `assertValidSchema` throws. Behaviour change: a schema that previously
+    validated with e.g. `type: 'ui:password'` is now invalid — inventing a
+    plausible-looking widget id fails loudly instead of rendering clear text.
+    `field:` ids stay valid whether or not the widget is registered, since
+    registration is a runtime fact an authoring-time validator cannot see.
+  - **`@object-ui/components` — the known secret types cover the remaining
+    spellings.** Bare `secret` and `ui:password` render the native masked input,
+    and `field:secret` is refused outright like `field:password`. Existing authors
+    need no migration.
+  
+  `ui:password` **is** registered — as an SDUI node renderer for a top-level
+  `{ type: 'email' }`-style node — so an author who checked whether it resolved
+  got a yes and still got a clear-text box on the field path. No producer emits
+  any of the three; all are reachable only through a hand-authored standalone
+  form schema, which is exactly the surface where the author is the producer and
+  no normalizer sits in between.
+- 490f482: The static `table` renderer reads only the declared `TableColumn` contract, and its published reference page teaches that spelling.
+  
+  `renderers/complex/table.tsx` resolved a heading as `col.header || col.label` and a
+  cell as `row[col.accessorKey || col.name]`. Neither `label` nor `name` is declared
+  on `TableColumn`, which declares `header` and `accessorKey` — both required
+  (`packages/types/src/data-display.ts`). This was the fourth site of the
+  column-alias family, after `data-table`, `ObjectDataTable` and `ObjectGrid`
+  (objectui#5350).
+  
+  Both aliases are retired. The ruling recorded on objectui#5120 (2026-08-20) is the
+  family direction — *retire the consumer-side alias; unify the producers* — and it
+  names this site: the declared `header`/`accessorKey` contract wins.
+  
+  What makes this site different from its three siblings is that the alias was not
+  merely tolerated, it was **published**. `content/docs/api/schema-reference.md`
+  §TableSchema shipped a copyable `{ "name": "id", "label": "#" }` example and a
+  property row reading *"Column definitions with `name`, `label`, …"*, while
+  `packages/types` declared the opposite pair. Docs and type disagreed about one
+  type they both call `TableColumn`, each internally consistent. Retiring the alias
+  without correcting the page would have turned a documented, working example into a
+  silently broken one, so both halves land together: the page now authors
+  `accessorKey`/`header`. The same row also advertised a `render` property that
+  `TableColumn` has never declared — the renderer's hook is `cell` — and that claim
+  is dropped rather than re-spelled.
+  
+  The failure mode of a now-unresolvable column is worth stating, because it is
+  quiet: the column keeps its slot and its neighbours are unaffected, the header or
+  the cells simply render empty, and nothing throws. This renderer keys its cells by
+  index rather than by accessor, so unlike `data-table` it does not even produce
+  React's generic missing-key warning — a retired-spelling column is fully silent.
+  Whether that silence should become an authoring diagnostic is objectui#5349's
+  question; no diagnostic is added here.
+  
+  The two `columns.map` callbacks are typed `TableColumn` instead of `any`, so
+  re-introducing an undeclared alias on this renderer is now a type error rather
+  than a reviewer's catch.
+
+### Patch Changes
+
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- fc62bb4: `TableColumn.type` now has ONE canonical value set across all three ends that disagreed
+  (objectui#5853, maintainer ruling 2026-08-25, Option B: the 8-literal interface union is
+  canonical). The interface declared `'text' | 'number' | 'date' | 'datetime' | 'currency' |
+  'percent' | 'boolean' | 'action'`; the zod mirror declared `z.string()` and accepted
+  anything; the renderer branched on a third set and could only read the key through an
+  `as any` cast.
+  
+  ## ⚠️ Accept-set narrowing — these spellings stop validating
+  
+  `TableColumnSchema.type` was `z.string().optional()`. **Any string parsed green.** It is now
+  `z.enum(TABLE_COLUMN_TYPES).optional()`, so a value outside the eight is refused at parse
+  time with `type` named in the error path. Spellings that validated before and are **refused
+  now**, grouped by why they were being written:
+  
+  - **Typos and invented names** — `'money'`, `'datetime2'`, `'string'`, `'int'`, `'integer'`,
+    `'float'`, `'double'`, `'datetime-local'`, and every other free-form string. `'money'` is
+    the card's headline case: it validated, matched no renderer branch, and the column fell
+    through to plain text rendering with nothing reported. That silent fall-through is the
+    lenient-validation face that lets AI-authored metadata errors through, and it is now a
+    loud parse failure.
+  - **Object-schema field types written into a column slot** — `'select'`, `'lookup'`,
+    `'user'`, `'file'`, `'formula'`, `'textarea'`, `'email'` and the other 35 members of
+    `@objectstack/spec`'s `FieldType` that are not among the eight. These belong on the FIELD,
+    not on the column: a column gets its dedicated widget from the field definition behind its
+    `accessorKey`, never from `type`.
+  
+  **Authored metadata in this repo needs no migration.** Measured before tightening, across
+  `examples/`, `content/`, `apps/`, `e2e/`, `docs/` and every package (591 JSON schema files
+  plus the docs and playground sources): **zero** authored `TableColumn.type` values outside
+  the eight, and zero occurrences of `int` / `integer` / `float` / `double` in a column
+  position anywhere in the repository. If you author `type` on a table column, check it
+  against the eight; if the value describes the FIELD rather than the column, remove it.
+  
+  ## The renderer's undeclared vocabulary disappears instead of being declared
+  
+  `int` / `integer` / `float` / `double` were members of the data-table's `NUMERIC_EDIT_TYPES`
+  and `datetime-local` had its own editor branch, none of them declared. They arrived because
+  column-inference producers forwarded an object schema's field type **verbatim** into
+  `TableColumn.type`. Rather than publishing that dialect, producers now fold their inferred
+  value onto the declared vocabulary at their emit seam via the new
+  `normalizeTableColumnType()`: `int`/`integer`/`float`/`double` → `number`,
+  `datetime-local` → `datetime`, and **anything else drops the `type` annotation — never the
+  column**. Two producers do this, not the one the card named: `ObjectGrid` (`@object-ui/plugin-grid`)
+  and `ObjectDataTable` (`@object-ui/plugin-dashboard`), whose `buildFieldMeta` spread wrote
+  the raw field type into the same slot.
+  
+  Dropping the annotation is behaviour-preserving at the only consumer that reads the key.
+  `data-table`'s inline editor branches on `date`, `datetime` and the numeric set and
+  otherwise falls through to a text input — which is exactly the `undefined` path. The
+  dedicated widget a `select` or `lookup` column gets comes from the host's `renderCellEditor`,
+  which resolves the field through `column.accessorKey` and never reads `type`.
+  
+  ## New public API
+  
+  `@object-ui/types` exports `TABLE_COLUMN_TYPES` (the canonical tuple — the single
+  declaration the zod mirror builds its enum from, so the two cannot drift), the
+  `TableColumnType` union, and `normalizeTableColumnType()` for producers. The `as any` cast
+  in `data-table.tsx` is deleted and the read is typed, so re-introducing an undeclared
+  spelling is a tsc error rather than a silent widening.
+  
+  A value-level parity pin covers all three ends
+  (`packages/types/src/__tests__/table-column-type-canonical.test.ts` and
+  `packages/components/src/renderers/complex/__tests__/table-column-type-read-set.test.tsx`).
+  objectui#5684's guard is key-set only and cannot see value drift — `type` was present on
+  both sides the whole time — which is how this instance survived while its siblings were
+  caught. A future inference value turning that pin red is by design; the note at the pin says
+  so, and names the two correct repairs.
+- 194fae1: `ui:button` resolves its authored `icon` through the shared `resolveIcon` instead of a
+  byte-equivalent copy of it (objectui#5993).
+  
+  `renderers/form/button.tsx` carried its own `toPascalCase`, its own `iconNameMap` holding
+  the single `Home -> House` entry, and its own index into lucide's runtime `icons` record —
+  the same algorithm as `renderers/action/resolve-icon.ts`, but not the same function. The
+  `action:*` family, `complex/data-table.tsx` and both menu renderers already import the
+  shared one. The hazard was drift, not rendering: an alias added to `resolve-icon.ts` to
+  absorb a lucide retirement (the objectui#5586 / #5622 mechanism) reached every one of those
+  sites and silently missed `ui:button`, which would have gone on resolving the retired
+  spelling to nothing while the rest of the repo resolved it correctly.
+  
+  **No behaviour changes, and that is measured rather than asserted.** The two
+  implementations were compared over 3547 names — every one of lucide's 1767 record keys in
+  both spellings, plus kebab-case probes (`arrow-right`, `dollar-sign`, `user-plus`), the
+  `Home` alias, retired spellings and `undefined`: 3539 identical by object identity, 8
+  differing only in the nullish flavour returned for a miss (the copy indexed the record and
+  got `undefined`; the shared resolver `?? null`s it), zero genuine forks. That one
+  difference cannot reach the DOM — `Icon` is consumed at exactly two sites, both
+  `{!isLoading && Icon && <Icon .../>}` truthiness tests, and React renders nothing for
+  `null` and `undefined` alike. Icon identity, `h-4 w-4` sizing, `iconPosition`, the loading
+  state and the `Loader2` spinner are unchanged, and are pinned by
+  `renderers/form/__tests__/button-shared-icon-resolver.test.tsx`.
+  
+  Because behaviour is unchanged, the usual red-before ablation does not exist for this
+  change and none was manufactured. The one row in that suite that discriminates is
+  structural: it spies on the shared module and fails when the glyph does not come out of it,
+  which is red on the copy and green on the import.
+  
+  `scripts/check-lucide-icon-record-names.mjs` drops `form/button.tsx` from
+  `DECLARED_RECORD_READERS` in the same commit — that gate rediscovers record readers from
+  source on every run and fails on drift in both directions, so the removal is verified by
+  the gate rather than declared. It is also what now guards the dedupe: a re-inlined copy
+  would be discovered as an undeclared record reader and fail. The census entry for the
+  `button` *type* stays, its resolver re-pointed at `resolve-icon.ts`, so `ui:button`'s
+  authored icon names are still judged against the live record.
+  
+  `renderers/basic/icon.tsx` keeps its own copy deliberately and is untouched: `ui:icon`
+  draws a `SquareDashed` placeholder and warns on an unresolvable name (objectui#5631), which
+  the shared resolver does not do.
+- 546ddf7: A node-gate visibility predicate that FAULTS now says so in a production build, once per
+  distinct predicate source (objectui#6038, maintainer ruling 2026-08-25, option B: "the
+  silence is no longer an accepted property"). Observability only — no verdict moves.
+  
+  `SchemaRenderer`'s visibility chain is fail-open: a predicate that cannot be evaluated
+  resolves to the same answer as one that said yes, so a gate that stops biting looks
+  exactly like a gate the author got right. The diagnostic that names it (objectui#5454 /
+  objectui#5687) sat behind a `__DEV__` short-circuit, because the only fault-detection
+  channel available was `throwOnError`, and on the CEL branch `evaluateCelCondition`
+  implements that by evaluating **twice** — too expensive to ship for every predicate of
+  every node.
+  
+  **What production actually printed before, measured per dialect on the built evaluator**
+  — the card's premise held for one dialect of three, and the other two failed in opposite
+  directions:
+  
+  | dialect | production console, before |
+  |---|---|
+  | bare string | **nothing** |
+  | `{ dialect: 'cel' }` envelope | one generic line, deduped per source |
+  | `${…}` template | one generic line **per evaluation**, never deduped |
+  
+  So the dialect objectstack#11254 measured a live gate breaking on was the silent one,
+  while the template dialect was the console flood the ruling's rate-limit clause exists to
+  prevent.
+  
+  **The fix reports the fault the evaluator already detected, at the same number of engine
+  calls.** `EvaluationOptions.onFault` is a new passback on `@object-ui/core`'s
+  `ExpressionEvaluator`: every fault site is already inside a `catch`, or already holds the
+  canonical engine's failure reason, so nothing is evaluated twice. It mirrors, one layer
+  up, the seam `FieldPredicateDiagnostic` already documents (`warn: false` plus a reason
+  passback), and supplying it transfers reporting to the caller so one fault stays one
+  line. Pinned: the CEL branch performs the same number of record reads with the passback
+  as without it, and strictly fewer than the `throwOnError` probe.
+  
+  `SchemaRenderer` passes it in production and reports through the **same** reporter the dev
+  branch uses — same message, same severity, same dedupe `Set`, same key. Development and
+  production now print the identical line for the identical fault; the `__DEV__` gate no
+  longer decides *whether* a fault is reported, only *how* it is detected.
+  
+  `page:tabs` item-level `visibleWhen` (`@object-ui/components`) is covered by the same
+  reporter and the same rate limit. It swallowed the identical fault under a different
+  helper, and it was the worse of the two: the node gate at least reported in development,
+  while a faulting item predicate was silent in *both* builds on a gate whose false verdict
+  removes an entire tab, header and panel.
+  
+  **Rate limit:** deduped per (node type, gate key, predicate source) — never per render and
+  never per node instance. A two-hundred-row list of one broken predicate is one line; a
+  second distinct predicate source still gets its own line. Both halves are pinned, because
+  a test that asserts only "a warning was emitted" is equally green on an implementation
+  that emitted fifty, and one that asserts only "exactly one" is equally green on an
+  implementation that suppresses everything.
+  
+  **Not changed by this card, deliberately:** the fail-open semantics themselves; the
+  objectui#5687 adapter-only `data.*` report, which stays development-only under its own
+  2026-08-22 ruling (that path is not a fault — the predicate evaluated perfectly, against
+  the wrong object); and the `/forms/:name` scope wiring of objectui#6262, which lands in
+  its own PR.
+  
+  `reportUnresolvableVisibilityPredicate`, `formatUnresolvableVisibilityMessage`,
+  `UNRESOLVABLE_VISIBILITY_PREFIX` and `__resetVisibilityPredicateWarnings` are now exported
+  from `@object-ui/react` so every surface that evaluates a node `visibleWhen` shares one
+  reporter and one rate limit — a second copy would mean a second dedupe `Set`, and one
+  authored predicate would be entitled to one line per package instead of one line.
+- 129bcc5: Column width and order that a user drags in `ObjectGrid` now actually persist
+  (objectui#6175). Both halves of `saveColumnState`'s only two call sites were dead, so a
+  drag was written nowhere — not to `localStorage`, not through `onColumnStateChange` to the
+  host's `dataSource.updateViewConfig`. The saved state was read back correctly forever; it
+  was simply never written.
+  
+  Two independent breaks, one per package:
+  
+  - **`@object-ui/components`** — `DataTableSchema` has declared
+    `onColumnResize?: (columnKey, width) => void` all along, and `data-table.tsx` invoked it
+    **nowhere**: the resize drag updated the table's local `columnWidths` state and stopped
+    there. It now reports the settled width once, at `mouseup`. Once, deliberately — the host
+    turns this callback into a write to shared view config, so a per-`mousemove` callback
+    would be a write storm.
+  - **`@object-ui/plugin-grid`** — `ObjectGrid` emitted `onColumnReorder` (singular) while the
+    renderer invokes the near-duplicate `onColumnsReorder` (with the `s`), a different declared
+    key with a different signature. The producer now emits the spelling the renderer actually
+    invokes, mapping the reported `TableColumn[]` to the `accessorKey` order `columnState`
+    stores.
+  
+  **Nothing is retired.** Both spellings remain declared on `DataTableSchema`;
+  `onColumnReorder` stays declared and stays unwired, exactly as the `RuntimeOnlyDeclared`
+  ledger in `zod-mirror-parity.test.ts` records it. Which of the two survives is a
+  declared-surface ruling that stays open and is deliberately not settled here.
+  
+  ⚠️ Behavioural note for hosts: `onColumnStateChange` now fires where it previously never
+  did, which means `dataSource.updateViewConfig` is now reached on a column drag. That call
+  was unreachable by this path before, so any permission gate on that write now sees traffic
+  it never saw.
+  
+  The renderer's resize/reorder gestures, the inbound seeding of `columnState`, and the
+  declared surface are all unchanged.
+- f8c70f4: `ui:context-menu` now resolves a menu item's authored `icon` to a glyph. It previously never read the key at all.
+  
+  Both arms of `renderContextMenuItems` — the leaf `ContextMenuItem` and the `ContextMenuSubTrigger` — ignored `icon` entirely, so an item authored as `{ "label": "Copy", "icon": "copy" }` drew its label and nothing else. The name is now resolved through `resolveIcon`, the same lucide **record** surface `ui:button`, `ui:dropdown-menu` and the `action:*` family already resolve against: a live name draws its glyph, and an unknown or retired spelling draws nothing rather than degrading to a wrong glyph. This mirrors the repair `ui:dropdown-menu` received for the identical defect.
+  
+  The `components-overlay-context-menu/basic-context-menu` catalog fixture already declared four live names — `copy`, `scissors`, `clipboard`, `trash` — which drew nothing before this change and draw their glyphs now. Those names are also brought under `check:lucide-icon-record-names` by a new `context-menu` census entry, so a future retired spelling fails the gate instead of silently drawing nothing.
+- f9c34df: An `action:icon` hosted by an `action:bar` now reaches its handler. It forwarded the
+  COMPONENT id as the action type, so the click resolved nothing at all — no error, no
+  toast, a button that silently did nothing (objectui#6306, the objectstack#2169 "Mark Done
+  does nothing" shape).
+  
+  `action:bar` does not route members through `SchemaRenderer`. It pulls each member's
+  renderer off the registry and RENAMES the declared type as it spreads it onto the child:
+  `type` becomes the component id (`'action:icon'`) and the real declaration moves to
+  `actionType`. `action:button` has always resolved that pair when it forwards
+  (`schema.actionType || schema.type`); `action:icon` read `schema.type` alone and dropped
+  `actionType` entirely. `ActionRunner.execute` resolves its handler from
+  `action.type || action.actionType || action.name`, and `'action:icon'` binds no registered
+  handler and no builtin — for a declaration carrying `target` rather than `endpoint` it does
+  not reach the legacy `navigate`/`api` fallback either, so it fell through to
+  `executeActionSchema` and the authored action never ran.
+  
+  **The bug was a function of the layout, not the declaration.** One authored action executed
+  or did nothing depending on which `component` the host picked for it — the same asymmetry
+  objectui#5493 fixed on this renderer for `onSuccess`, one key over.
+  
+  `check:action-forward-parity` could not have caught this and its green run was never
+  evidence: `type` **is** in the forward whitelist, and that gate diffs key PRESENCE against
+  the owed set. This is a wrong-VALUE defect behind a present key, a class the gate has no
+  opinion on by construction. The existing icon coverage could not catch it either — it
+  rendered `action:icon` bar members three times and asserted only `visible`/`enabled`, never
+  that a click reached a handler, which is exactly how this shipped.
+  
+  Pinned by `action-bar-member-type-resolution.test.tsx`, which executes clicks rather than
+  inspecting props. Every row that reads the icon member's zero renders a sibling
+  `action:button` member of the SAME declaration in the SAME bar and reads its one first, so
+  a zero cannot be "the harness never executed anything". One row registers a trap handler
+  keyed on the component id, making the unfixed behaviour a positive artefact (the trap
+  fires) rather than only a missing call. A standalone row stays green in both worlds on
+  purpose: it refuses a "fix" written as `schema.actionType` alone, which would trade this
+  defect for its mirror image on the surface where `type` IS the action type.
+  
+  Scope is this one renderer. `type: schema` appears in exactly two files under
+  `renderers/action/` — `action-button.tsx` (already correct) and `action-icon.tsx`;
+  `action:group` and `action:menu` compose their members differently and are untouched.
+- f24de8b: The form renderer no longer leaks `FormSchema.previousValues` onto the `<form>` DOM node
+  (objectui#6396).
+  
+  `previousValues` is a declared schema key with a real consumer: the renderer's
+  `previousRecord` memo, which binds `previous` for field-rule CEL predicates and is the
+  INSERT/UPDATE signal the read-only submit strip gates on (objectui#3484). That consumer
+  reads it off `schema` and is unchanged. The defect was on the other channel —
+  `SchemaRenderer` spreads every non-metadata top-level schema key as a React prop *in
+  addition* to handing the node over as `schema`, so an edit-mode host (`ObjectForm`, which
+  is what the `object-master-detail-form` header composes) delivered a second, top-level copy
+  in `...props`. The renderer already consume-and-drops that whole family before its DOM
+  spread — `objectName`, `onDirtyChange`, `defaultValues`, `fields`, `layout`, … —
+  and `previousValues` was the one member missing from the list.
+  
+  Two things followed, on every edit-mode header render. React declined the prop and printed
+  `React does not recognize the previousValues prop on a DOM element`, and — measured on
+  React 19, and not recorded on the card — the persisted record was still stamped onto the
+  element as `previousvalues="[object Object]"`. Consume-and-dropping the duplicate removes
+  both.
+  
+  Scope is the runtime leak only. The declared key stays exactly as declared
+  (`packages/types/src/form.ts`, `packages/types/src/zod/form.zod.ts` are untouched): it has
+  a live consumer, so there is nothing here for the enforce-or-remove channel.
+- 3c76801: `action:button`, `action:icon`, `action:group` and `action:menu` now forward the
+  declared `onSuccess` block, so the post-success navigation an author writes in metadata
+  actually happens on those four surfaces (objectui#5493).
+  
+  `onSuccess` — spec's closed strict `{ navigate, openIn }` object — became authorable on
+  `ActionSchema` with the `@objectstack/spec` 17.1.0 pin bump (objectui#5328), and the
+  runner has read it off the **forwarded** def since objectui#5221:
+  `ActionRunner.handlePostExecution` → `readOnSuccessNavigation` → `navigateOnSuccess`,
+  which hops through the app's own `navigationHandler` (a real SPA route change, immune to
+  popup blocking). Between those two halves sat these four forward whitelists, which never
+  carried the key. The action succeeded, the toast said so, and the declared hop silently
+  did not happen — the same "shipped green while dropped one hop before the runner" class
+  as `bodyExtra` (objectstack#6837), `bodyShape` (objectstack#6938) and `resultDialog`
+  (objectui#3646).
+  
+  Reachability before this change was a function of which host rendered the action: the
+  full-def-spread hosts (`DeclaredActionsBar`, `ObjectGrid.onActionDef`,
+  `RelatedRecordActionsBridge`, `useNavActionDispatch`) already carried it through, so the
+  same declaration hopped there and did nothing here — and on an `action:bar`, whether an
+  action lands inline (`action:button`) or in the overflow (`action:menu`) is decided by
+  `maxVisible`, 3 desktop / 1 mobile. The declared navigation therefore depended on
+  viewport width.
+  
+  Pinned end to end in
+  `packages/components/src/renderers/action/__tests__/action-onSuccess-forward.test.tsx`:
+  one row per surface drives the real renderer through the real runner and asserts the
+  `${result.*}`-interpolated url reaches `onNavigate`, with `openIn` exercised on both
+  branches. Each row asserts the action executed first, so a zero-navigation reading
+  cannot be a harness that did nothing.
+  
+  The four matching `KNOWN_GAPS` entries in `scripts/check-action-forward-parity.mjs` are
+  deleted — that ledger is ratcheted, so a stale entry excusing a key that is now
+  forwarded fails the gate. `element:button` is untouched and stays correct: `onSuccess`
+  is not on spec's `InlineActionSchema` pick list, so that surface never owed it.
+- 2c8474c: Published declaration text for the react page renderer changed: `kind:'react'` page `source` styling is now stated in the shipped `.d.ts`
+  
+  `dist/renderers/layout/react-page.d.ts` is in this package's npm tarball, and the
+  declaration emitter reproduces that module's file-header documentation into it
+  verbatim. Two things a consumer reads — on hover over `ReactKindPage` in an editor,
+  or straight out of the tarball — now say something different:
+  
+  - The injected-scope note no longer tells authors that layout is left to "plain
+    HTML + Tailwind". It says plain HTML.
+  - A new paragraph states the styling contract for `kind:'react'` page `source`:
+    `source` is runtime metadata, not build input. Style with inline `style` objects
+    using `hsl(var(--token))` theme colors, and render overlays through `ObjectForm`
+    with `formType` `"drawer"` or `"modal"` rather than a hand-rolled `fixed inset-0`
+    backdrop. Do **not** author Tailwind utility classes in page `source`: the
+    console's Tailwind is compiled at build time by scanning the console's own `src`
+    and there is no safelist, so an authored utility class silently produces no CSS
+    and no error anywhere. `os validate` reports it as
+    `page-source-className-tailwind`. (ADR-0065; ADR-0080's 2026-06-30 amendment;
+    see `content/docs/guide/react-pages.md`.)
+  
+  That is guidance an author can act on, and it contradicts what this package's
+  declarations previously told them, so it is a change to the published surface
+  rather than an internal edit. No runtime behaviour changed and no export moved.
+  
+  This entry is corrective. The text landed under objectui#5461 with a changeset that
+  declared only `@object-ui/types`, on the stated grounds that the edits "do not
+  project into any `.d.ts`". Rebuilding the package shows that they do — the reasoning
+  and the measurement are recorded in `scripts/check-changeset-presence.mjs`'s header,
+  where the next author will meet them.
+- ae61ad4: The console form now renders a refusal message the producer explicitly marked
+  as user-facing, instead of always substituting a generic string
+  (objectui#5210).
+  
+  An application's hook guards could not talk to their users. When a hook refused
+  a write with 403, the form replaced the server's text with
+  `form.noPermissionToSave` unconditionally — the recorded objectstack#3821 fix,
+  which exists because a raw refusal body puts untranslated platform diagnostics
+  (`FORBIDDEN: insufficient privileges to update showcase_private_note
+  pi-TgoJ4_DM55Fqz`) in front of end users. The external report behind this change
+  had 11 guards whose deliberate, localized guidance — which role owns the action,
+  whom to ask — never reached anyone, and named the incentive that creates:
+  returning 400 instead of 403 for permission failures, degrading the status
+  semantics logs, monitoring and API consumers depend on.
+  
+  The maintainer ruling (2026-08-19) was a producer-side opt-in rather than a
+  chattier 403 branch, and the platform half shipped as objectstack#9934: a hook
+  marks its refusal text with `userMessage` at throw time. This is the consumer
+  half.
+  
+  - `@object-ui/react` gains `declaredUserMessage(err)` — the one "is this
+    marked?" read. It answers the marking verbatim, from the two places the
+    adapter boundary parks the envelope (the error itself, where
+    `@objectstack/client` lifts it, and `details`), and `null` for everything
+    else.
+  - The form prefers a marked message over both its generic strings, on ANY
+    status — the marking is status-agnostic; 403 is where this was reported, not
+    a fence the contract draws.
+  
+  **Unmarked refusals are unchanged**: a 403 with no marking still shows the
+  generic `form.noPermissionToSave`, and the raw text still goes to the browser
+  console only. objectstack#3821's protection is preserved by construction, not
+  by re-guessing which 403 bodies are presentable — the mark and the marked text
+  are one field, so no boundary that rewraps or substitutes `message` can promote
+  platform prose into the user-facing channel, and platform code never sets it.
+- fe76ece: The typings both packages publish now carry an explicit extension on every relative specifier, so a consumer on `moduleResolution: nodenext` can follow them.
+  
+  `vite-plugin-dts` emits one declaration file per source file, and TypeScript
+  copies a module specifier into the declaration verbatim. `export * from './ui'`
+  therefore shipped extensionless in `dist/index.d.ts` — 21 such re-exports in
+  `@object-ui/components`, 7 in `@object-ui/layout`, 128 across the two emitted
+  trees. Node16/NodeNext resolution does not extension-search a relative
+  specifier, so the compiler could follow none of the hops and every symbol they
+  carried read as absent from the package:
+  
+  ```
+  error TS2305: Module '"@object-ui/components"' has no exported member 'Badge'.
+  ```
+  
+  Measured on `@object-ui/app-shell`, the largest consumer and the one that pulls
+  in both packages: 880 TS2305 across 162 files (864 from `components`, 16 from
+  `layout`), plus 215 TS7006 as fallout from the imports that stopped resolving.
+  On `@object-ui/fields`, 178 TS2305 and 57 TS7006. Both are zero now.
+  
+  The emitted `.js` never had the defect — rolldown resolves the same specifier
+  away — which is why `pnpm check:esm-specifiers`, whose verdict is about
+  specifier-preserving `.js` builds, correctly never scanned either package. The
+  fix is therefore in the declaration EMIT (`scripts/vite-dts-explicit-extensions.ts`,
+  shared by both `vite.config.ts` files), not in the sources: the same source line
+  produces a clean `.js` and a broken `.d.ts`, so no source edit can express the
+  difference. The rewriter resolves each specifier against the source tree the
+  output mirrors — a file hop becomes `./x.js`, a directory hop `./x/index.js` —
+  throws on anything it cannot resolve, and after the build re-parses the emitted
+  declarations to assert every relative specifier both carries an extension and
+  names a file the build really emitted.
+  
+  `packages/fields` takes the `nodenext` pin as a result — the same two lines
+  `packages/react` has carried since objectui#4538 — so the property is enforced by
+  the compiler on the consumer side rather than by review. `packages/app-shell`
+  does not: it type-checks clean without the pin and still shows 23 errors with it,
+  none of them from these two packages. That residue is filed separately.
+- 58770f3: **Behaviour change:** the eighteen renderers whose host element is a form
+  control no longer forward their whole prop bag to it. They route it through a
+  form-control DOM declaration — the same `pickDomProps` mechanism `grid`, `flex`,
+  `stack`, `container` and `text` were converged on — so an authored schema key
+  becomes an HTML attribute only if the contract declares it one (objectui#5632,
+  the `BARE_SPREAD_MINUS_NAME` slice of objectui#5574).
+  
+  The eighteen: `action:button`, `action:icon`, `ui:button`, `ui:checkbox`,
+  `ui:combobox`, `ui:date-picker`, `ui:email`, `ui:file-upload`, `ui:input`,
+  `ui:input-otp`, `ui:password`, `ui:radio-group`, `ui:sidebar-menu-button`,
+  `ui:slider`, `ui:sonner`, `ui:switch`, `ui:textarea`, `ui:toggle`.
+  
+  What this stops reaching the DOM: the renderer's own declared props, consumed
+  off `schema` to render the control AND spread onto the element a second time as
+  attributes HTML does not define, plus the authored node's SDUI metadata and the
+  flattened `props` container. Measured across `examples/schema-catalog`, rendered
+  through the real `SchemaRenderer`: 284 illegitimate attributes over 287
+  form-control nodes — `button[label]` 140, `button[icon]` 25, `input[inputtype]`
+  23, `input[label]` 19, `toggle[label]` 14, `radio-group[options]` 8,
+  `date-picker[placeholder]` 7, `file-upload[label]` 7, `file-upload[buttontext]`
+  7, `checkbox[label]` 6, `textarea[label]` 6, `toggle[arialabel]` 6,
+  `switch[label]` 4, `password[label]` 3, `email[label]` 2, `radio-group[direction]`
+  2, and six singletons. The same probe reads 0 after, with `grid`'s 26 nodes at 0
+  both times as the control and an unchanged node census across the two runs.
+  
+  `name` and `disabled` are DELIBERATELY still forwarded. Both are legal on a form
+  control and neither was ever part of the leak — the ledgered shape for this
+  group is thirteen attributes, not fourteen, precisely because HTML defines
+  `name` on these hosts. The whitelist this group uses is therefore the shared
+  SDUI one PLUS those two, not the bare `toDomProps` the container renderers take:
+  that would have stripped the form-serialization key off every control and
+  silently re-enabled every disabled one, and no gate in the repo would have gone
+  red for it.
+  
+  Nothing an author writes renders differently: every leaked key was already being
+  read off `schema` and applied. `id`, `role`, `tabIndex`, `className`, `style`,
+  event handlers and the open `data-*` / `aria-*` families are unchanged.
+  
+  Anything that read one of the leaked attributes off the DOM — a CSS attribute
+  selector such as `[label="Save"]`, or a test asserting `inputtype` on a rendered
+  `ui:input` — must read the schema instead. No `@object-ui` code did; this is
+  called out because the attributes were externally visible while they lasted.
+- 485f096: The form renderer now keeps a `defaultValues` reset off `onChange` and off the
+  `form_change` `onAction` for **every** caller — including one that memoizes the
+  callback (objectui#5235).
+  
+  "A record landing is not a user edit" was already this file's documented,
+  pinned behaviour, but two of the three channels delivered it by accident of
+  React's effect ordering: every layout DESTROY runs before any layout CREATE, so
+  a caller passing a fresh callback each render had its value subscription torn
+  down before the reset and re-established after. The guarantee was therefore
+  delivered by the callback's *identity changing*. Wrap the same callback in
+  `React.useCallback` — taught everywhere as a semantically neutral performance
+  optimization — and the identity stays put, the effect never re-runs, the
+  subscription survives the reset, and the whole loaded record comes back to the
+  host as if the user had typed it: the false "the user edited this" signal
+  objectui#2968 was filed about, in a form no type, doc or call site warned about.
+  
+  The reset now states what those two channels report, the way `onDirtyChange`
+  already did (it computes its payload against the freshly installed baseline and
+  calls the host outright). Callers passing inline arrows see byte-identical
+  behaviour; callers who memoize stop receiving a phantom edit.
+  
+  Not a contract change: whether a value channel *should* report a programmatic
+  reset stays open in objectui#5235. This only removes the answer's dependence on
+  caller identity.
+- b655a9d: The `ui:grid` renderer now forwards to the DOM by whitelist, so schema keys no longer
+  land on the rendered `<div>` as invalid HTML attributes (objectui#4787).
+  
+  `grid.tsx` ended in a bare `{...gridProps}` spread that removed only `data-obj-*` and
+  `style`, so everything else `SchemaRenderer` hands a registered component reached the
+  element. Measured on a canary node, eight attributes leaked:
+  `columns="4"`, `gap="4"`, `mdcolumns="2"`, `smcolumns="2"`, `name="grid_node"`,
+  `props="[object Object]"`, `colorvariant="x"` (the flattened `props` container) and an
+  unknown authored `zzcanary="leak"`. A responsive `columns` object rendered as
+  `columns="[object Object]"`. Layout was unaffected, so every catalog grid example
+  rendered with them — the reason this went unnoticed.
+  
+  The spread now goes through `toDomProps` from `@object-ui/core`, the same whitelist
+  objectui#3291 established in `packages/fields` and objectui#4425 phase 2 promoted to the
+  SDUI widget contract. Keys that are *declared* DOM-safe survive — `id`, `className`,
+  `role`, `tabIndex`, plus the open `data-*` and `aria-*` families, which is how the
+  designer's `data-obj-id` / `data-obj-type` still arrive — and `style` continues to be
+  forwarded by name. Nothing an author can add to a grid node reaches the DOM implicitly
+  any more, including keys `GridSchema` does not have yet; enumerating today's keys to
+  strip would have re-rotted on the next schema addition.
+  
+  No authored input changes and no layout changes: the grid's own vocabulary was always
+  read off `schema`, never off these props.
+- d7bd274: **Behaviour change:** the `flex`, `stack`, `container` and `text` renderers no
+  longer forward their whole prop bag to the host element. They route it through
+  `toDomProps` — the same whitelist `grid` was converged on — so an authored
+  schema key becomes an HTML attribute only if the SDUI DOM contract declares it
+  one (objectui#5574).
+  
+  What this stops reaching the DOM: the renderer's own declared props, which were
+  consumed off `schema` to build the class list AND spread onto the element a
+  second time as attributes HTML does not define. Measured across
+  `examples/schema-catalog`, rendered through the real `SchemaRenderer`: 1194
+  illegitimate attributes over 1141 nodes — `text[content]` 522, `flex[align]`
+  198, `flex[gap]` 193, `stack[gap]` 153, `flex[justify]` 98, `container[padding]`
+  14, `container[maxwidth]` 6, `flex[direction]` 5, `stack[align]` 4,
+  `text[value]` 1. The same probe reads 0 after, with `grid`'s 26 nodes at 0 both
+  times as the control.
+  
+  Nothing an author writes renders differently: every leaked key was already being
+  read off `schema` and applied as a class, so the markup loses attributes that
+  never had meaning and keeps the styling that did. `id`, `role`, `tabIndex`,
+  `className`, `style`, event handlers and the open `data-*` / `aria-*` families
+  are unchanged — including `data-obj-id` / `data-obj-type`, which now arrive
+  through the `data-*` family rather than by hand.
+  
+  Anything that read one of the leaked attributes off the DOM — a CSS attribute
+  selector such as `[gap="4"]`, or a test asserting `align` on a rendered `flex` —
+  must read the schema or the class instead. No `@object-ui` code did; this is
+  called out because the attributes were externally visible while they lasted.
+- 9d9040d: `ui:dropdown-menu` now resolves a menu item's authored `icon` to a glyph instead of drawing the name as raw text.
+  
+  Both arms of the item renderer — `DropdownMenuItem` and `DropdownMenuSubTrigger` — rendered `icon` straight into a text node, so an item authored as `{ "label": "Copy", "icon": "copy" }` drew the literal word `copy` beside its label. The name is now resolved through `resolveIcon`, the same lucide **record** surface `ui:button` and the `action:*` family already resolve against: a live name draws its glyph, and an unknown or retired spelling draws nothing rather than degrading to a wrong glyph.
+  
+  The `components-overlay-dropdown-menu/with-icons` catalog fixture declared the retired lucide spelling `edit`, which is absent from lucide's runtime `icons` record and would therefore have drawn no glyph; it now declares `square-pen`, the live key the retired export resolves to by identity.
+- 0b1326d: Documentation no longer teaches the "JSX/HTML + Tailwind" framing for a page's
+  `source`, which ADR-0080's own 2026-06-30 header amendment (under ADR-0065,
+  Accepted) retracted. objectui#5461 corrected three sites; a multiline census
+  found eight more, in three spellings a line-oriented grep could not see.
+  
+  A page's `source` is *runtime metadata*. The console's Tailwind is compiled at
+  build time by scanning the console's own `src`, and there is no safelist, so it
+  never sees your page: an authored utility class produces CSS only by coincidence
+  (when objectui already ships that exact class) and otherwise produces nothing,
+  with no error anywhere. That is the ADR-0065 "works only by coincidence" failure
+  mode, and it is how a modal's `bg-black/50` backdrop reached production fully
+  transparent. `os validate` reports it as `page-source-className-tailwind`, a
+  warning on kinds `html`, `react` and `jsx`, shipped in `@objectstack/lint@11.5.0`.
+  
+  The tiers themselves are unchanged and every load-bearing claim survives —
+  parse-never-execute, the untrusted-author safety argument for `html`, and the
+  deprecated `'jsx'` alias. Only the styling primitive is corrected, to the wording
+  `content/docs/guide/react-pages.md` §Styling already uses:
+  
+  | `kind` | Style with |
+  |---|---|
+  | `"html"` | The blocks' own structured props (`` `<flex direction gap>` ``, `` `<grid columns>` ``) plus a JSON `style` object. |
+  | `"react"` | Inline `style` objects. |
+  
+  Colors on both tiers come from the theme as `hsl(var(--token))`.
+  
+  Why each package has an entry — each was measured against its built artefact, not
+  assumed:
+  
+  - **`@object-ui/react-runtime`**: `README.md` is published to npm (npm includes
+    `README.md` in the tarball regardless of `files`). Its "no sandbox" callout is
+    the paragraph that routes untrusted-author work to the `html` tier, and it
+    carried the retracted framing line-wrapped across `:17-18`. It also gains the
+    §Styling section it was missing — the absence is why the framing survived here.
+  - **`@object-ui/sdui-parser`**: the corrected header of `src/types.ts` projects
+    verbatim into the published `dist/types.d.ts`.
+  - **`@object-ui/components`**: the corrected header of
+    `src/renderers/basic/html-elements.tsx` projects verbatim into the published
+    `dist/renderers/basic/html-elements.d.ts`. The `kind === 'html'` dispatch-arm
+    comment in `src/renderers/layout/page.tsx` does **not** project (it is inside a
+    function body) and is included here only because the same package already owes
+    an entry.
+  
+  No behaviour change: this is prose only. `CHANGELOG.md` occurrences are
+  deliberately untouched — immutable release history.
+- fa140b8: `element:record_picker`'s `emptyText` now resolves the inline per-locale map its
+  contract has admitted since rc.6, and its published declaration says so
+  (objectui#5590).
+  
+  `@objectstack/spec` widened this key to the `I18nLabel` union
+  (`string | Record< string, string >`) at 17.0.0-rc.6, and the installed 17.0.0 GA
+  still carries it — measured, not assumed:
+  `ElementRecordPickerPropsSchema.safeParse({ object: 'account', emptyText: { en, 'zh-CN' } })`
+  succeeds. The renderer honoured only the string arm, handing the map straight to a
+  text node. React refuses a plain object in a child position rather than stringifying
+  it, so an author writing the map form the contract accepts did not get a mis-rendered
+  empty state — the whole picker subtree threw
+  `Objects are not valid as a React child (found: object with keys {en, zh-CN})`.
+  
+  The read site now resolves through `pickLocalized`, the objectui-side helper the
+  sibling text-node sites already read through (`element:text.content`,
+  `element:button.label`, `page:card.title`), which spells a miss as `''` rather than
+  the spec resolver's `undefined`. The default is applied before resolution, so
+  `emptyText` absent still means "No records" and an authored empty string still
+  renders empty.
+  
+  The `ComponentMeta` entry, which held a single `'string'` arm precisely because the
+  renderer dropped the other one, now declares `['string', 'object']`. That narrowing
+  was correct for exactly as long as it was true: with the map arm reaching the screen
+  resolved, withholding it would be the false declaration in the other direction — the
+  manifest gate reporting `type-mismatch` on a legal write the same input's own
+  `description` teaches the author to make. The `apps/console` specimen that pinned the
+  narrow arm named this release condition in its own words ("keeps its single `'string'`
+  arm until the render site catches up") and is flipped here, keeping its controls.
+  
+  Three comments in the renderer deferred this gap to objectui#4163, which closed as
+  completed on 2026-08-15 while the gap was still open; the file now carries no
+  reference to it. The `ComponentInput.type` doc in `@object-ui/types` cited this very
+  key as its worked example of an arm deliberately withheld, and is corrected in the
+  same change so the example stays true.
+- 71cba28: `element:record_picker`'s `label` is now programmatically associated with its
+  `SelectTrigger` combobox — fixing a case where the caption the block's own
+  registration prose advertised (`'Caption rendered above the picker, in a
+  <label> element'`) named nothing at all (objectui#5771).
+  
+  Pre-fix, the render body was `{label && <label className="…">{label}</label>}`
+  against a `SelectTrigger` with no `id`: neither end of the association carried
+  any wiring. That is a step worse than the sibling gap objectui#5735 closed on
+  `element:text_input` — there the `label` half was already correctly wired and
+  only `description` was adrift; here the label element had no `htmlFor` and the
+  trigger had no `id`, so the picker had no accessible name unless a
+  `placeholder` happened to render text into the trigger's content.
+  
+  The fix follows the shape objectui#3341 already ruled on for the same defect
+  class (`InlineCreateRelated`'s `<label>`/`<Input>` pair) and objectui#5735
+  just landed on the complement block: `htmlFor`/`id` against the
+  `SelectTrigger` — a `button` with `role="combobox"`, and therefore labelable,
+  so no `aria-labelledby` is needed (Radix sets none on the trigger) — wired
+  **when `schema.id` exists**, matching `element:text_input`'s precedent rather
+  than an always-on `useId()` fallback. Only the author can supply `schema.id`,
+  so a picker authored without one keeps its pre-fix, unassociated caption text
+  exactly as before; nothing about this change mints an id the author did not
+  provide. The `<label>` element itself is also swapped for the shared `Label`
+  (`@radix-ui/react-label`) primitive `element:text_input` already uses for the
+  same wiring, rather than a bare `<label>` with a `htmlFor` bolted on.
+  
+  The registration prose for `label` is corrected to describe what the code now
+  does (tied to the control by `htmlFor` when the node carries an `id`) instead
+  of a caption association the renderer never performed.
+- 190fbd0: `element:record_picker`'s `label` and `placeholder` now resolve the inline
+  per-locale map their contract admits, and their published declarations say so
+  (objectui#5637).
+  
+  These are the two remaining keys of the trio objectui#5590 fixed one of. All
+  three members of `ElementRecordPickerPropsSchema` are the `I18nLabel` union
+  (`string | Record< string, string >`) — measured on the installed
+  `@objectstack/spec` 17.1.0 pin, where each resolves to
+  `optional -> union -> string | record` and
+  `safeParse({ object: 'account', <key>: { en, 'zh-CN' } })` succeeds. The
+  renderer honoured only the string arm on both, and the two keys failed in two
+  different ways:
+  
+  - `placeholder` was read raw and handed to `SelectValue`. React refuses a plain
+    object in that position rather than stringifying it, so the whole picker
+    subtree threw
+    `Objects are not valid as a React child (found: object with keys {en, zh-CN})`
+    — the same harm objectui#5590 removed from `emptyText`.
+  - `label` went through the file's local `toText`, whose object branch ends
+    `String(o.label ?? o.name ?? o.title ?? o.en ?? '')`. Reaching `o.en`
+    unconditionally is an English pick wearing locale resolution's clothes, so a
+    `zh-CN` viewer was shown the English entry — and a map that simply omits `en`
+    resolved to `''`, which the `{label && …}` render site drops, making the
+    picker's label element DISAPPEAR with nothing thrown and nothing logged.
+  
+  Both keys now resolve at their own read site through `pickLocalized`, the same
+  helper the settled `emptyText` shape uses. `toText` is deliberately unchanged:
+  it is shared with the row values (`toText(row?.[labelField])`), which are record
+  field values rather than `I18nLabel`, so teaching it locale resolution would
+  have changed a second, unrelated call site. The `placeholder` default is applied
+  before resolution, so an absent key still means "Select a record…" and an
+  authored empty string still renders empty.
+  
+  The two `ComponentMeta` entries, which held a single `'string'` arm precisely
+  because the renderer dropped the other one, now declare `['string', 'object']`
+  — declared in the change that makes the arm render, never before, which is the
+  order `ComponentInput.type` prescribes and the order `emptyText` set.
+  
+  KNOWN GAP, unchanged by this release: the sibling `label` read sites in
+  `renderers/layout/containers.tsx` compose
+  `translateLabel(pickLocalized(…), language)`, and that second helper is not
+  applied here — `translateLabel` and its `KNOWN_LABEL_DICT` are module-private to
+  that file. Only the locale-map resolution lands in this change; a plain-English
+  string `label` is still rendered verbatim in every language, exactly as before.
+- 6c6cee7: A RETIRED field-type spelling is now refused — out loud, once — by every
+  field-type predicate in the renderer, not just by the widget road
+  (objectui#4914, maintainer ruling B of 2026-08-18).
+  
+  `@object-ui/fields` exports a single `isRetiredFieldType(t)` gate, and it runs
+  ahead of six predicate faces that previously granted a retired spelling
+  first-class treatment: the filter builder's operator buckets and its value
+  control (`@object-ui/components`), the detail page's highlight-strip picker
+  (`@object-ui/plugin-detail`), `normalizeFieldType` (`@object-ui/plugin-view`),
+  the dashboard's `$expand` whitelist and `isLookupType`
+  (`@object-ui/plugin-dashboard`), and the list toolbar's lookup-like filter
+  control (`@object-ui/plugin-list`). Each one now fires the migration
+  prescription on the console — once per spelling across all of them, never once
+  per predicate — and then answers as it would for a spelling it does not
+  recognise.
+  
+  This closes the whole CLASS rather than one word: the gate is quantified over
+  `RETIRED_FIELD_TYPES`, so the next retirement covers all seven consumers on the
+  day it lands. It is the shape objectui#4932 and objectui#4942 already
+  established for the form and inline-edit roads.
+  
+  Measured before the change, and the reason the fix is a gate rather than a
+  deletion: `owner` was not dead in these faces. `operatorsForFieldType('owner')`
+  equalled the `user` bucket item for item, `computeLookupExpand` actively
+  requested `$expand` for it, `isLookupType('owner')` was `true` alongside
+  `reference`, and `normalizeFieldType('owner')` answered `'select'` exactly as
+  `picklist` does. Deleting the members alone would have traded a visible
+  contradiction for a SILENT degradation — a filter picker collapsing to a bare id
+  box, `$expand` quietly stopping so cells show raw foreign-key ids — which is
+  verbatim the failure mode `RETIRED_FIELD_TYPES`' own docblock exists to prevent.
+  The gate keeps that fallback and adds the half that was missing: the author is
+  told.
+  
+  The boundary question is answered on record: `owner` arriving through a
+  backend-vocabulary normalizer is an authoring error to refuse loudly, not
+  legitimate foreign input to tolerate. The open backend vocabulary those
+  normalizers exist for is untouched — `reference`, `picklist`, `money`, `int`,
+  `datetime_tz` and the rest are equally absent from the spec's closed `FieldType`
+  and are equally unretired, so they classify exactly as before.
+  
+  `RETIRED_FIELD_TYPES`, `reportRetiredFieldType` and `resetRetiredFieldTypeReports`
+  move to `@object-ui/core` and are re-exported from `@object-ui/fields`, so that
+  package's published surface is unchanged apart from the newly ruled gate.
+  `@object-ui/components` is a consumer of the gate and `@object-ui/fields`
+  depends on it, so a single shared table could not live in `fields` — and a
+  second copy would have meant a second dedupe set and two console lines for one
+  spelling. No package gained a new dependency.
+  
+  A retired spelling never loses a stored value: `retypeFilterValue` is
+  deliberately not gated, and the refused filter row stays operable rather than
+  drawing a blank operator trigger.
+- 42887e0: Repair five retired lucide icon spellings that reach a record-reading resolver, and pin
+  the names against the runtime `icons` record so the next lucide bump goes red instead of
+  silently blanking a glyph (objectui#5622).
+  
+  lucide retires a spelling by dropping it from its runtime `icons` record while KEEPING it
+  as a deprecated named export. A retired name therefore still imports, still type-checks,
+  and still renders wherever it is used as a COMPONENT — and resolves to `null` wherever it
+  is used as a STRING, because every string lookup here reads that record. Nothing goes red
+  either way. Measured against the installed `lucide-react@1.31.0` (1767 record entries) at
+  implementation time.
+  
+  What a user sees change:
+  
+  - `DetailView`'s mobile Edit action (`icon: 'edit'` → `'square-pen'`) draws its icon
+    again. Its items become an `action:bar` schema whose renderers resolve `icon` through
+    `renderers/action/resolve-icon.ts`, so the touch-breakpoint edit affordance had been
+    drawing a label with nothing beside it. `Edit === SquarePen`, so the glyph is unchanged.
+  - The `ui:icon` renderer's own declared default (`'smile'` → `'face-slightly-smiling'`, in
+    both the registration `icon` and the `name` input's `defaultValue`) resolves again: the
+    designer palette entry's glyph was blank, and an `icon` dropped from that palette
+    rendered nothing plus a `console.warn`. `Smile === FaceSlightlySmiling`, so the palette
+    looks exactly as it did.
+  - `plugin-list`'s `ViewSwitcher` moves `Grid` → `Grid3x3`, `BarChart3` → `ChartColumn`
+    (both identical objects, no visual change) and `GanttChartSquare` → `ChartGantt`. The
+    gantt one IS a glyph change: it matches the spelling the sibling `plugin-view` switcher
+    landed in objectui#5586, so one view type no longer draws two different icons depending
+    on which switcher is on screen.
+  
+  Four resolvability pins are added — in `plugin-detail`, `plugin-list`, `components` and
+  alongside the `DeclaredActionsBar` fixtures. Each asserts `icons`-record MEMBERSHIP rather
+  than resolvability, because every retired spelling repaired here is the SAME component
+  object as its replacement (`Edit === SquarePen`, `Smile === FaceSlightlySmiling`,
+  `Grid === Grid3x3`, `BarChart3 === ChartColumn`, `CheckCircle === CircleCheckBig`,
+  `XCircle === CircleX` are all true): a pin that rendered the glyph, or reached for the
+  export, would pass on the broken name. That is the blindness that let this ship.
+- 5a07e67: The `[page:header]` sparse-predicate warning no longer blames `hidden: true` — it
+  states what it actually measured (objectui#5399).
+  
+  When an action's `visible` predicate references a `record.<key>` the bound payload
+  does not carry, the warner names the missing key and then explained the cause:
+  
+  > Hidden (hidden: true) fields are stripped from detail payloads server-side, so a
+  > predicate gating on one may evaluate to a hide-by-default verdict.
+  
+  That cause is false, and it names a mechanism this repo does not own. `hidden` is a
+  UI concern — the framework spec describes it as "Hidden from default UI"
+  (`packages/spec/src/data/field.zod.ts`) — not a projection rule. Confirmed against
+  the framework checkout rather than taken on trust: ObjectQL's own strip for the
+  `__search` companion documents that the `hidden` / `readonly` / `system` markers are
+  "None of them is a PROJECTION rule", which is precisely why a dedicated strip rule
+  had to be written for that one column; drivers answer a query with no `fields` using
+  `SELECT *`; and `metadata-protocol` enumerates what the read path does drop —
+  `internal: true` columns and the `__search` companion, and nothing else. The only two
+  read-side uses of `field.hidden` in the framework are auto-view/auto-form column
+  generation and companion-source eligibility, neither of which removes a key from a
+  record body.
+  
+  So an author who read this diagnostic went hunting for a `hidden` flag they would
+  either not find, or find on a field the payload demonstrably still returns — while
+  the real source of the sparseness (a projected or partial read) went unexamined. A
+  confidently wrong cause in a diagnostic is worse than no cause, because it is
+  actionable in the wrong direction.
+  
+  The replacement states the fact this surface can actually see and the consequence it
+  does own: the page bound a payload without those keys, a projected or partial read
+  will not carry them, and the predicate therefore fails closed and hides the action.
+  The measured half of the message — action name, missing fields, predicate source —
+  is unchanged, and nothing about what triggers the warning changed.
+  
+  Message text only. The same false claim also sat in this warner's own doc comments
+  and in the comments of the test that pins the message; both are corrected here, and
+  the docstring now carries an explicit note against re-attributing the cause to
+  `hidden: true`. No other call site was swept.
+- 27308c5: `element:text_input` now ties its authored `description` to the field with
+  `aria-describedby`, so assistive tech announces the helper text as the input's
+  accessible description instead of leaving it as an unassociated paragraph
+  beside the field (objectui#5735).
+  
+  Before this the paragraph and the input were siblings with no programmatic
+  relationship: a screen reader moving to the field announced the label and the
+  value and never the helper text. The `label` half of the same block was already
+  wired (`htmlFor` against the input's `id`), which is what made the gap specific
+  to `description` rather than a general absence of a11y wiring — and the
+  identical key authored on a field INSIDE `renderers/form/form.tsx` has been
+  announced all along, so one authoring key behaved two ways depending on which
+  container the author reached for. It no longer does.
+  
+  The paragraph's id is minted per instance with `React.useId()` — the same source
+  `FormItem` mints the form renderer's description id from — and deliberately not
+  derived from `schema.id`. The two associations in this block need ids on
+  opposite ends: `htmlFor` names the INPUT, whose id only the author can supply,
+  so that wiring still holds only when they gave the node an `id`; `aria-describedby`
+  names the PARAGRAPH, which the renderer owns, so the description association
+  holds unconditionally and cannot collide when two nodes share an authored id.
+  The attribute is emitted only when a paragraph is actually rendered — an absent
+  or empty `description` leaves the input with no `aria-describedby` rather than a
+  dangling reference.
+  
+  The key's published `ComponentInput` description, which documented this gap in
+  so many words, is rewritten in the same change. Its closing advice — prefer
+  `label` for an instruction a user must not miss — is kept rather than deleted,
+  on a new basis: a description is announced after the field's name and screen
+  readers gate description text behind verbosity settings a user can turn down, so
+  it remains the half of the announcement most likely to go unheard.
+- 8689166: `element:text_input` now DECLARES the inline-translation arm on `label`,
+  `placeholder` and `description`, so the manifest gate stops reporting
+  `type-mismatch` on a locale map its own renderer has always resolved correctly
+  (objectui#5717).
+  
+  `@objectstack/spec` types all three keys as the `I18nLabel` union
+  (`string | Record<string, string>`) — measured on the installed 17.1.0 pin, per
+  key, from the schema's own verdicts — and `text-input.tsx` has resolved all
+  three through `pickLocalized` at their read sites since it was written. Only the
+  `ComponentMeta` entries stayed at a single `'string'` arm. Driven through the
+  same `manifestFromConfigs` + `validateTree` pair the JSX-page compiler and the
+  save gate use, an author writing `{ en: 'Owner', 'zh-CN': '负责人' }` got three
+  warnings on a write that renders correctly in the viewer's language:
+  
+  ```
+  <element:text_input> prop "label" expected a string
+  <element:text_input> prop "placeholder" expected a string
+  <element:text_input> prop "description" expected a string
+  ```
+  
+  That is the INVERSE of the direction the rest of this family moved in.
+  `element:record_picker.emptyText` (objectui#5590) and that block's `label` /
+  `placeholder` (objectui#5637) each held one arm for exactly as long as their
+  render site dropped the map, and gained the object arm in the change that taught
+  the render site to resolve it — never declare an arm the renderer drops. Here
+  the render site was never behind, so the same rule's other half applies:
+  withholding an arm the renderer resolves is the false declaration in the other
+  direction, and noise on legal writes trains authors (AI authors included) to
+  dismiss the `unknown-prop` and `type-mismatch` reports that are real.
+  
+  Per-key, not blanket. `defaultValue` on this same block keeps `['string',
+  'number']` — its contract has no object arm, measured the same way — and the
+  console specimen file keeps asserting that an `I18N_MAP` there still reports
+  `type-mismatch`. That control is what makes this a widening of three keys rather
+  than of a component.
+  
+  All three keys also gain a `description` written from what the renderer does
+  rather than from restating the contract: where each one lands in the rendered
+  output (a `<label>` above the field, the native `placeholder` attribute inside
+  it, a `<p>` below it), when each is omitted, and the locale fallback chain the
+  read site follows. No renderer behaviour changed.
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [69a2163]
+- Updated dependencies [8d3a529]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [b362c1b]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [199d31b]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [8d58f46]
+- Updated dependencies [689b979]
+- Updated dependencies [98c3a74]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [20e317c]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [305205a]
+- Updated dependencies [91783c4]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/react@17.7.0
+  - @object-ui/sdui-parser@17.7.0
+  - @object-ui/react-runtime@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/components/package.json b/packages/components/package.json
index bc5216958a..78e5f054b9 100644
--- a/packages/components/package.json
+++ b/packages/components/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/components",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Standard UI component library for Object UI, built with Shadcn UI + Tailwind CSS",
diff --git a/packages/core/CHANGELOG.md b/packages/core/CHANGELOG.md
index 8da3d58842..f31528a882 100644
--- a/packages/core/CHANGELOG.md
+++ b/packages/core/CHANGELOG.md
@@ -1,5 +1,1000 @@
 # @object-ui/core
 
+## 17.7.0
+
+### Minor Changes
+
+- 053fdc8: Console half of `ActionSchema.onSuccess` post-success navigation.
+  
+  `@objectstack/spec` declares `onSuccess` as a closed strict object
+  `{ navigate: string, openIn: 'self' | 'newTab' }`, refine-scoped to `type: 'api'` and
+  `type: 'script'` — the two action types whose success event carries a server response.
+  Nothing in this renderer read it, so an action declaring the hop navigated nowhere: the
+  block fell into `ActionRunner`'s older `ActionDef.onSuccess` chained-callback channel,
+  was dispatched as an action, and failed inside `executeNavigation` with "No URL provided
+  for navigation action" — a red toast and no jump. The motivating report is a clone action
+  that leaves the user sitting on the record they cloned from.
+  
+  `ActionRunner.handlePostExecution` now performs the declared hop through
+  `navigationHandler` — the same SPA seam every other navigator in that file uses, which
+  the console wires to react-router's `navigate`, so `openIn: 'self'` is a real in-place
+  route hop rather than a full-page load. `interpolateTarget` gains a `${result.*}` scope
+  alongside `${param.*}` and `${ctx.*}`, resolved against the handler's own return value
+  (the level `readActionPayload` reads, one below the action envelope) and supplied only by
+  this call site, so a target interpolated before its request still has no `result` to
+  name. `openIn` is read as the one member that changes the branch and no default is
+  written here — the spec materialises `.default('self')`, so parse output always carries a
+  resolved member — and the two `openIn` spellings stay apart: this reads
+  `onSuccess.openIn` (`'self' | 'newTab'`), never the top-level `type: 'url'` switch
+  (`'self' | 'new-tab'`), each of which spec refuses in the other's position.
+  
+  The console's server-action wrapper gains the matching handler-return half: a handler may
+  now return `openIn: 'self'` next to its `redirectUrl` to ask for the same-tab jump, while
+  a `redirectUrl` **without** `openIn` keeps its shipped new-tab behaviour unchanged. When
+  an action declares an `onSuccess` block, the wrapper defers to the runner and only tidies
+  its pre-opened tab, so one navigation happens rather than two.
+  
+  The pre-existing `ActionDef.onSuccess` chained-callback channel is unchanged. It is told
+  apart by the spec's own declaration — a non-array object whose `navigate` is a string —
+  and keeps running for every other shape.
+- 490d9a9: Grid headers offer a sort click only on columns the PLATFORM says it will order by
+  (objectui#5729 — the consumer leg of objectstack#10235, maintainer ruling A, 2026-08-23:
+  the platform serves an explicit per-column sortability signal and the grid reads it,
+  rather than re-deriving "virtual ⇒ unsortable" from field type).
+  
+  `GET /api/v1/meta/object/:name` now answers with a `sortability` projection on its
+  ENVELOPE — `{ fields: { [name]: { sortable, reason?, caveat? } } }`, computed at serve
+  time from the platform's own storage predicates, deliberately beside `item` rather than
+  inside it so the key stays un-authorable. The signal was reaching the browser and being
+  discarded one line before its only consumer: `ObjectStackAdapter.getObjectSchema` unwraps
+  the envelope to `item`, so every UI reader saw a document with no signal on it. It now
+  survives that unwrap, carried on the schema under a symbol key — invisible to
+  `JSON.stringify`, to `Object.keys` and to a spread, so a schema handed back at a metadata
+  write endpoint can never take it into a body the server parses strictly.
+  
+  `@object-ui/core` gains the one spelling of the consumer contract:
+  `isPlatformSortableField(projection, name)` is `true` iff an entry EXISTS for the name and
+  says `sortable: true`. Absence is a refusal — it is how the platform encodes an unknown
+  name, a dotted path and an unprovisioned audit column, all three of which the runtime
+  doors reject — so the `!== false` spelling every other optional flag in this repo uses
+  would get exactly that family backwards. A projection that is absent ALTOGETHER is a
+  different question with a different answer (`undefined`: no signal was served) and is
+  typed apart from an empty one, so a deployment older than the upstream change keeps the
+  behaviour it had rather than being told, falsely, that nothing on the object is sortable.
+  
+  Three things follow in the grid. The header click on a refused column ceases to exist, so
+  neither the old silent-unordered result nor the `400 INVALID_SORT` that replaced it is
+  reachable from it. A sort PERSISTED before the signal existed is filtered out of both what
+  the grid renders and what it emits, so a restored personalization cannot ride back into
+  the next `persistViewPatch({ sort })` — the half-fix where the affordance is gone and the
+  PUT still fires. And the relational carve-out is untouched and deliberately not delegated
+  to this signal: the platform answers `sortable: true` for a `lookup` (it has a stored
+  foreign key and both runtime doors accept ordering by it), while the grid withholds that
+  header for a different reason — a column of names ordered by an invisible id.
+  
+  Columns carrying `caveat: 'unprovisioned-anchor'` keep their click. The runtime accepts
+  those sorts; refusing what the platform does not refuse would recreate declared-≠-enforced
+  drift in mirror image.
+- 44d075b: `ComponentMeta` at the registry is now DERIVED from the one declaration in
+  `@object-ui/types` instead of restating it, and `tags` / `description` reach the
+  registration surface (objectui#6067).
+  
+  ## The convergence
+  
+  `packages/core/src/registry/Registry.ts` declared its own `ComponentMeta`: thirteen
+  keys, of which nine were restated from `@object-ui/types`' `base.ts`, four were
+  registry-only (`tier`, `namespace`, `skipFallback`, `labelling`), and `tags` /
+  `description` were **absent** — although both are declared on the canonical type and on
+  the `ComponentMetaSchema` zod mirror. Two of the three authorities agreed and the
+  registration surface did not, so those two keys were unwritable at exactly the
+  declaration most component registrations import. That is the same two-key delta
+  objectui#5893 had just closed inside `@object-ui/types`, arriving a third time on a
+  third declaration, and objectui#5671 had already made the identical move for the sibling
+  type `ComponentInput` in this very file.
+  
+  It is now:
+  
+  ```ts
+  export type RegistryComponentMetaExtras = {
+    tier?: 'public' | 'internal';
+    namespace?: string;
+    skipFallback?: boolean;
+    labelling?: 'control' | 'group' | 'display';
+  };
+  
+  export type ComponentMeta = CanonicalComponentMeta & RegistryComponentMetaExtras;
+  ```
+  
+  `RegistryComponentMetaExtras` is newly exported from `@object-ui/core`.
+  
+  **What changes for a consumer: `tags` and `description` become writable on the registry's
+  `ComponentMeta`. Nothing narrows.** No key is removed, no key is renamed, and no key's
+  type changes, so no existing registration stops compiling — verified by type-checking all
+  37 workspace consumers of `@object-ui/core` (`pnpm --filter '...@object-ui/core'`), which
+  is why this is a widening rather than the contract break a rename would have been. All
+  four registry-only keys have live consumers, and they are still declared here.
+  
+  This is `minor` under this repository's policy that its own breaking changes never declare
+  `major` (`scripts/check-changeset-no-major.mjs`); nothing here is breaking in any case.
+  
+  ## Converge rather than rename, and why the four keys did not move
+  
+  The alternative dispositions were to rename the type so the name stops claiming a mirror,
+  or to move the four registry keys onto `@object-ui/types`' `ComponentMeta` and re-export
+  it outright the way objectui#5671 handled `ComponentInput`.
+  
+  Renaming was rejected because it cannot be done without a break: `@object-ui/core` is
+  published, `ComponentMeta` is exported from it, and dropping the name would break every
+  external consumer — while keeping it as an alias would leave the mirror claim standing
+  under a second spelling, which fixes nothing.
+  
+  Moving the four keys was rejected because `skipFallback` and `namespace` are registration
+  mechanics — they describe how the registry keys an entry, not what a component is — and
+  `@object-ui/types`' `ComponentMeta` is the general, plugin-facing, AI-facing type. The
+  extension keeps them where they are read, under their own named type, while the eleven
+  shared members exist in exactly one place and can no longer drift.
+  
+  ## Pinned by key set, not by assignability
+  
+  Every member of both shapes is optional, so `extends` is mutually **true** across the
+  diverged pair — an assignability assertion is green on the defect and would not have
+  caught it. Measured on the emitted `.d.ts` of both packages, before and after:
+  
+  | reading | before | after |
+  |---|---|---|
+  | `Core extends Canonical` | `true` | `true` |
+  | `Canonical extends Core` | `true` | `true` |
+  | `Exclude<keyof Canonical, keyof Core>` | `"tags" \| "description"` | `never` |
+  | `Exclude<keyof Core, keyof Canonical>` | the four registry keys | the four registry keys |
+  
+  The new pin asserts the third row and names the fourth explicitly; the assignability pair
+  is kept beside it, labelled, as the control that shows what it cannot see. A source-level
+  assertion that the canonical members are not restated locally covers the remaining failure
+  mode — a member-identical copy, which every `keyof` comparison stays green on and which is
+  how the copy this replaces began.
+- d7573b3: `ComponentInput` is now declared once and re-exported, instead of restated in three
+  places (objectui#4972).
+  
+  `@object-ui/core`'s `ComponentInput` (`registry/Registry.ts`) and `@object-ui/types`'
+  plugin-scoped `ComponentInput` (`plugin-scope.ts`, published as `PluginComponentInput`)
+  were structural copies of the interface in `@object-ui/types`' `base.ts`. Both are now
+  re-exports of that one declaration, which is the disposition objectui#4580 ruled for the
+  identical shape — *a structural copy would reproduce the defect the moment either side
+  moved* — and the way `core/src/types/index.ts` already handles `SchemaNode`.
+  
+  Either side had already moved. `base.ts` declared thirteen keys; both copies declared
+  nine, so `min` / `max` / `step` / `placeholder` were missing from **the copy every
+  component registration actually imports**. Those four keys were unwritable at any real
+  registration — a plain TypeScript error at the call site — while `ComponentInputSchema`
+  (the zod schema) and `ComponentMeta.inputs` both accepted them. The publication face
+  advertised four keys the authoring face rejected. Measured over the repository, no
+  registration had tried to write one yet, so nothing a user hits was broken today; what
+  changes is that the four keys become writable, and there is no longer a second
+  declaration for the next widening to miss.
+  
+  `ComponentInput`'s arm vocabulary (`ComponentInputControlType`) was already a single
+  declaration imported by all three sites (objectui#3832); this converges the rest of the
+  interface.
+  
+  Measured, not assumed: `@object-ui/core`'s published entry `dist/index.d.ts` is
+  byte-identical across the change (sha256 `f6494f80…`, both legs). That gauge is reported
+  here only with its control — a probe that added a *required* key to `ComponentInput` left
+  the same file byte-identical, because `dist/index.d.ts` is a 63-line barrel of
+  `export *` lines that names `ComponentInput` zero times. The gauge that can actually fail
+  is the emitted declaration file: `dist/registry/Registry.d.ts` changes, as does
+  `@object-ui/types`' `dist/plugin-scope.d.ts`, and those two files are the *only* emitted
+  declarations that change in either package.
+  
+  `WidgetInput`'s union-arm capability is deliberately untouched — a different gate path
+  and a separate judgment.
+- bf3edfe: `ComponentRendererProps` is now declared once and re-exported, instead of
+  hand-declared a second time in `@object-ui/core` (objectui#4594).
+  
+  `@object-ui/core`'s `ComponentRendererProps` (`src/types/index.ts`) was a
+  non-generic interface typing `schema` as `SchemaNode`, while
+  `@object-ui/types`' declaration of the same name is generic —
+  `ComponentRendererProps< TSchema extends BaseSchema = BaseSchema >` with
+  `schema: TSchema`. Same name, both exported from their package entry, from two
+  packages the same consumers import together: which declaration a call site got
+  depended on which package it reached for, and the two disagree about whether a
+  primitive node is admissible. Core's is now a re-export of types', which is the
+  disposition objectui#4580 ruled for `SchemaNode` two lines above it in the same
+  file, and objectui#4972 for `ComponentInput` — *a structural copy would
+  reproduce the defect the moment either side moved*.
+  
+  **Published-surface effect, and the reason it is not neutral.** Resolved
+  through the TypeScript checker from `core/dist/index.d.ts` over a clean rebuild
+  of both legs, `ComponentRendererProps` as reached through `@object-ui/core`
+  moves from non-generic with
+  `schema: BaseSchema | string | number | boolean | null | undefined` to
+  `ComponentRendererProps<TSchema>` with `schema: TSchema`, defaulting to
+  `BaseSchema`. `schema` therefore **narrows** back to the object form — core's
+  copy had silently widened when objectui#4608 made core's `SchemaNode` a
+  re-export of types' union — and the type gains a parameter. **Nothing imported
+  it**, on either side, re-verified repo-wide on the merged ref, so no call site
+  can observe either move; the narrowing is recorded here because it is a change
+  to a published type, not because a consumer is affected.
+  
+  A compile-time pin now holds the reconciliation from
+  `@object-ui/react` — the only position that resolves both packages through
+  `node_modules` — alongside the existing `SchemaNode` one. It is a test-only
+  addition and emits nothing, so `@object-ui/react` takes no bump of its own.
+- e719ebd: `data-table` reads the declared `header`; the producers translate `label` into it.
+  
+  `TableColumn` declares `header: string` and does not declare `label`. The
+  renderer's column normalization nonetheless read `header: col.header || col.label`,
+  so the same key had one spelling the type admits and one only the runtime did.
+  That alias is gone (objectui#5351), and the translation it used to perform happens
+  once at each producer instead: metadata vocabulary in, adapter vocabulary out.
+  
+  **This narrows what `data-table` accepts, so read this if you author `data-table`
+  nodes by hand.** A column spelled `{ label: 'Stage', accessorKey: 'stage' }` on a
+  directly authored `data-table` now renders a **headerless** column over live
+  cells. Spell it `header` — the key `TableColumn` has always declared. Columns
+  reaching `data-table` through `object-data-table`, `object-grid` or a related
+  list are unaffected: those producers resolve `header` for you from the spec's
+  `ListColumnSchema.label`, so every spelling they accepted before they still
+  accept.
+  
+  `@object-ui/core` gains `columnHeader()` alongside `columnIdentity()` — the reader
+  producers use to cross that boundary. It is adapter-first (`header` wins over
+  `label`), so an author who addressed the table directly is never overwritten.
+  
+  `object-data-table` also gains a fix from the same move: a column carrying a
+  `label` used to render a **blank** header there even while the alias existed,
+  because the widget's field-meta enrichment overwrote the authored `label` before
+  the adapter ever saw it. `{ field: 'stage', label: 'Stage' }` now renders "Stage".
+  
+  The sibling `accessorKey: col.accessorKey || col.name` alias is **unchanged** here
+  and still resolves. Retiring it is objectui#5120's remaining step, which is
+  gated on two published skill guides that teach that spelling.
+- fa429cf: The register-meta key `defaultChildren` is retired (objectui#5051).
+  
+  It was declared in four places, produced in eleven, and read in **none**. The designer's
+  drop path builds a new node from its twin key only — `PageDesigner.tsx`,
+  `props: paletteItem?.defaultProps ?? {}` — with no `children:` line, so a palette item
+  that declared `defaultChildren` dropped an **empty** node and the declared children never
+  materialised. Nothing rendered the wrong thing; an entire declaration surface was simply
+  inert, which is the declared-but-unenforced shape ADR-0049 targets. Per the maintainer
+  ruling of 2026-08-19, the key is removed rather than wired up; if designer
+  default-children UX is ever product-wanted it returns as its own designed card.
+  
+  **If you author plugins against the published register-meta table, drop the key.** It is
+  gone from `skills/objectui/guides/plugin-development.md`, which had been teaching it. A
+  meta that still declares it stays *valid*: `ComponentMetaSchema` is a plain `z.object`,
+  and measured on zod 4.4.3 that STRIPS unknown keys rather than rejecting them — so the
+  key is silently dropped from the parse output instead of failing validation. TypeScript
+  authors get the loud signal instead: all three `ComponentMeta` declarations
+  (`@object-ui/types` `base.ts` and `plugin-scope.ts`, `@object-ui/core` `Registry.ts`) no
+  longer offer it, so re-declaring it is now a compile error.
+  
+  **No runtime behaviour changes in either direction.** No code path read the key before
+  this change, and the eleven producers that set it (`sidebar.tsx` x10, `span.tsx`) were
+  feeding a reader that did not exist. Dropping a `span` or any of the ten sidebar types
+  into the designer produces exactly the node it produced yesterday.
+  
+  Two suites keep it retired, one per package: `packages/types` pins the zod twin (the key
+  is absent from the parse output, with a surviving sibling asserted present through the
+  same parse as the control) plus the two TS twins with `@ts-expect-error`, and
+  `packages/core` pins the registration surface the eleven producers were written against.
+  Both are compile-time-enforced through each package's chained `tsconfig.test.json`.
+- 105f3c5: Retire `CRUDSchema` and the `type: 'crud'` node spelling (objectui#5373,
+  maintainer ruling 2026-08-20, route 2) under ADR-0049 enforce-or-remove.
+  
+  `crud` had four declaration faces and no registered renderer, for the whole
+  life of the key: the TS interface (`packages/types/src/crud.ts`), the zod
+  mirror (`packages/types/src/zod/crud.zod.ts`), a dedicated branch in
+  `validateSchema` that affirmatively PASSED it, and `CRUDBuilder` in
+  `@object-ui/core`. A node spelling it painted the OBJUI-001 "Unknown component
+  type" panel, and `content/docs/api/schema-reference.md` published it as
+  reference material — so a reader (or an AI author) who copied the page got a
+  red panel.
+  
+  Removed from `@object-ui/types`: the `CRUDSchema` interface and its zod
+  mirror, the four shapes that existed only to type its keys — `CRUDOperation`,
+  `CRUDFilter`, `CRUDToolbar`, `CRUDPagination` and their zod mirrors and
+  `…SchemaType` aliases — and `CRUDSchema` as a member of `CRUDComponentSchema`,
+  which is what took it off the node union `AnySchema`. `ActionSchema`,
+  `DetailSchema` and `CRUDDialogSchema` are unchanged and remain the union's
+  members.
+  
+  Removed from `@object-ui/core`: `CRUDBuilder` and the `crud()` factory.
+  
+  Authoring `crud` is now REFUSED BY NAME rather than passed or silently
+  ignored. `validateSchema` returns an `error` with `code: 'RETIRED_TYPE'` on
+  `schema.type` — at any depth, since it is what `validateChildren` recurses
+  with — so `assertValidSchema` throws and `isValidSchema` answers `false`. The
+  message names the migration: `object-grid` for the record table with its
+  toolbar, filters, pagination and row/batch actions, `object-form` for the
+  create/edit form, and `detail` for the record view. `api/schema-reference.md`
+  is rewritten around those shapes.
+  
+  Note on blast radius: the repository itself contains zero authored `crud`
+  nodes and zero registrations of the key (measured on the merge base against
+  the doc gate's own 659-key registry derivation, which reads `register` and
+  `registerLazy` alike). That is an IN-REPO zero, not an npm zero — a published
+  consumer that imported the `CRUDSchema` type, called `crud()` / `CRUDBuilder`,
+  or authored `type: 'crud'` will see a compile error or a validation error
+  respectively. Both are the intended, loud replacement for a shape that has
+  never rendered.
+- d1ab06f: Row predicates declare a canon: `record.*`. The bare shorthand and `data.*` now
+  warn once, and are unchanged otherwise.
+  
+  A row predicate (`visible` / `disabled` / `enabled` on an action renderer, a row
+  scope, a `record:alert`) has bound the row three ways since objectui#4075 —
+  `record.status`, bare `status`, and `data.status` — without any of them being
+  declared the contract. The maintainer ruled that question on 2026-08-20
+  (objectui#5330, option B), mirroring the objectstack#7917 option-② precedent for
+  the identical renderer-tolerance shape: **the canon is `record.*`**, and the
+  other two enter a deprecation window.
+  
+  The canon states the **server's** accept set, which was this card's first
+  measurement and turns out to be strictly narrower than the renderer's. Measured
+  against `@objectstack/formula@17.1.0`, the engine the server evaluates with:
+  
+  | spelling | server runtime | server authoring oracle |
+  |---|---|---|
+  | `record.status` | `{ ok: true, value: true }` | accepted |
+  | bare `status` | `Unknown variable: status` | refused |
+  | `data.status` | `Unknown variable: data` | **silently accepted** |
+  
+  `buildScope({ record })` mounts exactly `['record']` — `data` is never bound and
+  the row's fields are never flattened to top level. The three-way binding is a
+  client tolerance with no server counterpart, which is why the warning belongs on
+  this side.
+  
+  `data.*` is the dangerous one, and the reason the warning exists. `data` is in
+  `@objectstack/formula`'s `SCOPE_ROOTS`, so the server's bare-identifier oracle
+  waves it through — that list is a deliberately generous "never faults" lint
+  baseline, not the runtime accept set. A `data.*` row predicate therefore passes
+  every authoring gate the platform has and then binds nothing at runtime: not an
+  error, a constant `false`. A `visible` that is constantly false is a button that
+  silently never appears — the objectui#4075 fail-closed signature.
+  
+  What ships:
+  
+  - `@object-ui/core` exports `detectNonCanonicalRowSpelling`,
+    `warnNonCanonicalRowSpelling`, `resetRowPredicateCanonWarnings` and
+    `ROW_PREDICATE_CANONICAL_ROOT` from a new `evaluator/rowPredicateCanon.ts`,
+    which carries the canon statement and the measurement.
+  - Both evaluation tiers report once, in dev: `evalRowPredicate` (core) and
+    `useCondition` (react, for bags bound by `usePredicateRecordContext`).
+  - Detection reuses the server's own oracles (`collectCelRootIdentifiers`,
+    `firstUndeclaredReference`) rather than a regex, so no second dialect
+    judgement is invented client-side.
+  
+  **No spelling is removed and no behaviour changes.** Every predicate that
+  resolved before resolves now — the ruling defers removal behind a stored-metadata
+  survey, and the warning is what makes that survey possible (ADR-0078: a
+  tolerance nothing ever reports can never be retired).
+  
+  The deprecation is scoped to the **runtime record layer**. `data` remains the
+  canonical root one layer over, in a metadata-editing form (ADR-0089 D3
+  `CANONICAL_ROOT_BY_LAYER`), and the detector stands down there.
+- 91783c4: Three more secret-field spellings no longer render a secret in clear text on the form's unregistered-widget branch.
+  
+  Measured on `main` at `f2e11ae6f`, the real `form` renderer on the built-in path
+  (no `registerAllFields()`), before and after objectui#5322's fix:
+  
+  ```
+  type            registry hit   rendered type
+  ui:password     true           text
+  secret          false          text
+  field:secret    false          text
+  ```
+  
+  Two halves, per the maintainer ruling of 2026-08-20:
+  
+  - **`@object-ui/core` — an unresolvable namespaced widget id is now an authoring
+    ERROR.** A form field's widget id (`widget`, else `type`) may name the
+    `field:` namespace or a bare name; any other namespace resolves no field
+    widget (objectui#5254) and used to degrade silently to a plain text box.
+    `validateSchema` now reports `UNRESOLVABLE_FIELD_WIDGET_NAMESPACE` and
+    `assertValidSchema` throws. Behaviour change: a schema that previously
+    validated with e.g. `type: 'ui:password'` is now invalid — inventing a
+    plausible-looking widget id fails loudly instead of rendering clear text.
+    `field:` ids stay valid whether or not the widget is registered, since
+    registration is a runtime fact an authoring-time validator cannot see.
+  - **`@object-ui/components` — the known secret types cover the remaining
+    spellings.** Bare `secret` and `ui:password` render the native masked input,
+    and `field:secret` is refused outright like `field:password`. Existing authors
+    need no migration.
+  
+  `ui:password` **is** registered — as an SDUI node renderer for a top-level
+  `{ type: 'email' }`-style node — so an author who checked whether it resolved
+  got a yes and still got a clear-text box on the field path. No producer emits
+  any of the three; all are reachable only through a hand-authored standalone
+  form schema, which is exactly the surface where the author is the producer and
+  no normalizer sits in between.
+- 2d36552: Pins `@objectstack/spec`, `@objectstack/client`, `@objectstack/formula` and `@objectstack/lint` to `17.1.0`, and adapts the two consumer surfaces the new build moves.
+  
+  The pin itself is a lockfile refresh — every manifest already declared `^17.0.0`, which admits `17.1.0`, so no dependency range changed. All four move together: a split resolution is what produced the dual-version spec graph that reddened `check:spec-symbols` in this repo's history.
+  
+  **A `icontains` filter now reaches the driver as a filter.** `icontains` is a canonical `VIEW_FILTER_OPERATORS` member as of `17.1.0`, so an author can declare it on a `ViewFilterRule` and the spec validates it — but `@object-ui/data-objectstack`'s alias table had no row for it, and an unmapped operator is how this adapter shipped an unfiltered query before (objectstack#3948). It is an identity row like `contains`: `icontains` is itself a member of `VALID_AST_OPERATORS`, so the spelling the author writes is the spelling the AST takes, and no case-sensitivity is translated away. Declared rather than left to the table's `?? op` fall-through, on the rule its own parity test states — the AST gate accepting a spelling is not the driver compiling it into a `WHERE` clause.
+  
+  The same operator reaches the list view's own bridge: `@object-ui/plugin-list`'s `mapOperator` gains an explicit `icontains` arm. The emitted spelling is identical to the input, but the arm is written out rather than left to the `default` passthrough — `icontains` is its own member of `VALID_AST_OPERATORS`, so a raw passthrough is accepted *today*, and depending on that coincidence is what the bridge's own parity test records as how it once stopped discriminating.
+  
+  `@object-ui/core` adds `onSuccess` to its spec key inventory, so an author writing the key `17.1.0` now declares is no longer warned that it is unknown. That is a diagnostic statement only — the four declared action surfaces still drop the key before it reaches the runner, which is tracked separately.
+  
+  **A stored view filtering case-insensitively still shows that operator when it is reopened.** `@object-ui/plugin-view`'s canonical-to-builder table is keyed by `ViewFilterOperator`, so `17.1.0` adding `icontains` failed to compile rather than letting the operator reach the FilterBuilder as a raw spelling its dropdown cannot select. It maps to the builder's `containsCaseInsensitive` — the id that authors the spec's `$icontains` — and deliberately not to `contains`, which would quietly rewrite a case-insensitive filter into a case-sensitive one the next time the view was saved.
+  
+  **The page-editor palette keeps one entry per renderer.** `17.1.0` retires `element:filter` from `PageComponentType` and adds `record:discussion`, leaving the member count at 34 either side — so the swap is invisible to any count-based reading. The stale `element:filter` exclusion is dropped, and `record:discussion` is excluded because it is the *same renderer* as the already-offered `record:chatter`, not because it is unauthorable. Nothing the palette offers changes.
+  
+  **The console eager-closure ceiling is re-baselined, by maintainer ruling.** The release is roughly 930 KB larger uncompressed and nearly all of it lands in `vendor-objectstack-*.js`, which put the closure past a ceiling that was deliberately sized to catch a 89 KiB regression — the gate refused the bump, correctly. Raising it was escalated rather than taken locally, because gate-strength policy had been ruled the maintainer's; the ruling on objectui#5531 authorised the raise. `MAX_EAGER_CLOSURE_GZIP_BYTES` and the `BASELINE` it is derived from move together in one commit, keeping headroom at 2.00% and below the 91,136-byte regression size the gate must still catch. The gate's *sensitivity* is untouched: a repeat of that regression from the new baseline still fails. No behaviour ships from this file — it is CI policy, recorded here because the version it governs is the one this changeset publishes.
+
+### Patch Changes
+
+- 9801765: The selection bar's built-in **Delete** now honours `userActions.delete.visibleWhen`
+  per selected record (objectui#4420). It used to read that key as a bare boolean — the
+  object-level verdict only — so ticking a record the author's predicate excludes still
+  offered the red Delete, and pressing it deleted the record the predicate was written to
+  protect. The row kebab on the same screen hid its Delete correctly, so one declared key
+  meant two different things on two surfaces.
+  
+  Ruled by the maintainer on 2026-08-17 (behaviour 1 of the card's three): **filter the
+  operation and report the skipped**. The bar evaluates the predicate once per selected
+  record, the delete runs over the allowed subset, and the excluded records are reported
+  rather than silently dropped. The button itself is never hidden or disabled by the
+  predicate — a mixed selection is not punished for one stray tick — and a selection where
+  every row is excluded is a legible refusal rather than an unexplained absence.
+  
+  - `@object-ui/core` gains `partitionRowsByPredicate`, the set-shaped counterpart of
+    `evalRowPredicate`: the fail-closed per-record fold a bulk gate needs, written once.
+    A bulk gate evaluates N records in a loop, which is why it can never be a hook.
+  - `@object-ui/plugin-grid`'s bulk bar routes an excluded selection through
+    `BulkActionDialog`, whose existing `bulk-skipped-notice` slot reports the skipped
+    count; a selection with nothing excluded keeps the consumer's own delete flow
+    untouched. `resolveRowCrudAffordances` now also returns `objectDeletePredicates` —
+    the bulk half of the same predicates, gated on the object verdict rather than on the
+    row `onDelete` wiring. The dialog declines to run over zero records.
+  - `@object-ui/plugin-list`'s non-grid bulk bar (kanban / calendar / gallery / …) filters
+    the built-in `delete` to the eligible subset and states the skipped count inline.
+  
+  Custom bulk action ids are untouched: they route through the action runner carrying
+  their own gates. This is a UI affordance — server enforcement was never the leak.
+- 546ddf7: A node-gate visibility predicate that FAULTS now says so in a production build, once per
+  distinct predicate source (objectui#6038, maintainer ruling 2026-08-25, option B: "the
+  silence is no longer an accepted property"). Observability only — no verdict moves.
+  
+  `SchemaRenderer`'s visibility chain is fail-open: a predicate that cannot be evaluated
+  resolves to the same answer as one that said yes, so a gate that stops biting looks
+  exactly like a gate the author got right. The diagnostic that names it (objectui#5454 /
+  objectui#5687) sat behind a `__DEV__` short-circuit, because the only fault-detection
+  channel available was `throwOnError`, and on the CEL branch `evaluateCelCondition`
+  implements that by evaluating **twice** — too expensive to ship for every predicate of
+  every node.
+  
+  **What production actually printed before, measured per dialect on the built evaluator**
+  — the card's premise held for one dialect of three, and the other two failed in opposite
+  directions:
+  
+  | dialect | production console, before |
+  |---|---|
+  | bare string | **nothing** |
+  | `{ dialect: 'cel' }` envelope | one generic line, deduped per source |
+  | `${…}` template | one generic line **per evaluation**, never deduped |
+  
+  So the dialect objectstack#11254 measured a live gate breaking on was the silent one,
+  while the template dialect was the console flood the ruling's rate-limit clause exists to
+  prevent.
+  
+  **The fix reports the fault the evaluator already detected, at the same number of engine
+  calls.** `EvaluationOptions.onFault` is a new passback on `@object-ui/core`'s
+  `ExpressionEvaluator`: every fault site is already inside a `catch`, or already holds the
+  canonical engine's failure reason, so nothing is evaluated twice. It mirrors, one layer
+  up, the seam `FieldPredicateDiagnostic` already documents (`warn: false` plus a reason
+  passback), and supplying it transfers reporting to the caller so one fault stays one
+  line. Pinned: the CEL branch performs the same number of record reads with the passback
+  as without it, and strictly fewer than the `throwOnError` probe.
+  
+  `SchemaRenderer` passes it in production and reports through the **same** reporter the dev
+  branch uses — same message, same severity, same dedupe `Set`, same key. Development and
+  production now print the identical line for the identical fault; the `__DEV__` gate no
+  longer decides *whether* a fault is reported, only *how* it is detected.
+  
+  `page:tabs` item-level `visibleWhen` (`@object-ui/components`) is covered by the same
+  reporter and the same rate limit. It swallowed the identical fault under a different
+  helper, and it was the worse of the two: the node gate at least reported in development,
+  while a faulting item predicate was silent in *both* builds on a gate whose false verdict
+  removes an entire tab, header and panel.
+  
+  **Rate limit:** deduped per (node type, gate key, predicate source) — never per render and
+  never per node instance. A two-hundred-row list of one broken predicate is one line; a
+  second distinct predicate source still gets its own line. Both halves are pinned, because
+  a test that asserts only "a warning was emitted" is equally green on an implementation
+  that emitted fifty, and one that asserts only "exactly one" is equally green on an
+  implementation that suppresses everything.
+  
+  **Not changed by this card, deliberately:** the fail-open semantics themselves; the
+  objectui#5687 adapter-only `data.*` report, which stays development-only under its own
+  2026-08-22 ruling (that path is not a fault — the predicate evaluated perfectly, against
+  the wrong object); and the `/forms/:name` scope wiring of objectui#6262, which lands in
+  its own PR.
+  
+  `reportUnresolvableVisibilityPredicate`, `formatUnresolvableVisibilityMessage`,
+  `UNRESOLVABLE_VISIBILITY_PREFIX` and `__resetVisibilityPredicateWarnings` are now exported
+  from `@object-ui/react` so every surface that evaluates a node `visibleWhen` shares one
+  reporter and one rate limit — a second copy would mean a second dedupe `Set`, and one
+  authored predicate would be entitled to one line per package instead of one line.
+- a26b9e4: `packages/core/src/adapters/README.md` now documents the adapters that are actually in that
+  directory, and the ObjectStack material it carried moved to the package that owns the behaviour
+  (objectui#6213). Both files ship to consumers — `@object-ui/core` publishes its `src/`, and a
+  README rides every tarball — so this was published documentation describing the wrong package.
+  
+  The page had been left behind when the ObjectStack adapter moved out to
+  `@object-ui/data-objectstack`: its headings, feature list, filter-operator table and
+  query-parameter table were all about that adapter, and its one-entry "Available Adapters" list
+  told a reader Object UI has exactly one adapter and that it comes from `@object-ui/core`.
+  `ApiDataSource`, `ValueDataSource`, `resolveDataSource`, `runBatchTransaction` and
+  `emulateBatchTransaction` — the five exports that directory really ships — were named nowhere.
+  
+  - **`@object-ui/core`**: the page now opens with what the directory holds, gives each export a
+    usage snippet and a `provider` mapping, and points at `@object-ui/data-objectstack` for the
+    ObjectStack adapter. `## Creating Custom Adapters` is unchanged — it is the one section that was
+    always about this directory.
+  - **`@object-ui/data-objectstack`**: gains a `## Query Translation` section carrying the
+    filter-operator and query-parameter mapping tables, the AST conversion example and the sorting
+    example. That material existed **only** in the `core` copy — this package's README documented
+    query translation as a single feature bullet — so it is ported, not dropped.
+  
+  No runtime behaviour changes; the duplicate copy of one package's documentation living under
+  another package is what goes away.
+- 3c2b6f7: Two deprecation warnings pointed at `MIGRATION_GUIDE.md`, a file deleted from the
+  repository in `8c5d20455` (objectui#6342).
+  
+  `Registry.register()`'s missing-namespace warning now points at the live docs page
+  that documents namespaced registration
+  (`/docs/guide/plugin-development#namespaced-registration`) instead of the deleted
+  guide. `ValidationEngine`'s function-based-condition warning drops its `See:` line
+  entirely: the deleted guide covered component namespaces and lazy field
+  registration and never documented conditions at all, so that pointer was
+  misdirected as well as dead, and the warning already carries the complete
+  before/after migration inline.
+  
+  Both are console messages shipped to application developers, so neither can use
+  the immutable `git show <sha>^:<path>` provenance form objectui#6275 used for a
+  docblock — a reader of the npm package has no repository to run it against.
+- 5961030: `@object-ui/core` and `@object-ui/data-objectstack` now declare
+  `"@objectstack/spec": "^17.2.0"` rather than `^17.0.0`, which is the lowest published
+  spec that carries every symbol each package's own build output references
+  (objectui#6361).
+  
+  `packages/core/dist/utils/column-sortability.d.ts` references
+  `FIELD_SORTABLE_UNPROVISIONED_ANCHOR`, `FIELD_UNSORTABLE_VIRTUAL_TYPE`,
+  `FieldSortability` and `ObjectSortability` from `@objectstack/spec/api`, and
+  `packages/data-objectstack/dist/index.js` references the first two — none of which
+  `@objectstack/spec@17.0.0` exports. Measured against the published tarballs rather than
+  the installed tree, by `scripts/check-spec-range-floors.mjs`: six `floor-too-low`
+  findings across the two packages, and `^17.2.0` is that gate's own computed answer for
+  both. So the old range was a claim neither package could honour: any consumer
+  resolution that lands 17.0.0 — a sibling pinning it exactly, an `overrides` entry, a
+  mirror two minors behind — satisfied `^17.0.0` and got a dangling reference.
+  
+  Nothing a consumer installs today changes: normal resolution already picks the newest
+  17.x, and `pnpm-lock.yaml` still resolves `17.2.0` on both edges after the bump — only
+  the recorded `specifier:` moves. No source and no behaviour changes, which is why this
+  is scored `patch`, on the reasoning objectui#5793 used for the same remediation on
+  `@object-ui/plugin-detail`.
+  
+  The bump is release-blocking rather than cosmetic. `check:spec-floors` is deliberately
+  not a `pull_request` job, so every PR stayed green while its blocking copy on the
+  publish path — `pnpm changeset:publish` runs it before a single tarball reaches npm —
+  would have cancelled the next release.
+- 299102e: `ExpressionEvaluator.evaluate` now reports a faulting `${…}` at most **once per authored
+  source** instead of once per evaluation (objectui#6444). It is the hottest of the three
+  predicate paths in this area — `SchemaRenderer` calls it for every `properties.*` value,
+  every `props.*` value and `content`, for every node, on every render — so a single broken
+  `${…}` prop in a 200-row list wrote 200 console lines per render, and 200 more on the next
+  one. Measured on the built evaluator before the fix: three identical faulting
+  `evaluateCondition` calls produced 3 lines where the `{ dialect: 'cel' }` envelope produced
+  1; the 200-row list produced 200. After: 1 in every case.
+  
+  This is the one-per-source rate limit both sibling reporters already carry
+  (`warnPredicateFailure` in `fieldRules.ts`, `visibilityDiagnostic.ts` in `@object-ui/react`),
+  not a third mechanism. The dedupe key is the predicate's **authoring** identity — the fault
+  site plus the source text, never the scope it ran against — which is both the siblings'
+  precedent and the defect itself: the 200-row flood is one authored source evaluated against
+  200 distinct scopes, so a scope-sensitive key would emit all 200 lines again.
+  
+  Nothing else moves. The two message texts are unchanged, a distinct broken source still gets
+  its own line, `EvaluationOptions.onFault` still fires on every fault (objectui#6038's passback
+  contract, so a caller doing its own warn-once bookkeeping keeps control of it), `throwOnError`
+  still throws on every evaluation, and no symbol is added to the published surface.
+- 831be72: Dev-mode `validateSchema` no longer reports every expression-valued `visible` / `disabled`
+  gate as an invalid schema (objectui#6505). `BASE_SCHEMA_RULES` declared both keys
+  `typeof value === 'boolean'`, so the exact authoring form the docs teach —
+  `{ "type": "button", "disabled": "${record.stage == 'closed'}" }` — printed
+  `disabled must be a boolean` and its host element got `data-obj-schema-invalid`, the cue
+  apps are told to hang a red outline off.
+  
+  **The accept set widens to what the protocol already declares and the runtime already
+  accepts, not beyond it.** `AGENTS.md` §4 declares both keys as expressions, `SchemaRenderer`
+  evaluates them through `hasDeclaredPredicate` + `evaluateCondition`, `@objectstack/spec`
+  normalizes every authored predicate into a `{ dialect, source }` envelope, and the
+  objectui#3862 / objectui#3955 rulings are entirely about which expression spellings count
+  as declared. This table was the one place in the repo that disagreed, so this restores
+  declared = enforced rather than changing a contract.
+  
+  **The rule still bites, and that half is pinned separately.** The two keys stay in
+  `BASE_SCHEMA_RULES`: a number, `null`, `{}`, an array, `''`, whitespace-only predicate text
+  and the empty / blank-`source` envelope (objectui#3960) are all still reported at their own
+  path with `INVALID_TYPE`. Every one of those was reported before this change too — the
+  accept set is a strict superset of the old one, so nothing that validated stops validating
+  and nothing refused becomes accepted. The message now names both halves of the accept set
+  instead of only the half that did not change.
+  
+  The verdict is delegated to `hasDeclaredPredicate` (`evaluator/declaredPredicate.ts`), the
+  repo's single definition of "is a predicate gate declared on this value?"
+  (objectui#3850's ruling), rather than answered a second time in the validator — a
+  hand-rolled twin that agrees today and drifts tomorrow is the defect class this rule was
+  already an instance of. `packages/core/src/validation/__tests__/predicate-valued-gate-rules.test.ts`
+  pins the delegation behaviourally: the rule's verdict must equal
+  `boolean || hasDeclaredPredicate(value)` across every probe in the file.
+  
+  The explicit boolean arm is kept even though `hasDeclaredPredicate` already subsumes it, so
+  the superset relationship is provable locally: a future narrowing on the declaredness side
+  cannot silently start reporting `disabled: false` — the most explicit gate an author can
+  write — as an invalid schema.
+  
+  The zod `safeValidateSchema` surface (`@object-ui/types/zod`, objectui#6318) is a different
+  validator and is untouched.
+- 81c0bc4: The dev-mode unknown-key warning stops stating a fact that was retired, and
+  sends the author to the file that actually declares the interface
+  (objectui#5642).
+  
+  Both halves of the message's tail had outlived the change they described. It
+  told the author the key was warned about rather than rejected because
+  `ActionDef` "still carries `[key: string]: any`" — objectstack#4075 step 3
+  deleted that index signature, and `actionKeys.pin.test.ts` pins the deletion in
+  the opposite direction (`{ ActionDef: false, ActionContext: true }`), while
+  `actionDef-closed-surface.test.ts` pins that `tsc` now rejects exactly such a
+  key at the construction site. And it prescribed promoting the key to an explicit
+  field on `ActionDef` "(packages/core/src/actions/actionKeys.ts)" — that file
+  holds the INVENTORY (`ACTION_DEF_KEYS`); the interface is in `ActionRunner.ts`.
+  The wrong pointer had teeth: an author who followed it edited the inventory
+  alone, which is precisely the half-change the pin test reddens on, since it
+  re-derives the inventory from the interface's AST.
+  
+  The tail now carries the reason the module's own header already gives for why
+  this warning survived step 3 — the two mechanisms cover disjoint populations.
+  `tsc` sees action literals authored in code; the warning sees actions that
+  arrive as data, from stored rows that are rehydrated unparsed and that no
+  compiler ever looked at (objectstack#3903). The prescription names
+  `ActionRunner.ts` for the field and `ACTION_DEF_KEYS` as the same-commit second
+  edit, saying why.
+  
+  No behaviour change: the classification logic, the key inventory and its
+  derivation are untouched, and the warning fires on exactly the same actions as
+  before. Two comments in the same file and two in the pin test that described the
+  pre-step-3 world were refreshed in the same pass, and the message text is now
+  pinned — the printed interface path is resolved off the message and read, so a
+  move or rename reddens by name instead of shipping a second dead prescription.
+- 8ebd57f: Both `evaluateExpression` references in the `ExpressionEvaluator.registerFunction`
+  JSDoc are now qualified, so each resolves to the entity it means (objectui#5580).
+  
+  `ExpressionEvaluator.ts` declares two things spelled `evaluateExpression`: the method
+  on `ExpressionEvaluator` (bare expression, throws) and the module-level export
+  (context bag, fail-soft, delegating to `evaluate`). The `registerFunction` block
+  referred to both under the one spelling, four lines apart.
+  
+  The prose link was not merely ambiguous, it was bound wrong. Measured with
+  `checker.getSymbolAtLocation` on the pre-fix source, `{@link evaluateExpression}`
+  resolved to the module-level `FunctionDeclaration` — the fail-soft one — inside the
+  sentence that calls it *"the throwing sibling"*. The neighbouring `{@link evaluate}`
+  binds to the method, but only because no module-level `evaluate` exists to outrank
+  it, so the rule "an unqualified link resolves to the enclosing class's member" does
+  not hold here. The link is now `{@link ExpressionEvaluator.evaluateExpression}`,
+  which the checker resolves to the `MethodDeclaration`.
+  
+  The `@example`'s final line is the module-level export — its second parameter is a
+  context bag and the `${...}` wrapper only resolves on the `evaluate` path — but it sat
+  two lines below calls that establish `evaluator.` as the receiver, and a `.d.ts` hover
+  carries no import to disambiguate. It now names the module-level export and shows the
+  import it needs.
+  
+  This is prose only: the diff is confined to a block comment and no declaration moves.
+  It is scored `patch` rather than the empty-frontmatter form because the block is
+  emitted into what npm ships — measured, this edit moves both
+  `dist/evaluator/ExpressionEvaluator.d.ts` and `dist/evaluator/ExpressionEvaluator.js`
+  (this package builds with a bare `tsc`, which preserves comments in the JS emit), and
+  the ten changed lines in that JS are all comment lines.
+  
+  `registerFunction-jsdoc-links.test.ts` pins the binding against the checker rather
+  than asserting it in prose, since a `{@link}` that binds to the wrong entity is
+  indistinguishable in source from one that binds right.
+- 7138bc1: The dev-mode unknown-key warning stops flagging `overrideNotice`, the console's
+  privileged-override safety copy (objectui#5611).
+  
+  `ActionRunner.execute` classifies the object it was HANDED, and a console host
+  hands it a DISPATCH, not a stored metadata row. `DeclaredActionsBar` composes
+  `overrideNotice` on that dispatch and two param-collection handlers read it —
+  yet the key inventory only mirrored AUTHORED surfaces, so the runner reported a
+  key two files read as one "no reader recognizes", and prescribed promoting it to
+  an explicit field on `ActionDef`. That prescription is the one shape the
+  2026-08-22 maintainer ruling forbids for this key, so acting on the diagnostic
+  walked an author into a rejected design. A false warning on the product's own
+  privileged path — the branch that finalises an approval over approvers who have
+  not acted — is how a dev console gets muted.
+  
+  Adds an exported `HOST_DISPATCH_ACTION_KEYS` (sole member `overrideNotice`) to
+  `actions/actionKeys.ts` and unions it into `KNOWN_ACTION_KEYS`, which is the
+  fourth input to that set and the first one that is not an authored-surface
+  mirror. Measured before and after on the exact dispatch the bar composes: the
+  warning went from one call naming `overrideNotice` to none, `KNOWN_ACTION_KEYS`
+  grew by exactly one member, and an action carrying a real typo alongside it
+  still warns — naming `targt` only.
+  
+  The authored surface does not move. `overrideNotice` is still NOT declared on
+  `ActionDef` and still NOT in `ACTION_DEF_KEYS`; writing it in an action literal
+  remains a compile error, and the AST-derived pin over the interface is unchanged.
+  Membership in `KNOWN_ACTION_KEYS` widens what the WARNING tolerates, never what
+  an author may write — `actionKeys.pin.test.ts` now pins both halves, including
+  the new list's exact contents so a second member cannot arrive quietly.
+- cef27e2: The value-fallback label prettifier `humanizeLabel` has one implementation instead of two byte-identical copies.
+  
+  `humanizeLabel` turns a stored value into a display string when nothing else
+  resolves it — an option with no declared label, an object name, a chart axis
+  member. It existed twice, byte for byte: once in `@object-ui/fields` (read by
+  `plugin-grid`, `plugin-gantt`, `plugin-detail` and by that package's own
+  renderers) and once as a deliberate local copy in `plugin-charts`'
+  `ObjectChart.tsx`, whose comment said it was there "to avoid a dependency on
+  `@object-ui/fields`".
+  
+  Two copies of one convention is a live hazard rather than tidiness: one
+  dashboard can hold a chart and a grid over the same stored value, so a change
+  landing on one copy alone would put that value on screen under two spellings at
+  once. The single implementation now lives in `@object-ui/core` — the shared
+  ancestor both packages already depend on, so the dependency the copy existed to
+  avoid is still avoided and no new edge is created, and core takes no React
+  (objectui#4389: core-canonical logic, plugins consume). Both former sites
+  re-export it, so `import { humanizeLabel } from '@object-ui/fields'` keeps
+  working unchanged.
+  
+  **Nothing rendered changes.** The surviving implementation is byte-identical to
+  both deleted copies, and each former call site is pinned by identity against the
+  core function — not by a copied output table that someone would have to remember
+  to edit in two places.
+  
+  The core module also writes down, for the first time, why this convention stays
+  distinct from `humanizeFieldKey` (the KEY fallback, in `@object-ui/plugin-dashboard`),
+  which additionally splits camelCase:
+  
+  ```
+  input                humanizeFieldKey     humanizeLabel
+  needs_analysis       Needs Analysis       Needs Analysis
+  NeedsAnalysis        Needs Analysis       NeedsAnalysis        <- differ
+  unitPrice            Unit Price           UnitPrice            <- differ
+  BestCase             Best Case            BestCase             <- differ
+  lost-to-competitor   Lost-To-Competitor   Lost To Competitor   <- differ
+  ```
+  
+  A field KEY is authored in the codebase and carries a machine spelling, so
+  splitting camelCase recovers words its author meant. A stored VALUE is arbitrary
+  tenant data, where a mid-token capital is not reliably a word boundary and
+  splitting it rewrites what the tenant wrote (`McDonald` to `Mc Donald`). The two
+  conventions also do not nest — on the last row each leaves alone the separator
+  the other rewrites. Whether they should ever converge is a separate decision
+  that would move rendered output in four packages at once; it is deliberately not
+  made here.
+- af3861f: `normalizeListViewSchema` now folds the four per-view-type config aliases phase 3
+  carried over — `kanban.groupField` → `groupByField`, `kanban.cardFields` →
+  `columns`, `gallery.imageField` → `coverField`, `timeline.dateField` →
+  `startDateField` (objectui#2890).
+  
+  These are the pre-#2231 objectui spellings, kept declared alongside the spec keys
+  so stored view metadata would keep validating. They now fold at the same
+  component boundary as the A1–A5 vocabulary folds, in the same one-directional
+  shape: the canonical key wins when a config carries both, and the legacy key is
+  removed from the result so a missed read-site fails loudly instead of quietly
+  taking the legacy path.
+  
+  One rendering behaviour changes, and it is a correction of the same inverted
+  precedence the `densityMode` fold fixed: `ListView`'s kanban adapter resolves the
+  card field list as `cardFields || columns` — legacy over canonical — so a kanban
+  config carrying **both** rendered the legacy `cardFields` value and silently
+  ignored the spec-canonical `columns`. After the fold the authored `columns` is
+  what reaches it. Configs carrying only one of the two are unaffected, and every
+  other reader of these four keys was already canonical-first.
+  
+  `calendar.defaultView` is deliberately **not** folded: it aliases nothing and has
+  no spec counterpart, so it wants promotion upstream rather than a rename.
+- c00bf28: `getRecordDisplayName`: stop consulting the undeclared object-level
+  `titleField`, restoring `nameField` as the top of the object ladder
+  
+  Step 0 of the unified record-title resolver read
+  `options?.titleField ?? objectDef?.titleField`. The second leg ranked an
+  object-level `titleField` above `nameField` — the pointer ADR-0079 Phase 2 made
+  canonical — and above the deprecated `displayNameField` alias and the legacy
+  `titleFormat` template.
+  
+  `@objectstack/spec`'s object schema does not declare that key, and it is not
+  merely undeclared: the schema is a `strictObject`, so
+  `ObjectSchema.safeParse({ …, titleField: 'x' })` fails with `unrecognized_keys`
+  — the same code a nonsense key gets — while `nameField`, `displayNameField` and
+  `titleFormat` all parse and survive. A producer census across both repos found
+  nothing that puts the key on an object-shaped payload: not the metadata, not any
+  `getObjectSchema` implementation (the ObjectStack adapter stamps only reference
+  keys and field-widget hints), not the lookup-chip path, not the
+  search-candidate path, and not the platform's own server-side resolver
+  (`@objectstack/objectql#titleFieldOf` reads `nameField` → `displayNameField`).
+  Reading a key no producer can ship is a consumer-side alias — the shape
+  Commandment #0.1 bans — and it inverted the governed-authority default on top of
+  that.
+  
+  No authoring surface changes and no view loses its author-chosen title field:
+  `titleField` remains a real, declared VIEW key (`ui/CalendarConfig`,
+  `ui/GalleryConfig`, `ui/GanttConfig`, `ui/ListMapConfig`,
+  `ui/ObjectKanbanProps`, `ui/TimelineConfig`), views hand it in as
+  `options.titleField`, and that half of step 0 still wins over everything.
+  The behaviour change is confined to an object payload that carried a key the
+  contract rejects: it now resolves through the declared ladder instead.
+- f2158ec: `ExpressionEvaluator.registerFunction` now documents the case-fold it has always
+  performed: the name is stored — and must be called — in UPPER CASE
+  (objectui#5363).
+  
+  `registerFunction('formatCurrency', fn)` registers `FORMATCURRENCY`, because the
+  method delegates to `FormulaFunctions.register`, which stores under
+  `name.toUpperCase()`. That fold is correct for the spreadsheet-style built-in
+  vocabulary (`SUM`, `IF`, `UPPER`) and is unchanged here — but nothing declared
+  it on the public method, and two things keep it from being self-evident at the
+  call site. The registry API stays case-insensitive, so `getFormulas().has()` and
+  `.get()` both answer to the original spelling and never reveal the fold; only
+  expressions see the stored key, because the evaluation scope is built from
+  `FormulaFunctions.toObject()`, a plain object whose identifiers are matched
+  case-sensitively. And a wrong-case call site does not raise: `evaluate()`
+  catches, warns, and returns `defaultValue ?? expression`, so the template
+  renders its own `${...}` source as literal text on screen rather than erroring.
+  
+  Behavior is untouched — this is the declaration catching up with what the code
+  enforces. It ships as a patch rather than as an empty changeset because the
+  JSDoc is emitted into the published `dist/evaluator/ExpressionEvaluator.d.ts`,
+  so it is what consumers see on hover.
+  
+  `ExpressionEvaluator.test.ts` gains three cases pinning the half that was
+  uncovered — that the given spelling does *not* resolve in an expression, that
+  the failure renders the raw template source instead of throwing, and that the
+  registry API stays case-insensitive underneath — so making registration
+  case-preserving fails a test instead of silently invalidating the new JSDoc.
+- 6c6cee7: A RETIRED field-type spelling is now refused — out loud, once — by every
+  field-type predicate in the renderer, not just by the widget road
+  (objectui#4914, maintainer ruling B of 2026-08-18).
+  
+  `@object-ui/fields` exports a single `isRetiredFieldType(t)` gate, and it runs
+  ahead of six predicate faces that previously granted a retired spelling
+  first-class treatment: the filter builder's operator buckets and its value
+  control (`@object-ui/components`), the detail page's highlight-strip picker
+  (`@object-ui/plugin-detail`), `normalizeFieldType` (`@object-ui/plugin-view`),
+  the dashboard's `$expand` whitelist and `isLookupType`
+  (`@object-ui/plugin-dashboard`), and the list toolbar's lookup-like filter
+  control (`@object-ui/plugin-list`). Each one now fires the migration
+  prescription on the console — once per spelling across all of them, never once
+  per predicate — and then answers as it would for a spelling it does not
+  recognise.
+  
+  This closes the whole CLASS rather than one word: the gate is quantified over
+  `RETIRED_FIELD_TYPES`, so the next retirement covers all seven consumers on the
+  day it lands. It is the shape objectui#4932 and objectui#4942 already
+  established for the form and inline-edit roads.
+  
+  Measured before the change, and the reason the fix is a gate rather than a
+  deletion: `owner` was not dead in these faces. `operatorsForFieldType('owner')`
+  equalled the `user` bucket item for item, `computeLookupExpand` actively
+  requested `$expand` for it, `isLookupType('owner')` was `true` alongside
+  `reference`, and `normalizeFieldType('owner')` answered `'select'` exactly as
+  `picklist` does. Deleting the members alone would have traded a visible
+  contradiction for a SILENT degradation — a filter picker collapsing to a bare id
+  box, `$expand` quietly stopping so cells show raw foreign-key ids — which is
+  verbatim the failure mode `RETIRED_FIELD_TYPES`' own docblock exists to prevent.
+  The gate keeps that fallback and adds the half that was missing: the author is
+  told.
+  
+  The boundary question is answered on record: `owner` arriving through a
+  backend-vocabulary normalizer is an authoring error to refuse loudly, not
+  legitimate foreign input to tolerate. The open backend vocabulary those
+  normalizers exist for is untouched — `reference`, `picklist`, `money`, `int`,
+  `datetime_tz` and the rest are equally absent from the spec's closed `FieldType`
+  and are equally unretired, so they classify exactly as before.
+  
+  `RETIRED_FIELD_TYPES`, `reportRetiredFieldType` and `resetRetiredFieldTypeReports`
+  move to `@object-ui/core` and are re-exported from `@object-ui/fields`, so that
+  package's published surface is unchanged apart from the newly ruled gate.
+  `@object-ui/components` is a consumer of the gate and `@object-ui/fields`
+  depends on it, so a single shared table could not live in `fields` — and a
+  second copy would have meant a second dedupe set and two console lines for one
+  spelling. No package gained a new dependency.
+  
+  A retired spelling never loses a stored value: `retypeFilterValue` is
+  deliberately not gated, and the refused filter row stays operable rather than
+  drawing a blank operator trigger.
+- ed71d9e: Withdraw the entry-surface justification on core's `SchemaNode` re-export, and put
+  the gauge that can actually fail in its place (objectui#5673).
+  
+  `packages/core/src/types/index.ts` carried, as the justification for the #4580
+  re-export convergence, *core's own entry surface is unchanged (`dist/index.d.ts` is
+  byte-identical across the change — measured, both rounds)*. The reading was real and
+  it certified nothing. `core/dist/index.d.ts` is emitted from a barrel that only
+  FORWARDS the symbol, and forwarding never restates a shape — not `export *`, and not
+  the `export type { … }` line that names this one. Only the module that DECLARES the
+  symbol can move, so that file is byte-identical under any change to a re-exported
+  declaration's shape, and it could not have failed for the change class it was quoted
+  against.
+  
+  Measured for this change rather than argued. One optional key was injected into
+  `BaseSchema` — the shape `SchemaNode` publishes — both packages were rebuilt from a
+  cleared `dist/` and a cleared `tsconfig.tsbuildinfo`, then the probe was dropped and
+  both rebuilt again:
+  
+  | emitted file | base | with probe | probe dropped |
+  |---|---|---|---|
+  | `@object-ui/types` `dist/base.d.ts` — declares the shape | `31b5a01d…` | `8487500e…` **moved** | `31b5a01d…` |
+  | `@object-ui/core` `dist/types/index.d.ts` — forwards it | `0e64c8c6…` | `0e64c8c6…` | `0e64c8c6…` |
+  | `@object-ui/core` `dist/index.d.ts` — entry barrel, names it | `5cca207a…` | `5cca207a…` | `5cca207a…` |
+  
+  The corrected block states that calibration as a recipe with its failure mode, so the
+  next reader inherits a gauge that can be checked instead of a sentence that cannot.
+  The `ComponentRendererProps` block below it already reached the right verdict, but
+  gave a narrower reason for it — that core's entry is an `export *` barrel — which is
+  not the mechanism, and is wrong for a symbol the barrel names on its
+  `export type { … }` line; it now states the forwarding rule.
+  
+  Documentation only, in a published declaration file: these docblocks sit on export
+  specifiers, so `core/dist/types/index.d.ts` carries them into the tarball, while
+  `core/dist/index.d.ts` does not move for them either — the same insensitivity,
+  demonstrated once more on this very change. No type moves and no runtime behaviour
+  changes.
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [69a2163]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [e4559d1]
+- Updated dependencies [6f81384]
+- Updated dependencies [dddb942]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [d7acad6]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [100547e]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [0e05aac]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [199d31b]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [515f171]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [3c73d99]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/types@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/core/package.json b/packages/core/package.json
index 28d15940f2..5cc0eb9bfd 100644
--- a/packages/core/package.json
+++ b/packages/core/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/core",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "sideEffects": false,
   "license": "MIT",
diff --git a/packages/create-plugin/CHANGELOG.md b/packages/create-plugin/CHANGELOG.md
index 9e3b4d302a..5e1f0eae00 100644
--- a/packages/create-plugin/CHANGELOG.md
+++ b/packages/create-plugin/CHANGELOG.md
@@ -1,5 +1,7 @@
 # @object-ui/create-plugin
 
+## 17.7.0
+
 ## 17.6.0
 
 ### Patch Changes
diff --git a/packages/create-plugin/package.json b/packages/create-plugin/package.json
index 38fbec8df3..66611aca10 100644
--- a/packages/create-plugin/package.json
+++ b/packages/create-plugin/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/create-plugin",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "description": "CLI tool to scaffold ObjectUI plugins",
   "type": "module",
   "license": "MIT",
diff --git a/packages/data-objectstack/CHANGELOG.md b/packages/data-objectstack/CHANGELOG.md
index 731d4a9c83..05fc339e4b 100644
--- a/packages/data-objectstack/CHANGELOG.md
+++ b/packages/data-objectstack/CHANGELOG.md
@@ -1,5 +1,422 @@
 # @object-ui/data-objectstack
 
+## 17.7.0
+
+### Minor Changes
+
+- 41b7ce3: **View configuration is explicitly org-wide, and its write path is now gated (objectstack#7494's
+  ruling, maintainer 2026-08-12).** The `sort` / `hiddenFields` / `columnState` / `rowHeight` that a
+  list toolbar persists were never per-user: they are one shared row on the view, so an ordinary user
+  dragging a column or cycling density was re-styling that view for the entire organization. Nothing
+  in the console said so, and nothing stopped it. A per-user scope stays parked (objectstack#7611,
+  v18) and is deliberately not built here — which is precisely why the write has to be gated rather
+  than narrowed: there is no second, private store for it to fall back to.
+  
+  `ObjectStackAdapter.updateViewConfig` now refuses when the session's **reported** ADR-0066 capability
+  set does not contain `manage_metadata`, throwing the new `ViewConfigPermissionDeniedError`
+  (`VIEW_CONFIG_PERMISSION_DENIED`, with `isViewConfigPermissionDeniedError` and the
+  `VIEW_CONFIG_CAPABILITY` constant alongside it). The gate is the **first** statement in the method —
+  before `connect()`, before the payload is assembled — so a refused call puts nothing on the wire.
+  It is on the write rather than on the toolbar button on purpose: withholding the affordance would
+  leave the method still accepting the call from anything else holding the adapter, whereas a gate on
+  the write is inherited by every caller, present and future.
+  
+  `manage_metadata` is not a newly minted name. It is the capability this repo already treats as
+  metadata-authoring authority — `HomePage`'s `AUTHORING_CAPABILITY`, the one the server itself
+  refuses metadata writes without — and the gated write goes through `client.meta.saveItem`, the very
+  same ADR-0005 metadata door, so this applies the authority the server is already applying instead of
+  inventing a parallel one.
+  
+  **Unknown fails open, by doctrine.** A capability set that was never reported (a backend predating
+  ADR-0066, or no permission provider mounted) is not a denial: the server enforces regardless, so a
+  client-side refusal on missing data cannot protect anything and can only break a permitted user. A
+  *reported* empty grant gates strictly. Hosts push the session's capabilities in with the new
+  `setSystemCapabilities`; `ObjectView` wires it from `usePermissions()`.
+  
+  The refusal is also **said out loud**. `ObjectView`'s persist path previously swallowed every failure
+  into `console.error`, which for a debounced toggle whose UI has already moved would have left the
+  operator looking at a density they did not get; a denied write now raises a toast. And the "View
+  settings" popover — where density and field visibility are actually changed — now states the scope
+  before the operator acts: *"Grouping, color, density, and visible fields. Applies to everyone who
+  uses this view."*, translated in all ten packs.
+- 94e2fa7: `MetadataClient.layered()` validates the ADR-0010 protection envelope against the
+  producer's own schema at the boundary, instead of casting ten wire fields through
+  unchecked (objectui#5676, triage adjudication 2026-08-22).
+  
+  The envelope arrived by ten `as` assertions over a raw `res.json()` body — no parse, no
+  allowlist, no default. The consumer that reads it opens the metadata lock banner on
+  `layered?.lock && layered.lock !== 'none'`, true for **any** non-`none` value, so a server
+  sending a lock state this console had never heard of opened the amber box, drew the padlock
+  and the border, and rendered an empty title. No fifth state ever had to be added to this
+  repo for that to happen: a union types what this repo writes and constrains nothing about
+  what a server sends.
+  
+  The boundary now runs `GetMetaItemLayeredResponseSchema.safeParse`. On the conforming path
+  every value is the producer's schema output and the ten assertions are gone. `safeParse`
+  and never `parse`: a metadata console that rejected every dialect it had not been compiled
+  against would answer a newer server with a blank page, which is strictly worse than the
+  wrong render being fixed. Values the schema rejects are still **forwarded** — dropping them
+  would be that same refused rejection wearing different clothes — and are named in a new
+  optional `MetadataLayered._unrecognized`, absent whenever everything parsed. This extends
+  to the whole envelope the "pass through and label" treatment objectui#5672 chose for `lock`
+  alone; the banner's existing unrecognised-token title is unchanged and needed no edit.
+  
+  The labelling is per field, which is the part that makes it a degrade rather than a subtler
+  version of the same bug. Measured on the installed spec (17.2.0):
+  `GetMetaItemLayeredResponseSchema.safeParse(body)` is all-or-nothing — one unknown `lock`
+  returns `success: false` with `data` undefined — so the failure branch re-checks each key
+  against that schema's own `shape[key]`, where only the offending field fails and the other
+  six still arrive typed. Absence is never "unrecognised": the four resolved verdicts are
+  required upstream on this path, so a pre-ADR-0010 backend takes the failure branch with
+  nothing flagged and behaves exactly as before.
+  
+  One consequence of the same ruling, fixed alongside because it defeats it: a 200 answer
+  whose body was a bare JSON string or number **rejected** the promise with a
+  `TypeError: Cannot use 'in' operator`, from the envelope-detection guard's bare truthiness
+  check. A malformed body must degrade, never throw.
+- b2065e7: Classify `/analytics/query` failures by their ADR-0112 `code` rather than their HTTP status, so a chart is no longer answered from a different code path behind the wrong explanation.
+  
+  `classifyAnalyticsFailure` tested `status === 404 || status === 501` before the code operands on the same line, so the status short-circuited every one of them: any 404 on this face was classified "the analytics capability is not installed" whatever code it carried, and `NOT_IMPLEMENTED` / `ROUTE_NOT_FOUND` were unreachable for the conditions they name. Three unrelated conditions answer 404 on this url, so the status cannot tell them apart — the `code` is the contract.
+  
+  Two conditions change behaviour:
+  
+  - **404 `CUBE_NOT_FOUND`** (a misspelled or unregistered cube — an authoring mistake) now **throws** the server's own error verbatim, keeping `code` and the producer's repair instructions. It previously warned "install `@objectstack/service-analytics`" and silently degraded to `find()` + client-side aggregation — which cannot answer it anyway, because the fallback re-reads the same name through `/data`, where an unregistered object is a 404 `OBJECT_NOT_FOUND`.
+  - **401 `UNAUTHENTICATED`** (an anonymous or lapsed session) now **throws** `AnalyticsUnauthenticatedError` instead of degrading silently behind a `find()` that is about to be refused the same way.
+  
+  Unchanged: `NOT_IMPLEMENTED` / `ROUTE_NOT_FOUND` and code-less 404/501 answers still degrade loudly to the client-side fallback, 400 `VALIDATION_FAILED` still throws, and 5xx / network failures still degrade silently.
+- b470e91: The metadata designer states its package on the publish step, not only on the save (#5420)
+  
+  Studio's designer save→publish loop bound the draft to a software package on the
+  save (`PUT ?mode=draft&package=<id>`) and then sealed it with a publish that named
+  no package at all. `objectstack#10354` (shipped in `@objectstack/rest` 17.2.0) taught
+  `POST /meta/:type/:name/publish` to accept `?package=<id>`, so the second call can now
+  state the same binding the first one already states.
+  
+  - `MetadataClient.publish()` accepts `packageId` and sends `?package=<id>`, the same
+    wire spelling and the same `encodeURIComponent` treatment `save()` gives it.
+  - `MetadataResourceEditPage` reads the binding for BOTH steps from one derivation
+    (`readActivePackageBinding`), so the two calls of one loop cannot drift apart. The
+    `?package=all` "show everything" scope keeps folding to "no package".
+  
+  The parameter is **omitted**, never sent empty, when the designer holds no binding.
+  Empty and absent are the same to the framework's normaliser today, but absent is the
+  shape the save door already followed, and the framework's promotion path branches on
+  the key being present downstream.
+  
+  What this buys is **reachability**, not speed: it lets `#9612`'s package-closure
+  narrowing at the runtime publish gate fire on an HTTP-driven promotion at all. That
+  narrowing has a second, independent gate this does not touch — objects carrying no
+  `_packageId` provenance are kept unconditionally — so on a tenant-authored overlay
+  corpus stating the package still narrows nothing.
+- 8e00bfd: **Breaking (published surface):** remove `options.actor` from `MetadataClient`'s
+  `save`, `reset`, `publish` and `rollback`, and stop emitting the `X-Actor`
+  request header.
+  
+  The server stopped honouring that header. objectstack#7941 ruled that the
+  recorded actor is the identity the request was authorized as, and removed the
+  header limb from the `/meta` write resolver — attribution cannot drift from
+  authorization. The option therefore typed cleanly, sent a header, and could not
+  influence the audit or history row it appeared to address: a false affordance
+  that promised attribution and silently failed to deliver it.
+  
+  Three declarations go: `MetadataClientSaveOptions.actor` (inherited by
+  `MetadataDeleteOptions` via `extends`, so it served both `save` and `reset`),
+  and the inline `{ actor?: string }` on each of `publish` and `rollback`.
+  `MetadataAuditEntry.actor` is unaffected — that is the server's read-back of
+  who acted, and it remains the way to see attribution.
+  
+  Marked `minor` rather than `major` per this repo's version-alignment policy
+  (the fixed group's major tracks `@objectstack`, and `major` in a changeset
+  would drag all 39 packages off that cadence).
+  
+  No caller in this repo passed `actor`; the census found the only in-repo
+  occurrence was the client's own unit test. Callers outside this repo that still
+  pass it are unaffected at runtime beyond losing a header the server already
+  ignored — the property is dropped rather than forwarded, pinned by
+  `metadata-actor-retired-4834.pin.test.ts`.
+- 2d36552: Pins `@objectstack/spec`, `@objectstack/client`, `@objectstack/formula` and `@objectstack/lint` to `17.1.0`, and adapts the two consumer surfaces the new build moves.
+  
+  The pin itself is a lockfile refresh — every manifest already declared `^17.0.0`, which admits `17.1.0`, so no dependency range changed. All four move together: a split resolution is what produced the dual-version spec graph that reddened `check:spec-symbols` in this repo's history.
+  
+  **A `icontains` filter now reaches the driver as a filter.** `icontains` is a canonical `VIEW_FILTER_OPERATORS` member as of `17.1.0`, so an author can declare it on a `ViewFilterRule` and the spec validates it — but `@object-ui/data-objectstack`'s alias table had no row for it, and an unmapped operator is how this adapter shipped an unfiltered query before (objectstack#3948). It is an identity row like `contains`: `icontains` is itself a member of `VALID_AST_OPERATORS`, so the spelling the author writes is the spelling the AST takes, and no case-sensitivity is translated away. Declared rather than left to the table's `?? op` fall-through, on the rule its own parity test states — the AST gate accepting a spelling is not the driver compiling it into a `WHERE` clause.
+  
+  The same operator reaches the list view's own bridge: `@object-ui/plugin-list`'s `mapOperator` gains an explicit `icontains` arm. The emitted spelling is identical to the input, but the arm is written out rather than left to the `default` passthrough — `icontains` is its own member of `VALID_AST_OPERATORS`, so a raw passthrough is accepted *today*, and depending on that coincidence is what the bridge's own parity test records as how it once stopped discriminating.
+  
+  `@object-ui/core` adds `onSuccess` to its spec key inventory, so an author writing the key `17.1.0` now declares is no longer warned that it is unknown. That is a diagnostic statement only — the four declared action surfaces still drop the key before it reaches the runner, which is tracked separately.
+  
+  **A stored view filtering case-insensitively still shows that operator when it is reopened.** `@object-ui/plugin-view`'s canonical-to-builder table is keyed by `ViewFilterOperator`, so `17.1.0` adding `icontains` failed to compile rather than letting the operator reach the FilterBuilder as a raw spelling its dropdown cannot select. It maps to the builder's `containsCaseInsensitive` — the id that authors the spec's `$icontains` — and deliberately not to `contains`, which would quietly rewrite a case-insensitive filter into a case-sensitive one the next time the view was saved.
+  
+  **The page-editor palette keeps one entry per renderer.** `17.1.0` retires `element:filter` from `PageComponentType` and adds `record:discussion`, leaving the member count at 34 either side — so the swap is invisible to any count-based reading. The stale `element:filter` exclusion is dropped, and `record:discussion` is excluded because it is the *same renderer* as the already-offered `record:chatter`, not because it is unauthorable. Nothing the palette offers changes.
+  
+  **The console eager-closure ceiling is re-baselined, by maintainer ruling.** The release is roughly 930 KB larger uncompressed and nearly all of it lands in `vendor-objectstack-*.js`, which put the closure past a ceiling that was deliberately sized to catch a 89 KiB regression — the gate refused the bump, correctly. Raising it was escalated rather than taken locally, because gate-strength policy had been ruled the maintainer's; the ruling on objectui#5531 authorised the raise. `MAX_EAGER_CLOSURE_GZIP_BYTES` and the `BASELINE` it is derived from move together in one commit, keeping headroom at 2.00% and below the 91,136-byte regression size the gate must still catch. The gate's *sensitivity* is untouched: a repeat of that regression from the new baseline still fails. No behaviour ships from this file — it is CI policy, recorded here because the version it governs is the one this changeset publishes.
+
+### Patch Changes
+
+- 490d9a9: Grid headers offer a sort click only on columns the PLATFORM says it will order by
+  (objectui#5729 — the consumer leg of objectstack#10235, maintainer ruling A, 2026-08-23:
+  the platform serves an explicit per-column sortability signal and the grid reads it,
+  rather than re-deriving "virtual ⇒ unsortable" from field type).
+  
+  `GET /api/v1/meta/object/:name` now answers with a `sortability` projection on its
+  ENVELOPE — `{ fields: { [name]: { sortable, reason?, caveat? } } }`, computed at serve
+  time from the platform's own storage predicates, deliberately beside `item` rather than
+  inside it so the key stays un-authorable. The signal was reaching the browser and being
+  discarded one line before its only consumer: `ObjectStackAdapter.getObjectSchema` unwraps
+  the envelope to `item`, so every UI reader saw a document with no signal on it. It now
+  survives that unwrap, carried on the schema under a symbol key — invisible to
+  `JSON.stringify`, to `Object.keys` and to a spread, so a schema handed back at a metadata
+  write endpoint can never take it into a body the server parses strictly.
+  
+  `@object-ui/core` gains the one spelling of the consumer contract:
+  `isPlatformSortableField(projection, name)` is `true` iff an entry EXISTS for the name and
+  says `sortable: true`. Absence is a refusal — it is how the platform encodes an unknown
+  name, a dotted path and an unprovisioned audit column, all three of which the runtime
+  doors reject — so the `!== false` spelling every other optional flag in this repo uses
+  would get exactly that family backwards. A projection that is absent ALTOGETHER is a
+  different question with a different answer (`undefined`: no signal was served) and is
+  typed apart from an empty one, so a deployment older than the upstream change keeps the
+  behaviour it had rather than being told, falsely, that nothing on the object is sortable.
+  
+  Three things follow in the grid. The header click on a refused column ceases to exist, so
+  neither the old silent-unordered result nor the `400 INVALID_SORT` that replaced it is
+  reachable from it. A sort PERSISTED before the signal existed is filtered out of both what
+  the grid renders and what it emits, so a restored personalization cannot ride back into
+  the next `persistViewPatch({ sort })` — the half-fix where the affordance is gone and the
+  PUT still fires. And the relational carve-out is untouched and deliberately not delegated
+  to this signal: the platform answers `sortable: true` for a `lookup` (it has a stored
+  foreign key and both runtime doors accept ordering by it), while the grid withholds that
+  header for a different reason — a column of names ordered by an invisible id.
+  
+  Columns carrying `caveat: 'unprovisioned-anchor'` keep their click. The runtime accepts
+  those sorts; refusing what the platform does not refuse would recreate declared-≠-enforced
+  drift in mirror image.
+- a26b9e4: `packages/core/src/adapters/README.md` now documents the adapters that are actually in that
+  directory, and the ObjectStack material it carried moved to the package that owns the behaviour
+  (objectui#6213). Both files ship to consumers — `@object-ui/core` publishes its `src/`, and a
+  README rides every tarball — so this was published documentation describing the wrong package.
+  
+  The page had been left behind when the ObjectStack adapter moved out to
+  `@object-ui/data-objectstack`: its headings, feature list, filter-operator table and
+  query-parameter table were all about that adapter, and its one-entry "Available Adapters" list
+  told a reader Object UI has exactly one adapter and that it comes from `@object-ui/core`.
+  `ApiDataSource`, `ValueDataSource`, `resolveDataSource`, `runBatchTransaction` and
+  `emulateBatchTransaction` — the five exports that directory really ships — were named nowhere.
+  
+  - **`@object-ui/core`**: the page now opens with what the directory holds, gives each export a
+    usage snippet and a `provider` mapping, and points at `@object-ui/data-objectstack` for the
+    ObjectStack adapter. `## Creating Custom Adapters` is unchanged — it is the one section that was
+    always about this directory.
+  - **`@object-ui/data-objectstack`**: gains a `## Query Translation` section carrying the
+    filter-operator and query-parameter mapping tables, the AST conversion example and the sorting
+    example. That material existed **only** in the `core` copy — this package's README documented
+    query translation as a single feature bullet — so it is ported, not dropped.
+  
+  No runtime behaviour changes; the duplicate copy of one package's documentation living under
+  another package is what goes away.
+- 5961030: `@object-ui/core` and `@object-ui/data-objectstack` now declare
+  `"@objectstack/spec": "^17.2.0"` rather than `^17.0.0`, which is the lowest published
+  spec that carries every symbol each package's own build output references
+  (objectui#6361).
+  
+  `packages/core/dist/utils/column-sortability.d.ts` references
+  `FIELD_SORTABLE_UNPROVISIONED_ANCHOR`, `FIELD_UNSORTABLE_VIRTUAL_TYPE`,
+  `FieldSortability` and `ObjectSortability` from `@objectstack/spec/api`, and
+  `packages/data-objectstack/dist/index.js` references the first two — none of which
+  `@objectstack/spec@17.0.0` exports. Measured against the published tarballs rather than
+  the installed tree, by `scripts/check-spec-range-floors.mjs`: six `floor-too-low`
+  findings across the two packages, and `^17.2.0` is that gate's own computed answer for
+  both. So the old range was a claim neither package could honour: any consumer
+  resolution that lands 17.0.0 — a sibling pinning it exactly, an `overrides` entry, a
+  mirror two minors behind — satisfied `^17.0.0` and got a dangling reference.
+  
+  Nothing a consumer installs today changes: normal resolution already picks the newest
+  17.x, and `pnpm-lock.yaml` still resolves `17.2.0` on both edges after the bump — only
+  the recorded `specifier:` moves. No source and no behaviour changes, which is why this
+  is scored `patch`, on the reasoning objectui#5793 used for the same remediation on
+  `@object-ui/plugin-detail`.
+  
+  The bump is release-blocking rather than cosmetic. `check:spec-floors` is deliberately
+  not a `pull_request` job, so every PR stayed green while its blocking copy on the
+  publish path — `pnpm changeset:publish` runs it before a single tarball reaches npm —
+  would have cancelled the next release.
+- b2e85a9: `ObjectStackAdapter.getApp` and `getPage` now address the `app` / `page` metadata
+  types in the singular, matching the other twelve `client.meta.*` call sites in this
+  file (objectui#4940).
+  
+  `getApp` (`getItem('apps', …)`) and `probeAppAccess` (`getItem('app', …)`) addressed
+  the same metadata type sixty lines apart, and only `probeAppAccess`'s comment argued
+  its singular spelling was deliberate — the plural site was silent. Both plural sites
+  resolved today only because the server folds plural → singular
+  (`RestServer.metaTypeSingular` via `PLURAL_TO_SINGULAR` from `@objectstack/spec/shared`,
+  confirmed by reading both the mapping and the by-name route handler that calls it), so
+  this is consistency restoration rather than a behavior change — nothing a user hits was
+  broken, and nothing a user hits changes.
+  
+  `appAccessProbe.test.ts` (objectui#4252's local pin for this same spelling) is extended
+  with two new cases asserting `getApp`/`getPage` pass the singular type to
+  `client.meta.getItem`, so a future revert to the plural spelling fails a test instead of
+  depending on the server-side fold staying in place.
+- c7cd2b6: `ObjectStackAdapter.queryDataset` now maps a failed dataset query by the server's
+  ADR-0112 error `code`, not by the HTTP status, so an unknown dataset and an
+  unauthenticated session stop being reported as a missing analytics capability
+  (objectui#5663).
+  
+  Two unrelated conditions answer **404** on `POST /api/v1/analytics/dataset/query`:
+  the runtime dispatcher's `ROUTE_NOT_FOUND` when the route was never mounted, and
+  the route's own `NOT_FOUND` when `body.datasetName` matches no saved dataset. The
+  mapping tested `res.status === 501 || res.status === 404` and called all of it
+  "the analytics capability is not installed", so every unknown dataset produced a
+  banner telling the operator to install `@objectstack/service-analytics` and mount
+  `AnalyticsServicePlugin`. Measured live on a prod tenant, that banner was shown on
+  four HotCRM Executive Overview widgets while the analytics service was installed
+  and answering — the real condition was an installed `app.objectstack.hotcrm` at
+  1.3.0 whose datasets ship in 2.2.2, i.e. a package upgrade, the opposite corner of
+  the system from the remedy the banner named.
+  
+  Three conditions now get three answers, each keyed on the code the framework
+  declares for it:
+  
+  - `NOT_IMPLEMENTED` (501, route mounted with no analytics service) and
+    `ROUTE_NOT_FOUND` (404, route not mounted) keep the existing
+    `AnalyticsNotInstalledError` and its copy — one remedy, one message.
+  - `NOT_FOUND` (404, unknown `datasetName`) throws the new
+    `AnalyticsDatasetNotFoundError` (`ANALYTICS_DATASET_NOT_FOUND`), naming the
+    dataset and pointing at the installed app's version rather than at the server.
+  - `UNAUTHENTICATED` (401, `enforceAuth`) throws the new
+    `AnalyticsUnauthenticatedError` (`ANALYTICS_UNAUTHENTICATED`), which says the
+    request was refused before it ran and therefore says nothing about the
+    capability.
+  
+  The banner also used to print the server's own message in a parenthetical while
+  contradicting it in the headline — it quoted `Dataset "opportunity_metrics" not
+  found.` under a headline claiming a missing capability. That is now structurally
+  impossible rather than merely fixed: the headline is a pure function of `code` and
+  the parenthetical is a verbatim quote of `message`, both read off the same
+  response, and a test walks every branch asserting each message carries its own
+  headline and none of the others'.
+  
+  Additive only. `AnalyticsNotInstalledError` keeps its `code`, its copy and its
+  constructor signature (it gains an optional third `serverCode` argument and a
+  `serverCode` field), so consumers matching `ANALYTICS_NOT_INSTALLED` — including
+  the metadata-admin dataset preview — are unaffected. A 404 carrying a code this
+  client does not recognise, such as the analytics cube gate's `CUBE_NOT_FOUND`, now
+  keeps its server detail instead of being relabelled as a missing capability; a 404
+  or 501 carrying no code at all is still read as the capability being absent, since
+  the route's own `NOT_FOUND` always ships a code.
+- 8d37efb: The metadata lock banner can no longer render an amber, padlocked box with no
+  title, and the ADR-0010 §3.6 lock vocabulary is declared once instead of three
+  times (objectui#5024).
+  
+  `MetadataLayered.lock` and `MetadataAuditEntry.lockState` each spelled the four
+  states out by hand, 42 lines apart in one file, compared by no gate. They are now
+  one exported `MetadataLockState` — derived from `GetMetaItemLayeredResponseSchema`'s
+  `z.enum` in `@objectstack/spec`, which already owns this vocabulary, so the copies
+  were restating a schema rather than filling a gap.
+  
+  The user-visible half is the banner. Its title was three independent `&&` branches
+  with no fallback, while the switch that opens the banner is true for any non-`none`
+  value — so a lock state outside the four opened the box and left the headline
+  empty. That is reachable without a fifth state ever being added here:
+  `MetadataClient.layered()` casts the wire value through unchecked, so a newer
+  server reaches this banner as-is. Measured, not assumed — feeding `no-publish`
+  through the page rendered the padlock, the border and an empty title. The title is
+  now a keyed lookup with a loud fallback that names the unrecognised token, so a
+  fifth state fails `type-check` here and, if one arrives from a server anyway, the
+  operator reads a sentence instead of a blank box.
+- 9118a31: Preserve the producer's `userMessage` marking when `normaliseClientError` re-wraps a refusal.
+  
+  `ApiErrorSchema.userMessage` (objectstack#9934) is the opt-in channel an application author
+  sets at throw time to say "this text is for the end user", and the contract states it
+  status-agnostic — any refusal status may carry it. Both of the shapes this adapter re-wraps
+  into typed errors dropped the marking: a hook that refused a write with `VALIDATION_FAILED`
+  or `CONCURRENT_UPDATE` and marked its own sentence had that sentence discarded at the
+  adapter boundary, before any surface could render it. Nothing threw and the typed error was
+  otherwise correct, so the only symptom was the user reading a generic string instead of the
+  sentence their administrator wrote.
+  
+  The marking now rides both re-wraps, in the form the shared reader (`declaredUserMessage`)
+  already looks for: on the details bag for `DataApiValidationError`, exactly the way `fields`
+  already survives, and on a new readonly `userMessage` member for `ConcurrentUpdateError`,
+  which has no details bag. Unmarked refusals are untouched — they carry no key and still read
+  as `null`, so nothing a producer did not opt into can reach a user.
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [69a2163]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [e4559d1]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [dddb942]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [299102e]
+- Updated dependencies [d7acad6]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [100547e]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [0e05aac]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [199d31b]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [91783c4]
+- Updated dependencies [2d36552]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [3c73d99]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/types@17.7.0
+  - @object-ui/core@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/data-objectstack/package.json b/packages/data-objectstack/package.json
index bf7ffa5572..6872e0e7ff 100644
--- a/packages/data-objectstack/package.json
+++ b/packages/data-objectstack/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/data-objectstack",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "description": "ObjectStack Data Adapter for Object UI",
   "license": "MIT",
   "type": "module",
diff --git a/packages/fields/CHANGELOG.md b/packages/fields/CHANGELOG.md
index c64ede5243..97dfadbc7c 100644
--- a/packages/fields/CHANGELOG.md
+++ b/packages/fields/CHANGELOG.md
@@ -1,5 +1,489 @@
 # @object-ui/fields
 
+## 17.7.0
+
+### Minor Changes
+
+- 9a1fb41: **API addition (public-surface widening):** `FileCell` — the compact upload
+  control `@object-ui/fields` exports for line-item grid cells — gains the
+  published optional `error?: string` slot, mirroring `LookupField` and
+  `FileField`: the same validation slot `@objectstack/spec/ui`'s
+  `FieldWidgetPropsSchema` declares and `FieldWidgetComponentProps` names
+  (objectui#3222). When set, `FileCell` puts `aria-invalid` on its own focusable
+  picker button; the message text stays with the host (objectui#5431).
+  
+  `GridField` now passes that slot for a required-but-empty `file` cell — the one
+  cell type objectui#3318's per-cell `aria-invalid` delivery left out. Before
+  this, a required `file` cell flagged only the visual ring and `title` on the
+  `td`; no element in the cell subtree announced the state, so assistive tech was
+  told nothing (a wrapper-only mark is exactly what objectui#5223 forbids). Text,
+  number, select, and lookup cells were wired in PR #5429; `file` cells now
+  behave identically.
+
+### Patch Changes
+
+- 06a8af5: `QueryParams.$filter` now declares both shapes the data sources actually accept — the
+  MongoDB-style field-keyed record, or a `FilterArray`, the ObjectQL AST sugar bound from
+  `@objectstack/spec/data` (objectui#3909).
+  
+  **Nothing is narrowed and no accepted value changes.** `Record<string, any>` already
+  accepted arrays structurally — they satisfy its string index — so the union documents
+  shapes that were always legal rather than admitting new ones. Measured both ways under
+  `tsc --strict`: all five inputs `translateFilterToAST` enumerates assign to the old and
+  new declarations alike, and both reject a bare number and a bare string identically. A
+  downstream `turbo run build` over all 43 dependent packages is green, which is the
+  evidence a published type change breaks no consumer.
+  
+  The harm was entirely on the type face, and it was two-sided. The declaration blocked
+  nothing while describing one legal shape as though it were the only one — objectui#3831
+  is what that cost, a rule array accepted by a `Record<string, any>` slot, object-spread
+  flattened to `{"0": {...}}`, types green, and the query filtering on a column literally
+  named `0`. And someone writing a new consumer would read the type and its record-only
+  `@example`, conclude the array path was illegal, and add a tolerant conversion for it —
+  the "widen the consumer to tolerate the producer" shape AGENTS.md #0.1 forbids. Two
+  producers have fed arrays through this slot all along: `plugin-list`'s
+  `buildEffectiveFilter` (grid and export) and `plugin-view`'s `ObjectView` (calendar /
+  kanban / gallery / timeline). The runtime was right; the declaration was narrow.
+  
+  The array half is **bound** to the spec's `FilterArray` rather than restated locally, so
+  it cannot fork from the vocabulary the servers parse — the same failure two hand-written
+  operator lists had in objectui#3948. The doc comment names `translateFilterToAST` as the
+  authoritative accepted set instead of carrying a second list to drift from.
+  
+  `@object-ui/fields` drops the local cast this defect forced. PR objectui#3908 wrote
+  `filter as Record<string, any>` at one assignment in `useRecordQuery`, deliberately, as
+  debt rather than widening the shared type. `hasFilter` is now a type predicate narrowing
+  to the `$filter` slot's own type, so the assignment needs no cast and the guard cannot
+  drift from the declaration it guards. Type-only throughout; no runtime behaviour changes.
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- 5d3a2d1: The capability picker localizes `manage_sharing` (objectui#6285). Before this, "Manage
+  Sharing" was the one platform capability in `sys_permission_set`'s picker that rendered in
+  English in every locale, beside seven siblings that translated — a user-visible missing
+  translation, in all ten packs at once.
+  
+  The cause was an unchecked copy. `CURATED_CAPABILITY_LABELS` in
+  `CapabilityMultiSelectField.tsx` listed seven capability names under a doc comment claiming
+  it mirrored `@objectstack/spec/security`'s `PLATFORM_CAPABILITIES`; the spec grew an eighth
+  member and the list did not follow, so `manage_sharing` fell through to the English label
+  the `sys_capability` registry serves. Nothing could catch it: the i18n gate reads that list
+  as this key family's vocabulary and checks the members it names — all seven had keys — and
+  no instrument compared the vocabulary to the array it was named after.
+  
+  `capability.label.manage_sharing` is now authored in all ten packs and in the field widgets'
+  provider-less defaults map, the list carries the member, and the prose claim is replaced by
+  a check: `CapabilityMultiSelectField.specParity-6285.test.tsx` imports `PLATFORM_CAPABILITIES`
+  and fails on any difference in either direction, reading the declaration through the i18n
+  gate's own source reader so what it pins is exactly what that gate consumes. `labelFor` also
+  gains a `defaultValue`, so a capability that arrives in a future spec bump before its
+  translation is authored degrades to the registry's English label rather than rendering a raw
+  i18n key at the user.
+- dddb942: Delete the dead `metadata-admin/previews/object-fields-bridge.ts` module, and the three
+  prose references that still described it as wired.
+  
+  The module exported `bridgeFromDraft`, `commitToDraft` and `FieldsBridgeResult` and had
+  **zero importers** — re-measured on the merged base, not inherited from the filing. Nothing
+  in the repository could reach it either: `@object-ui/app-shell`'s `exports` map declares
+  only `.` and `./styles.css`, so the file was not addressable as a deep import even from
+  outside the workspace.
+  
+  Removing it is not the whole change. Three comments — in `types/src/designer.ts`, `types`'
+  `designer-field-types.test.ts` (twice) and `fields`' `richtext-cell-renderer-5452.test.tsx`
+  — cited the bridge as a live corroborating source. Left behind, they would have swapped
+  dead code for false documentation: three in-repo pointers telling a future reader that this
+  bridge mediates between the framework field record and `FieldDesigner`, and nothing telling
+  them it is unreachable. The two that named it as the consumer deriving an editable-subset
+  check from `DESIGNER_FIELD_TYPES` now name `MetadataFieldsPage`, which does exactly that
+  with the same idiom and the same `objectui#3017` anchor. The third cited the bridge's
+  `richtext` → `html` mapping as one of three corroborations that `richtext` stores HTML; the
+  other two (the showcase seed and the field-type decision tree) are live and carry the point
+  on their own, so that clause is dropped rather than repointed.
+  
+  No behaviour changes: nothing imported the module, so there is nothing to migrate.
+- a865c73: Grid field widget: announce a form-level validation failure to assistive tech.
+  
+  A required `grid` submitted while still empty rendered its "is required" message
+  but marked nothing — every row was a ghost row, and ghost rows were skipped by
+  the widget's per-cell validity channel. A sighted user saw the red message; a
+  screen-reader user was told nothing at all.
+  
+  The host failure now drives the per-cell channel the widget already owns: when
+  the `error` slot is set on an empty grid, the ghost entry row's required cells
+  flag, and the mark sits on each cell's own control rather than on the `td`
+  wrapper (a `td` is not focusable, and assistive tech reads validity from the
+  control). Populated grids are unaffected — they already marked their own empty
+  required cells inline.
+- cef27e2: The value-fallback label prettifier `humanizeLabel` has one implementation instead of two byte-identical copies.
+  
+  `humanizeLabel` turns a stored value into a display string when nothing else
+  resolves it — an option with no declared label, an object name, a chart axis
+  member. It existed twice, byte for byte: once in `@object-ui/fields` (read by
+  `plugin-grid`, `plugin-gantt`, `plugin-detail` and by that package's own
+  renderers) and once as a deliberate local copy in `plugin-charts`'
+  `ObjectChart.tsx`, whose comment said it was there "to avoid a dependency on
+  `@object-ui/fields`".
+  
+  Two copies of one convention is a live hazard rather than tidiness: one
+  dashboard can hold a chart and a grid over the same stored value, so a change
+  landing on one copy alone would put that value on screen under two spellings at
+  once. The single implementation now lives in `@object-ui/core` — the shared
+  ancestor both packages already depend on, so the dependency the copy existed to
+  avoid is still avoided and no new edge is created, and core takes no React
+  (objectui#4389: core-canonical logic, plugins consume). Both former sites
+  re-export it, so `import { humanizeLabel } from '@object-ui/fields'` keeps
+  working unchanged.
+  
+  **Nothing rendered changes.** The surviving implementation is byte-identical to
+  both deleted copies, and each former call site is pinned by identity against the
+  core function — not by a copied output table that someone would have to remember
+  to edit in two places.
+  
+  The core module also writes down, for the first time, why this convention stays
+  distinct from `humanizeFieldKey` (the KEY fallback, in `@object-ui/plugin-dashboard`),
+  which additionally splits camelCase:
+  
+  ```
+  input                humanizeFieldKey     humanizeLabel
+  needs_analysis       Needs Analysis       Needs Analysis
+  NeedsAnalysis        Needs Analysis       NeedsAnalysis        <- differ
+  unitPrice            Unit Price           UnitPrice            <- differ
+  BestCase             Best Case            BestCase             <- differ
+  lost-to-competitor   Lost-To-Competitor   Lost To Competitor   <- differ
+  ```
+  
+  A field KEY is authored in the codebase and carries a machine spelling, so
+  splitting camelCase recovers words its author meant. A stored VALUE is arbitrary
+  tenant data, where a mid-token capital is not reliably a word boundary and
+  splitting it rewrites what the tenant wrote (`McDonald` to `Mc Donald`). The two
+  conventions also do not nest — on the last row each leaves alone the separator
+  the other rewrites. Whether they should ever converge is a separate decision
+  that would move rendered output in four packages at once; it is deliberately not
+  made here.
+- e4e9557: A multi-value lookup cell no longer grows its row without bound: `LookupCellRenderer`
+  now shows at most 3 chips and collapses the rest into one muted `+N` chip, the same
+  cap `UserCellRenderer` has always applied to its avatar stack in the very same file.
+  
+  Previously the array branch rendered EVERY referenced record as its own chip inside a
+  `flex-wrap` container. In a grid column that wraps to one chip per line, so a cell
+  referencing a large set — a production 排班计划 row referencing 60+ work objects — grew
+  a single row to several screens of height and blew the page layout apart. The same
+  uncapped rendering reached every surface that resolves through `getCellRenderer('lookup')`:
+  grid, related lists, gallery, kanban, report and dashboard tables, and the record detail
+  sections.
+  
+  The collapsed names stay reachable: the `+N` chip's `title` lists the display names of
+  the hidden references (resolved through the same option/label/record-name path as the
+  visible chips), and the record's own detail view remains the place to see the full set.
+  The first 3 chips keep their per-record links (#4336) and their resolution order —
+  nothing changes for cells with 3 or fewer references.
+- 7a28e1e: A lookup's inline dropdown renders its columns through the same cell renderer the browse-all picker uses, so one `lookup_columns` declaration cannot produce two answers.
+  
+  A form's lookup field offers two ways to pick a related record, and both read
+  the same declaration: the inline dropdown under the field, and the
+  "browse all records" picker behind it. The picker resolved every cell through
+  the type-aware cell renderer. The dropdown did not — it printed
+  `record[descriptionField]` verbatim into the option subtitle and concatenated
+  `label: String(rawValue)` into the row's `title` attribute. Measured on the
+  same declaration, on a real 17.1.0 deployment:
+  
+  ```
+  column          inline dropdown (before)          browse-all picker
+  lookup          T5MsMCuwP4t_yUHq (bare FK id)     the related record's name
+  date            2026-08-20T00:00:00.000Z (ISO)    a formatted date
+  select          pending (enum code)               the authored option label
+  ```
+  
+  Both surfaces now call one shared module — `widgets/lookupColumnDisplay.tsx`,
+  which owns column normalisation, the field-descriptor enrichment from the
+  referenced object's schema, and the render itself. The picker's own
+  `renderCellContent` and `columnFieldDescriptors` are now thin calls into it, so
+  there is a single renderer left to drift from. The dropdown's extra columns are
+  rendered into the option row itself; the row's `title` keeps the full option
+  label, which is what a truncated label needs, instead of a raw-value dump.
+  
+  No query changed and no contract widened. `lookupColumns` entries stay bare
+  field names — no dot paths, no populate/expand semantics — because neither
+  surface's request carries populate to begin with: the picker resolves a
+  foreign-key id to a name client-side, in the lookup cell renderer, and the
+  dropdown now inherits exactly that. An unresolved reference therefore renders
+  what the picker renders for it, and keeps its column: a slot is dropped only
+  when the record holds no value for the field, decided on the raw value and
+  never on what the renderer makes of it, so an unresolved id can never degrade
+  into a silently empty column.
+- 4bb940b: A readonly `markdown` / `html` / `richtext` form field now renders its content
+  FORMATTED instead of showing the user its markup source (objectui#5498).
+  
+  `RichTextField`'s readonly early return rendered `{value}` as a React text child,
+  so a readonly field of any of those three types displayed the stored markup as
+  literal characters — a markdown field's asterisks and hashes, a richtext field's
+  tags. The `prose` classes on that wrapper were the tell: they style rendered rich
+  content, and there was none to style. Every other read surface — grid, kanban
+  card, gallery, related list, dashboard record panel and the record detail page's
+  read mode — dispatches through `getCellRenderer` and rendered the same stored
+  bytes formatted, so one field disagreed with itself depending on which surface it
+  was read on.
+  
+  The readonly branch now renders through the same components `getCellRenderer`
+  resolves: `markdown` through the GFM renderer, `html` and `richtext` through the
+  sanitizing HTML renderer. The two renderers moved out of the package barrel into
+  `widgets/richTextDisplay.tsx` so the widget can reach them without importing the
+  barrel back, and both sides now read one shared type-to-renderer table rather
+  than two that can drift apart.
+  
+  The editor header's format label is fixed with it: it was computed as
+  `field.format || 'markdown'`, and `format` is declared on `date` / `datetime` /
+  `time` / `phone` / `auto_number` and on no rich-content type — so it read
+  `undefined` for every real field and labelled an `html` field "Format: markdown".
+  The label is now derived from the field type's display pipeline, so it names the
+  syntax the value is actually stored in.
+- 6c6cee7: A RETIRED field-type spelling is now refused — out loud, once — by every
+  field-type predicate in the renderer, not just by the widget road
+  (objectui#4914, maintainer ruling B of 2026-08-18).
+  
+  `@object-ui/fields` exports a single `isRetiredFieldType(t)` gate, and it runs
+  ahead of six predicate faces that previously granted a retired spelling
+  first-class treatment: the filter builder's operator buckets and its value
+  control (`@object-ui/components`), the detail page's highlight-strip picker
+  (`@object-ui/plugin-detail`), `normalizeFieldType` (`@object-ui/plugin-view`),
+  the dashboard's `$expand` whitelist and `isLookupType`
+  (`@object-ui/plugin-dashboard`), and the list toolbar's lookup-like filter
+  control (`@object-ui/plugin-list`). Each one now fires the migration
+  prescription on the console — once per spelling across all of them, never once
+  per predicate — and then answers as it would for a spelling it does not
+  recognise.
+  
+  This closes the whole CLASS rather than one word: the gate is quantified over
+  `RETIRED_FIELD_TYPES`, so the next retirement covers all seven consumers on the
+  day it lands. It is the shape objectui#4932 and objectui#4942 already
+  established for the form and inline-edit roads.
+  
+  Measured before the change, and the reason the fix is a gate rather than a
+  deletion: `owner` was not dead in these faces. `operatorsForFieldType('owner')`
+  equalled the `user` bucket item for item, `computeLookupExpand` actively
+  requested `$expand` for it, `isLookupType('owner')` was `true` alongside
+  `reference`, and `normalizeFieldType('owner')` answered `'select'` exactly as
+  `picklist` does. Deleting the members alone would have traded a visible
+  contradiction for a SILENT degradation — a filter picker collapsing to a bare id
+  box, `$expand` quietly stopping so cells show raw foreign-key ids — which is
+  verbatim the failure mode `RETIRED_FIELD_TYPES`' own docblock exists to prevent.
+  The gate keeps that fallback and adds the half that was missing: the author is
+  told.
+  
+  The boundary question is answered on record: `owner` arriving through a
+  backend-vocabulary normalizer is an authoring error to refuse loudly, not
+  legitimate foreign input to tolerate. The open backend vocabulary those
+  normalizers exist for is untouched — `reference`, `picklist`, `money`, `int`,
+  `datetime_tz` and the rest are equally absent from the spec's closed `FieldType`
+  and are equally unretired, so they classify exactly as before.
+  
+  `RETIRED_FIELD_TYPES`, `reportRetiredFieldType` and `resetRetiredFieldTypeReports`
+  move to `@object-ui/core` and are re-exported from `@object-ui/fields`, so that
+  package's published surface is unchanged apart from the newly ruled gate.
+  `@object-ui/components` is a consumer of the gate and `@object-ui/fields`
+  depends on it, so a single shared table could not live in `fields` — and a
+  second copy would have meant a second dedupe set and two console lines for one
+  spelling. No package gained a new dependency.
+  
+  A retired spelling never loses a stored value: `retypeFilterValue` is
+  deliberately not gated, and the refused filter row stays operable rather than
+  drawing a blank operator trigger.
+- f1690d4: A populated `richtext` field no longer renders as a blank cell (objectui#5452).
+  
+  `richtext` stores HTML — the spec documents the type as "Formatted content with
+  HTML/WYSIWYG", the showcase seed's own specimen is `<p>Rich <strong>text</strong></p>`,
+  and this repo's designer bridge already maps `richtext` onto its `html` type. The
+  display registry nevertheless dispatched it to `MarkdownCellRenderer`, whose
+  sanitizing GFM pipeline runs react-markdown with no `rehype-raw` and therefore drops
+  raw HTML. Because a richtext value is *entirely* HTML, everything was dropped and the
+  cell body came out empty — with no error, no fallback and no console warning, so a
+  populated field read as an empty field and anyone auditing data through a grid
+  concluded the records were blank. Measured on the same stored bytes, a neighbouring
+  `html`-typed column rendered them correctly, which is what ruled out "the value never
+  arrived".
+  
+  `richtext` now resolves to `HtmlCellRenderer`, which sanitizes with `sanitizeHtml`
+  (script/style/iframe/object/embed blocks, inline event handlers and `javascript:`
+  URLs removed) and keeps everything a rich-text editor legitimately emits — headings,
+  paragraphs, emphasis, lists, links, quotes. One map entry fixes every read surface at
+  once: the grid, the kanban card, the gallery, the related list, the dashboard record
+  panel and the record detail page all resolve their read-mode cells through this same
+  `getCellRenderer`.
+  
+  The markdown pipeline is untouched. Passing raw HTML through it would have "fixed"
+  one type by moving every `markdown` cell's trust boundary, so `markdown` still drops
+  raw HTML — pinned alongside the fix, on the same bytes `richtext` must now render.
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [a1c41c5]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [8d3a529]
+- Updated dependencies [194fae1]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [b362c1b]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [20e317c]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/providers@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/fields/package.json b/packages/fields/package.json
index 5e442f18c7..8226417c6c 100644
--- a/packages/fields/package.json
+++ b/packages/fields/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/fields",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "description": "Field renderers and registry for Object UI",
   "license": "MIT",
   "type": "module",
diff --git a/packages/i18n/CHANGELOG.md b/packages/i18n/CHANGELOG.md
index 5fa542ac97..9dc85faf03 100644
--- a/packages/i18n/CHANGELOG.md
+++ b/packages/i18n/CHANGELOG.md
@@ -1,5 +1,706 @@
 # @object-ui/i18n
 
+## 17.7.0
+
+### Minor Changes
+
+- b362c1b: Setup gains a **Packaged automation** page — the operational surface for the flows an
+  installed package ships (ADR-0126 §7.4, objectui#6301). Reached the way every other
+  framework-contributed Setup surface is: the page registers the component-registry ref
+  `automation:packaged`, so app navigation names the ref and `ComponentNavView` resolves it
+  at `/apps/<app>/component/automation/packaged`. No bespoke route is added — a second way
+  in would be a URL the app metadata does not know about.
+  
+  Per packaged flow the page does exactly two things:
+  
+  - **on/off for this scope** — reads the activation state the engine reports
+    (`GET /api/v1/automation/_status`, backed by the ADR-0126 §7.2 `sys_metadata_activation`
+    ledger) and flips it through `POST /api/v1/automation/<name>/toggle`;
+  - **clone** — `POST /api/v1/automation/<name>/clone` with a mandatory new machine name and
+    label (§7.1). The carried-over definition is never offered as editable form fields; the
+    copy is edited in Studio like any other flow.
+  
+  Authoring stays in Studio. The list is scoped to packaged flows by the server's own
+  three-clause provenance test (`isCodeArtifactBody`, ADR-0029 D9.6) rather than the
+  `_packageId`-only shortcut, which classifies a tenant overlay bound to a package as
+  packaged — the cloud#970 misread, and here it would put a tenant's own flow behind an
+  install-wide switch.
+  
+  **Server refusals reach the operator verbatim** — no client-side softening or rewording.
+  Three shapes are relayed as sent: the §5 posture gate (403 `PERMISSION_DENIED`, whose
+  message names the tenancy posture *and* the sanctioned clone path), the §7.3 subflow guard
+  (409 `DELETE_RESTRICTED`, which names the packaged callers that would break mid-run — a
+  list nothing on the client could reconstruct), and the §7.1 clone name conflict (409).
+  
+  ⛔ **No drift or ancestry surface** (§9): no diff-vs-base, no "customized" badge, no
+  base-moved notice, no link from a clone back to its source. Cloned-without-disabled and
+  disabled-without-clone are ordinary states, shown plainly. Tests pin the absence, including
+  the case where a response carries a `clonedFrom` key anyway — the platform does not track
+  that lineage, so a page that displayed it would be displaying something it invented.
+  
+  `@object-ui/i18n` gains the `packagedAutomation` key group — 24 keys in `en` and real
+  translations in all nine other packs, matching each pack's existing vocabulary for "flow"
+  and "package" (zh 流程/软件包, ja フロー/パッケージ, ko 플로우/패키지, de Flow/Paket,
+  fr Flux/Package, es Flujo/Paquete, pt Fluxo/Pacote, ru Поток/Пакет, ar التدفق/الحزمة) and
+  each one's quotation convention. The group deliberately carries no drift or ancestry
+  wording, and no server refusal text: those arrive as server-authored prose and are
+  rendered verbatim.
+- 9602dc8: Setup › **Packaged automation** gains a packaged **actions** section beside its flows one —
+  the surface half of ADR-0126 §8 item 2 (objectui#6412; the engine, ledger and both dispatch
+  doors landed in objectstack#12348). The maintainer's pull, verbatim and untranslated:
+  「动作 可能是需要开关的，因为有的 action 我不想启用。」
+  
+  Per packaged action the section does exactly **one** thing: **on/off for this scope**. That
+  is all the `sys_metadata_activation` ledger knows about an action, and the section claims
+  nothing more.
+  
+  - **State** comes from the ledger's `metadata_type: 'action'` rows, read through the generic
+    data API list the object itself sanctions for exactly this
+    (`apiMethods: ['get', 'list']` — *"Reads stay open so operability surfaces can answer
+    'what is disabled here?'"*). **Absence of a row means active**, so a stock boot shows
+    everything armed.
+  - **Discovery** mirrors the runtime's own `collectActionDeclarations`: object-embedded
+    `actions[]` from `GET /meta/object` **plus** standalone items from `GET /meta/action`, with
+    the object-embedded declaration winning a `<object>:<action>` key clash. Listing only the
+    first source would leave an administrator with no off-switch for a packaged standalone
+    action.
+  - **Flips** invoke the L6 write door `POST /actions/_activation/:object/:action` with exactly
+    the one key its body declares (`{ enabled }`); `global` is the object segment for an
+    object-less action, the same spelling both dispatch doors take.
+  
+  **⛔ No clone for actions.** The flows section keeps its own (§7.1); amendment ruling 3
+  charters the *switch* for actions and nothing else, and §8 keeps the clone half pre-chartered
+  until real pull appears. A clone control here would advertise machinery that does not exist —
+  which is also why the server's §5 refusal for actions recommends the platform operator and an
+  ordinary sibling action where the flow refusal recommends a clone.
+  
+  **⛔ No drift or ancestry surface** (§9): no "customized" badge, no diff-vs-base, no
+  base-moved notice. The platform tracks no such lineage, so a surface showing it would be
+  showing something it had to invent. The absence is pinned against a response that smuggles
+  `clonedFrom` / `baseVersion` in, so it is enforced at the renderer and not merely by the wire.
+  
+  Server refusals reach the operator **verbatim** — no client-side softening, no retry loop.
+  Three shapes are reachable in tests, each transcribed character-for-character from the
+  runtime's own message builders: the §5 posture gate (403 `PERMISSION_DENIED`, naming the
+  posture *and* the sanctioned path), the ambiguous-name refusal (409 `RESOURCE_CONFLICT`,
+  naming the objects a machine name collides across — a list nothing on the client could
+  reconstruct) and the no-ledger outage (503 `SERVICE_UNAVAILABLE`).
+  
+  One further refusal is the section's own and it points the same way: a `hasMore` on the
+  ledger read is treated as a **load failure** rather than rendered. A dropped row reads as
+  "active", so a partial ledger would show a switched-off action as armed — the one direction
+  this section must not fail in.
+  
+  The flows section is unchanged in behaviour. It gains a heading beside the new one, and the
+  page subtitle now says "Flows and actions" — that string moved in all ten packs together.
+  Nine new `packagedAutomation.*` keys land in `en` **and in all nine other packs** as real
+  translations; the two toggle-failure keys are artifact-neutral by wording and are reused
+  rather than duplicated.
+- 77f846a: The approval panel identifies the pending approver by name, not by a truncated raw id.
+  
+  A record waiting on a position rendered its approver as `positi…ager` — the
+  engine reference `position:sales_manager`, 22 characters, past the identity
+  formatter's 14-character truncation arm and middle-truncated to fit its chip. The
+  step names beside it were human prose; the one line answering *who is holding
+  this record* was an internal identifier, and not even a complete one. The same
+  reference reached the admin-override confirm dialog un-truncated, so a paragraph
+  of plain governance prose ended `— position:sales_manager` (objectui#5414).
+  
+  Both surfaces now resolve the reference before rendering, in three tiers, most
+  authoritative first. The server's own `pending_approver_names` wins whenever it
+  answers, and a backend that resolves its own slate costs the record page no extra
+  request. Otherwise the console reads the directory row the spec's approver
+  binding names — `sys_position.label` gives `Sales Manager` / `销售经理` — and,
+  for a position, who fills the seat (`Sales Manager · Zhang Wei, Li Na`). With no
+  adapter and no row, the machine name still prettifies into prose rather than
+  truncating. The raw reference stays on hover, which is where an internal
+  identifier belongs.
+  
+  An unstaffed position is surfaced rather than hidden: `销售经理（暂无在岗人员）`
+  is actionable where `positi…ager` is not, and it is the motivating rescue case
+  for the admin-override path. Staffing is deliberately tri-state — a
+  `sys_user_position` read the viewer is not permitted to make leaves the seat's
+  staffing UNKNOWN and says nothing, because "I could not look" is a different
+  claim from "nobody holds it" and only one of them is safe to print on a
+  governance surface.
+  
+  Two locale keys are added across all ten packs: `approvalsInbox.approverUnstaffed`
+  and `approvalsInbox.approverNameSeparator`. The separator is a translated
+  punctuation key rather than `Intl.ListFormat`, which was measured on this tree
+  joining `['张伟','李娜']` into `张伟李娜` for `zh` — two names run together with
+  no separator, reading as one person's name.
+  
+  The directory-backed kinds and their value columns are read from
+  `@objectstack/spec`'s `APPROVER_VALUE_SOURCES` rather than restated, so a new
+  approver type is covered the day the spec publishes it. Id-valued kinds
+  (`user` / `team` / `department`) keep the existing middle-truncation: a row id
+  has no prose to recover, and that arm is objectui#3461's answer, not this card's
+  defect.
+- c40f3b8: A screen flow's resume result reaches the user — on both outcomes (objectui#5417).
+  
+  A dogfood walkthrough reported that a refused `resume` and a successful one
+  "render identically: the dialog closes and the page is unchanged", leaving no
+  gesture that distinguishes "created" from "rejected". Re-measured against `main`
+  before any change, one half of that was already fixed — `interpretFlowResponse`
+  reads the ADR-0112 envelope, and `FlowRunner`'s `toast.error` has carried its
+  prose since the `400 FLOW_FAILED` classification landed in `17.6.0`, five minors
+  after the version the report was measured on. There was no interpreter bug and
+  no un-consolidated fourth call site. Three gaps in the RUNNER's disposition were
+  real, and they are what changed:
+  
+  - **A terminal failure no longer closes the dialog.** The reason it closed is
+    unchanged and is not reversed: on a `FLOW_FAILED` the engine has already
+    consumed the suspension, so a resubmit can only reach "No suspended run" and
+    must not be offered. Closing was one way to withhold that dead retry and the
+    expensive one — the user had just typed a form they could no longer see, and
+    the engine's sentence names a value that left the screen with it. The dialog
+    now stays open with the submit affordance withdrawn: the flat footer swaps
+    Submit for Close, and an `object-form` step drops its Save (which also stops a
+    second click from duplicating the record it had already persisted).
+  - **The refusal has a second, non-expiring carrier.** The toast stays — it is
+    viewport-fixed, so it still reaches a user scrolled past a tall step's header
+    — and an inline destructive `Alert` (`role="alert"`) now holds the same
+    sentence inside the dialog, beside the values that produced it. A retryable
+    refusal (`INVALID_SCREEN_INPUT`, transport, 5xx) keeps Submit live as before,
+    and its banner clears as soon as the user starts editing.
+  - **A successful run invalidates what the flow WROTE, not just what the user is
+    looking at.** Both hosts answered `onComplete` with
+    `notifyDataChanged({ objectName: <this page's object> })`, so a flow that
+    created a quote from an Opportunity page never told the related list that
+    would now contain it — the record did not appear until a manual reload. The
+    runner cannot know which objects a flow touched, so it emits
+    `{ objectName: '*' }`: the same scope, for the same stated reason, that the
+    record page's manual ⟳ already uses. Everything mounted refetches in place
+    over the invalidation bus, with no remount.
+  
+  The runner's copy now goes through `@object-ui/i18n` instead of being hardcoded
+  English: a new `flowRunner` namespace (`title`, `submitting`, `saveAndContinue`,
+  `nextStep`, `completed`) in all ten packs, plus reuse of
+  `common.{loading,cancel,close,submit}` and `wizard.missingRequired`. The
+  server's own refusal sentence is still passed through untranslated — it is prose
+  the automation engine composed for a human, not copy with a key.
+- 20e317c: Marketplace-less runtimes now say so instead of erroring: `OS_CLOUD_URL=off` is a
+  first-class disabled state, and the load-failure hint describes the control plane
+  the runtime was actually pointed at (objectui#5504).
+  
+  `apps/objectos-ee/deploy/.env.example` ships `OS_CLOUD_URL=off` as its factory
+  default, so a stock self-hosted stack has no marketplace at all. The Console still
+  recommended one: Home led with "Start with a template" and "Browse App
+  Marketplace", and the click landed on a red **Failed to load marketplace / Not
+  found** card whose hint claimed this runtime "points at the public ObjectStack
+  cloud by default" and advised setting `OS_CLOUD_URL`. Both claims were false for
+  exactly the deployment reading them — the operator had not left the default, and
+  the advice pointed back at the template that told them to set `off`. "Marketplace
+  disabled by configuration" is a configuration conclusion, not a load failure.
+  
+  - `isMarketplaceEnabled()` (`runtime-config`) reads the server's own
+    `features.marketplace`, which `RuntimeConfigPlugin` derives per request from the
+    serving app's route table (objectstack#8356). It is never inferred from the shape
+    of a failed request: a control plane that is merely DOWN leaves the flag `true`,
+    so an outage still renders as an outage. Unknown fails OPEN.
+  - The marketplace page renders an informational "App Marketplace is turned off"
+    state — muted, not `destructive` — and issues no request it knows will 404.
+  - Home's "Start with a template" cover greys out with a visible localized reason,
+    and the "Browse App Marketplace" shortcut is withheld, exactly as they already
+    are for the `manage_metadata` capability gate.
+  - `marketplace.load.failedHint` is replaced by `failedHintConfigured` (naming the
+    configured control plane) and `failedHintSameOrigin`. The "points at the public
+    cloud by default" sentence is gone: it was rendered unconditionally, including on
+    every runtime whose operator had overridden `OS_CLOUD_URL`.
+  
+  All ten locale packs carry the new keys.
+- 7a90afd: Studio's `新建对象` asks for the record-sharing baseline, and an unauthored one is reported before Publish rather than by it.
+  
+  Creating an object through Studio collected exactly two things — display name and
+  identifier — and saved a draft that declared no `sharingModel`. The draft saved
+  happily, the form designer worked, and the object was then refused at 发布 →
+  全部发布 by `security-owd-unset`: a required decision the surface never asked
+  for, delivered by failing, as English ADR prose in a toast that then vanished on
+  a timer. The one actionable word in it named a control three clicks away that
+  nothing routed to.
+  
+  The publish gate is correct and is unchanged — an org-wide default has to be an
+  authored decision, not an accident. What changes is when the console asks and
+  when it answers:
+  
+  - **The create dialog asks.** A third field collects the baseline, pre-selected
+    to `private` and glossed with the Settings tab's own strings, so a new object
+    is publishable by construction. `buildObjectSkeleton` now takes the value as a
+    required parameter — a future create path cannot omit the baseline without
+    failing to type-check. `controlled_by_parent` is deliberately not offered at
+    creation: it derives access from a master relation a brand-new object does not
+    have yet, so offering it would trade one publish refusal for another.
+  - **The review sheet reports it.** The pending-changes panel now runs the
+    framework's own `validateSecurityPosture` over the pending object drafts and
+    names any blocking finding, with its fix-it hint, next to the Publish button.
+    It mirrors the producer's rule rather than re-deriving it, and it reports
+    without blocking — the server door stays the authority.
+  - **The Settings tab stops calling an unset baseline safe.** It described unset
+    as "defaults to Private", which answers what the runtime does and not whether
+    the object can ship. It now reads as the publish-blocking problem it is,
+    styled like the external-wider warning beside it.
+- fb96ecb: `WidgetConfigPanel` reads an inline-locale-map title, and a save no longer destroys the other locales.
+  
+  The dashboard widget config panel carried a private `resolveLabel` documented as
+  resolving an `I18nLabel` while reading `defaultValue || key` — the key-reference
+  form `@objectstack/spec` retired at 17.0.0-rc.6 (objectstack#5055). The inline
+  per-locale map `I18nLabelSchema` actually admits has neither limb, so
+  `{ en: 'Revenue', zh: '收入' }` resolved to `''`. It was the fourth private copy
+  of that resolver; objectui#4032 swept the other three out of `DashboardRenderer`,
+  `MetricWidget` and `MetricCard`.
+  
+  This was not a display bug. The resolved value seeds the panel's editable draft,
+  so a widget whose stored title was a map opened with an **empty** Title field and
+  the next save wrote `''` over the author's map — on the ordinary path, not an
+  exotic one: open the widget, change anything, save.
+  
+  Both halves are fixed, per the maintainer's 2026-08-20 ruling on objectui#5301:
+  
+  - **Reading** goes through `pickLocalized(value, language)`, so the panel shows
+    the active locale like every sibling surface post-objectui#4032.
+  - **Writing** replaces only the active locale's entry and carries every other
+    locale across. A title the author never touched round-trips the stored object
+    itself through an unrelated config edit; an edited one merges into the entry
+    that was displayed. The live-update callback (`onFieldChange`) forwards the
+    merged map for the same reason — hosts feed it back into the widget the panel
+    re-opens from, so a bare string there dropped the map before a save ever ran.
+  
+  `@object-ui/i18n` gains `setLocalized(value, language, next)`, the write-side
+  inverse of `pickLocalized`, so the rule is stated once instead of re-derived per
+  panel. It follows `pickLocalized`'s first three limbs — exact tag, base language,
+  region-qualified sibling — and deliberately stops there: the `default` / `en` /
+  first-value limbs are display fallbacks that hand back *another* locale's string,
+  and writing to one would let an author editing in `fr` overwrite English. With no
+  entry for the active locale the edit adds one. The pairing
+  `pickLocalized(setLocalized(map, lang, s), lang) === s` is pinned, because a
+  write that lands where the read does not look is how a "saved" string disappears.
+  
+  A full multi-locale editing UI remains out of scope (objectui#4163).
+
+### Patch Changes
+
+- b06e374: The Spanish pack renders `Done` as `Listo` at every one of the four sites that say it
+  (objectui#3880, triage adjudication 2026-08-09). `grid.bulk.done` — the footer button that
+  dismisses the bulk-action result dialog — read `Hecho` while `common.done`, `view.done` and
+  `form.fullscreen.done` all read `Listo`, so the same English word rendered two ways in
+  Spanish across dialogs a user meets in one session.
+  
+  Adjudicated a typo rather than a deliberate contextual split, on three checks. All four
+  keys hold the byte-identical `en` value `Done`, and all four call sites are the same
+  control: a dialog-footer button whose click finishes or dismisses the surface
+  (`BulkActionDialog` `onClose(result)`, `ManageViewsDialog` `onOpenChange(false)`,
+  `fullscreen-editor` `commitFullscreen`, `InviteMemberDialog`'s invitation-created footer).
+  The nine other packs each render all four identically (de `Fertig`, fr `Terminé`, pt
+  `Concluído`, ru `Готово`, ja `完了`, ko `완료`, zh `完成`, ar `تم`), so no other translation
+  pass had found a context worth splitting on. And the neighbouring `Hecho`/`Deshecho`
+  pairing that could have justified it does not hold: `grid.bulk.undo` is the verb `Deshacer`,
+  and `Deshecho: ` is `undonePrefix`, a result-line status rather than a button.
+  
+  `Hecho` moved to the 3:1 majority `Listo`, which is the value objectui#3546 slice seven had
+  already chosen for `common.done`. `packages/i18n/src/__tests__/residue-namespaces-3546.test.tsx`
+  pinned the old outlier as a recorded example of deliberate divergence; that pin now asserts
+  the four as one value instead, and its note keeps the history plus the `Pending`/zh row,
+  which remains a genuine deliberate split.
+  
+  No `en` value changes, so no other pack is asked to follow. This is the value half of
+  objectui#3880 only — the card's 281/164 shared-string census stays on the card as
+  documentation, and is explicitly not a gate: 164 of those groups diverge legitimately.
+- 594704f: The `console.objectView.*` config-panel vocabulary is retired — 116 keys removed from each
+  of the ten packs, 1160 translated strings that nothing read (objectui#4730, maintainer
+  ruling 2026-08-19).
+  
+  The namespace held 209 keys per pack. 116 of them labelled a view-configuration settings
+  panel that does not exist: appearance and density toggles, accessibility attributes,
+  conditional-formatting rules, row-action and inline-edit switches, quick-filter builders,
+  an advanced-settings tier. `packages/app-shell/src/views/ViewConfigPanel.tsx` — the panel
+  they were written for — was migrated off the legacy `buildViewConfigSchema` engine onto
+  `ViewVariantInspector`, a spec-driven inspector whose field labels come from
+  `@objectstack/spec` metadata rather than from this namespace. The panel was replaced; the
+  keys were not cleaned up with it.
+  
+  Removed under objectui#4658's three-legged evidence standard, re-measured on this branch's
+  merge base rather than inherited from the card: zero `t()`/`tt()` call sites, zero textual
+  occurrence of the dotted key anywhere in the repo outside the packs that define it, and a
+  consumer spot-check confirming no i18n wiring. The 93 live keys stay — the create-view
+  dialog fields, the view-type catalogue, `new`/`save`/`cancel`, the object-not-found copy,
+  plus the 38 keys whose spelling still appears somewhere the AST pass cannot see, which are
+  out of scope here.
+  
+  Four of the retired keys name `ListViewSchema` properties that are still active —
+  `rowActions`, `inlineEdit`, `hiddenFields`, `filterableFields`. They are retired anyway, by
+  the ruling's own words: a live schema property is not a consumer of a locale string; only a
+  labelled UI control is. If such a panel is ever specified, its keys are re-authored
+  alongside it.
+  
+  `packages/i18n/src/__tests__/objectView-config-keys-retired-4730.test.ts` pins the removal
+  by name. Every i18n gate in this repo runs call site → key, so none of them can see a dead
+  key come back: the parity gate is fully satisfied by 116 dead keys present in all ten packs,
+  and the reverse sweep that found them (`scripts/check-i18n-dead-keys.mjs`) is report-only by
+  design. The pin is the only thing that would notice.
+- 41b7ce3: **View configuration is explicitly org-wide, and its write path is now gated (objectstack#7494's
+  ruling, maintainer 2026-08-12).** The `sort` / `hiddenFields` / `columnState` / `rowHeight` that a
+  list toolbar persists were never per-user: they are one shared row on the view, so an ordinary user
+  dragging a column or cycling density was re-styling that view for the entire organization. Nothing
+  in the console said so, and nothing stopped it. A per-user scope stays parked (objectstack#7611,
+  v18) and is deliberately not built here — which is precisely why the write has to be gated rather
+  than narrowed: there is no second, private store for it to fall back to.
+  
+  `ObjectStackAdapter.updateViewConfig` now refuses when the session's **reported** ADR-0066 capability
+  set does not contain `manage_metadata`, throwing the new `ViewConfigPermissionDeniedError`
+  (`VIEW_CONFIG_PERMISSION_DENIED`, with `isViewConfigPermissionDeniedError` and the
+  `VIEW_CONFIG_CAPABILITY` constant alongside it). The gate is the **first** statement in the method —
+  before `connect()`, before the payload is assembled — so a refused call puts nothing on the wire.
+  It is on the write rather than on the toolbar button on purpose: withholding the affordance would
+  leave the method still accepting the call from anything else holding the adapter, whereas a gate on
+  the write is inherited by every caller, present and future.
+  
+  `manage_metadata` is not a newly minted name. It is the capability this repo already treats as
+  metadata-authoring authority — `HomePage`'s `AUTHORING_CAPABILITY`, the one the server itself
+  refuses metadata writes without — and the gated write goes through `client.meta.saveItem`, the very
+  same ADR-0005 metadata door, so this applies the authority the server is already applying instead of
+  inventing a parallel one.
+  
+  **Unknown fails open, by doctrine.** A capability set that was never reported (a backend predating
+  ADR-0066, or no permission provider mounted) is not a denial: the server enforces regardless, so a
+  client-side refusal on missing data cannot protect anything and can only break a permitted user. A
+  *reported* empty grant gates strictly. Hosts push the session's capabilities in with the new
+  `setSystemCapabilities`; `ObjectView` wires it from `usePermissions()`.
+  
+  The refusal is also **said out loud**. `ObjectView`'s persist path previously swallowed every failure
+  into `console.error`, which for a debounced toggle whose UI has already moved would have left the
+  operator looking at a density they did not get; a denied write now raises a toast. And the "View
+  settings" popover — where density and field visibility are actually changed — now states the scope
+  before the operator acts: *"Grouping, color, density, and visible fields. Applies to everyone who
+  uses this view."*, translated in all ten packs.
+- 95f8704: `record:path` now announces each stage's state, not just its label (WCAG 2.2 SC 1.4.1)
+  
+  The lifecycle path distinguished travelled, upcoming and lost-terminal stages with
+  colour plus a `✓`/`✗` glyph, and both glyphs are `aria-hidden` decoration.
+  `aria-current="step"` marked the current stage and nothing else, so a screen-reader
+  user heard a run of identically-announced items — and a rejected stage announced
+  exactly like an ordinary stage the record had not reached yet.
+  
+  Each stage now carries an accessible name composing its (already picklist-localized)
+  label with its state, from five new `detail.pathStage*` keys translated in all ten
+  locale packs. The glyphs stay decorative and the readout's `role="listitem"` /
+  `aria-current` semantics are unchanged.
+  
+  The name is composed into `aria-label` rather than visually-hidden text because
+  `listitem` takes its name from the author only: text placed inside a stage computes
+  to an empty accessible name, so the visually-hidden shape would have looked right in
+  the markup and delivered nothing to the accessibility tree.
+- 8d3a529: `record:path` finishes localizing and de-colouring its accessible names — the two residues
+  objectui#5916 named and deliberately left behind (objectui#5956, objectui#5957).
+  
+  **The list's own label was English on a localized surface, and the other one named nothing.**
+  Both the desktop and the mobile `role="list"` row did
+  `aria-label={schema.aria?.label || 'Record path'}`, so a zh/ja/ar session heard `Record path`
+  for the list while every stage inside it announced in the session locale — one control
+  speaking two languages at once. The fallback is now `detail.pathLabel`, translated in all ten
+  packs; the `schema.aria.label` author override still wins ahead of it.
+  
+  The lost-terminal alt group was a different defect wearing the same clothes: its
+  `aria-label="Alternative terminal stages"` sat on a bare `div`, which has the `generic` role,
+  and browsers expose no accessible name on a generic element. That string reached nobody —
+  inert, not merely untranslated — so translating it would have shipped copy to ten packs that
+  no user can hear. It is removed rather than given a role that takes a name, on three
+  measurements: nothing is lost (it was never announced), it would be redundant (every stage
+  inside already announces `closed lost` in the session locale after objectui#5916, in the one
+  place `role="list"` can carry it), and it would fork the two rows (the mobile row renders one
+  flat list with no alt group, so a named group would make one control expose two structures by
+  viewport).
+  
+  **An unreached goal terminus was distinguished by hue alone.** `railClass` paints it
+  `bg-emerald-500/30` where a plain upcoming stage gets `bg-muted` — the renderer's own note
+  calls this "a faint emerald so the goal is legible" — while both announced the identical
+  `{{stage}}, upcoming`. Two stages ahead of the record painted differently and read the same:
+  the WCAG 2.2 SC 1.4.1 class objectui#5916 closed, on the one distinction it left behind, and
+  reachable without authors opting in because `classify()` finds `won` through the `WON_TOKENS`
+  heuristic as well as an explicit `terminal: 'won'`. New key `detail.pathStageWonUpcoming`
+  (`{{stage}}, goal stage, not reached`), translated in all ten packs.
+  
+  Scoped to the UNREACHED goal, which is a measurement of the stylesheet rather than a
+  preference: a reached goal terminus paints `bg-primary` when current and `bg-emerald-500` when
+  completed, byte-identical to any other current or completed stage. Naming it apart would hand
+  a screen reader a distinction the screen does not make — the mirror image of the defect — so
+  it is one new key, not a pair, and a test pins that decision so it cannot drift into a fourth
+  state unnoticed.
+  
+  Both new keys also land in `DETAIL_DEFAULT_TRANSLATIONS`, which
+  `defaults-maps-mirror-en-pack` compares against the `en` pack key by key, so neither can fork
+  between a provider-mounted console and a provider-less embed. No existing `en` value changes,
+  so no pack is asked to follow an edit.
+- b08b7eb: All ten locale packs now define `home.recentApps.itemType.report` and
+  `home.recentApps.itemType.metadata` (objectui#6023). `RecentItem['type']` is a six-member
+  union and `useTrackRouteAsRecent` writes both of these at runtime — `metadata` on any
+  `/metadata/<type>/<name>` route visit, `report` on any `/report/<name>` visit — but the
+  packs defined only four of the six, so the Recently Accessed and Starred cards labelled
+  those two items from the call sites' inline `defaultValue` instead of from the pack.
+  
+  Ten packs missing the same member is full parity, so no pack-vs-pack gate could see it,
+  and the prefix rule only ever asked whether `home.recentApps.itemType` resolved, which it
+  did. What made it quiet rather than loud is the `defaultValue`: English readers saw a
+  plausible `Report` / `Metadata` (lowercase in the rail) rather than a raw key, and the
+  other nine locales saw those English words — objectui#3517's mechanism for hiding a
+  missing key for months.
+  
+  The nine translations were taken from each pack's own existing rendering of the same word
+  rather than composed: the singular `Report` that `appDesigner.navReport`,
+  `appDesigner.navTypeReport` and `search.badgeReport` already carry (ar `تقرير`, de
+  `Bericht`, es `Informe`, fr `Rapport`, ja `レポート`, ko `보고서`, pt `Relatório`, ru
+  `Отчёт`, zh `报表`), and the `Metadata` that `layout.metadata.label` already carries (ar
+  `البيانات الوصفية`, de `Metadaten`, es `Metadatos`, fr `Métadonnées`, ja `メタデータ`, ko
+  `메타데이터`, pt `Metadados`, ru `Метаданные`, zh `元数据`). No new vocabulary was invented
+  for any locale.
+  
+  The two matching entries in `scripts/i18n-call-site-key-baseline.json`'s `missingMembers`
+  are cleared, since that list is a ratchet: a baselined entry whose defect is gone fails the
+  build too. The union itself is untouched — narrowing `RecentItem['type']` is the other
+  resolution the gate accepts, and it would have been a lie about data both call sites
+  demonstrably write.
+- 5fa06c4: The zh pack's `console.breadcrumb.reports` renders 报表, the noun the rest of the pack
+  already uses for the report feature (objectui#6166).
+  
+  **The authority for this edit is the maintainer ruling of 2026-08-25, not an occurrence
+  count.** The card was filed explicitly as a native-speaker call and explicitly forbade
+  resolving it by normalising to the majority: 报表 (a tabular/data report) and 报告 (a
+  written/narrative report) are not interchangeable, so a pack that spells one key
+  differently from its siblings is evidence of a majority and never, on its own, evidence of
+  a mistake. The maintainer ruled that no deliberate narrative-report distinction was
+  intended here and that the breadcrumb names the same report feature the rest of the pack
+  calls 报表.
+  
+  The render context corroborates the ruling and closes the confidence gap triage recorded
+  when it declined to decide this itself. `console.breadcrumb.reports` labels the
+  `routeType === 'report'` **list** route in app-shell's `AppHeader` — a structural sibling
+  of the `dashboards`, `pages` and `system` segments beside it — and drilling through it
+  appends a metadata report definition, the same feature named by
+  `console.commandPalette.reports`, `console.nav.navReport`, `search.typeReports`,
+  `search.badgeReport` and `search.reportNotFound`. Nothing narrative renders beneath it.
+  
+  A comment at the key records that this was **ruled** rather than counted, and states the
+  报表/报告 distinction it was ruled against, so the next reader measuring pack consistency
+  neither re-files it nor quietly restores 报告 after reading the render context and
+  disagreeing. That comment is half of the deliverable; the value change alone would leave
+  the decision unrecorded, which is the failure mode the card was most concerned about.
+  
+  **Scope: one key, one pack.** This is not a licence to normalise vocabulary across the ten
+  packs — the card names that hazard explicitly and says it would need its own ruling, and
+  this ruling grants nothing beyond the single key it names. No `en` value changes, so no
+  other pack is asked to follow, and no other pack was touched.
+- 5d3a2d1: The capability picker localizes `manage_sharing` (objectui#6285). Before this, "Manage
+  Sharing" was the one platform capability in `sys_permission_set`'s picker that rendered in
+  English in every locale, beside seven siblings that translated — a user-visible missing
+  translation, in all ten packs at once.
+  
+  The cause was an unchecked copy. `CURATED_CAPABILITY_LABELS` in
+  `CapabilityMultiSelectField.tsx` listed seven capability names under a doc comment claiming
+  it mirrored `@objectstack/spec/security`'s `PLATFORM_CAPABILITIES`; the spec grew an eighth
+  member and the list did not follow, so `manage_sharing` fell through to the English label
+  the `sys_capability` registry serves. Nothing could catch it: the i18n gate reads that list
+  as this key family's vocabulary and checks the members it names — all seven had keys — and
+  no instrument compared the vocabulary to the array it was named after.
+  
+  `capability.label.manage_sharing` is now authored in all ten packs and in the field widgets'
+  provider-less defaults map, the list carries the member, and the prose claim is replaced by
+  a check: `CapabilityMultiSelectField.specParity-6285.test.tsx` imports `PLATFORM_CAPABILITIES`
+  and fails on any difference in either direction, reading the declaration through the i18n
+  gate's own source reader so what it pins is exactly what that gate consumes. `labelFor` also
+  gains a `defaultValue`, so a capability that arrives in a future spec bump before its
+  translation is authored degrades to the registry's English label rather than rendering a raw
+  i18n key at the user.
+- 00c665e: `appDesigner.fieldDesigner.formula` is retired — one row removed from each of the ten
+  locale packs plus the designer defaults map, 11 lines, zero readers (objectui#6310).
+  
+  objectui#6043 retired the Field Designer's formula-expression textarea, which was the
+  key's only call site (`FieldDesigner.tsx`, the `{ name: 'formula', label:
+  t('appDesigner.fieldDesigner.formula') }` field descriptor). The value outlived it in
+  eleven places: `DESIGNER_DEFAULT_TRANSLATIONS` in
+  `packages/plugin-designer/src/hooks/useDesignerTranslation.ts`, and the `appDesigner >
+  fieldDesigner > formula` leaf of `packages/i18n/src/locales/{en,de,es,fr,pt,ru,ja,ko,zh,ar}.ts`.
+  
+  Removed under objectui#4658's evidence standard, re-measured on this branch rather than
+  inherited from the card: zero `t()`/`tt()` call sites, no dynamic template head that could
+  reach it (`appDesigner.fieldDesigner.typeCategory.` is the namespace's only one), and its
+  sole textual occurrence anywhere in the repo was the defaults-map row this change removes
+  with it — so the key goes from NEEDS-REVIEW to no footprint at all.
+  
+  The map and all ten packs move in one commit, which is what keeps
+  `defaults-maps-mirror-en-pack` green: that gate fails a map row whose key the `en` pack
+  lacks, and `all-locales-key-parity` fails a pack left behind.
+  
+  Not touched: `designer.field.formula` (`'Formula (CEL)'`) in
+  `packages/app-shell/src/views/metadata-admin/i18n.ts`, a different and live key belonging
+  to metadata-admin's `ObjectFieldInspector` — the surface that still authors formula
+  expressions.
+  
+  `packages/i18n/src/__tests__/appDesigner-fieldDesigner-formula-retired-6310.test.ts` pins the
+  removal by name, following the four prior retirements (objectui#4145, objectui#4392,
+  objectui#4730, objectui#5504). Every i18n gate here runs call site → key, so none of them can
+  see a dead key come BACK into the packs: the reverse sweep that found this one is report-only
+  by design, `all-locales-key-parity` is fully satisfied by ten packs agreeing on a dead key, and
+  `check:i18n-drift` only fires when a value changes. Reverse-verified rather than asserted —
+  reviving the row in all ten packs turns exactly that one case red, naming each pack, while the
+  parity gate and the defaults-map mirror stay green.
+- 3a58149: A cloud-connection bind failure now reads in the user's language whichever clock
+  noticed it (objectui#5054).
+  
+  One abandoned device approval could be noticed by either of two clocks, and the
+  Cloud Connection panel had a different answer for each. When the panel's own
+  `expires_in` deadline fired first it rendered `cloudConnection.errors.expired` —
+  translated in all ten packs. When the SERVER noticed first, `/bind/poll` answered
+  HTTP 400 with `message: 'Device authorization failed: expired_token'`; `getJson`
+  threw a bare `Error` carrying only that sentence, and the catch rendered it
+  verbatim. Same user, same failure, two languages, decided by which clock got
+  there first — visible on a zh console as the same abandoned approval reading
+  Chinese or English depending on whether the tab sat open past `expires_in`.
+  
+  `getJson` now carries the envelope's `declaredCode` and `code` across its throw,
+  and a single closed map turns the two RFC 8628 outcomes a user can actually cause
+  into console copy: `expired_token` → the existing `cloudConnection.errors.expired`,
+  `access_denied` → a new `cloudConnection.errors.accessDenied` added to all ten
+  locale packs. `declaredCode` is read first, because ADR-0112 keeps the upstream
+  spelling there — `code` is `DEVICE_CODE_FAILED` for both.
+  
+  Every other code is unchanged: `invalid_grant`, and anything upstream invents
+  next, still render the wire `message`, which stays the single source of truth for
+  failures this console has no copy for. No API, export or resolver was widened.
+- 6ce89da: The 确认修改 (confirm changes) card now carries a UI-owned terminal state after approval (#5695): `detectReplayOutcome` lifts the confirm-replay envelope (`replay_*` tool results) into 应用中 / 已生效 / 已暂存为草稿（含内联发布）/ 未生效（含 publishError 首行）, rendered on the original card across the live, hydration/share, and localStorage-cache converters. A failed in-turn publish no longer rehydrates as an ordinary draft card with a live Publish button — the UI-rendered refusal is the layer a model cannot narrate over. New `console.ai.changesApplying/Applied/Drafted/Failed` keys in all ten locale packs.
+- de570cc: fix(i18n): `useObjectTranslation`'s provider-less `t` now interpolates its inline `defaultValue`
+  
+  With no `I18nProvider` mounted, react-i18next hands back its not-ready `t`, which
+  returns `options.defaultValue` **verbatim** — so an inline default written
+  `'Deleted {{count}} rows'` reached the user with the braces intact. 68 inline
+  defaults across 24 files rendered through that path on any host that embeds an
+  ObjectUI component without a provider, which is the configuration
+  `createSafeTranslation` exists for.
+  
+  `useObjectTranslation` now runs its not-ready result through the same one
+  interpolator `createSafeTranslation`'s `fallbackT` uses, so both provider-less
+  renderers fill exactly the `{{name}}` spelling the copy is already gated to. The
+  ready path is untouched: with a provider, i18next's own `t` is returned by
+  reference and nothing is interpolated twice. Pre-interpolated template-literal
+  defaults (`` `Deleted ${n} rows` ``) stay correct — they have no holes left to
+  fill — so no call site changes.
+- 1e66879: `console.ai.pendingDrafts` — the standing unpublished-changes bar's five strings —
+  now exists in all ten locale packs. It previously existed only in `en` and `zh`, so
+  `ar`, `ru`, `pt`, `es`, `fr`, `de`, `ko` and `ja` rendered the English defaults and
+  `all-locales-key-parity` failed on `main` (objectui#5705).
+  
+  The feature landed `en`-only in objectui#5696; the follow-up in objectui#5697 was
+  titled for the locale packs but reached only `zh`, so eight packs × five keys stayed
+  missing and the parity assertion — which carries no allowlist — was red on `main` and
+  on every PR whose diff touched source. Source-free diffs skip the shard that runs it,
+  which is why the breakage survived several merges.
+  
+  Each pack keeps its own conventions rather than `en`'s: the eight all quote with `"`,
+  `ru` puts the number last (`…: {{count}}`) as it already does for the sibling
+  `home.pendingDrafts` counts, and `ja` uses the full-width `：` before `{{detail}}`
+  because that value is a runtime message rather than a single token — both choices
+  carry an in-pack note. Terminology is taken from each pack's existing publish-bar
+  vocabulary (`home.pendingDrafts`, `console.ai.seedWarn`) so the two banners read
+  alike.
+  
+  Both interpolations survive verbatim in every pack — `{{count}}` in `count` and
+  `{{detail}}` in `publishedWithFindings` — asserted mechanically against the evaluated
+  packs, not by eye. The unrelated `home.pendingDrafts` block (`message` / `cta`) is a
+  different node and is untouched.
+- c5200f0: Follow-up to #5696: the pending-drafts bar's strings live at `console.ai.pendingDrafts.*` with en+zh locale entries — the i18n call-site key gate and ratchet flagged the original root-level keys that existed nowhere.
+- 38a9568: `useObjectLabel` now keeps a stable identity when no i18next instance is bound,
+  so the memoization it advertises holds on the no-provider path too
+  (objectui#5564).
+  
+  react-i18next's `useTranslation` builds its return value out of a fresh `{}` on
+  every render when it has nothing to bind to (`const finalI18n = i18n || {}`,
+  which then feeds that hook's own `useMemo` deps), so the `i18n` object arrived
+  with a new identity each render. `useObjectLabel` keyed its memo on `[t, i18n]`,
+  so the memo never held: measured 4 distinct returned objects across 4 renders
+  with no instance, against 1 with one. That is the wrong way round — the memo
+  exists to stop downstream `useMemo`/`useCallback` deps from being re-keyed in
+  heavy consumers, and `useSafeFieldLabel`'s docstring names the no-provider case
+  as the one it exists to serve.
+  
+  Both memo dependencies are now pinned to module-level constants while no
+  instance is bound. The substitution is unobservable rather than merely
+  convenient: every `t()` call in the module sits inside a
+  `for (… of getAppNamespaces())` loop, and `getAppNamespaces()` returns `[]`
+  under exactly the same "is there a usable instance" predicate — so while the
+  substitution is in effect, the closures cannot read either value. When an
+  instance appears the dependencies become the live values again, so a provider
+  mounting after first render recomputes the object exactly once and resolves
+  real translations from then on.
+  
+  No API change: no new exports, no signature changes, and the returned surface is
+  identical on both paths. Direct `useObjectLabel()` consumers are fixed alongside
+  `useSafeFieldLabel()` ones, including `ListView.filterFields` — the consumer the
+  memo's own docstring names.
+- b2437a7: `setLocalized`'s published docblock states the single-locale write rule that is
+  actually in force, instead of deferring the multi-locale-authoring question to a
+  closed card (objectui#5591).
+  
+  The docblock read "is not a multi-locale authoring UI (objectui#4163)". objectui#4163
+  closed as completed on 2026-08-15 with that product question still unanswered, so the
+  parenthetical pointed at nothing — and it read as though the question had been settled
+  somewhere a reader could go and check. This is the failure mode objectui#5428
+  demonstrated is not harmless: there, a dangling deferral of exactly this shape let an
+  expired justification sit unread for a release cycle at two surfaces.
+  
+  The remedy is objectui#5428's, not a re-pointing at a successor card: state the rule in
+  force (`setLocalized` reaches only the entry for the locale the author is in), keep the
+  open product question open **in place**, and record why there is deliberately no tracker
+  reference — so the next reader cannot restore one. Re-pointing is how the class
+  regenerates, because the next card closes too. The same wording form already landed in
+  `plugin-designer`'s `writeWidgetTitle` and `DashboardWidgetInspector`.
+  
+  Prose only. No behaviour, no signature, no test changes — `setLocalized`'s pairing with
+  `pickLocalized` is unchanged and still pinned by `src/__tests__/setLocalized.test.ts`.
+  
+  Declared as a `patch` for `@object-ui/i18n` alone because the emit was measured per
+  package rather than assumed, and the two packages this change touches differ:
+  
+  - `@object-ui/i18n` — the docblock sits on the **exported** `setLocalized`, so it reaches
+    the published artifacts. Rebuilt with `tsconfig.tsbuildinfo` cleared first (the build is
+    `composite`, which otherwise skips emit), and compared by SHA-256 rather than byte count:
+    `dist/pickLocalized.d.ts` `1e2170ad…` -> `124a1c07…` and `dist/pickLocalized.js`
+    `06eb88bd…` -> `568cb703…`. A consumer reads this text on hover and in the API docs, so
+    it publishes something.
+  - `@object-ui/plugin-dashboard` — the two comments changed there are a `//` banner between
+    declarations and a test docblock, neither attached to an exported declaration.
+    `dist/WidgetConfigPanel.d.ts` is **byte-identical** across the rebuild
+    (`93252e8cdf5a6faa…` both sides). The only artifact that moved is
+    `dist/WidgetConfigPanel.d.ts.map`, whose mappings shift because lines were added above
+    the declarations; no declaration text changed. Nothing user-visible publishes from that
+    package, so it is not named here.
+- eddc1dd: The Studio copilot tells the agent WHAT the user is discussing (cloud#1610 send half): `ChatPane` accepts a `surfaceContext` and sends it as `context.surface` on every turn (the transport reads the body per send, so it stays fresh); the Studio copilot derives it from the URL alone — the `:tab` pillar segment plus the `?surface=type:name` deep-link the pillars already mirror, so the artifact carries its type discriminator (page/object/dashboard/report). A display chip above the composer (「正在讨论：…」, new `console.ai.discussing` key in all ten packs) makes the sent context visible instead of invisible grounding.
+- Updated dependencies [9801765]
+- Updated dependencies [053fdc8]
+- Updated dependencies [490d9a9]
+- Updated dependencies [546ddf7]
+- Updated dependencies [44d075b]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [299102e]
+- Updated dependencies [831be72]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [e719ebd]
+- Updated dependencies [fa429cf]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [105f3c5]
+- Updated dependencies [af3861f]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [91783c4]
+- Updated dependencies [2d36552]
+- Updated dependencies [ed71d9e]
+  - @object-ui/core@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/i18n/package.json b/packages/i18n/package.json
index a1173f6592..08ec2ead5b 100644
--- a/packages/i18n/package.json
+++ b/packages/i18n/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/i18n",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "sideEffects": false,
   "license": "MIT",
diff --git a/packages/layout/CHANGELOG.md b/packages/layout/CHANGELOG.md
index 728f273d41..d80001c2e8 100644
--- a/packages/layout/CHANGELOG.md
+++ b/packages/layout/CHANGELOG.md
@@ -1,5 +1,169 @@
 # @object-ui/layout
 
+## 17.7.0
+
+### Patch Changes
+
+- fe76ece: The typings both packages publish now carry an explicit extension on every relative specifier, so a consumer on `moduleResolution: nodenext` can follow them.
+  
+  `vite-plugin-dts` emits one declaration file per source file, and TypeScript
+  copies a module specifier into the declaration verbatim. `export * from './ui'`
+  therefore shipped extensionless in `dist/index.d.ts` — 21 such re-exports in
+  `@object-ui/components`, 7 in `@object-ui/layout`, 128 across the two emitted
+  trees. Node16/NodeNext resolution does not extension-search a relative
+  specifier, so the compiler could follow none of the hops and every symbol they
+  carried read as absent from the package:
+  
+  ```
+  error TS2305: Module '"@object-ui/components"' has no exported member 'Badge'.
+  ```
+  
+  Measured on `@object-ui/app-shell`, the largest consumer and the one that pulls
+  in both packages: 880 TS2305 across 162 files (864 from `components`, 16 from
+  `layout`), plus 215 TS7006 as fallout from the imports that stopped resolving.
+  On `@object-ui/fields`, 178 TS2305 and 57 TS7006. Both are zero now.
+  
+  The emitted `.js` never had the defect — rolldown resolves the same specifier
+  away — which is why `pnpm check:esm-specifiers`, whose verdict is about
+  specifier-preserving `.js` builds, correctly never scanned either package. The
+  fix is therefore in the declaration EMIT (`scripts/vite-dts-explicit-extensions.ts`,
+  shared by both `vite.config.ts` files), not in the sources: the same source line
+  produces a clean `.js` and a broken `.d.ts`, so no source edit can express the
+  difference. The rewriter resolves each specifier against the source tree the
+  output mirrors — a file hop becomes `./x.js`, a directory hop `./x/index.js` —
+  throws on anything it cannot resolve, and after the build re-parses the emitted
+  declarations to assert every relative specifier both carries an extension and
+  names a file the build really emitted.
+  
+  `packages/fields` takes the `nodenext` pin as a result — the same two lines
+  `packages/react` has carried since objectui#4538 — so the property is enforced by
+  the compiler on the consumer side rather than by review. `packages/app-shell`
+  does not: it type-checks clean without the pin and still shows 23 errors with it,
+  none of them from these two packages. That residue is filed separately.
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [194fae1]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/types@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/layout/package.json b/packages/layout/package.json
index 6581d4f15d..45bd6519c5 100644
--- a/packages/layout/package.json
+++ b/packages/layout/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/layout",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "sideEffects": [
     "./dist/index.js",
diff --git a/packages/mobile/CHANGELOG.md b/packages/mobile/CHANGELOG.md
index 4161e7dc50..67f19d6f5c 100644
--- a/packages/mobile/CHANGELOG.md
+++ b/packages/mobile/CHANGELOG.md
@@ -1,5 +1,106 @@
 # @object-ui/mobile
 
+## 17.7.0
+
+### Minor Changes
+
+- 2d7304d: Retire the `MobileOverrides` type and its `mobileOverrides` mount point (objectui#4919,
+  maintainer ruling 2026-08-19, ADR-0049 enforce-or-remove).
+  
+  `MobileOverrides` published a six-key mobile override surface — `layout`, `columns`,
+  `useBottomSheet`, `fullScreen`, `touchTarget` and a three-value `navigation` vocabulary
+  (`'bottom-tabs' | 'hamburger' | 'drawer'`) — from `@object-ui/types` and, re-exported,
+  from `@object-ui/mobile`. Nothing read any of it. Measured on current `main`: the type had
+  exactly four mentions repo-wide — its own declaration, the single
+  `MobileComponentConfig.mobileOverrides` mount point, and the two barrel re-exports — and
+  the lower-case property name (the spelling a renderer would actually read) appeared only
+  in that declaration. No renderer, hook or adapter resolved it, and a sweep of the example
+  apps and the `objectstack` sibling checkout found zero authors. The three `navigation`
+  values were three spellings of the same no-op.
+  
+  The declared surface is removed rather than narrowed. The #3985 lineage's rule is "narrow
+  to the implemented values"; here the implemented set is empty, so that rule terminates in
+  deletion — a config that type-checks, builds and silently does nothing is the
+  declare-without-enforce shape the platform doctrine forbids.
+  
+  Removal rather than a `?: never` tombstone follows this package's own discriminator. A
+  tombstone exists to steer authors to a named live replacement — `crud.ts` `confirm` →
+  `confirmText` (objectui#4314), `data-display.ts` `hoverable` / `striped` → `data-table`
+  (objectui#5474) — or to keep a key loud that the docs had actively taught as working.
+  Neither applies: there is no replacement key to steer to, no documentation ever described
+  the surface, and there is no successor spelling. That is the same zero-pull, no-successor
+  shape as the retired `AccordionItem.icon` (objectui#4652) and `ToggleGroupItem.icon`
+  (objectui#4632), both of which were removed outright rather than tombstoned.
+  
+  **Breaking for TypeScript authors of `MobileOverrides` / `mobileOverrides` only** (marked
+  `minor` per this repo's version-alignment rule, which reserves `major` for following
+  `@objectstack` across a major — see AGENTS.md's 版本号策略, and the identical
+  classification used for `AccordionItem.icon`). Runtime behaviour is unchanged: an authored
+  `mobileOverrides` did nothing before and does nothing now. What changes is that the
+  contract no longer claims otherwise, so the mistake surfaces at authoring time — importing
+  the type is now a "has no exported member" error, and authoring the key on a
+  `MobileComponentConfig` object literal is an excess-property error, instead of a silent
+  no-op that type-checks and builds.
+  
+  If real mobile-override renderer work is ever wanted it re-enters deliberately, as designed
+  product surface on its own card, with the renderer landing in the same change as the
+  declaration — not by resurrecting this declaration.
+
+### Patch Changes
+
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [69a2163]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [e4559d1]
+- Updated dependencies [6f81384]
+- Updated dependencies [dddb942]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [d7acad6]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [100547e]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [0e05aac]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [199d31b]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [515f171]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [3c73d99]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/types@17.7.0
+
 ## 17.6.0
 
 ### Patch Changes
diff --git a/packages/mobile/package.json b/packages/mobile/package.json
index 11bf8a8e93..caf6c9ba7b 100644
--- a/packages/mobile/package.json
+++ b/packages/mobile/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/mobile",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Mobile optimization for Object UI with responsive components, PWA support, and touch gesture handling.",
diff --git a/packages/permissions/CHANGELOG.md b/packages/permissions/CHANGELOG.md
index 70e748b38a..4a82bc46fa 100644
--- a/packages/permissions/CHANGELOG.md
+++ b/packages/permissions/CHANGELOG.md
@@ -1,5 +1,66 @@
 # @object-ui/permissions
 
+## 17.7.0
+
+### Minor Changes
+
+- 3c9fca3: Create forms pre-fill the `current_user` defaultValue token with the acting user (#5683). `PermissionContextValue` gains `userId` (from `/me/permissions`; `null` = unknown), and the create-form seeding resolves `defaultValue: 'current_user'` on `user` / `lookup→sys_user` fields to that id — the same value the engine stamps at insert, so the pre-fill is a preview of the server's own resolution, not a second default contract. Unknown user (no provider / anonymous / role-based provider) seeds nothing and keeps the omit-and-let-the-engine-resolve behavior. `NOW()` and CEL defaults stay server-owned.
+
+### Patch Changes
+
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [69a2163]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [e4559d1]
+- Updated dependencies [6f81384]
+- Updated dependencies [dddb942]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [d7acad6]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [100547e]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [0e05aac]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [199d31b]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [515f171]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [3c73d99]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/types@17.7.0
+
 ## 17.6.0
 
 ### Patch Changes
diff --git a/packages/permissions/package.json b/packages/permissions/package.json
index 5c457f5276..9ba91d28cf 100644
--- a/packages/permissions/package.json
+++ b/packages/permissions/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/permissions",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "RBAC permission system for Object UI with object/field/row-level access control, permission guards, and hooks.",
diff --git a/packages/plugin-ai/CHANGELOG.md b/packages/plugin-ai/CHANGELOG.md
index 028227253e..80e8af2272 100644
--- a/packages/plugin-ai/CHANGELOG.md
+++ b/packages/plugin-ai/CHANGELOG.md
@@ -1,5 +1,156 @@
 # @object-ui/plugin-ai
 
+## 17.7.0
+
+### Patch Changes
+
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [194fae1]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/types@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Patch Changes
diff --git a/packages/plugin-ai/package.json b/packages/plugin-ai/package.json
index c925294af4..77323afe92 100644
--- a/packages/plugin-ai/package.json
+++ b/packages/plugin-ai/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-ai",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "main": "dist/index.umd.cjs",
   "module": "dist/index.js",
diff --git a/packages/plugin-calendar/CHANGELOG.md b/packages/plugin-calendar/CHANGELOG.md
index 4289380882..b1efb94df0 100644
--- a/packages/plugin-calendar/CHANGELOG.md
+++ b/packages/plugin-calendar/CHANGELOG.md
@@ -1,5 +1,320 @@
 # @object-ui/plugin-calendar
 
+## 17.7.0
+
+### Patch Changes
+
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- 3e853c9: Let a producer-marked refusal reach the drag-write surfaces (objectui#5902).
+  
+  The kanban card-move toast, the calendar drag-to-reschedule toast and the OCC
+  conflict dialog each substituted a generic string for a refusal the producer had
+  marked as user-facing (`userMessage`), so a user was told "Save failed" where the
+  application author had written a sentence addressed to them. All three now read
+  the marking through the shared `declaredUserMessage` reader, which covers both
+  places the adapter boundary parks it — the typed member on
+  `ConcurrentUpdateError` and the details bag on `DataApiValidationError`.
+  
+  Nothing unmarked changes: the reader answers `null` for it, so every existing
+  generic substitution — including the localized "not authorized" message that
+  keeps raw server diagnostics away from end users — still governs unmarked
+  refusals exactly as before.
+  
+  The two toasts substitute; the conflict dialog augments. Its description also
+  explains what the destructive "Overwrite" button does, which is affordance copy
+  that surface owns rather than a refusal message, so the marking leads and that
+  paragraph stays.
+- 7975f2d: A standalone `object-calendar` bound to an object now queries WITH its `$expand`, so
+  lookup / master_detail / user / tree fields render the related record instead of a raw
+  foreign-key id (objectui#6453).
+  
+  `ObjectCalendar`'s fetch effect built its expand set from a ref assigned in the render body
+  (`objectSchemaRef.current = objectSchema`) and left `objectSchema` out of its dependency
+  list. That bought the effect exactly one run per mount and paid for it with the expansion,
+  permanently: on that one run the ref was still `null`, `buildExpandFields` saw no fields,
+  the query went out with no `$expand` at all, and nothing re-ran the effect when the schema
+  landed. Only the standalone calendar reached this path — one hosted by `ObjectView` or
+  `ListView` receives its rows as `data`, which objectui#6419 already covers.
+  
+  The ref is replaced by a settled-and-keyed resolution (`{ key, def } | null`) that GATES the
+  record query, the third member of the family after objectui#6271 (`ObjectKanban`) and
+  objectui#6419 (`ObjectView`). Measured on this component rather than inherited: gated, the
+  calendar issues one query carrying `$expand` in every latency profile; the alternative of
+  adding `objectSchema` to the dependency list issued two, and when the schema read was the
+  slower of the two it painted raw ids, reverted to the "Loading calendar..." placeholder,
+  then swapped — a three-step paint the correct rows do not arrive any later than.
+  
+  The gate is on the schema read having SETTLED, never on a truthy schema: an adapter that
+  exposes no `getObjectSchema`, and a read that throws, both settle with nothing and the
+  calendar still queries (unexpanded) rather than waiting forever. An inline `value` data set
+  is deliberately not gated — it issues no metadata read, so there would be no resolution to
+  wait for.
+- 76ae729: `README.md`'s "Schema API / CalendarView" block described a `CalendarViewSchema`
+  that does not exist. Measured against the interface itself
+  (`packages/types/src/complex.ts`) and its zod mirror: `events` — the schema's
+  only required key besides `type` — was published as `events?`, so a reader
+  following the README omits it and TypeScript rejects the node; `defaultDate` was
+  `string` where the schema says `string | Date`; and `onDateClick` was listed as a
+  schema key when it is a `CalendarViewProps` **component** prop, sending readers
+  to a different package's surface for a key `calendar-view` does not have (the
+  schema's key is `onDateChange`). The block also listed 6 of the schema's 13 keys
+  with nothing saying it was a summary (objectui#5045).
+  
+  The block now carries the requiredness the schema declares, names itself a
+  partial summary of `CalendarViewSchema`, and adds the author-facing
+  `defaultView` / `view` / `views` / `editable` / `date`. It also states plainly
+  what the registered `calendar-view` renderer actually reads — it builds events
+  from the node's `data` array and drops an authored `events` key (objectui#4433) —
+  so the corrected requiredness does not itself become a new wrong instruction.
+  
+  This is a documentation fix to a file `plugin-calendar` publishes to npm, which
+  is why it carries a version: the npm landing page only picks up the correction
+  on a release. No behaviour, export, type, or `dist` byte changes. The pin test
+  added alongside it publishes nothing.
+- f47d94c: `@object-ui/plugin-calendar` now exports the `CalendarView` component's runtime event
+  type as **`CalendarViewEvent`**, and keeps `CalendarEvent` as a **`@deprecated` alias**
+  of it. **Non-breaking:** the alias is a working re-export denoting the same type, so
+  code importing `CalendarEvent` from this package keeps compiling unchanged — nothing is
+  removed and no behaviour changes.
+  
+  Why: `@object-ui/types` exports its own `CalendarEvent`, the AUTHORING event
+  (`id: string`, `start` / `end` accept ISO strings with `end` required, plus
+  `description`), while this package's was the runtime event (`id: string | number`,
+  `start: Date`, `end?: Date`). Neither is assignable to the other, and IDE auto-import
+  chose between the two identical names essentially at random — the wrong pick surfaced as
+  a remote `TS2322` about `Date` rather than as a wrong import, which is how this package's
+  own README example stayed uncompilable through an earlier import-path fix. The authoring
+  type keeps the canonical `CalendarEvent` name; the runtime type gets the self-describing
+  one (objectui#5044, following the `ObjectCalendarProps` -> `ObjectCalendarComponentProps`
+  rename in objectui#4650).
+  
+  Write `CalendarViewEvent` in new code.
+- 065bba7: `CalendarViewSchema` (TS interface and zod mirror) converges on the registered
+  `calendar-view` renderer's measured read set (objectui#5667, maintainer ruling
+  option A — the renderer is authoritative).
+  
+  **Breaking for consumers of the published type** (deliberate; per-repo policy
+  breaking changes ship as `minor` — the fixed group's `major` tracks
+  `@objectstack`):
+  
+  - Nine inert keys are retired: `events` (the interface's only required key,
+    which the renderer deliberately drops — objectui#4433), `defaultView`,
+    `defaultDate`, `date`, `views`, `editable`, `onEventCreate`,
+    `onEventUpdate`, `onDateChange`. None had a read site on the authored-node
+    path and no measured app authors them (ADR-0049 enforce-or-remove).
+  - The type now declares what the renderer actually reads: `data`, `titleField`,
+    `startDateField`, `endDateField`, `allDayField`, `colorField`, `view`,
+    `currentDate`, `allowCreate`, `className`, plus the two host-only function
+    hatches it forwards (`onEventClick`, `onViewChange`).
+  - Practical radius, measured: `BaseSchema` carries an index signature and the
+    zod `BaseSchema` is `.passthrough()`, so nodes still authoring retired keys
+    neither fail to compile nor get rejected at validation — they are simply no
+    longer declared, documented, or type-checked. The material accept change is
+    that zod no longer **requires** `events`: a `{ "type": "calendar-view" }`
+    node without it now validates (previously the one key validation demanded
+    was the one key guaranteed to do nothing).
+  
+  Runtime renderer behaviour is unchanged. `@object-ui/plugin-calendar`'s README
+  and `content/docs/api/schema-reference.md` are repaired to the converged
+  surface in the same change, so no copy of the old contradiction survives.
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [f66072d]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [1117414]
+- Updated dependencies [6d63cd0]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [7c96c94]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [8d3a529]
+- Updated dependencies [194fae1]
+- Updated dependencies [63d54dd]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [b4393e5]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [d3005f7]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [b362c1b]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [3777538]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [d06fba8]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [9a1fb41]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [a865c73]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [0b12a33]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [e4e9557]
+- Updated dependencies [7a28e1e]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [6c1b105]
+- Updated dependencies [9d9040d]
+- Updated dependencies [20e317c]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [4bb940b]
+- Updated dependencies [17fbbaf]
+- Updated dependencies [d8cf1cb]
+- Updated dependencies [0d1e702]
+- Updated dependencies [0068348]
+- Updated dependencies [641543f]
+- Updated dependencies [8a44390]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [23705b7]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [f1690d4]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/fields@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/plugin-detail@17.7.0
+  - @object-ui/mobile@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Patch Changes
diff --git a/packages/plugin-calendar/package.json b/packages/plugin-calendar/package.json
index b2b8d67e1e..5bec20d437 100644
--- a/packages/plugin-calendar/package.json
+++ b/packages/plugin-calendar/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-calendar",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Calendar view plugins for Object UI - includes both ObjectQL-integrated and standalone calendar components",
diff --git a/packages/plugin-charts/CHANGELOG.md b/packages/plugin-charts/CHANGELOG.md
index f8807b8dad..928ed74b3a 100644
--- a/packages/plugin-charts/CHANGELOG.md
+++ b/packages/plugin-charts/CHANGELOG.md
@@ -1,5 +1,268 @@
 # @object-ui/plugin-charts
 
+## 17.7.0
+
+### Minor Changes
+
+- 6f017e9: Dashboard chart widgets no longer render as a blank area when their height class
+  resolves to `auto`.
+  
+  `ChartContainer`'s min-size fallback was applied only to the wrapper `div`.
+  Recharts measures its own `width:100%;height:100%` size-detector element, and a
+  percentage height never resolves against an ancestor's `min-height`, so the
+  wrapper obediently grew to 280px while the measured element stayed at 0 — and
+  Recharts renders no children at all for a non-positive box. The result was a
+  widget card with its title over an empty chart area: no marks, no refusal, no
+  empty state, and permanent, because a box that never changes fires no resize.
+  The floor is now applied to the measured element as well, under the same
+  condition, so an author's explicit height still wins.
+
+### Patch Changes
+
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- 894d103: `ObjectChart`'s wrapper div now carries `h-full`, keeping the height chain intact from a dashboard grid cell's declared height down to the element Recharts measures. Previously the chain died at the plain auto-height wrapper: `height: 100%` on the chart container computed to `auto`, Recharts measured a permanent zero, and only the `CHART_MIN_HEIGHT` floor (#5503) kept dashboard charts visible — at a fixed floor height instead of filling the cell (#5451). Under auto-height parents `h-full` resolves to `auto`, so non-dashboard hosts are unchanged.
+- cef27e2: The value-fallback label prettifier `humanizeLabel` has one implementation instead of two byte-identical copies.
+  
+  `humanizeLabel` turns a stored value into a display string when nothing else
+  resolves it — an option with no declared label, an object name, a chart axis
+  member. It existed twice, byte for byte: once in `@object-ui/fields` (read by
+  `plugin-grid`, `plugin-gantt`, `plugin-detail` and by that package's own
+  renderers) and once as a deliberate local copy in `plugin-charts`'
+  `ObjectChart.tsx`, whose comment said it was there "to avoid a dependency on
+  `@object-ui/fields`".
+  
+  Two copies of one convention is a live hazard rather than tidiness: one
+  dashboard can hold a chart and a grid over the same stored value, so a change
+  landing on one copy alone would put that value on screen under two spellings at
+  once. The single implementation now lives in `@object-ui/core` — the shared
+  ancestor both packages already depend on, so the dependency the copy existed to
+  avoid is still avoided and no new edge is created, and core takes no React
+  (objectui#4389: core-canonical logic, plugins consume). Both former sites
+  re-export it, so `import { humanizeLabel } from '@object-ui/fields'` keeps
+  working unchanged.
+  
+  **Nothing rendered changes.** The surviving implementation is byte-identical to
+  both deleted copies, and each former call site is pinned by identity against the
+  core function — not by a copied output table that someone would have to remember
+  to edit in two places.
+  
+  The core module also writes down, for the first time, why this convention stays
+  distinct from `humanizeFieldKey` (the KEY fallback, in `@object-ui/plugin-dashboard`),
+  which additionally splits camelCase:
+  
+  ```
+  input                humanizeFieldKey     humanizeLabel
+  needs_analysis       Needs Analysis       Needs Analysis
+  NeedsAnalysis        Needs Analysis       NeedsAnalysis        <- differ
+  unitPrice            Unit Price           UnitPrice            <- differ
+  BestCase             Best Case            BestCase             <- differ
+  lost-to-competitor   Lost-To-Competitor   Lost To Competitor   <- differ
+  ```
+  
+  A field KEY is authored in the codebase and carries a machine spelling, so
+  splitting camelCase recovers words its author meant. A stored VALUE is arbitrary
+  tenant data, where a mid-token capital is not reliably a word boundary and
+  splitting it rewrites what the tenant wrote (`McDonald` to `Mc Donald`). The two
+  conventions also do not nest — on the last row each leaves alone the separator
+  the other rewrites. Whether they should ever converge is a separate decision
+  that would move rendered output in four packages at once; it is deliberately not
+  made here.
+- 6c5ee71: `ObjectChart` now depends on the `fieldOptionLabel` resolver directly instead of
+  holding it behind a ref, so a chart re-resolves its groupBy option labels when
+  the resolver genuinely changes (objectui#5587).
+  
+  The ref existed for a reason that no longer holds. `useSafeFieldLabel()` returned
+  a fresh object on every render outside an i18next provider, so a direct
+  dependency made `fetchData`'s `useCallback` identity fresh on every render, and
+  the effect that depends on `fetchData` refetched on every render — an unbounded
+  loop. `ObjectChart` worked around that locally with `fieldOptionLabelRef` plus a
+  `useEffect` keeping it current. `useObjectLabel`'s memo now holds with or without
+  an i18next instance bound (objectui#5564), so the resolver's identity is stable
+  on both paths and the indirection buys nothing.
+  
+  It did cost something, and that is the user-visible half: a ref-hidden dependency
+  meant `fetchData` did NOT re-run when the resolver changed. A chart mounted
+  before its `I18nProvider`, or rendered across a language switch, kept serving
+  groupBy labels resolved by the old resolver until some unrelated dependency
+  (object name, filter, aggregate) happened to move. It now refetches once on that
+  transition and shows labels in the active language.
+  
+  Pinned by `ObjectChart.fieldOptionLabelRefetch.test.tsx`, which counts fetches
+  across forced re-renders both outside and inside a provider. Reverting
+  `useObjectLabel.ts` to its pre-objectui#5564 state turns the no-provider case red
+  (2 fetches instead of 1, alongside React's "Maximum update depth exceeded"), so
+  the removal is pinned to the fix that unlocked it rather than to a comment.
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [8d3a529]
+- Updated dependencies [194fae1]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [b362c1b]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [20e317c]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/plugin-charts/package.json b/packages/plugin-charts/package.json
index ef57547a34..f2ef1019e3 100644
--- a/packages/plugin-charts/package.json
+++ b/packages/plugin-charts/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-charts",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Chart components plugin for Object UI, powered by Recharts",
diff --git a/packages/plugin-chatbot/CHANGELOG.md b/packages/plugin-chatbot/CHANGELOG.md
index 525453d4d6..aefc892661 100644
--- a/packages/plugin-chatbot/CHANGELOG.md
+++ b/packages/plugin-chatbot/CHANGELOG.md
@@ -1,5 +1,251 @@
 # @object-ui/plugin-chatbot
 
+## 17.7.0
+
+### Minor Changes
+
+- 6ce89da: The 确认修改 (confirm changes) card now carries a UI-owned terminal state after approval (#5695): `detectReplayOutcome` lifts the confirm-replay envelope (`replay_*` tool results) into 应用中 / 已生效 / 已暂存为草稿（含内联发布）/ 未生效（含 publishError 首行）, rendered on the original card across the live, hydration/share, and localStorage-cache converters. A failed in-turn publish no longer rehydrates as an ordinary draft card with a live Publish button — the UI-rendered refusal is the layer a model cannot narrate over. New `console.ai.changesApplying/Applied/Drafted/Failed` keys in all ten locale packs.
+
+### Patch Changes
+
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- 79a4b8f: Recognize the landed AI quota ledger vocabulary in the chat error path
+  
+  `parseAiQuotaError` now accepts the three SCREAMING_SNAKE ledger codes the cloud
+  token guardrail emits (`AI_ALLOWANCE_EXHAUSTED`, `AI_DESIGN_QUOTA_EXHAUSTED`,
+  `AI_DATA_CHAT_TRIAL_EXHAUSTED`) alongside the legacy lowercase trio, which stays
+  readable for producers that have not converged yet. The companion fields
+  (`messageEn` / `upgrade` / `topUp` / `resetsTonight`) are now read from the
+  declared envelope's `error.details` as well as their legacy top-level position,
+  with the declared position winning.
+  
+  A quota-exhausted user gets the upgrade / top-up CTA again instead of the
+  generic "Response failed" banner. The per-turn message cap's generic
+  `QUOTA_EXCEEDED` deliberately keeps its existing rate-limit path — it has no
+  upgrade or top-up next step.
+- cc3366b: The built-moment transition (#5799) now fires on auto-publish environments too: `detectBuiltAppPackage` reads the raw build envelope (`status:'drafted'` OR `'published'`, packageId + an `app` item), because an auto-publish posture rewrites apply_blueprint's envelope to `published` and the drafted-only `draftReview` lift never fired there — measured live on staging, where reopening a built conversation stayed on the full page.
+- a31adc6: `useObjectChat` no longer rebuilds its `DefaultChatTransport` on every render
+  (objectui#4187).
+  
+  The transport `useMemo` listed the caller's `body` and `headers` in its dep list.
+  Both are object props and every caller passes a fresh literal each render — the AI
+  page's chat pane builds its `body.context` inline — so the memo never hit and a
+  transport was constructed on every render of every chat surface, which during a
+  streaming turn is once per token batch.
+  
+  `body` and `headers` are now read through refs inside
+  `prepareSendMessagesRequest`, the idiom this hook already uses for the live model
+  (`modelRef`) and the handoff conversation id (`parentConvRef`), and they are gone
+  from the dep list. Unlike memoizing at each call site, a future caller cannot
+  undo it.
+  
+  No user-visible behaviour changes: `@ai-sdk/react` keeps the transport in a ref
+  and re-keys its `Chat` only on `chat`/`id` (verified against the installed
+  4.0.68), which `useObjectChat` passes neither of, so the message thread was never
+  at risk — the rebuild was pure waste. The one real difference is *when* the two
+  values are sampled: a send now reads them at send time, so it observes the values
+  of the most recent render instead of those of the last render that happened to
+  rebuild the transport. That is never staler than before, and it is pinned by
+  `useObjectChat.transportIdentity.test.tsx`.
+- 0fce2ef: `maxToolRoundtrips` on `ChatbotSchema` is deprecated: it is inert, and an author
+  who sets it is now told so instead of being left believing the documented cap
+  applies (objectui#5605).
+  
+  The key was declared authorable in `@object-ui/types` (interface and zod, with a
+  description), threaded from the authored document through the chatbot renderer at
+  three call sites, accepted by `useObjectChat`, given a default — and then dropped.
+  Measuring the installed chat runtime says it cannot be honoured from here rather
+  than that someone forgot to wire it: `@ai-sdk/react`'s `useChat` takes `ChatInit`
+  plus throttle/resume, and `ChatInit` declares exactly one loop control — the
+  boolean predicate `sendAutomaticallyWhen` — and no numeric cap under any
+  spelling. The numeric knob was removed from `useChat` in a major, and its
+  successor was renamed through `continueUntil` to `stopWhen` / `stepCountIs`,
+  which the installed `ai` package declares only on `generateText`, `streamText`
+  and the tool-loop agent settings — all server-side. ObjectUI is backend-agnostic,
+  so it owns no server loop to cap either, and putting the number in the request
+  body would only move the same dead key one hop onto a wire contract no backend
+  reads.
+  
+  This is stage one of a two-stage retirement, so nothing an author already wrote
+  breaks: the key still parses, still carries its declared shape, and the renderer
+  still threads it. What changes is that it is now marked `@deprecated` in the
+  interface, the zod description and the docs, and that authoring it logs a
+  one-time notice naming the knob that does work — `planning.maxIterations` on the
+  agent. A follow-up removes the declaration once this deprecation has shipped in a
+  release.
+- ad404e0: Confirm-replay dispatch errors (bare `{error: …}` envelopes) now resolve the 确认修改 card instead of leaving it on 应用中 forever: `detectReplayOutcome` classifies them as a provisional failure, and a later successful authoring result in the same turn (the model self-repairing, e.g. after an `object not found` on a blueprint-local name) supersedes it via `detectAuthoringVerdict` — so the card never says 未生效 over a change that actually landed. Real publish failures (`publishFailed` envelopes) are never superseded. Measured live on the local rig, 2026-08-24.
+- eddc1dd: The Studio copilot tells the agent WHAT the user is discussing (cloud#1610 send half): `ChatPane` accepts a `surfaceContext` and sends it as `context.surface` on every turn (the transport reads the body per send, so it stays fresh); the Studio copilot derives it from the URL alone — the `:tab` pillar segment plus the `?surface=type:name` deep-link the pillars already mirror, so the artifact carries its type discriminator (page/object/dashboard/report). A display chip above the composer (「正在讨论：…」, new `console.ai.discussing` key in all ten packs) makes the sent context visible instead of invisible grounding.
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [8d3a529]
+- Updated dependencies [194fae1]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [b362c1b]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [20e317c]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Patch Changes
diff --git a/packages/plugin-chatbot/package.json b/packages/plugin-chatbot/package.json
index da3497e4c8..04fb3e77fe 100644
--- a/packages/plugin-chatbot/package.json
+++ b/packages/plugin-chatbot/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-chatbot",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Chatbot interface plugin for Object UI",
diff --git a/packages/plugin-dashboard/CHANGELOG.md b/packages/plugin-dashboard/CHANGELOG.md
index 0f5ae3c432..0e9b0dfa1a 100644
--- a/packages/plugin-dashboard/CHANGELOG.md
+++ b/packages/plugin-dashboard/CHANGELOG.md
@@ -1,5 +1,738 @@
 # @object-ui/plugin-dashboard
 
+## 17.7.0
+
+### Minor Changes
+
+- 2e471a6: `dashboard` now publishes the authoring inputs its renderer already honours — `widgets`, `label`, `description`, `header`, `globalFilters`, `dateRange`, `refreshInterval` — so `validateTree`, the generated `sdui.manifest.json` and `sdui-intrinsics.d.ts` stop warning authors off keys that work (previously only `columns`/`gap`/`className` were published, and every other honoured key drew `unknown-prop`). Each declared key is accepted by the spec's strict `DashboardSchema`, so the manifest never offers a key the save gate refuses. The legacy `title` spelling and the retired `aria` key stay deliberately unpublished and are pinned as such; the `schema.title || schema.label` fallback read is unchanged, so documents in the wild keep rendering their header title.
+- 1d9100e: Dashboard `table` widget — a numeric **measure** column now sorts **descending
+  on the first click** (objectui#5845).
+  
+  The sortable headers shipped in objectui#5827 started every column ascending,
+  which left the card's own motivating complaint — the largest industry rendering
+  last — two clicks away. For a measure in an analytics widget the question a
+  click asks is "who is biggest", so that column now cycles
+  **descending → ascending → the dataset's own order**.
+  
+  Unchanged: a **dimension** column, and a measure whose values are not numbers
+  (a `min()`/`max()` over a text field), keep **ascending → descending → the
+  dataset's own order** — the idiom the console's own DataTable uses. The
+  first-click direction is decided by the same measure-and-all-values-are-numbers
+  classification that decides right-alignment, so it follows the column's *role*
+  rather than "it looks like digits": a digit-keyed dimension (a year, a quarter)
+  still starts ascending.
+  
+  Blanks still sort **last in both directions** — that arm is now what a measure
+  column's very first click runs — and `aria-sort` reports the direction actually
+  applied.
+- 62c0fa1: Dashboard `table` widget (dataset-backed, flat grouped table) — four rendering
+  fixes so it reads as a table rather than a raw dump (objectui#5827):
+  
+  - **Numeric columns right-align**, header and cells. `tabular-nums` was already
+    applied to every cell and could not do its job while the digits were flushed
+    left. A column qualifies when it is a MEASURE and every non-null value in it
+    is a number — the declared column `type` cannot decide it, because the
+    analytics executor stamps `type: 'number'` on every measure regardless of the
+    aggregate, so a `min()`/`max()` over a text field would have been
+    right-aligned on the strength of a label. Dimensions stay left-aligned even
+    when their bucket keys are digits: a grouping axis is not a quantity.
+  - **Sortable headers.** Each header is a keyboard-reachable button that cycles
+    ascending → descending → back to the dataset's own order, with the console's
+    existing sort indicator and `aria-sort` on the `th`. Blanks sort last in
+    BOTH directions. The sort is client-side over the rows already fetched — the
+    widget issues one `queryDataset` call and paginates nothing, so no round trip
+    is involved.
+  - **The empty-dimension bucket sorts last** in the default order instead of
+    floating to the top. It keeps its `—` label; only its position moves.
+  - **Row hover feedback on every row**, not only on a drillable one. A drillable
+    row keeps its stronger accent fill.
+  
+  The CSV export now follows the order the table is showing, which is the same
+  "the CSV is the table's data" convention its cell text already followed.
+  Drill-through is unaffected: rows are reordered as `(row, incoming index)`
+  pairs, so a drill still resolves through the server's parallel raw-value
+  sidecar.
+  
+  Unchanged: the cross-tab (a `pivot` with ≥2 dimensions) renderer, the KPI and
+  chart paths, and every non-dataset table in the console.
+- e719ebd: `data-table` reads the declared `header`; the producers translate `label` into it.
+  
+  `TableColumn` declares `header: string` and does not declare `label`. The
+  renderer's column normalization nonetheless read `header: col.header || col.label`,
+  so the same key had one spelling the type admits and one only the runtime did.
+  That alias is gone (objectui#5351), and the translation it used to perform happens
+  once at each producer instead: metadata vocabulary in, adapter vocabulary out.
+  
+  **This narrows what `data-table` accepts, so read this if you author `data-table`
+  nodes by hand.** A column spelled `{ label: 'Stage', accessorKey: 'stage' }` on a
+  directly authored `data-table` now renders a **headerless** column over live
+  cells. Spell it `header` — the key `TableColumn` has always declared. Columns
+  reaching `data-table` through `object-data-table`, `object-grid` or a related
+  list are unaffected: those producers resolve `header` for you from the spec's
+  `ListColumnSchema.label`, so every spelling they accepted before they still
+  accept.
+  
+  `@object-ui/core` gains `columnHeader()` alongside `columnIdentity()` — the reader
+  producers use to cross that boundary. It is adapter-first (`header` wins over
+  `label`), so an author who addressed the table directly is never overwritten.
+  
+  `object-data-table` also gains a fix from the same move: a column carrying a
+  `label` used to render a **blank** header there even while the alias existed,
+  because the widget's field-meta enrichment overwrote the authored `label` before
+  the adapter ever saw it. `{ field: 'stage', label: 'Stage' }` now renders "Stage".
+  
+  The sibling `accessorKey: col.accessorKey || col.name` alias is **unchanged** here
+  and still resolves. Retiring it is objectui#5120's remaining step, which is
+  gated on two published skill guides that teach that spelling.
+- 9e725e0: Dashboard flat `table` widget: render the server's grand total as a `tfoot` row (objectui#5846).
+  
+  The flat branch now requests the `[]` marginal grouping — the same server-side
+  totals machinery the cross-tab has used since framework#1753 — and renders the
+  answer under the console's existing `dashboard.total` label. Totals are computed
+  by the server with each measure's TRUE aggregate (a `sum` sums, an `avg`/`min`/
+  `max` reports the whole-set aggregate); nothing is recombined client-side. The
+  row lives in `tfoot`, so it is exempt from sorting, renders below the `—` null
+  bucket, and never joins the drillable rows.
+  
+  No footer is rendered when the executor answers no `[]` grouping, and none is
+  requested for a table truncated by `options.limit`, whose visible rows a
+  whole-set total could not be reconciled against.
+
+### Patch Changes
+
+- baac3f4: Fix four `find()` calls that passed a query option without its `$`, and gate the shape.
+  
+  `QueryParams` declares every query option `$`-prefixed and `convertQueryParams` copies
+  exactly those keys, so an unprefixed spelling reaches no branch and is dropped — no throw,
+  no warning, and it type-checks because the type carries `[key: string]: any` for
+  adapter-specific params. For a dropped cap the result is an **unbounded** read rather than
+  a truncated one: the platform's GET list route has no default page size, so the query
+  returns the whole match set and stays invisible until the object is large.
+  
+  - `app-shell` `ObjectView` fetched the footer's record count with `{ limit: 0 }`. This one
+    **inverted** rather than widened — `$top: 0` is honoured end to end as "no records", so
+    the dropped key turned "count only, fetch nothing" into "fetch every row in the object",
+    on every mount and every refresh of every list view. It now sends `$top: 0` and reads
+    the count off `total` only; the row-counting fallbacks are gone rather than repointed,
+    because once zero rows are requested an empty `data` means "you asked for none", not
+    "the object is empty", and counting it would assert a confident `0`. With no total the
+    footer line is omitted instead.
+  - `app-shell` `AssignedUsersSection` looked a permission set up with `{ …, limit: 1 }`,
+    one line from three correct `$top` calls.
+  - `plugin-dashboard` `DashboardFilterBar` passed `fields` **and** `top` in one literal, so
+    a filter's option list read every row and every column of its source object while its
+    own comment described it as capped at 200. The same call read `records.items`, which is
+    not a `QueryResult` member, so against a real adapter the fallback produced no options
+    at all.
+  - `console` `sdui-workbench-preview` passed `{ top: 200 }` and read `.records` off the
+    result in its page-source metadata.
+  
+  A new `object-ui/no-unprefixed-query-params` ESLint rule rejects the shape at write time:
+  a known query-option name missing its `$` in the second argument of a `find`/`findOne`
+  call. It is narrow on purpose — a closed list of spellings, anchored to the call — because
+  the index signature exists so adapters can take adapter-specific params, and a rule that
+  flagged any unprefixed key would report the shape the type was written to allow. Its
+  sibling `no-query-params-under-options` (the `{ options: { $top } }` half) is unchanged.
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- fc62bb4: `TableColumn.type` now has ONE canonical value set across all three ends that disagreed
+  (objectui#5853, maintainer ruling 2026-08-25, Option B: the 8-literal interface union is
+  canonical). The interface declared `'text' | 'number' | 'date' | 'datetime' | 'currency' |
+  'percent' | 'boolean' | 'action'`; the zod mirror declared `z.string()` and accepted
+  anything; the renderer branched on a third set and could only read the key through an
+  `as any` cast.
+  
+  ## ⚠️ Accept-set narrowing — these spellings stop validating
+  
+  `TableColumnSchema.type` was `z.string().optional()`. **Any string parsed green.** It is now
+  `z.enum(TABLE_COLUMN_TYPES).optional()`, so a value outside the eight is refused at parse
+  time with `type` named in the error path. Spellings that validated before and are **refused
+  now**, grouped by why they were being written:
+  
+  - **Typos and invented names** — `'money'`, `'datetime2'`, `'string'`, `'int'`, `'integer'`,
+    `'float'`, `'double'`, `'datetime-local'`, and every other free-form string. `'money'` is
+    the card's headline case: it validated, matched no renderer branch, and the column fell
+    through to plain text rendering with nothing reported. That silent fall-through is the
+    lenient-validation face that lets AI-authored metadata errors through, and it is now a
+    loud parse failure.
+  - **Object-schema field types written into a column slot** — `'select'`, `'lookup'`,
+    `'user'`, `'file'`, `'formula'`, `'textarea'`, `'email'` and the other 35 members of
+    `@objectstack/spec`'s `FieldType` that are not among the eight. These belong on the FIELD,
+    not on the column: a column gets its dedicated widget from the field definition behind its
+    `accessorKey`, never from `type`.
+  
+  **Authored metadata in this repo needs no migration.** Measured before tightening, across
+  `examples/`, `content/`, `apps/`, `e2e/`, `docs/` and every package (591 JSON schema files
+  plus the docs and playground sources): **zero** authored `TableColumn.type` values outside
+  the eight, and zero occurrences of `int` / `integer` / `float` / `double` in a column
+  position anywhere in the repository. If you author `type` on a table column, check it
+  against the eight; if the value describes the FIELD rather than the column, remove it.
+  
+  ## The renderer's undeclared vocabulary disappears instead of being declared
+  
+  `int` / `integer` / `float` / `double` were members of the data-table's `NUMERIC_EDIT_TYPES`
+  and `datetime-local` had its own editor branch, none of them declared. They arrived because
+  column-inference producers forwarded an object schema's field type **verbatim** into
+  `TableColumn.type`. Rather than publishing that dialect, producers now fold their inferred
+  value onto the declared vocabulary at their emit seam via the new
+  `normalizeTableColumnType()`: `int`/`integer`/`float`/`double` → `number`,
+  `datetime-local` → `datetime`, and **anything else drops the `type` annotation — never the
+  column**. Two producers do this, not the one the card named: `ObjectGrid` (`@object-ui/plugin-grid`)
+  and `ObjectDataTable` (`@object-ui/plugin-dashboard`), whose `buildFieldMeta` spread wrote
+  the raw field type into the same slot.
+  
+  Dropping the annotation is behaviour-preserving at the only consumer that reads the key.
+  `data-table`'s inline editor branches on `date`, `datetime` and the numeric set and
+  otherwise falls through to a text input — which is exactly the `undefined` path. The
+  dedicated widget a `select` or `lookup` column gets comes from the host's `renderCellEditor`,
+  which resolves the field through `column.accessorKey` and never reads `type`.
+  
+  ## New public API
+  
+  `@object-ui/types` exports `TABLE_COLUMN_TYPES` (the canonical tuple — the single
+  declaration the zod mirror builds its enum from, so the two cannot drift), the
+  `TableColumnType` union, and `normalizeTableColumnType()` for producers. The `as any` cast
+  in `data-table.tsx` is deleted and the read is typed, so re-introducing an undeclared
+  spelling is a tsc error rather than a silent widening.
+  
+  A value-level parity pin covers all three ends
+  (`packages/types/src/__tests__/table-column-type-canonical.test.ts` and
+  `packages/components/src/renderers/complex/__tests__/table-column-type-read-set.test.tsx`).
+  objectui#5684's guard is key-set only and cannot see value drift — `type` was present on
+  both sides the whole time — which is how this instance survived while its siblings were
+  caught. A future inference value turning that pin red is by design; the note at the pin says
+  so, and names the two correct repairs.
+- a100f77: The dashboard package now holds ONE relation predicate instead of two that
+  agreed only because a sweep had just aligned them (objectui#5876).
+  
+  `computeLookupExpand` in `ObjectDataTable.tsx` carried its own `isLookup`,
+  byte-identical to the exported `isLookupType` in `recordFields.tsx` after
+  objectui#5692 pointed both at `@object-ui/core`'s `EXPANDABLE_FIELD_TYPES`.
+  Nothing kept them aligned: a future edit to either — a member added, the
+  retirement gate moved — would have re-forked the `$expand` decision from the
+  predicate whose docblock claims to drive it. `computeLookupExpand` now calls
+  `isLookupType`, which gains its first production consumer, and the module no
+  longer imports the shared family or the retirement gate at all.
+  
+  **No behaviour changes**, and that is measured rather than assumed:
+  
+  - The two bodies were identical, so every boolean answer — `tree` is expanded,
+    `reference` is not, ordinary relations are — is the same before and after.
+  - The retired-spelling warning is not emitted a different number of times.
+    `reportRetiredFieldType` dedupes per SPELLING in one module-level set inside
+    `@object-ui/core`, which both bodies already shared, so routing two callers
+    through one function cannot change the count.
+  
+  Nothing published moves: `isLookupType` is not re-exported from
+  `@object-ui/plugin-dashboard`'s entry, so this is internal shape only.
+  
+  Because a refactor with no observable delta cannot be pinned by a behavioural
+  test — a byte-identical local copy satisfies every assertion you can write
+  about `$expand` — the pin is identity, in
+  `__tests__/expandableFamily.identity-5692.test.ts`: `computeLookupExpand` is
+  observed CALLING `isLookupType`, and `ObjectDataTable.tsx` is read at source
+  level to confirm no second body survives for it to call instead.
+- 129c7a9: `ObjectDataTable` no longer writes six undeclared keys into the `data-table` columns slot
+  (objectui#6373). `enrich()` returned `NormalizedColumn`, whose `[key: string]: any` accepts
+  anything, so nothing checked the producer's output against
+  `DataTableSchema.columns: TableColumn[]`: `{ ...col, ...fieldMeta }` spread `label`,
+  `options`, `referenceTo`, `format`, `currency` and `decimals` onto every emitted column, and
+  `TableColumn` declares none of them.
+  
+  The measured read set of the consumer (`data-table.tsx`, comments stripped) contains none of
+  the six, so all six retire from the emit rather than being declared — declaring a key nothing
+  reads is the same `declared != enforced` defect facing the other way. Rendering is unchanged
+  because none of those keys was the live path for its own value: the `FieldMeta` the `cell`
+  closure captures is what this widget's type-aware rendering has always read, and it is
+  untouched. Authored spellings still pass through, so a column the author wrote as
+  `{ format: '$0,0' }` keeps its `format` exactly as before.
+  
+  `type` is unchanged — objectui#5853's fold at this seam still applies. `name` is unchanged
+  and still written: `data-table` reads `col.accessorKey || col.name` and objectui#5120 holds
+  that alias while two published skill guides still teach a `{ name, label }` column. The hold
+  is now declared at the seam instead of arriving anonymously inside a spread.
+  
+  The seam's emit type carries ADR-0049 `?: never` tombstones for the retired keys rather than
+  being a bare `TableColumn` annotation. Measured before the shape was chosen: a bare annotation
+  raises no error at all here, because TypeScript's excess-property check exempts properties
+  that arrive through a spread — it would have type-checked the boundary without enforcing it.
+- 3d79455: `plugin-dashboard`'s two private copies of the reference-bearing field family now
+  read `@object-ui/core`'s published `EXPANDABLE_FIELD_TYPES` instead of restating
+  it — `LOOKUP_TYPES` in `recordFields.tsx` and the inline disjunction inside
+  `computeLookupExpand` in `ObjectDataTable.tsx`. Both carry the identity pin the
+  already-converged consumers carry, so a member-identical private copy fails
+  rather than quietly re-forking the table.
+  
+  Two behaviour changes on the dashboard table's `$expand`, in opposite directions:
+  
+  - **A `tree` column is now expanded.** A self-referencing hierarchy field is
+    reference-bearing and a member of the shared family, so its cell renders the
+    parent record's display name instead of a bare id — the same treatment the form
+    and grid roads already gave it.
+  - **A `reference`-typed column is no longer expanded.** Measured before removing
+    it: `reference` is absent from `@objectstack/spec`'s closed `FieldType`
+    vocabulary and is refused by `FieldSchema.safeParse`, so no spec-compliant
+    object schema can declare a field whose stored type is `reference`. Dropping it
+    is a no-op on real data; the spelling is a legacy dialect alias on the
+    action-param surface, folded to `lookup` before any field-type data is read.
+  
+  `EXPANDABLE_FIELD_TYPES` itself is unchanged — the measurement did not license
+  widening a published shared set.
+- cc5de5c: `DashboardRenderer` no longer emits an empty dashboard header wrapper. The
+  wrapper used to render whenever `header` was declared, while each of its
+  children — title, description, actions — was additionally suppressible. With
+  the console page chrome present (`hideHeaderText`, set because the chrome
+  already renders the dashboard's title and description) and no `header.actions`,
+  every child evaluated falsy and the DOM still received
+  `<div class="col-span-full mb-4"></div>`: zero children, yet a full grid row
+  (measured 64px) plus `mb-4` of dead band above the filter bar, on every console
+  dashboard page (objectui#5812, measured on HotCRM 17.1.0).
+  
+  The three children are now computed first and the wrapper renders only if one
+  of them survives. Nothing else changes: a standalone embed (no chrome) renders
+  title and description exactly as before, and declared `header.actions` keep the
+  wrapper alive even under the chrome, since the chrome renders text only. Authors
+  needed this — dropping `header` from the metadata to reclaim the pixels would
+  have cost the standalone embed its title, which is what `header` is for.
+- 84d2e98: `DashboardRenderer` drops the unreachable `DatasetWidget` fork from its self-contained
+  (card-less) branch, leaving that branch to render `SchemaRenderer` unconditionally
+  (objectui#4620).
+  
+  `isSelfContained` is defined as `widget.type === 'metric' && !datasetBound`, and the
+  `isSelfContained` arm of `renderedNode` then forked on `datasetBound` a second time. The
+  `datasetBound` side of that inner fork could never execute: reaching it required
+  `isSelfContained` to be true, which requires `!datasetBound`. Behaviour is unchanged —
+  the removed arm never ran, and the reachable fork in the Card branch (the one that gives
+  a dataset-bound metric its title and border chrome) is untouched.
+  
+  The cost was to readers, not to users: the shape read as "both branches handle
+  dataset-bound widgets" when only one can, and a previous PR mirroring this fork onto
+  `DashboardGridLayout` had to pay for the reachability argument before it could decline to
+  copy the dead limb. A comment now names the invariant in place so the arm is not re-added.
+- f24195a: `ObjectDataTable` and `ObjectPivotTable` now use a module-scope frozen empty for
+  "no rows yet" instead of a fresh array literal per render (objectui#4629).
+  
+  Both spelled the resolved row list as `Array.isArray(rawData) ? rawData : []`, so
+  whenever `rawData` was a truthy non-array — a provider-config `data`, or a `bind`
+  path that resolves to an object — the fallback produced a NEW array identity on
+  every render. In `ObjectDataTable` that value keys the `derivedColumns` memo, so
+  every column was re-derived (`buildFieldMeta`, a fresh `cell` closure, the
+  `isSystemField` pass, the `fieldLabel` lookups) and then discarded by the
+  `finalData.length === 0` early return. In `ObjectPivotTable` the value is handed
+  straight to `PivotTable`, where it keys the cross-tabulation memo, so the pivot
+  rebuilt its row/column sets, bucket map and totals on every render over no rows
+  at all.
+  
+  Nothing rendered wrong before or after; this is wasted work in the empty window,
+  plus the live `react-hooks/exhaustive-deps` warning the conditional raised. It is
+  the same module-scope frozen empty `data-table.tsx` adopted for its own
+  `EMPTY_ROWS` (objectui#4618), applied to the `provider: 'object'` siblings.
+- 56f4e34: A dashboard table's auto-derived column headers spell a field key the same way every other path in the `table` widget family does.
+  
+  `ObjectDataTable` derives headers on two paths — from the author's declared
+  `columns`, and from the object schema when no columns were declared. The
+  declared path (and the static `data-table` half of the same widget family)
+  already used `humanizeFieldKey`, whose docstring names it "the single home for
+  the convention, because both halves of the `table` widget family need it and
+  they must agree". The auto-derived path carried a third, inline spelling that
+  split camelCase but never turned `_` into a space, so it left a raw underscore
+  on screen. Measured over the same object's columns:
+  
+  ```
+  path                                     close_date    needs_analysis
+  object-bound, AUTO-DERIVED   (before)    Close_date    Needs_analysis
+  object-bound, AUTO-DERIVED   (after)     Close Date    Needs Analysis
+  object-bound, DECLARED columns           Close Date    Needs Analysis
+  static `data-table`, no columns          Close Date    Needs Analysis
+  ```
+  
+  One dashboard can hold all three widgets over one object, so a single field key
+  rendered under two spellings — the defect class objectui#5425 rules out. The odd
+  path adopts the shared convention rather than the convention gaining a fourth
+  dialect. camelCase keys are unaffected (`unitPrice` read `Unit Price` before and
+  after — the coincidence that kept the snake_case divergence unnoticed), and a
+  translated header still wins: only the fallback handed to `fieldLabel` changed.
+  
+  Dimension MEMBER labels are untouched by this. The same card reported dashboard
+  members rendering a prettified enum instead of the picklist's translated label,
+  measured on 17.1.0; re-measured on this branch it no longer reproduces — the
+  analytics label net shipped in 17.5.0 routes every non-metric dataset dimension
+  through the field's declared options and the locale bundle. That behaviour had
+  no test stated in the card's terms and now has one, over the four dashboards the
+  card measured, including the property that a bar axis and a pivot header cannot
+  disagree about one stored value.
+- 84d70bb: `ObjectPivotTable` now depends on the `fieldLabel` / `fieldOptionLabel`
+  resolvers directly instead of holding them behind refs, so a pivot re-derives
+  its header and option labels when the resolver genuinely changes
+  (objectui#5625).
+  
+  The refs existed for a reason that no longer holds. `useSafeFieldLabel()`
+  returned a fresh object on every render outside an i18next provider, so a direct
+  dependency would have re-run the metadata-derivation effect on every render —
+  and that effect ends in `setFieldLabelMaps` / `setFieldNameLabels` with freshly
+  built objects, so each run scheduled the next one: an unbounded derive loop.
+  `ObjectPivotTable` worked around that locally with `fieldLabelRef` /
+  `fieldOptionLabelRef` plus a `useEffect` keeping them current.
+  `useObjectLabel`'s memo now holds with or without an i18next instance bound
+  (objectui#5564), so both resolvers have a stable identity on both paths and the
+  indirection buys nothing.
+  
+  It did cost something, and that is the user-visible half: a ref-hidden
+  dependency meant the derivation did NOT re-run when the resolver changed. A
+  pivot mounted before its `I18nProvider`, or rendered across a language switch,
+  kept showing its top-left header label and its select-option cell labels as
+  resolved by the old resolver — until some unrelated dependency (the data source,
+  the object name) happened to move. It now re-derives once on that transition and
+  renders in the active language.
+  
+  This is the same removal objectui#5587 made in `ObjectChart`, one package over.
+  
+  Pinned by `ObjectPivotTable.i18nResolverDeps.test.tsx`, which counts derivations
+  across forced re-renders both outside and inside a provider, checks that the two
+  derived state maps settle, and asserts the language-switch re-derivation.
+  Reverting `useObjectLabel.ts` to its pre-objectui#5585 state turns the
+  no-provider case red (derivations in the dozens instead of 1), so the removal is
+  pinned to the fix that unlocked it rather than to a comment.
+- f1c27f0: Dashboard record fields: percent columns now render through the one percent
+  scaling decision instead of a second, drifted copy of it.
+  
+  `renderFieldValue`'s `%`-format branch normalised the value itself before
+  calling `formatPercent` (`const normalized = value > 1 ? value / 100 : value`,
+  then `normalized * 100`). `formatPercent` already applies `percentDisplayValue`,
+  which `@object-ui/core` documents as the single source of truth for percent
+  display scaling, so the branch was re-deciding what core owns — and its copy had
+  drifted from it in three measured ways:
+  
+  - `(value / 100) * 100` is not value-preserving in binary floating point,
+    re-introducing one call frame upstream the round trip that was removed from
+    inside `formatPercent`. On the 0.001-step grid to 200, 19,978 of 199,000
+    values change bit pattern and 1,108 rendered strings move, every one a
+    last-digit off-by-one: a stored `1.605` rendered `1.60%` where half-up is
+    `1.61%`.
+  - A stored fraction below `0.01` was scaled twice — the local `* 100` put it
+    back under 1, so core's fraction arm scaled it again. `0.005` (0.5%) rendered
+    `50.00%`.
+  - The local test was `value > 1` rather than core's symmetric `|value| < 1`, so
+    a negative already in percentage points took the fraction arm: `-5` rendered
+    `-500.00%`.
+  
+  The branch now hands the raw stored value to `formatPercent` — the identical
+  call the list-view percent cell already makes for an ordinary percent column —
+  so a percent reads the same as a record field, as a grid cell and as a dashboard
+  measure. Output moves where it was wrong: values at or above 1 whose round trip
+  lost a digit, fractions below `0.01`, negatives at or below `-1`, and exactly
+  `1`, which is one percentage point by core's convention and now renders
+  `1.00%` at two decimals, where the local `value > 1` test had made it
+  `100.00%`.
+- 0ccbdc1: `PivotTable` no longer re-runs its cross-tabulation memo on every render when it
+  has no rows (objectui#5562).
+  
+  The component spelled the empty array twice — as the destructuring default for
+  `schema.data` and as the `Array.isArray` fallback that keeps a provider-config
+  object out of iteration — so a schema declaring no `data` key, or one whose
+  `data` is a provider config rather than rows, produced a fresh array identity on
+  every render. That value is the first entry of the memo's dependency list, so
+  the memo rebuilt its two ordered key sets, its `bucket[row][col]` map, the
+  aggregated matrix and the row/column/grand totals on every render, over nothing.
+  Both spellings now resolve to one module-scope frozen empty, so "no rows" is a
+  stable value and the memo holds.
+  
+  Wasted work only: the churn feeds a memo rather than a `setState`, and
+  `PivotTable` holds no prop-to-state sync, so nothing rendered wrong and no
+  render loop was possible. The identical fix landed for `data-table` in
+  objectui#4618 and for `ObjectPivotTable` in objectui#4629; this closes the
+  direct-use path those two did not cover, where `DashboardRenderer` and
+  `DashboardGridLayout` construct pivot schemas without `ObjectPivotTable` in the
+  chain.
+- 6c6cee7: A RETIRED field-type spelling is now refused — out loud, once — by every
+  field-type predicate in the renderer, not just by the widget road
+  (objectui#4914, maintainer ruling B of 2026-08-18).
+  
+  `@object-ui/fields` exports a single `isRetiredFieldType(t)` gate, and it runs
+  ahead of six predicate faces that previously granted a retired spelling
+  first-class treatment: the filter builder's operator buckets and its value
+  control (`@object-ui/components`), the detail page's highlight-strip picker
+  (`@object-ui/plugin-detail`), `normalizeFieldType` (`@object-ui/plugin-view`),
+  the dashboard's `$expand` whitelist and `isLookupType`
+  (`@object-ui/plugin-dashboard`), and the list toolbar's lookup-like filter
+  control (`@object-ui/plugin-list`). Each one now fires the migration
+  prescription on the console — once per spelling across all of them, never once
+  per predicate — and then answers as it would for a spelling it does not
+  recognise.
+  
+  This closes the whole CLASS rather than one word: the gate is quantified over
+  `RETIRED_FIELD_TYPES`, so the next retirement covers all seven consumers on the
+  day it lands. It is the shape objectui#4932 and objectui#4942 already
+  established for the form and inline-edit roads.
+  
+  Measured before the change, and the reason the fix is a gate rather than a
+  deletion: `owner` was not dead in these faces. `operatorsForFieldType('owner')`
+  equalled the `user` bucket item for item, `computeLookupExpand` actively
+  requested `$expand` for it, `isLookupType('owner')` was `true` alongside
+  `reference`, and `normalizeFieldType('owner')` answered `'select'` exactly as
+  `picklist` does. Deleting the members alone would have traded a visible
+  contradiction for a SILENT degradation — a filter picker collapsing to a bare id
+  box, `$expand` quietly stopping so cells show raw foreign-key ids — which is
+  verbatim the failure mode `RETIRED_FIELD_TYPES`' own docblock exists to prevent.
+  The gate keeps that fallback and adds the half that was missing: the author is
+  told.
+  
+  The boundary question is answered on record: `owner` arriving through a
+  backend-vocabulary normalizer is an authoring error to refuse loudly, not
+  legitimate foreign input to tolerate. The open backend vocabulary those
+  normalizers exist for is untouched — `reference`, `picklist`, `money`, `int`,
+  `datetime_tz` and the rest are equally absent from the spec's closed `FieldType`
+  and are equally unretired, so they classify exactly as before.
+  
+  `RETIRED_FIELD_TYPES`, `reportRetiredFieldType` and `resetRetiredFieldTypeReports`
+  move to `@object-ui/core` and are re-exported from `@object-ui/fields`, so that
+  package's published surface is unchanged apart from the newly ruled gate.
+  `@object-ui/components` is a consumer of the gate and `@object-ui/fields`
+  depends on it, so a single shared table could not live in `fields` — and a
+  second copy would have meant a second dedupe set and two console lines for one
+  spelling. No package gained a new dependency.
+  
+  A retired spelling never loses a stored value: `retypeFilterValue` is
+  deliberately not gated, and the refused filter row stays operable rather than
+  drawing a blank operator trigger.
+- cfcff30: Each package's README now states, up front, that it needs a bundler: importing it from plain Node ESM fails, and that is a supported-configuration boundary rather than a defect.
+  
+  `@object-ui/plugin-dashboard` imports `react-grid-layout/css/styles.css` at module
+  scope and `@object-ui/plugin-map` imports `maplibre-gl/dist/maplibre-gl.css`;
+  `@object-ui/app-shell` reaches the first of those through the static
+  `@object-ui/plugin-dashboard` imports in `DashboardView` and `ReportView`. Node has
+  no loader for `.css` at all, so all three resolve and then die during evaluation:
+  
+  ```
+  TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".css"
+    for .../react-grid-layout/css/styles.css
+  ```
+  
+  Nothing about how these packages load has changed — every supported host bundles
+  them (Vite, webpack, or Next with the package in `transpilePackages`), and that is
+  still the only supported way to consume them. What changed is that the boundary is
+  now written where a consumer meets it, instead of being learned from a red import.
+  
+  objectui#5384 ruled unbundled Node consumption **unsupported** for style-carrying
+  plugin packages — permanently, over the three packages as a group — rather than
+  moving the stylesheet imports out of module scope. No unbundled-Node consumer
+  exists, and buying permanent machinery to close a capability gap nobody is pulling
+  on was the trade the ruling declined. A real consumer request reopens it as a
+  design question, not as a defect: the READMEs say so and name the issue.
+- fb96ecb: `WidgetConfigPanel` reads an inline-locale-map title, and a save no longer destroys the other locales.
+  
+  The dashboard widget config panel carried a private `resolveLabel` documented as
+  resolving an `I18nLabel` while reading `defaultValue || key` — the key-reference
+  form `@objectstack/spec` retired at 17.0.0-rc.6 (objectstack#5055). The inline
+  per-locale map `I18nLabelSchema` actually admits has neither limb, so
+  `{ en: 'Revenue', zh: '收入' }` resolved to `''`. It was the fourth private copy
+  of that resolver; objectui#4032 swept the other three out of `DashboardRenderer`,
+  `MetricWidget` and `MetricCard`.
+  
+  This was not a display bug. The resolved value seeds the panel's editable draft,
+  so a widget whose stored title was a map opened with an **empty** Title field and
+  the next save wrote `''` over the author's map — on the ordinary path, not an
+  exotic one: open the widget, change anything, save.
+  
+  Both halves are fixed, per the maintainer's 2026-08-20 ruling on objectui#5301:
+  
+  - **Reading** goes through `pickLocalized(value, language)`, so the panel shows
+    the active locale like every sibling surface post-objectui#4032.
+  - **Writing** replaces only the active locale's entry and carries every other
+    locale across. A title the author never touched round-trips the stored object
+    itself through an unrelated config edit; an edited one merges into the entry
+    that was displayed. The live-update callback (`onFieldChange`) forwards the
+    merged map for the same reason — hosts feed it back into the widget the panel
+    re-opens from, so a bare string there dropped the map before a save ever ran.
+  
+  `@object-ui/i18n` gains `setLocalized(value, language, next)`, the write-side
+  inverse of `pickLocalized`, so the rule is stated once instead of re-derived per
+  panel. It follows `pickLocalized`'s first three limbs — exact tag, base language,
+  region-qualified sibling — and deliberately stops there: the `default` / `en` /
+  first-value limbs are display fallbacks that hand back *another* locale's string,
+  and writing to one would let an author editing in `fr` overwrite English. With no
+  entry for the active locale the edit adds one. The pairing
+  `pickLocalized(setLocalized(map, lang, s), lang) === s` is pinned, because a
+  write that lands where the read does not look is how a "saved" string disappears.
+  
+  A full multi-locale editing UI remains out of scope (objectui#4163).
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [8d3a529]
+- Updated dependencies [194fae1]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [b362c1b]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [9a1fb41]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [a865c73]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [e4e9557]
+- Updated dependencies [7a28e1e]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [20e317c]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [4bb940b]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [f1690d4]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/fields@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/plugin-dashboard/package.json b/packages/plugin-dashboard/package.json
index d3ec891f06..3b377845fe 100644
--- a/packages/plugin-dashboard/package.json
+++ b/packages/plugin-dashboard/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-dashboard",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Dashboard plugin for Object UI",
diff --git a/packages/plugin-designer/CHANGELOG.md b/packages/plugin-designer/CHANGELOG.md
index 38c0b0feef..c3e18fc6b0 100644
--- a/packages/plugin-designer/CHANGELOG.md
+++ b/packages/plugin-designer/CHANGELOG.md
@@ -1,5 +1,532 @@
 # @object-ui/plugin-designer
 
+## 17.7.0
+
+### Minor Changes
+
+- 864154e: The Field Designer no longer offers a formula-expression textarea, and no designer write
+  path emits a `formula` key (objectui#6043).
+  
+  **This is a behaviour change on an authoring surface: a control is removed.** A field's
+  `type` may still be set to `formula` — that is a valid spec `FieldType` and stays in the
+  palette — but the expression itself is no longer authored here. Authors write formula
+  expressions in metadata-admin's field inspector, where they are checked.
+  
+  The control wrote `formula`, which is not in `FieldSchema`'s accept set. Measured against
+  the installed `@objectstack/spec` 17.2.0:
+  
+  ```
+  FieldSchema.safeParse({ type:'formula', label:'Tax', formula:'price * quantity' })
+    => success = false
+    => unrecognized_keys ['formula']   "Did you mean `formula` -> `expression`?"
+  ```
+  
+  so `PUT /api/v1/meta/object/:name` returned a hard 422 `INVALID_METADATA` — and because
+  the key was then stored, it blocked **every later save of that object**, not just the one
+  that introduced it.
+  
+  **The key was deliberately NOT renamed to the spec's `expression`.** `FieldSchema` judges
+  the key name and never the expression LANGUAGE — measured, it accepts
+  `expression: 'price * quantity'` and even `expression: '!!!not cel at all!!!'`; only the
+  empty string is refused. Spec `expression` is CEL rooted at `record`
+  (`record.amount * 0.1`), whereas this control's own placeholder taught `price * quantity`
+  — bare field refs, which under the scope formulas bind evaluate to null silently. A rename
+  would therefore have converted a loud, immediate 422 into a formula that saves clean and
+  then quietly computes nothing, which is strictly worse than the bug it appears to fix.
+  
+  Making refusals loud *in the control* would need CEL lint, autocomplete and `returnType`
+  inference — that is `CelPredicateField`, which lives in `@object-ui/app-shell`, and
+  app-shell depends on `@object-ui/plugin-designer`, so it cannot be imported back without a
+  dependency cycle. Growing a second formula-authoring surface inside plugin-designer is a
+  feature, not this fix. `returnType` is likewise not authored here: it is only derivable by
+  inferring the CEL result type, and with no expression control there is nothing to infer
+  from.
+  
+  `formula` joins the retired-key tombstone in `MetadataFieldsPage`, so an object already
+  carrying the key is stripped clean on its next save instead of staying blocked forever —
+  which matters more than usual here, because with the control gone an author would
+  otherwise have no way left to clear it. It is dropped rather than migrated to `expression`,
+  for the same reason the rename was refused. A `expression` authored in metadata-admin is
+  **not** touched: it is a real `FieldSchema` key and rides through the designer's
+  round-trip untouched.
+  
+  Also removes the now-unreachable `formula` read/write from
+  `views/metadata-admin/previews/object-fields-bridge.ts`, which was a third emit site for
+  the key that neither the card nor the parity gate named.
+  
+  The `formula` entry is removed from `check-designer-field-key-parity.mjs`'s
+  `KNOWN_UNPARSEABLE_KEYS` ledger, which ratchets in both directions — a resolved key that
+  left a stale entry behind would be as red as a new offender.
+- d18a0d3: Object-level metadata payloads no longer emit the three keys `ObjectSchema` refuses by
+  name — **group**, **sortOrder** and **relationships** (objectui#6223).
+  
+  Measured against the installed `@objectstack/spec` 17.2.0, whose `ObjectSchema` accept set
+  is 42 keys:
+  
+  ```
+  const base = { name: 'account', label: 'Account', fields: { n: { type: 'text', label: 'N' } } };
+  
+  ObjectSchema.safeParse(base)                              => success = true    (control)
+  ObjectSchema.safeParse({ ...base, isSystem: true })       => success = true    (control)
+  ObjectSchema.safeParse({ ...base, pluralLabel: 'A' })     => success = true    (control)
+  
+  ObjectSchema.safeParse({ ...base, group: 'Sales' })       => unrecognized_keys ["group"]
+  ObjectSchema.safeParse({ ...base, sortOrder: 3 })         => unrecognized_keys ["sortOrder"]
+  ObjectSchema.safeParse({ ...base, relationships: [ … ] }) => unrecognized_keys ["relationships"]
+  ```
+  
+  The two controls are what make that a key-by-key result rather than a schema refusing
+  everything. Each key was resolved on its own, as the objectui#5761 family ruling requires:
+  
+  - **group** — the Object Manager's grouping is a UI-only display category. The spec has no
+    object-level grouping key (`fieldGroups` groups the fields *inside* one object), so the
+    grouping control and its column stay, and the value is now DERIVED from the spec key that
+    is accepted (`isSystem`) instead of round-tripped. `MetadataObjectsPage` also strips a
+    `group` already stored by an earlier build, because its save-back spreads the server
+    document verbatim and would otherwise keep re-sending it forever.
+  - **sortOrder** — what populated it was the array index the converter happened to be at,
+    i.e. the order the list was already in. The declaration is removed from the object
+    payload. The field-level `sortOrder` is a different key with a different card
+    (objectui#6045) and is untouched.
+  - **relationships** — the spec models relationships on the FIELD (`reference` /
+    `master_detail`, plus object-level `indexes`). The object payload stops declaring and
+    sending an object-level relationship array; what the designer should author for a
+    relationship is a data-model question this change does not settle.
+  
+  **Breaking for TypeScript consumers of `ObjectMetadataPayload`** (exported from app-shell):
+  the three properties are gone from the published type, so code that set them stops
+  compiling. That is the point — setting any of them produced a payload the metadata route
+  refuses. `ObjectDefinition` (the designer's UI model) is unchanged and still carries all
+  three.
+  
+  The parity gate built for objectui#5761 now has a **second oracle**: every shape in
+  `PAYLOAD_SHAPES` names the schema that judges it, `ObjectSchema` alongside `FieldSchema`,
+  and reach is resolved within an oracle rather than across one — `group` is a legal
+  `FieldSchema` key and a refused `ObjectSchema` key at the same time. That extension found a
+  fourth object-level key (`enabled`, objectui#6238) and a value-level rejection the key-name
+  check cannot see (`fields` sent as an array where the spec wants a map, objectui#6240);
+  both are filed and ledgered rather than fixed here.
+
+### Patch Changes
+
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- 2cf69e4: The field designer now reads and writes a lookup field's relationship target under the
+  spec's spelling `reference` (objectui#6041), in both directions.
+  
+  `referenceTo` is not in `FieldSchema`'s accept set. Measured against the installed
+  `@objectstack/spec` 17.2.0, through the whole object document that
+  `PUT /api/v1/meta/object/:name` validates:
+  
+  ```
+  ObjectSchema.safeParse({ …, fields: { rel: { type: 'lookup', label: 'Owner',
+                                              referenceTo: 'user' } } })
+    => success = false
+    => unrecognized_keys at ["fields","rel"] keys=["referenceTo"]
+       "Did you mean `referenceTo` -> `reference`?"
+  ```
+  
+  so authoring a lookup field through the designer returned a hard 422 `INVALID_METADATA`,
+  and — because the key is then stored — blocked **every subsequent save** of that object,
+  with nothing in the UI to say which key did it.
+  
+  The read direction was broken symmetrically and is the half that would have survived a
+  write-only fix: `toDesignerField` read `raw.referenceTo` while a spec-parsed server sends
+  `reference`, so every already-saved lookup field loaded into the designer with an **empty
+  reference box**. Both wire-bound payload shapes move — `FieldMetadataPayload`
+  (`MetadataService.toFieldPayload`) and `ServerFieldSchema`
+  (`MetadataFieldsPage.fromDesignerField`).
+  
+  `referenceTo` also joins `RETIRED_FIELD_KEYS`. Renaming the emit sites alone does not
+  unblock an object whose stored fields already carry the misspelling: `carryOver` spreads
+  the previous server def verbatim, so the key would ride straight back out to the same 422.
+  The designer's in-memory `DesignerFieldDefinition` keeps `referenceTo` — that is the
+  internal prop name every other UI surface in this repo already uses (`LookupField`,
+  `filter-builder`, `ObjectChart`, `ListView`, `UserFilters`), it reaches no wire-bound
+  shape, and the parity gate classifies it as `uiOnly` rather than a violation.
+  
+  No behavioural change for a half-filled draft: the spec's prose calls `reference`
+  "required for relationship types", but that is not enforced by the zod parse at 17.2.0 —
+  `{ type: 'lookup', label: 'L' }` parses green at field level and through `ObjectSchema`,
+  and `undefined` is dropped by `JSON.stringify` under either spelling, so the wire bytes
+  are identical before and after.
+- 2cf69e4: The field designer now reads the system-field marker under the spec's spelling `system`,
+  and never hands `isSystem` back to the metadata API (objectui#6044).
+  
+  `isSystem` is not in `FieldSchema`'s accept set. Measured against the installed
+  `@objectstack/spec` 17.2.0:
+  
+  ```
+  FieldSchema.safeParse({ type: 'text', label: 'L', isSystem: true })
+    => success = false
+    => unrecognized_keys keys=["isSystem"]  "Did you mean `isSystem` -> `system`?"
+  ```
+  
+  Two defects, one misspelling, and they are two different sites.
+  
+  **The read was dead** — the quieter and worse half. `toDesignerField` read `raw.isSystem`
+  while a spec-parsed server sends `system`, so the flag was always `undefined`. Nothing went
+  red, because the flag is optional and `undefined` is a valid "not a system field". But it is
+  load-bearing: `FieldDesigner` refuses to delete a system field and disables its name and
+  type inputs, so with the read dead `organization_id`, `created_at` and friends presented as
+  ordinary editable, **deletable** business fields.
+  
+  **The write had no emit site at all.** `fromDesignerField` never names `isSystem`; its only
+  route out is the verbatim `...carryOver(prev)` spread, so a stored misspelling round-tripped
+  back to `PUT /api/v1/meta/object/:name` as a hard 422 `INVALID_METADATA` that blocks every
+  later save. The repair is a `RETIRED_FIELD_KEYS` tombstone rather than a renamed line — and
+  it is deliberately paired with the read fix, never a substitute for it: stripping alone would
+  close the 422 and fossilize the dead detection. The spec spelling `system` is not stripped,
+  so a server-injected flag rides through untouched and feeds the read.
+  
+  `app-shell`'s `FieldMetadataPayload` never declared the key, so `toFieldPayload` had nothing
+  to fix. The designer's in-memory `DesignerFieldDefinition` keeps `isSystem`: it reaches no
+  wire-bound shape and the parity gate classifies it as `uiOnly`.
+- 00c665e: `appDesigner.fieldDesigner.formula` is retired — one row removed from each of the ten
+  locale packs plus the designer defaults map, 11 lines, zero readers (objectui#6310).
+  
+  objectui#6043 retired the Field Designer's formula-expression textarea, which was the
+  key's only call site (`FieldDesigner.tsx`, the `{ name: 'formula', label:
+  t('appDesigner.fieldDesigner.formula') }` field descriptor). The value outlived it in
+  eleven places: `DESIGNER_DEFAULT_TRANSLATIONS` in
+  `packages/plugin-designer/src/hooks/useDesignerTranslation.ts`, and the `appDesigner >
+  fieldDesigner > formula` leaf of `packages/i18n/src/locales/{en,de,es,fr,pt,ru,ja,ko,zh,ar}.ts`.
+  
+  Removed under objectui#4658's evidence standard, re-measured on this branch rather than
+  inherited from the card: zero `t()`/`tt()` call sites, no dynamic template head that could
+  reach it (`appDesigner.fieldDesigner.typeCategory.` is the namespace's only one), and its
+  sole textual occurrence anywhere in the repo was the defaults-map row this change removes
+  with it — so the key goes from NEEDS-REVIEW to no footprint at all.
+  
+  The map and all ten packs move in one commit, which is what keeps
+  `defaults-maps-mirror-en-pack` green: that gate fails a map row whose key the `en` pack
+  lacks, and `all-locales-key-parity` fails a pack left behind.
+  
+  Not touched: `designer.field.formula` (`'Formula (CEL)'`) in
+  `packages/app-shell/src/views/metadata-admin/i18n.ts`, a different and live key belonging
+  to metadata-admin's `ObjectFieldInspector` — the surface that still authors formula
+  expressions.
+  
+  `packages/i18n/src/__tests__/appDesigner-fieldDesigner-formula-retired-6310.test.ts` pins the
+  removal by name, following the four prior retirements (objectui#4145, objectui#4392,
+  objectui#4730, objectui#5504). Every i18n gate here runs call site → key, so none of them can
+  see a dead key come BACK into the packs: the reverse sweep that found this one is report-only
+  by design, `all-locales-key-parity` is fully satisfied by ten packs agreeing on a dead key, and
+  `check:i18n-drift` only fires when a value changes. Reverse-verified rather than asserted —
+  reviving the row in all ten packs turns exactly that one case red, naming each pack, while the
+  parity gate and the defaults-map mirror stay green.
+- 73e8c33: The Field Designer builds an object's `fields` map by defining own properties and refuses
+  the three field lists a name-keyed map cannot carry (objectui#6489). `MetadataFieldsPage`
+  keyed the map by blind assignment — `nextFields[f.name] = fromDesignerField(…)` inside a
+  bare `for` loop — which failed silently in three directions, all measured on the installed
+  `@objectstack/spec` 17.2.0:
+  
+  - **A field named `__proto__` never reached the wire.** `map['__proto__'] = def` invokes the
+    prototype setter instead of creating a key, so the field vanished from the serialised PUT
+    body. `__proto__` matches `ObjectSchema.fields`' key rule `/^[a-z_][a-z0-9_]*$/`, so the
+    spec stood ready to accept the field the client had thrown away. The map is now built
+    through `Object.fromEntries`, which defines an own property.
+  - **A nameless field was stored under the literal key `"undefined"`.** Measured:
+    `ObjectSchema.safeParse` with `fields: { undefined: … }` returns `success = true`, so the
+    document parsed, persisted, and had no reader anywhere. It is now refused before the
+    request.
+  - **Two fields sharing a name collapsed into one entry.** A designer list carrying two
+    `amount` fields PUT a single entry, the later silently replacing the earlier. Also refused
+    before the request.
+  
+  Both refusals raise before `client.save`, so a refused list issues no PUT at all, and the
+  message lands in the page's existing error surface naming the offending index — the caller
+  is fire-and-forget (`void handleFieldsChange(next)`), so throwing past it would show the
+  author nothing.
+  
+  This is the plugin-designer port of the refusals objectui#6240 landed in the sibling object
+  writer (app-shell's `MetadataService.toFieldsMap`), down to the wording, so the two writers
+  of the objectui#5761 parity family cannot drift. `fromDesignerField`'s carry-over semantics
+  are untouched.
+- b49f9a1: `MetadataObjectsPage` keys its object-name lookups as own entries, so deleting an object
+  named `constructor` (or `__proto__`) from the Object Manager actually deletes it
+  (objectui#6522).
+  
+  Both name lookups in the page were plain object literals filled by assignment, and the
+  consequential one was a READ. The delete scan asked `!nextByName[name]`, which for an
+  object named `constructor` answered out of `Object.prototype` with the `Object` function —
+  truthy — so the deletion read as "still present" and `client.reset('object', …)` never
+  fired. Not a refusal: the row disappeared from the manager, no error was shown, the save
+  reported success, and the object was still there after the next reload. Measured against
+  the installed `@objectstack/spec`, `ObjectSchema` pins object names to
+  `/^[a-z_][a-z0-9_]*$/` and accepts both `constructor` and `__proto__` — those two are
+  exactly the intersection with `Object.prototype`'s own names, so both are storable and
+  neither was deletable.
+  
+  The second lookup, one function over, failed on the WRITE instead: `byName[item.name] =
+  item` for an object named `__proto__` invoked the prototype setter rather than creating a
+  key, so the object never became an own property, never reached the Object Manager at all,
+  and left its payload on the lookup's prototype chain for later name lookups to answer out
+  of. Both are now `Map`s — neither container is ever serialised, only its values are, so a
+  `Map` fits where the sibling `MetadataFieldsPage` fields map (which IS the PUT body) needs
+  `Object.fromEntries`.
+  
+  Keying only. Nameless and duplicate entries behave exactly as before: this page writes
+  per-object, so the refusal semantics objectui#6489 added to the fields map are a separate
+  question and are deliberately not ported here.
+- 4db5989: A widget title stored as an inline per-locale map is editable again in both dashboard
+  authoring surfaces, and a save writes back only the active locale's entry
+  (objectui#5428).
+  
+  `@objectstack/spec` widened `I18nLabel` from `string` to `string | Record` at
+  17.0.0-rc.6, so a stored widget title may be an inline per-locale map while both
+  authoring panels edit a title in ONE single-line input. Writing the input's value back
+  as the whole value would collapse every other locale on the first keystroke, so both
+  surfaces took the same conservative branch: show a map-valued title resolved, and make
+  it READ-ONLY.
+  
+  That branch could not lose data, but it rested on a premise the spec had already
+  invalidated — "nothing can reach this path from stored metadata yet, `I18nLabel` was
+  plain `string` through rc.5" — stated sixty lines below a comment in the same file
+  documenting the rc.6 widening that makes a stored map reachable. Both could not hold.
+  The pinned spec is 17.0.0. What the read-only branch did in practice from rc.6 onward
+  was not protect an unreachable path: it denied an author the ability to edit a widget
+  title in their own locale.
+  
+  objectui#5301's maintainer ruling settled the write rule for the sibling surface — a
+  save replaces only the active locale's entry and preserves the others — and
+  `@object-ui/i18n` ships it as `setLocalized`, co-located with `pickLocalized` because
+  the read and the write have to agree. Both panels now adopt it:
+  
+  - `@object-ui/plugin-designer`'s `DashboardEditor` widget property panel;
+  - `@object-ui/app-shell`'s `DashboardWidgetInspector` in metadata-admin.
+  
+  A plain-string title keeps saving as a plain string, so the common path is unchanged.
+  An edit made in a locale the stored map does not carry ADDS an entry under that locale
+  rather than overwriting the entry the display fell back to.
+  
+  The pins are preservation pins, not "the input is editable" pins: at both surfaces a
+  keystroke on a map-valued title must leave every other locale's entry byte-identical.
+  Reverse-verified by mutating each write back to the flattening form and confirming those
+  assertions go red at both surfaces.
+  
+  Not a multi-locale editor: an author still reaches only the entry for the locale they
+  are in. Authoring every locale from one panel remains an open product question. The
+  stale deferrals both comments carried pointed at objectui#4163, which closed as
+  completed on 2026-08-15 while the placeholders were still in the tree; they are replaced
+  with the rule that is actually in force rather than re-pointed at another tracker.
+- f7e34ca: Close the dashboard widget `type` vocabulary, and admit `metric-card` as objectui's own component extension.
+  
+  `DashboardWidgetSchema.type` was `string` on the TypeScript interface and `z.string()` in the Zod twin — an unbounded hatch. A typo'd family, a chart type the spec retired, and a component type nothing registers all type-checked and validated, surfacing only as the renderer's red `OBJUI-001` panel at runtime.
+  
+  It is now the CLOSED `DashboardWidgetTypeName` / `DashboardWidgetTypeSchema`: the spec's own `ChartTypeSchema` families **by reference**, plus two named, closed objectui extension sets — `DASHBOARD_WIDGET_TYPE_EXTENSIONS` (`list`, `custom`: objectui-only widget families) and `DASHBOARD_COMPONENT_WIDGET_TYPES` (`metric-card`: an objectui SDUI **component** type the widget slot holds directly, per the maintainer ruling of 2026-08-14 — objectui's own component enum, explicitly not the spec widget enum).
+  
+  Three drifts the closure surfaced and this change fixes: the dashboard designer's palette offered `grid`, which is not a widget family in either contract and was refused at publish; the metadata-admin widget inspector and the designer both wrote an unvalidated `string` from their select boxes; and a `@object-ui/types` fixture pinned `bar-chart`, a `plugin-charts` component type, on a dataset-bound widget that could never render as one.
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [2d7304d]
+- Updated dependencies [062943f]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [94e2fa7]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [3e853c9]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [17ccec9]
+- Updated dependencies [8d3a529]
+- Updated dependencies [194fae1]
+- Updated dependencies [beccf1c]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [5173a5e]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [c9a7252]
+- Updated dependencies [5f19b92]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [c38162d]
+- Updated dependencies [b362c1b]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [1c19722]
+- Updated dependencies [5961030]
+- Updated dependencies [faa863d]
+- Updated dependencies [fd814d6]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [b2e85a9]
+- Updated dependencies [c7cd2b6]
+- Updated dependencies [b2065e7]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [3c9fca3]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [b470e91]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [9a1fb41]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [9e22085]
+- Updated dependencies [b655a9d]
+- Updated dependencies [c574dfb]
+- Updated dependencies [02f48b6]
+- Updated dependencies [a865c73]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [e4e9557]
+- Updated dependencies [7a28e1e]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [20e317c]
+- Updated dependencies [425762e]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [8e00bfd]
+- Updated dependencies [8d37efb]
+- Updated dependencies [9850c6e]
+- Updated dependencies [9118a31]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [83ec618]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [4bb940b]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [f1690d4]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [591bf27]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [43ca9d5]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [ba306e3]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [26a2238]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [5d79faf]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/fields@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/plugin-grid@17.7.0
+  - @object-ui/plugin-form@17.7.0
+  - @object-ui/data-objectstack@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/plugin-designer/package.json b/packages/plugin-designer/package.json
index 905734071a..5ce5762e77 100644
--- a/packages/plugin-designer/package.json
+++ b/packages/plugin-designer/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-designer",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Visual designer plugin for Object UI with page, data model, process, and report designers plus collaborative editing.",
diff --git a/packages/plugin-detail/CHANGELOG.md b/packages/plugin-detail/CHANGELOG.md
index 1076d9b139..cb494c8bab 100644
--- a/packages/plugin-detail/CHANGELOG.md
+++ b/packages/plugin-detail/CHANGELOG.md
@@ -1,5 +1,917 @@
 # @object-ui/plugin-detail
 
+## 17.7.0
+
+### Minor Changes
+
+- 6d63cd0: An auto-derived related list now orders its rows by the CHILD object's default list view
+  `sort`, instead of falling to the server's primary-key order (objectui#5795). A task
+  version's "check items" tab whose child object declares `sort: [{ field: 'seq_no' }]`
+  renders 10/20/30/40; before this it rendered whatever order the ids happened to give —
+  20/30/10/40 in the reported case — while the child object's own list page obeyed the
+  declaration.
+  
+  **Declared as user-visible, deliberately, even though no key was added.** The contract
+  question ("where does a derived related list's sort declaration live?") was ruled on
+  objectstack#11345 (maintainer, 2026-08-23) as **direction 1**: inherit the child's list
+  view sort, and add **no** new spec key — the field-level `relatedListSort` the issue also
+  proposed was explicitly not approved. So there is nothing new to author, and
+  `record:related_list.sort` was already declared, parsed and consumed; this fills it. What a
+  host observes is nonetheless new: a derived related-list descriptor gains a populated
+  `sort` where it had none, and the query it issues gains an `$orderby`. An app whose child
+  objects declare a default list order will see those tabs re-order on upgrade — which is the
+  point of the change, and is why this is not a patch.
+  
+  Nothing is inherited where nothing was declared: a child object with no default list-view
+  sort produces the same descriptor, the same node and the same `$orderby`-free query as
+  before.
+  
+  The two `sort` surfaces declare the same union and mean different things by its string arm
+  — a `ListView` string is the legacy space-separated `'seq_no desc'`, while the related
+  list's own reader takes `'field'` / `'-field'` — so the inherited value is normalized to
+  the array arm once, at the derivation, through `@object-ui/core`'s
+  `convertSortToQueryParams` (the repo's single definition of both authored dialects). An
+  un-normalized inherit would have ordered by a field literally named `seq_no desc`.
+  
+  Known and unchanged: `$orderby` is only assembled while the related list is in windowed
+  (server-paged) mode, so a declared *or* inherited sort still disappears while the built-in
+  client text filter is active. That hole pre-dates this change and affects the authored prop
+  identically; it is now pinned as a recorded fact in
+  `plugin-detail/src/__tests__/RelatedList.sortDroppedOutsideWindowed.test.tsx` rather than
+  fixed here.
+- 3777538: `isConcurrentUpdateError` no longer promises a `code` its runtime check
+  knowingly accepts values without.
+  
+  The exported predicate matches on two limbs — `code === 'CONCURRENT_UPDATE'`
+  (the wire shape) **or** `name === 'ConcurrentUpdateError'` (the deliberate
+  cross-realm discriminator, for a host that bundles the adapter twice so
+  `instanceof` fails). Its narrowed type declared `code: 'CONCURRENT_UPDATE'` as
+  a **required** literal, so for exactly the case the second limb exists to serve
+  the predicate handed the caller a property the value does not have. `code` is
+  now declared optional (`code?: 'CONCURRENT_UPDATE'`), stating only what both
+  limbs guarantee.
+  
+  **Type-level only; zero runtime change.** The two-limb check is byte-identical
+  — it is deliberate and documented, and the diff touches nothing but the return
+  type and the comment above it. There was no runtime symptom to fix: the only
+  consumer (`InlineEditSaveBar`'s conflict builder) reads just the optional
+  `currentVersion` / `currentRecord` fields.
+  
+  **Breaking for TypeScript consumers that read the narrowed `code`.** After
+  narrowing, `err.code` is now `'CONCURRENT_UPDATE' | undefined` instead of
+  `'CONCURRENT_UPDATE'`, so code that assigned it to a non-optional `string` will
+  newly fail to compile. That failure is the point: on a name-only error the
+  value was already `undefined` at runtime, and the old declaration was the
+  reason the compiler could not say so. Guard the read (`err.code ===
+  'CONCURRENT_UPDATE'` still narrows fine) or branch on the predicate itself
+  rather than on the field.
+  
+  Pinned by `ConcurrentUpdateDialog.narrowedCode-6421.test.tsx`, which asserts
+  the invariant by assignability — the value the runtime accepts through the
+  `name` limb must be assignable to the type the predicate returns — alongside
+  runtime coverage of both limbs, which `plugin-detail` had none of.
+- d06fba8: The console record page and the `record:activity` block read ONE `sys_activity`
+  type table, so a scheduled meeting no longer appears on one and vanishes on the
+  other.
+  
+  `RecordDetailView`'s `sys_activity` merge carried a hand-written copy of the
+  table that `record:activity` exports as `ACTIVITY_TYPE_TO_FEED_TYPE`. Neither
+  file imported the other and nothing compared them, so the two could drift
+  silently — and they had. objectui#5840 added `scheduled` -> `event` to the
+  exported table, because a shipped producer (HotCRM's `schedule_meeting`) writes
+  that value and the row was being dropped before any filter ran. The copy here
+  was left untouched, so the same row rendered on a hand-authored record page and
+  was dropped on the console record page: same record, same row, two answers.
+  
+  `RecordDetailView` now imports the exported table, and the copy is gone. The
+  table is re-exported from `@object-ui/plugin-detail`'s entry point, which is
+  what makes a single reading possible at all — it was previously reachable only
+  from inside the plugin. No module enters the eager closure: the module holding
+  it was already pulled in by the renderer beside it.
+  
+  Adding an activity type is now one edit, in one place, that both surfaces see.
+  A re-fork is caught rather than merely discouraged: the new pins spy on the
+  shared object and inject a member into it at runtime, so a private copy holding
+  today's members exactly — the failure this change removes — fails, where a
+  value comparison would pass on the defect.
+  
+  Only the table converges. The row-to-`FeedItem` construction around it is still
+  written twice, so an unmapped activity type is still dropped silently on the
+  console surface where the block warns once; that mirror is filed separately.
+- e719ebd: `data-table` reads the declared `header`; the producers translate `label` into it.
+  
+  `TableColumn` declares `header: string` and does not declare `label`. The
+  renderer's column normalization nonetheless read `header: col.header || col.label`,
+  so the same key had one spelling the type admits and one only the runtime did.
+  That alias is gone (objectui#5351), and the translation it used to perform happens
+  once at each producer instead: metadata vocabulary in, adapter vocabulary out.
+  
+  **This narrows what `data-table` accepts, so read this if you author `data-table`
+  nodes by hand.** A column spelled `{ label: 'Stage', accessorKey: 'stage' }` on a
+  directly authored `data-table` now renders a **headerless** column over live
+  cells. Spell it `header` — the key `TableColumn` has always declared. Columns
+  reaching `data-table` through `object-data-table`, `object-grid` or a related
+  list are unaffected: those producers resolve `header` for you from the spec's
+  `ListColumnSchema.label`, so every spelling they accepted before they still
+  accept.
+  
+  `@object-ui/core` gains `columnHeader()` alongside `columnIdentity()` — the reader
+  producers use to cross that boundary. It is adapter-first (`header` wins over
+  `label`), so an author who addressed the table directly is never overwritten.
+  
+  `object-data-table` also gains a fix from the same move: a column carrying a
+  `label` used to render a **blank** header there even while the alias existed,
+  because the widget's field-meta enrichment overwrote the authored `label` before
+  the adapter ever saw it. `{ field: 'stage', label: 'Stage' }` now renders "Stage".
+  
+  The sibling `accessorKey: col.accessorKey || col.name` alias is **unchanged** here
+  and still resolves. Retiring it is objectui#5120's remaining step, which is
+  gated on two published skill guides that teach that spelling.
+- 0b12a33: `record:path` stops looking like a control it cannot be.
+  
+  The record page draws the object's lifecycle across the top from the
+  `stageField` role, and it drew each stage as a filled, shadowed, equal-width
+  pill — a segmented button group, sitting exactly where a CRM user reaches for
+  the stage control. Nothing was behind it. Measured in a browser on a shipped
+  build (HotCRM `crm_quote`, and this is generic record chrome, so every object
+  that declares a `stageField` has it): the segments were `role="listitem"` with
+  `cursor: auto` and `tabindex` null, no ancestor `button`/`tab`/`a`, and a full
+  pointer sequence (pointerdown → mousedown → pointerup → mouseup → click) left
+  the record's status untouched. Advancing a record needs the edit form or a bulk
+  action. Users spent two or three clicks on the path before concluding it was
+  decoration.
+  
+  There is no write path to connect it to, and this change does not open one:
+  this renderer's only channel is `useRecordContext()`, whose value exposes
+  `data` / `refresh` / `headerSystemActions` / `onToggleFavorite` and no
+  record-field mutation. Editing runs through `record:details`'
+  `<InlineEditProvider>` + `<InlineEditSaveBar>` (`dataSource.update(...,
+  { ifMatch })`) or an action via `useActionEngine`; neither reaches this
+  component.
+  
+  So the promise is withdrawn rather than honoured. Each stage now renders as a
+  thin decorative rail segment with its label as plain text beneath it — the
+  vocabulary app-shell's approval step readout already uses. Gone: the per-stage
+  filled pill, the shadow, the ring, the bordered chip, the equal-width tap
+  target. Kept exactly as they were: which stage is current (`aria-current="step"`
+  and type weight), the travelled/untravelled distinction, the check on completed
+  stages, and the separated `lost`-terminal group. The accessible semantics did
+  not move — `role="list"` / `role="listitem"` with no tab stop was already
+  correct for a readout, and it stays that way.
+  
+  Three DOM attributes carry the state that colour used to be the only carrier
+  of, so the classification is assertable without reading CSS:
+  `data-stage-state` (`completed` | `current` | `upcoming`),
+  `data-stage-terminal` (`won` | `lost`), and `data-stage-rail` on the decorative
+  indicator.
+  
+  **Not in this change:** click-to-advance. A stage control that writes
+  `stageField` through the same permission/validation envelope an edit takes is a
+  separate feature with its own appetite, and folding it in here was explicitly
+  ruled out.
+- ebce5a3: `object-grid` / `object-form` / `detail-view` resolve their data source the same way, and a block that resolves none says so
+  
+  The three object-bound blocks disagreed about how the data-source adapter reached
+  them. `object-grid` and `object-form` were registered through wrappers that read
+  it from `SchemaRendererProvider` context; `detail-view` was registered as the raw
+  component, which reads a React `dataSource` prop. `SchemaRenderer` itself reads
+  only context, so the two wirings were mutually exclusive: measured with correct
+  keys in every cell, provider wiring gave the grid `find` 1 and the detail view
+  `findOne` 0, and prop wiring gave exactly the reverse. Neither reported anything.
+  
+  All three now resolve the adapter through one rule — an explicit `dataSource`
+  prop first, the provider context second. This is additive: `detail-view` keeps
+  its prop form (and direct `<DetailView dataSource={…} />` callers are untouched),
+  `object-form` gains a prop form it did not have, and `object-grid` no longer
+  throws `useSchemaContext must be used within a SchemaRendererProvider` when a
+  page has no provider.
+  
+  And the silence is over. A block in this family that resolves no adapter renders
+  a **No data source resolved** panel naming the block, the object it was about to
+  read, and the ancestor that injects the adapter — instead of a header-only grid,
+  a field-less form card, or nothing at all. The check is opt-in per block, so a
+  placement with inline rows, inline `customFields`, an inline record or an `api`
+  endpoint is untouched.
+  
+  New from `@object-ui/react`: `useResolvedDataSource`, `NoDataSourcePanel`,
+  `noDataSourceMessage`, and a `requiresDataSource` prop on `ElementDataSourceGate`.
+- 8a44390: `record:alert` binds the row through `usePredicateRecordContext`, so an
+  author-declared `properties.visible` is actually consulted.
+  
+  `renderers/record-alert.tsx` was the last predicate face in the repo still
+  handing `useCondition` a root-only `{ record }` bag. Every other row-scoped
+  predicate — the four generic action renderers (objectui#4075) and app-shell's
+  `DeclaredActionsBar` (objectui#4077) — binds the row through the shared
+  `usePredicateRecordContext(record)` helper, which resolves the three spellings
+  objectui#5330 ruled on: canonical `record.status`, the deprecated row-action
+  shorthand `status`, and deprecated legacy `data.status`.
+  
+  Under the root-only bag only the canonical spelling worked, and the two others
+  failed in **opposite** directions — both of them silently, because this call
+  site is fail-soft:
+  
+  - **row-action shorthand** (`status == 'x'`) resolved nothing, so the evaluator
+    threw. The legacy `${…}` path answers a throw with its own source text, a
+    non-empty and therefore truthy string, so the verdict was **SHOWN on every
+    row**. A banner the author had gated was permanently on screen.
+  - **legacy `data.*`** (`data.status == 'x'`) did not throw at all. App-shell's
+    ambient predicate scope (`providers/ExpressionProvider.tsx`) carries
+    `data: {}`, so the predicate read that object instead of the row, compared
+    `undefined`, and the verdict was a constant false — **never shown**.
+  
+  **Behaviour change, stated plainly:** a shipped `record:alert` whose `visible`
+  was written in either deprecated spelling was inert and is now live. A banner
+  that was permanently visible may begin to hide, and one that never appeared may
+  begin to show — that is the point of the fix, but it is a verdict change rather
+  than a no-op. Canonical `record.*` predicates are unaffected in verdict: they
+  resolved before and resolve now, pinned on both polarities. An in-tree census
+  found no `record:alert` `visible` predicate outside this package's own tests.
+  
+  A node-level `visibleWhen` is a separate gate one tier up in `SchemaRenderer`,
+  with its own deliberate bindings (`data` is the data-source adapter there, not
+  the row). This change does not touch it; the two still compose as AND.
+  
+  The renderer's header comment described the shared-scope behaviour it did not
+  have. It now describes what the file does, including the fail-soft policy and
+  the two-gate composition.
+- 23705b7: **`ReferenceRailEntry` is now the spec's type, and the reference-rail `icon` key retires** (objectui#5494, maintainer ruling 2026-08-22).
+  
+  `ReferenceRailEntry` is owned by `@objectstack/spec` as of 17.1.0. The hand-written interface in `record-reference-rail.tsx` is replaced by a re-export of the spec's `ReferenceRailEntry` (derived from `ReferenceRailEntrySchema`, `$strict` over `{ objectName, relationshipField, title?, limit?, displayField? }`), and `buildDefaultPageSchema` no longer emits `icon` on the reference-rail entries it synthesizes.
+  
+  **Migration — if you write `icon` on `record:reference_rail` entries, remove it.** Be aware of what this does and does not change:
+  
+  - **Runtime validation does not move.** The spec's strict schema already refused `icon` at save — that refusal is unchanged. What was broken was objectui's declaration: the TS type advertised a key that could never be saved.
+  - **Nothing ever rendered `icon`.** No render path in `RecordReferenceRailRenderer` has ever read the key (measured back to the file's first commit, and independently by the spec's `ui-reference-rail-unknown-keys-refused` migration entry). An authored `icon` that survived in unsaved/preview metadata was already a silent no-op — after this change the TS type says so instead of suggesting otherwise.
+  - **The published TS surface narrows.** Code that imported `ReferenceRailEntry` from `@object-ui/plugin-detail` internals and set `icon` will now get a type error. That error is the contract speaking: remove the key.
+  
+  The reference-rail icon affordance is retired rather than proposed upstream: a stock scan of this repo, its examples and schema-catalog corpus, and the objectstack tree (examples, templates, docs) found no reachable authored usage of `icon` on reference-rail entries. Stored customer metadata is not reachable from this seat and was not scanned.
+
+### Patch Changes
+
+- f66072d: Inline `t(key, { defaultValue })` strings are now held to the one placeholder spelling a
+  provider-less host can resolve, and five of them are pinned to the pack value for the first
+  time (objectui#4905).
+  
+  `check:i18n-keys`' `default-value-drift` class pins an inline default byte-identical to its
+  `en` row, and objectui#3512 holds `en` to the one spelling `createSafeTranslation`'s
+  `fallbackT` interpolates — so most inline defaults were covered transitively. Re-measured
+  on this tree, 66 of 1003 were not: three literal defaults on dynamic keys, and 63 written
+  as a computed expression. A new `unresolvable-default-spelling` class in
+  `scripts/check-i18n-call-site-keys.mjs` now judges the text every inline default carries —
+  the folded sentence, or a template literal's static segments — so `{{ name }}`,
+  `{{count, number}}`, `{{- name}}` and `$t(key)` are refused wherever they are written,
+  rather than only inside a copy table.
+  
+  Four call sites gain a real pin because their default carries no placeholder at all: the
+  record-form submit button now falls back to `Update`/`Create` (the pack's wording) instead
+  of `Save`/`Create` via a nested `t('common.save')`, the context selector's package label
+  and the approvals separator now state their literal. One more (`detail.showEmptyFields`)
+  is behind a `createSafeTranslation` hook, whose fallback does interpolate, so it can safely
+  say what the pack says.
+  
+  The other 61 are deliberately left computed, and the measurement behind that is the useful
+  part: react-i18next's not-ready `t` returns `options.defaultValue` **verbatim, without
+  interpolating it**. At a call site bound to a bare `useObjectTranslation()`, a default
+  written as `` `Signed in as ${user.email}` `` is therefore the only form that renders
+  correctly with no provider — rewriting it to `'Signed in as {{email}}'` would put literal
+  braces in front of the user, which is the exact defect this family of cards exists to
+  prevent. Those sites keep their template literals and are covered by the spelling class
+  instead.
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- 1117414: `@object-ui/plugin-detail` now declares `"@objectstack/spec": "^17.1.0"` rather than
+  `^17.0.0`, which is the lowest published spec that carries the symbol its own build
+  output re-exports (objectui#5793).
+  
+  `dist/renderers/record-reference-rail.d.ts` reads
+  `export type { ReferenceRailEntry } from '@objectstack/spec/ui'`, and
+  `ReferenceRailEntry` first appears in `@objectstack/spec@17.1.0` — measured against the
+  published tarballs, not the installed tree: the name is absent from 17.0.0's
+  `dist/ui/index.d.mts` (425 exported names) and present in 17.1.0's (442). So the old
+  range was a claim the package could not honour. Any consumer resolution that lands
+  17.0.0 — a sibling pinning it exactly, an `overrides` entry, a mirror a minor behind —
+  satisfied `^17.0.0` and got a dangling type re-export.
+  
+  Nothing a consumer installs today changes: normal resolution already picks the newest
+  17.x, and `pnpm-lock.yaml` still resolves 17.2.0 on this edge after the bump. The change
+  is to the declared floor only, which is why it is scored `patch` rather than `minor` —
+  the same reasoning objectui#5753 used for the other direction on this dependency.
+  
+  The bump is one instance; the durable half is `scripts/check-spec-range-floors.mjs`, a
+  gate that compares every published package's `dist` imports of `@objectstack/spec/*`
+  against the export set of that package's own declared minimum. It runs on the publish
+  path (`pnpm changeset:publish`) and nightly, and it names the symbol behind every range
+  it asks for. No other package's floor is touched: the gate finds nothing else to justify
+  one across the 19 packages that declare the spec in a consumer-facing field.
+- 7c96c94: Four more private copies of the reference-bearing field family converge onto
+  `@object-ui/core`'s `EXPANDABLE_FIELD_TYPES`, and the "fourth and last private copy" claim
+  that `paramToField` still stated is corrected (objectui#5874, objectui#5875).
+  
+  Each copy diverged from the published family in BOTH directions, so this is a behaviour
+  change on every face and not a refactor:
+  
+  - **`user` and `tree` are now treated as relations.** Both carry the same foreign-key
+    storage as `lookup` and resolve through the same expand path (objectui#2032), and each
+    face's own stated reason for special-casing `lookup` applied to them verbatim — so
+    gaining them restores the rule each face already meant. A `user` / `tree` field is now
+    read-only in the quick-look drawer (`RecordDetailDrawer`), where the drawer wires no
+    relation picker and a plain text input let a user overwrite the relation with a
+    free-form string; it gets the wide layout basis in the record header's highlights strip
+    (`HeaderHighlight`), whose inline editor is a record picker; and a field-backed action
+    param over one now inherits the picker config it needs (`resolveActionParams`).
+  - **`master_detail` is now treated as a relation by `resolveActionParams` too** — it was
+    the only face missing that member as well, so a field-backed `master_detail` action param
+    inherited no `referenceTo` at all and degraded to the unexplained "paste a record id"
+    text input that objectui#3405 exists to prevent.
+  - **The undeclarable `reference` spelling is gone from the three field-type faces.**
+    Measured against `@objectstack/spec`'s closed `FieldType` vocabulary with live controls
+    (`lookup` / `master_detail` / `user` / `tree`) and dead ones (the retired `owner`, plus a
+    nonsense spelling): `reference` is absent, so no spec-compliant object schema could
+    declare a field that reached those branches. It sat exactly where `owner` sat before
+    objectui#4814 retired it — dead weight that read as live capability.
+  
+  `resolveActionParams` keeps answering for `reference`, deliberately and by a different
+  route: it is refused by the spec's `ActionParamSchema` too, but the dialog still accepts it
+  from params already authored with it, and that acceptance belongs to the one alias table in
+  `paramToField` rather than to a hand-copied membership test. This face now asks the shared
+  family over the widget key that table produces — the same expression `paramToField`
+  evaluates one step later, so the half that populates a param's picker config and the half
+  that forwards it can no longer disagree.
+  
+  No face copies the set: each calls `.has()` on the object `@object-ui/core` exports, and
+  each carries an identity pin (a spy on that `has`) so a member-identical private copy fails
+  instead of quietly re-forking the table.
+- 95f8704: `record:path` now announces each stage's state, not just its label (WCAG 2.2 SC 1.4.1)
+  
+  The lifecycle path distinguished travelled, upcoming and lost-terminal stages with
+  colour plus a `✓`/`✗` glyph, and both glyphs are `aria-hidden` decoration.
+  `aria-current="step"` marked the current stage and nothing else, so a screen-reader
+  user heard a run of identically-announced items — and a rejected stage announced
+  exactly like an ordinary stage the record had not reached yet.
+  
+  Each stage now carries an accessible name composing its (already picklist-localized)
+  label with its state, from five new `detail.pathStage*` keys translated in all ten
+  locale packs. The glyphs stay decorative and the readout's `role="listitem"` /
+  `aria-current` semantics are unchanged.
+  
+  The name is composed into `aria-label` rather than visually-hidden text because
+  `listitem` takes its name from the author only: text placed inside a stage computes
+  to an empty accessible name, so the visually-hidden shape would have looked right in
+  the markup and delivered nothing to the accessibility tree.
+- 8d3a529: `record:path` finishes localizing and de-colouring its accessible names — the two residues
+  objectui#5916 named and deliberately left behind (objectui#5956, objectui#5957).
+  
+  **The list's own label was English on a localized surface, and the other one named nothing.**
+  Both the desktop and the mobile `role="list"` row did
+  `aria-label={schema.aria?.label || 'Record path'}`, so a zh/ja/ar session heard `Record path`
+  for the list while every stage inside it announced in the session locale — one control
+  speaking two languages at once. The fallback is now `detail.pathLabel`, translated in all ten
+  packs; the `schema.aria.label` author override still wins ahead of it.
+  
+  The lost-terminal alt group was a different defect wearing the same clothes: its
+  `aria-label="Alternative terminal stages"` sat on a bare `div`, which has the `generic` role,
+  and browsers expose no accessible name on a generic element. That string reached nobody —
+  inert, not merely untranslated — so translating it would have shipped copy to ten packs that
+  no user can hear. It is removed rather than given a role that takes a name, on three
+  measurements: nothing is lost (it was never announced), it would be redundant (every stage
+  inside already announces `closed lost` in the session locale after objectui#5916, in the one
+  place `role="list"` can carry it), and it would fork the two rows (the mobile row renders one
+  flat list with no alt group, so a named group would make one control expose two structures by
+  viewport).
+  
+  **An unreached goal terminus was distinguished by hue alone.** `railClass` paints it
+  `bg-emerald-500/30` where a plain upcoming stage gets `bg-muted` — the renderer's own note
+  calls this "a faint emerald so the goal is legible" — while both announced the identical
+  `{{stage}}, upcoming`. Two stages ahead of the record painted differently and read the same:
+  the WCAG 2.2 SC 1.4.1 class objectui#5916 closed, on the one distinction it left behind, and
+  reachable without authors opting in because `classify()` finds `won` through the `WON_TOKENS`
+  heuristic as well as an explicit `terminal: 'won'`. New key `detail.pathStageWonUpcoming`
+  (`{{stage}}, goal stage, not reached`), translated in all ten packs.
+  
+  Scoped to the UNREACHED goal, which is a measurement of the stylesheet rather than a
+  preference: a reached goal terminus paints `bg-primary` when current and `bg-emerald-500` when
+  completed, byte-identical to any other current or completed stage. Naming it apart would hand
+  a screen reader a distinction the screen does not make — the mirror image of the defect — so
+  it is one new key, not a pair, and a test pins that decision so it cannot drift into a fourth
+  state unnoticed.
+  
+  Both new keys also land in `DETAIL_DEFAULT_TRANSLATIONS`, which
+  `defaults-maps-mirror-en-pack` compares against the `en` pack key by key, so neither can fork
+  between a provider-mounted console and a provider-less embed. No existing `en` value changes,
+  so no pack is asked to follow an edit.
+- 63d54dd: `record:path` now derives ONE stage classification and hands it to both of its rows, so a
+  stage can no longer paint and announce two different ways depending on viewport width
+  (objectui#5998).
+  
+  The renderer draws a desktop row (`hidden sm:flex`) and a mobile row (`flex sm:hidden`) from
+  the same `stages[]`, and each used to compute its own `terminal` from that array.
+  `renderStage` passes the same `terminal` to `railClass` and — since objectui#5957 — to
+  `stageAriaLabel`, so any disagreement surfaced in the colour and in the accessible name at
+  once. The rows disagreed on two axes:
+  
+  Mid-path goal. `WON_TOKENS` matches `完成`, an ordinary word rather than a Salesforce-style
+  `closed_won` value, so a path like `草稿 → 完成 → 已归档` classified index 1 as `won`.
+  Desktop declined it, because only the last forward stage can be the goal terminus; mobile
+  marked it `bg-emerald-500/30` and announced `goal stage, not reached`.
+  
+  The lost slice. Desktop renders `stages.slice(firstLostIdx)` as a visually separated alt
+  group and hardcoded `terminal: 'lost'` on every member of that positionally-defined group,
+  while mobile classified each stage on its own. A plain stage after a `lost` one
+  (`草稿 → 失败 → 已归档`) therefore painted destructive and announced `closed lost` on
+  desktop and plain on mobile; a `won`-classified stage in the same position drew `'lost'`
+  from one row and `'won'` from the other.
+  
+  Both rows now index a single `stageTerminals` array: `lost` is a property of the stage
+  itself, `won` is the goal terminus and so is the last forward stage or nothing, and the
+  positional grouping is a layout concern that no longer overrides what a stage is. Behaviour
+  is narrowed on both axes and never widened — no stage gains a `terminal` on either row that
+  it did not already carry there, and a goal terminus that really is last keeps its faint
+  emerald rail and its `goal stage, not reached` name on both rows.
+- b4393e5: The last three sort-axis consumers read the platform's per-column sortability signal instead
+  of re-deriving it from the field's type (objectui#6108, inheriting objectstack#10235 ruling A
+  through objectui#5729's landed contract). ListView's toolbar sort picker and both of
+  RelatedList's sort entry points — the embedded table's column headers and the `data-list`
+  sort-button row — now go through `isPlatformSortableField`, the same spelling the grid header
+  adopted; their `UNMATERIALIZED_FIELD_TYPES` / `isUnmaterializedFieldType` re-derivations are
+  deleted.
+  
+  The re-derivation was not wrong about `formula`: the platform computes its own projection from
+  the same `@objectstack/spec` storage fact, which is why the drift went unnoticed across two
+  cards. It parts company on everything the projection encodes as ABSENCE — an unknown name, a
+  dotted path a caller can put in a related list's `columns`, an unprovisioned audit column —
+  where a type read finds no field definition, answers "sortable", and offers a control the
+  runtime meets with `400 INVALID_SORT`. It parts company again on any refusal that carries no
+  `reason: virtual-type`, and it cannot follow the platform in the other direction either: a
+  field the platform now DOES order by stays withheld forever on its type alone.
+  
+  Two behaviours are deliberately unchanged. The relational carve-out stays separate from the
+  signal — the projection answers `sortable: true` for a `lookup` because the platform can order
+  by the stored foreign key, while the UI withholds because that order means nothing beside a
+  column of names — so a relational column does not get its sort back. And ListView's picker
+  still lists a field the CURRENT sort already names, which is the only way to remove a sort the
+  server refuses outright; that exception now covers platform-refused fields, not just formulas.
+  
+  A deployment that served no `sortability` key at all is a different case from "nothing is
+  sortable": that branch keeps the type read as a compatibility floor, so behaviour on a backend
+  older than objectstack#10235 (or an inline/mock data source) is byte-identical to before.
+- d3005f7: `DetailSection` now resolves `section.headerColor` through a lookup of complete
+  Tailwind class literals instead of building `bg-` + the authored value as a
+  template literal (objectui#6178).
+  
+  Tailwind v4 has no runtime — it builds the stylesheet by scanning source text
+  for complete class tokens, and this workspace ships no `bg-*` safelist — so the
+  old expression contributed nothing to the compiled CSS. Measured, not assumed:
+  compiling `apps/console/src/index.css` with that expression deleted produced a
+  byte-identical stylesheet (same sha256). An authored value styled the header
+  only when some other source file happened to author the identical class
+  literally, which is why both documented examples appeared to work: `bg-muted`
+  occurs 691 times and `bg-primary/10` 63 times elsewhere in the workspace. That
+  liveness was accidental and moved with unrelated edits in unrelated packages.
+  
+  The shape matches the sibling this repo already solved the same way —
+  `useRowColor`'s `COLOR_TO_CLASS` in `@object-ui/plugin-grid`:
+  
+  - a lookup of literal, tint-only design-system classes: `muted`, `muted/50`,
+    `accent`, `primary/10`, `secondary/10`, `destructive/10`. Both values the
+    `@object-ui/types` mirror documents (`muted`, `primary/10`) are in it, so
+    nothing that rendered before renders differently now;
+  - a value that is already a complete `bg-*` class is passed through untouched.
+    This is new — `headerColor: 'bg-muted'` previously produced the meaningless
+    `bg-bg-muted`;
+  - anything else contributes no class at all, instead of a fabricated one.
+  
+  Behaviour change to be aware of: an undocumented bare suffix outside the
+  vocabulary (say `headerColor: 'blue-100'`) no longer reaches the DOM as
+  `bg-blue-100`. It rendered before only where another file happened to author
+  that exact class; write it as the complete class (`headerColor: 'bg-blue-100'`)
+  to keep it, on the same terms as any `className` a schema carries. No value is
+  rejected and the declared type is unchanged.
+  
+  `headerColor` remains undeclared on the strict `@objectstack/spec`
+  `record:details` section schema, which refuses it today on the strength of this
+  defect (objectstack#11661). Declaring it, and with which vocabulary, is a
+  separate spec decision.
+- 830ed58: The record page's approval band offers its **Recall** button to the approval's submitter
+  only (objectui#6464).
+  
+  Field report on `@objectstack/*@17.2.0`: user A submits a record into a 4-level approval;
+  user B — not the submitter, read access, not an admin — opens the record and the band still
+  lights a clickable recall button. The click cannot succeed. The recall endpoint authorizes
+  on submitter identity and refuses everyone else, so the only outcome available to that
+  button was a failure toast. Record state was never at risk; this was purely a
+  writability-feedback mismatch, the same family as objectui#3794.
+  
+  The button's only gate was `dataSource.cancelPendingApproval` — "can this adapter recall at
+  all" — which is a question about the DataSource, not about the viewer. Identity now joins
+  it, threaded the way every other signal on that band already travels: the HOST resolves it
+  and passes it through `InlineEditProvider`, so the renderer stays DataSource-agnostic and
+  never re-derives who submitted what.
+  
+  - `@object-ui/react` — `InlineEditProvider` accepts `approvalIsSubmitter`, surfaced on
+    `InlineEditContextValue`. Additive and optional; no existing prop changes.
+  - `@object-ui/plugin-detail` — the band's recall button is withdrawn when that signal is a
+    resolved `false`.
+  - `@object-ui/app-shell` — `RecordDetailView` resolves the verdict from its existing
+    approvals read and threads it.
+  
+  **The signal is tri-state, and the third state is the load-bearing one.** `true` offers
+  recall, `false` withdraws it, and **`undefined` — a host that resolves no approval identity
+  — renders exactly as it did before this release.** Omission preserving prior behaviour
+  mirrors how `approvalPending` falls back to `locked`. Defaulting the unknown case to "hide"
+  would have traded a cosmetic defect for a functional loss: every host whose band runs off
+  the record's `approval_status` mirror alone would silently lose its submitter's only way to
+  unlock their own record.
+  
+  **Withdrawn rather than disabled-with-reason.** The card offered either. For a
+  non-submitter this control is never actionable on any pending record, so a permanently
+  disabled button is standing clutter rather than a lesson; and the two sibling submitter
+  levers already hide — the approvals panel's Remind button, and the declared
+  `approval_recall` action's `visible` predicate. The band, its quorum tally and the
+  approvals timeline still tell a non-submitter exactly what state the record is in. Only the
+  lever they can never pull is gone.
+  
+  **This changes no permission.** Nothing about what the server allows moves, `canEdit` and
+  the approval lock are untouched, and nothing downstream reads `approvalIsSubmitter` as an
+  authorization verdict — the recall endpoint remains the sole authority, and it refused
+  these callers before this change and refuses them after. There is deliberately **no admin
+  carve-out** (the reporter ruled that case out, cf. objectstack#9464).
+  
+  The derivation itself is now one function, `isSubmitterOf` — server-resolved
+  `viewer.is_submitter` first (framework#3310), an id comparison as the fallback for backends
+  that predate it, joined with `??` so a server that resolved `false` is believed rather than
+  re-litigated client-side. The approvals panel's Remind gate, which already carried that
+  expression inline and whose behaviour is unchanged, now reads the same answer: two copies
+  would have been two definitions of who submitted.
+  
+  The **untranslated refusal text** the reporter also saw ("No pending approval request found
+  for this record", concatenated after a localized prefix) is a separate defect and is not
+  addressed here; it is tracked on objectstack#11993.
+- 6c1b105: `record:activity` now says out loud when an unrecognised `filterMode` is folded onto `all`.
+  
+  `normalizeFilterMode` folds every value it does not recognise onto `'all'` — the widest of the four declared modes — so a near-miss like `comments-only` opened the panel on the unfiltered stream instead of the slice the author asked for, and said nothing. The fallback is kept (a dropdown handed a value with no matching item renders blank), but the fold now emits one deduped diagnostic naming the offending value and the declared modes. Nothing that renders changes.
+- 17fbbaf: `record:activity` renders an author-extended `sys_activity.type` instead of dropping it
+  
+  **Behaviour change.** `activityRowToFeedItem` used to return `null` for any
+  `sys_activity.type` outside `ACTIVITY_TYPE_TO_FEED_TYPE`: the row was stored,
+  queryable and invisible, with only a console warning to say so. It now renders
+  through a defined fallback presentation (`UNMAPPED_ACTIVITY_FEED_TYPE`, the
+  generic `system` feed type), still announced once per distinct type.
+  
+  This follows the maintainer ruling of 2026-08-24 on objectstack#11507,
+  direction 4: `sys_activity.type` is **author-extensible**. Every field on
+  `sys_activity` is `readonly: true` and objectql's `validateRecord` skips
+  readonly fields on both write branches, and ADR-0052 §5b.2 forwards an author's
+  `activityMilestones[].type` into the column verbatim — so a value the platform
+  never declared is legitimate stored data, not a mistake, and dropping it
+  reproduces the objectui#5840 failure for every author who writes one.
+  
+  The types this map deliberately excludes (`commented` / `mentioned` / `login` /
+  `logout` → `undefined`) are unchanged: those are decisions, not gaps, and they
+  still return `null` silently. `ACTIVITY_TYPE_TO_FEED_TYPE` itself is unchanged,
+  so the copy `RecordDetailView` reads is unaffected.
+  
+  The pin that goes with it replaces the set-equality check objectui#5840 removed,
+  and is deliberately two-directional: the map must cover every **built-in** type
+  (superset — a new built-in turns it red), and an unknown type must reach the
+  feed through the fallback (never dropped, never crashing). Set equality is not
+  asserted in either spelling, and the docblock says so, because pinning to the
+  closed declaration is what made #5840 drop stored rows.
+- d8cf1cb: `record:activity` no longer discards scheduled activities. `sys_activity` rows with
+  `type: "scheduled"` now map to the `event` feed kind instead of being dropped before any
+  filter runs, so a not-yet-held meeting reaches the timeline and `types: ['event']` stops
+  being a permanently empty tab. Held meetings are unchanged: `completed` still maps to
+  `task` and still hides unless `showCompleted` is set, which is what keeps an upcoming
+  meeting visible by default while a finished one is not.
+  
+  The unknown-type default is unchanged and deliberately so — a row whose type nothing maps
+  is still dropped rather than bucketed into `system`, because rendering an unmeasured kind
+  as something it is not would be new wrong data rather than recovered data. What changes is
+  that the drop is no longer silent: an unmapped type now logs one `console.warn` naming it,
+  once per type. Types the map knows and deliberately excludes (`commented`, `mentioned`,
+  `login`, `logout`) stay silent, since those are decisions rather than gaps.
+- 0d1e702: `record:activity` no longer widens when its `types` filter cannot be honoured. An
+  unrecognised or empty kind list used to sanitise to `undefined`, which the filter
+  pipeline reads as "no filter authored" — so three distinct authored intents collapsed
+  into one rendering, and the widest one: a page that named the wrong kind was served
+  every activity on the record, with no diagnostic anywhere at runtime. The principle now
+  held is that a sanitiser may narrow an author's request or refuse it, but must never
+  silently widen it; widening turns a typo into "show the user everything", which is the
+  one outcome no author asked for, and it hides behind a plausible result — a populated
+  timeline reads as working, an empty one gets investigated.
+  
+  **Behaviour change.** A page authoring `types: []`, or a `types` list whose every entry
+  is unrecognised, now renders an EMPTY timeline where it previously rendered every kind.
+  That is the fix rather than a regression, but a page relying on the old fallback will
+  visibly change: `types: []` is honoured as "no kinds", and a list that keeps nothing
+  filters to nothing. A mixed list keeps its recognised entries and drops the rest. Omitting
+  `types` is unchanged and remains the only way to say "no filter". A `types` that is not a
+  list at all (`types: 'comment'` — brackets dropped) is likewise refused rather than
+  ignored, since a filter that cannot be read is not a request to remove the filter.
+  
+  Unrecognised entries are now named out loud: one `console.warn` listing them and the
+  declared feed item types, deduped so one bad kind warns once however many times the feed
+  re-renders, matching the unknown-activity-type diagnostic already in this file. A
+  well-formed filter stays silent, `types: []` included — there is nothing to report about
+  a request that was carried out exactly.
+- 0068348: `record:alert`'s renderer-local `RecordAlertProps` CTA slot (`action.label`) is
+  widened to `string | I18nLabel` in both copies (`properties.*` and the flat
+  compat mirror) in `packages/plugin-detail/src/renderers/record-alert.tsx`.
+  
+  The renderer already resolves `action.label` through the same inline-locale-map
+  `pickLocalized` call as `title` / `body` (`const ctaLabel =
+  pickLocalized(props.action?.label, language)`), so a bare `string` declaration
+  was narrower than the renderer's own runtime behavior — the same
+  declaration-narrower-than-the-renderer contradiction objectui#4970 fixed for
+  `title` / `body` one level up in the same interface (objectui#4998).
+  
+  Type-only: the block's published authoring surface still declares `action` as
+  a bare `object` with the member shape in prose only
+  (`plugin-detail/src/index.tsx`), so there is no manifest arm to align yet —
+  that half stays parked on the `ComponentInput` member-shape question (PR
+  #3795) and is out of scope here.
+- 641543f: `record:alert`'s `visible` predicate no longer logs a spurious `record is not
+  defined` evaluation-failure warning during the record-detail loading frame.
+  
+  The predicate is evaluated on every render (Rules of Hooks), including the
+  frame before `useRecordContext().data` has loaded. In that frame `record` is
+  unset, `usePredicateRecordContext` binds an empty context bag by design (no
+  `record` key at all), and a bare/`${…}` predicate referencing `record.*`
+  faulted with `record is not defined` — logged via `console.warn` on every
+  page load, even the correct, working ones, because the SAME predicate
+  resolved fine one frame later once `record` populated. The banner's own
+  visibility was never wrong (it already hides unconditionally while unloaded);
+  only the diagnostic was permanently misleading on the happy path.
+  
+  The predicate is now skipped while `record` hasn't loaded — the same
+  condition the banner's own "hide while unloaded" early return already used —
+  since its verdict in that frame was never consulted anyway. A predicate that
+  is genuinely broken (bad field, bad syntax) still faults, and still logs, on
+  every frame once `record` is populated (objectui#5776).
+- 6c6cee7: A RETIRED field-type spelling is now refused — out loud, once — by every
+  field-type predicate in the renderer, not just by the widget road
+  (objectui#4914, maintainer ruling B of 2026-08-18).
+  
+  `@object-ui/fields` exports a single `isRetiredFieldType(t)` gate, and it runs
+  ahead of six predicate faces that previously granted a retired spelling
+  first-class treatment: the filter builder's operator buckets and its value
+  control (`@object-ui/components`), the detail page's highlight-strip picker
+  (`@object-ui/plugin-detail`), `normalizeFieldType` (`@object-ui/plugin-view`),
+  the dashboard's `$expand` whitelist and `isLookupType`
+  (`@object-ui/plugin-dashboard`), and the list toolbar's lookup-like filter
+  control (`@object-ui/plugin-list`). Each one now fires the migration
+  prescription on the console — once per spelling across all of them, never once
+  per predicate — and then answers as it would for a spelling it does not
+  recognise.
+  
+  This closes the whole CLASS rather than one word: the gate is quantified over
+  `RETIRED_FIELD_TYPES`, so the next retirement covers all seven consumers on the
+  day it lands. It is the shape objectui#4932 and objectui#4942 already
+  established for the form and inline-edit roads.
+  
+  Measured before the change, and the reason the fix is a gate rather than a
+  deletion: `owner` was not dead in these faces. `operatorsForFieldType('owner')`
+  equalled the `user` bucket item for item, `computeLookupExpand` actively
+  requested `$expand` for it, `isLookupType('owner')` was `true` alongside
+  `reference`, and `normalizeFieldType('owner')` answered `'select'` exactly as
+  `picklist` does. Deleting the members alone would have traded a visible
+  contradiction for a SILENT degradation — a filter picker collapsing to a bare id
+  box, `$expand` quietly stopping so cells show raw foreign-key ids — which is
+  verbatim the failure mode `RETIRED_FIELD_TYPES`' own docblock exists to prevent.
+  The gate keeps that fallback and adds the half that was missing: the author is
+  told.
+  
+  The boundary question is answered on record: `owner` arriving through a
+  backend-vocabulary normalizer is an authoring error to refuse loudly, not
+  legitimate foreign input to tolerate. The open backend vocabulary those
+  normalizers exist for is untouched — `reference`, `picklist`, `money`, `int`,
+  `datetime_tz` and the rest are equally absent from the spec's closed `FieldType`
+  and are equally unretired, so they classify exactly as before.
+  
+  `RETIRED_FIELD_TYPES`, `reportRetiredFieldType` and `resetRetiredFieldTypeReports`
+  move to `@object-ui/core` and are re-exported from `@object-ui/fields`, so that
+  package's published surface is unchanged apart from the newly ruled gate.
+  `@object-ui/components` is a consumer of the gate and `@object-ui/fields`
+  depends on it, so a single shared table could not live in `fields` — and a
+  second copy would have meant a second dedupe set and two console lines for one
+  spelling. No package gained a new dependency.
+  
+  A retired spelling never loses a stored value: `retypeFilterValue` is
+  deliberately not gated, and the refused filter row stays operable rather than
+  drawing a blank operator trigger.
+- 42887e0: Repair five retired lucide icon spellings that reach a record-reading resolver, and pin
+  the names against the runtime `icons` record so the next lucide bump goes red instead of
+  silently blanking a glyph (objectui#5622).
+  
+  lucide retires a spelling by dropping it from its runtime `icons` record while KEEPING it
+  as a deprecated named export. A retired name therefore still imports, still type-checks,
+  and still renders wherever it is used as a COMPONENT — and resolves to `null` wherever it
+  is used as a STRING, because every string lookup here reads that record. Nothing goes red
+  either way. Measured against the installed `lucide-react@1.31.0` (1767 record entries) at
+  implementation time.
+  
+  What a user sees change:
+  
+  - `DetailView`'s mobile Edit action (`icon: 'edit'` → `'square-pen'`) draws its icon
+    again. Its items become an `action:bar` schema whose renderers resolve `icon` through
+    `renderers/action/resolve-icon.ts`, so the touch-breakpoint edit affordance had been
+    drawing a label with nothing beside it. `Edit === SquarePen`, so the glyph is unchanged.
+  - The `ui:icon` renderer's own declared default (`'smile'` → `'face-slightly-smiling'`, in
+    both the registration `icon` and the `name` input's `defaultValue`) resolves again: the
+    designer palette entry's glyph was blank, and an `icon` dropped from that palette
+    rendered nothing plus a `console.warn`. `Smile === FaceSlightlySmiling`, so the palette
+    looks exactly as it did.
+  - `plugin-list`'s `ViewSwitcher` moves `Grid` → `Grid3x3`, `BarChart3` → `ChartColumn`
+    (both identical objects, no visual change) and `GanttChartSquare` → `ChartGantt`. The
+    gantt one IS a glyph change: it matches the spelling the sibling `plugin-view` switcher
+    landed in objectui#5586, so one view type no longer draws two different icons depending
+    on which switcher is on screen.
+  
+  Four resolvability pins are added — in `plugin-detail`, `plugin-list`, `components` and
+  alongside the `DeclaredActionsBar` fixtures. Each asserts `icons`-record MEMBERSHIP rather
+  than resolvability, because every retired spelling repaired here is the SAME component
+  object as its replacement (`Edit === SquarePen`, `Smile === FaceSlightlySmiling`,
+  `Grid === Grid3x3`, `BarChart3 === ChartColumn`, `CheckCircle === CircleCheckBig`,
+  `XCircle === CircleX` are all true): a pin that rendered the glyph, or reached for the
+  export, would pass on the broken name. That is the blindness that let this ship.
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [8d3a529]
+- Updated dependencies [194fae1]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [b362c1b]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [3c9fca3]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [9a1fb41]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [a865c73]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [e4e9557]
+- Updated dependencies [7a28e1e]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [20e317c]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [4bb940b]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [f1690d4]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/fields@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+  - @object-ui/permissions@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/plugin-detail/package.json b/packages/plugin-detail/package.json
index 957a7d1cb2..1829a01755 100644
--- a/packages/plugin-detail/package.json
+++ b/packages/plugin-detail/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-detail",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "DetailView plugin for Object UI - comprehensive detail page with sections, tabs, and related lists",
diff --git a/packages/plugin-editor/CHANGELOG.md b/packages/plugin-editor/CHANGELOG.md
index 9aca54cdca..1b0123bb47 100644
--- a/packages/plugin-editor/CHANGELOG.md
+++ b/packages/plugin-editor/CHANGELOG.md
@@ -1,5 +1,156 @@
 # @object-ui/plugin-editor
 
+## 17.7.0
+
+### Patch Changes
+
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [194fae1]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/types@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Patch Changes
diff --git a/packages/plugin-editor/package.json b/packages/plugin-editor/package.json
index 0ac4c314ec..0015b4620c 100644
--- a/packages/plugin-editor/package.json
+++ b/packages/plugin-editor/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-editor",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Rich text editor plugin for Object UI, powered by Monaco Editor",
diff --git a/packages/plugin-form/CHANGELOG.md b/packages/plugin-form/CHANGELOG.md
index 8907c722cf..f2c409b8ed 100644
--- a/packages/plugin-form/CHANGELOG.md
+++ b/packages/plugin-form/CHANGELOG.md
@@ -1,5 +1,636 @@
 # @object-ui/plugin-form
 
+## 17.7.0
+
+### Minor Changes
+
+- 636b236: `navigateOnSuccess` is relative-only, escapes the interpolated id, and is deprecated in favour of `submitBehavior`
+  
+  The url contract for this key was undeclared: it was same-origin-guarded (so a same-origin
+  ABSOLUTE value was accepted), it interpolated `{id}` / `{recordId}` without escaping the
+  substituted value, and nothing said which of those was intended. The maintainer ruled it on
+  2026-08-17: `navigateOnSuccess` is the pre-ruling ancestor of the `submitBehavior` family
+  rather than a second dialect, so as a compat alias it runs under the semantics
+  objectstack#7496 ruled for that family.
+  
+  **Relative paths only.** A same-origin absolute such as `https://own-host/record/{id}` is
+  now refused like any other out-of-contract value, rather than accepted and navigated at
+  browser level. The destination is authored metadata, which is exactly where an address
+  somebody else chose gets copied in. Cross-origin and protocol-relative values were already
+  refused and still are; every relative shape that worked before still works.
+  
+  **The interpolated id is URL-escaped.** `/r/{id}` with an id of `a/b c` resolved to
+  `/r/a/b c`, silently growing a path segment, and a template of `{id}` let the id become the
+  whole destination. The substituted value now goes through `encodeURIComponent`, so a token
+  is a value in the path and never a way to add path structure. The template is the author's
+  and is untouched — only the id, which is data read off the written record, is escaped.
+  
+  Both halves are needed and neither implies the other: relative-only is a rule about where a
+  destination starts, so it cannot see structure injected further along; escaping runs only on
+  the substituted value, so it cannot see an absolute the author wrote out.
+  
+  This can only narrow what is reachable. Every destination the key now accepts is a relative
+  reference, and a relative reference cannot carry an authority, so it was already accepted by
+  the same-origin guard this replaces — no value that was refused is now followed. With every
+  accepted destination relative, the browser-level `window.location.assign` fallback at both
+  call sites became unreachable and was removed; an accepted destination goes to the injected
+  navigation seam, and the absent-seam fallback inside the shared hook is unchanged.
+  
+  **Deprecation.** `navigateOnSuccess` is marked `@deprecated` in favour of `submitBehavior`,
+  which already takes precedence over it and carries the richer `{{record.field_name}}`
+  interpolation. The `{id}` / `{recordId}` dialect keeps working for forms that already
+  declare it — the ruling converges the documentation and the semantics, not the spelling.
+- 5173a5e: ⚠️ **Behaviour change: `current_user` predicates that have been doing nothing on
+  the console form routes and in the wizard's submit gate now TAKE EFFECT.** Read
+  this before upgrading if any of your form metadata gates on the session user.
+  
+  objectui#6010 bound the host predicate scope on the five authored-predicate call
+  sites in the components form renderer, so `current_user` (plus the ADR-0068
+  `user` / `ctx.user` / `os.user` aliases) resolves on `visibleWhen` / `visibleOn`
+  there. Two other authored-predicate evaluators were still passing `undefined`
+  for that argument, so the same authored text meant two different things
+  depending on which surface opened the form (objectui#6110):
+  
+  - **`apps/console`'s form renderer**, on the authed internal route
+    `/forms/:name`. The internal route is a runtime record surface by ADR-0089
+    D1's own words (*"runtime record surfaces bind `record` + `current_user`"*),
+    and its `visibleWhen` metadata is the same `*.view.ts` FormView the
+    object-view chain renders — so a role gate authored once behaved differently
+    depending on which route opened the form.
+  - **`WizardForm`'s submit-time required re-check** (`missingRequiredByStep`),
+    the gate that re-checks the whole declared field set at final submit because
+    `allowSkip` can jump past a step. Its docstring promises *"the same verdict
+    from all three rather than a second, divergent dialect"*, and since #6010 it
+    was the divergent one.
+  
+  **Why nobody noticed, and why the fix is felt as a change.** `visibleWhen` fails
+  OPEN: a field on screen is what you get when the predicate resolves TRUE, when
+  the scope was never bound so the predicate faulted, *and* when the predicate is
+  broken. Those worlds were indistinguishable, so an app that authored a
+  `current_user` gate saw the field render and had no way to tell the rule was
+  inert. After this change the predicate is evaluated for real, and fields and
+  sections that have always been visible will disappear for the users the rule
+  excludes. `requiredWhen` fails the other way (CLOSED), so a `current_user`
+  requiredWhen that has been silently not applying will now start holding submits.
+  
+  In the wizard the change is a fix in the user's favour as well: a required field
+  the wizard HID from this user was still counted as visible by the submit gate,
+  so the submit was refused on a control the submitter could neither see nor fill
+  in.
+  
+  **Before upgrading**, audit any `visibleWhen` / `visibleOn` / `requiredWhen` in
+  your form-view and object metadata that names `current_user`, and confirm each
+  predicate says what you actually want evaluated against `record` +
+  `current_user`.
+  
+  **The public anonymous form `/f/:slug` is deliberately unchanged.** It is
+  mounted outside `ProtectedRoute` so an anonymous visitor can submit it, there is
+  no authenticated principal, and no provider is mounted above it — so its scope
+  is empty and a `current_user` predicate authored on a public form still faults
+  and still fails open, exactly as before. Nothing new is declared to say so: the
+  two routes are told apart by which component mounts them.
+  
+  `@object-ui/app-shell` exports `buildExpressionUser`, the `ExpressionProvider`
+  user normalisation, so every console surface that mounts the provider publishes
+  the same `current_user` shape rather than re-deriving it.
+- 971d387: ⚠️ **Behaviour change: an authored `FormSection.visibleWhen` that has been doing nothing
+  will now START HIDING SECTIONS.** Read this before upgrading if any of your metadata
+  authors a section predicate.
+  
+  `@objectstack/spec` declares `FormSection.visibleWhen` and this repo's spec bridge maps it
+  through, but every plugin-form layout renders a section header as a virtual
+  `section-divider` pseudo-field and none of them copied the predicate onto it. On the
+  object-view chain — the create/edit modal, the drawer, the split form, and the full-page
+  record form — the key was declared, mapped, carried, and then dropped one hop before
+  anything could evaluate it. The section rendered unconditionally, with no diagnostic
+  (objectui#6111).
+  
+  **Why nobody noticed, and why the fix is felt as a regression.** `visibleWhen` fails OPEN:
+  a section that renders is what you get when the predicate resolves TRUE, when the predicate
+  never arrives, *and* when the predicate faults. Those three worlds were indistinguishable,
+  so an app that authored a section predicate saw its section render and had no way to tell
+  that the rule was inert. Every such app has been running with the rule switched off, and
+  some will have been authored — or simply grown used to — that state. After this change the
+  predicate is evaluated for real, and sections that have always been visible will disappear
+  for the users the rule excludes.
+  
+  This is the intended ADR-0089 contract being delivered, not a new capability: the key was
+  already declared, already documented, and already honoured by the console form renderer.
+  The object-view chain was the one that silently ignored it.
+  
+  **Before upgrading**, audit any `sections[].visibleWhen` in your form-view metadata and
+  confirm each predicate says what you actually want, evaluated against `record` +
+  `current_user`. A predicate that was written speculatively, or left behind after a rework,
+  now takes effect.
+  
+  **Measured scope of the hide.** The predicate gates the section's HEADER row. The renderer
+  treats `section-divider` as presentational and holds no association between it and the
+  fields that follow it, so a false predicate removes the heading and the section's fields
+  keep rendering. The console renderer (`apps/console`) drops the whole `<section>`, fields
+  included. That divergence is real, is pinned honestly by this change's tests rather than
+  implied away, and is filed separately — it needs a renderer-side grouping contract, not
+  another line in a layout.
+  
+  Two hops were dropping the key and both are repaired: `ObjectForm` rebuilds each section
+  key by key when it delegates to Split/Drawer/Modal (and `ModalForm`'s own `groups` map does
+  it again), so a key those maps did not copy never reached the layout at all; and the six
+  `section-divider` synthesis sites across the four layout files.
+  
+  `@object-ui/types` gains the matching `ObjectFormSection.visibleWhen` declaration.
+- 3c9fca3: Create forms pre-fill the `current_user` defaultValue token with the acting user (#5683). `PermissionContextValue` gains `userId` (from `/me/permissions`; `null` = unknown), and the create-form seeding resolves `defaultValue: 'current_user'` on `user` / `lookup→sys_user` fields to that id — the same value the engine stamps at insert, so the pre-fill is a preview of the server's own resolution, not a second default contract. Unknown user (no provider / anonymous / role-based provider) seeds nothing and keeps the omit-and-let-the-engine-resolve behavior. `NOW()` and CEL defaults stay server-owned.
+- ebce5a3: `object-grid` / `object-form` / `detail-view` resolve their data source the same way, and a block that resolves none says so
+  
+  The three object-bound blocks disagreed about how the data-source adapter reached
+  them. `object-grid` and `object-form` were registered through wrappers that read
+  it from `SchemaRendererProvider` context; `detail-view` was registered as the raw
+  component, which reads a React `dataSource` prop. `SchemaRenderer` itself reads
+  only context, so the two wirings were mutually exclusive: measured with correct
+  keys in every cell, provider wiring gave the grid `find` 1 and the detail view
+  `findOne` 0, and prop wiring gave exactly the reverse. Neither reported anything.
+  
+  All three now resolve the adapter through one rule — an explicit `dataSource`
+  prop first, the provider context second. This is additive: `detail-view` keeps
+  its prop form (and direct `<DetailView dataSource={…} />` callers are untouched),
+  `object-form` gains a prop form it did not have, and `object-grid` no longer
+  throws `useSchemaContext must be used within a SchemaRendererProvider` when a
+  page has no provider.
+  
+  And the silence is over. A block in this family that resolves no adapter renders
+  a **No data source resolved** panel naming the block, the object it was about to
+  read, and the ancestor that injects the adapter — instead of a header-only grid,
+  a field-less form card, or nothing at all. The check is opt-in per block, so a
+  placement with inline rows, inline `customFields`, an inline record or an `api`
+  endpoint is untouched.
+  
+  New from `@object-ui/react`: `useResolvedDataSource`, `NoDataSourcePanel`,
+  `noDataSourceMessage`, and a `requiresDataSource` prop on `ElementDataSourceGate`.
+
+### Patch Changes
+
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- 3e853c9: Let a producer-marked refusal reach the drag-write surfaces (objectui#5902).
+  
+  The kanban card-move toast, the calendar drag-to-reschedule toast and the OCC
+  conflict dialog each substituted a generic string for a refusal the producer had
+  marked as user-facing (`userMessage`), so a user was told "Save failed" where the
+  application author had written a sentence addressed to them. All three now read
+  the marking through the shared `declaredUserMessage` reader, which covers both
+  places the adapter boundary parks it — the typed member on
+  `ConcurrentUpdateError` and the details bag on `DataApiValidationError`.
+  
+  Nothing unmarked changes: the reader answers `null` for it, so every existing
+  generic substitution — including the localized "not authorized" message that
+  keeps raw server diagnostics away from end users — still governs unmarked
+  refusals exactly as before.
+  
+  The two toasts substitute; the conflict dialog augments. Its description also
+  explains what the destructive "Overwrite" button does, which is affordance copy
+  that surface owns rather than a refusal message, so the marking leads and that
+  paragraph stays.
+- 17ccec9: `object-master-detail-form` declines to fetch a detail collection whose child object it never resolved, instead of calling `getObjectSchema(undefined)`.
+  
+  `childObject` is REQUIRED on `MasterDetailDetailConfig` and is what every downstream read is keyed
+  on — `deriveDetail(d.childObject, …)`, the child-schema cache, and the FK scope of each child
+  fetch. But a detail entry reaches the renderer straight off an authored schema, so a malformed one
+  arrives with the key `undefined`, and the resolve effect asked the data layer for it anyway.
+  Measured: mounting the block with a detail entry that carries no `childObject` issued
+  `getObjectSchema(undefined)` — a real backend receives a query for an object literally named
+  `undefined`, and whatever it returns becomes the console's problem.
+  
+  The resolve effect now skips such an entry and warns, leaving it in place so the grid card shows
+  its config hint and the row-state array stays index-matched. This is the choice `RelatedList`
+  already makes for the same class of missing key (*"has no referenceField/parentId — refusing to
+  fetch all rows"*), and the sibling child-schema-cache effect in this same component already spelled
+  it `.filter(Boolean)`; the three now agree. A detail collection that names its child object fetches
+  exactly as before.
+- c9a7252: `record:line_items` declines to fetch the child schema of a panel whose child object it never resolved, instead of calling `getObjectSchema(undefined)`.
+  
+  `childObject` is declared `required: true` on the block's registry entry and typed `string` on
+  `LineItemsPanelSchema`, but nothing enforces either — `inputs[].required` is designer metadata, and
+  the block has no spec schema — so a node reaches the renderer straight off an authored schema with
+  the key `undefined`, and the child-schema effect asked the data layer for it anyway. Measured:
+  mounting the block through the registry with `childObject` unset issued
+  `getObjectSchema(undefined)`, and a real backend receives a query for an object literally named
+  `undefined`. The effect's `.catch` then turned the answer into a null child schema, so the visible
+  outcome was a silently unsanitized child grid rather than an error.
+  
+  The effect now declines and warns, naming the key and what to set it to, and clears the cached child
+  schema so a later save is never sanitized against a previous object's fields. This is the choice
+  `RelatedList` already makes for the same class of missing key (*"has no referenceField/parentId —
+  refusing to fetch all rows"*), and the one `object-master-detail-form` makes on this exact key. A
+  panel that names its child object fetches exactly as before.
+- 5f19b92: `record:line_items` declines to LOAD OR WRITE the rows of a panel whose child object it never resolved, instead of calling `find(undefined, …)` — the sibling site of the child-schema decline, in the same component.
+  
+  `LineItemsPanel` read `schema.childObject` at two sites. The first now declines; the row load still
+  asked the data layer to `find` an object literally named `undefined`, scoped by
+  `{ [relationshipField]: parentId }`. `load` guarded the *data source* and the *parent id* — the two
+  things `RelatedList` calls "can I scope this query" — but not the *object being queried*.
+  
+  Declining that fetch is not enough on its own, and this is the part worth reading: `load` owns
+  `loading`, and the panel branched `loading ? "Loading…" : !parentId ? "Save the record first…" :
+  <grid>`. So the moment the fetch declined, an unresolvable panel with a parent id bound fell to the
+  third branch and showed an **empty editable grid with an Add button, over an object that does not
+  exist** — a worse outcome than the fetch it replaced. Measured on the pre-fix component: one
+  keystroke in the grid's always-present ghost row materialised a row, which enabled Save, which
+  reached `batchTransaction([{ object: undefined, action: 'create', data: { qty: 3, invoice: 'inv-1' } }])`.
+  The bad *read* was one keystroke away from a bad *write*.
+  
+  An unresolvable panel therefore gets its own render branch — a config hint naming `childObject` and
+  what to set it to, following the precedent `object-master-detail-form` set for this exact key and
+  `AdvancedChartImpl`'s refusal placeholders. It is checked ahead of `loading`, because nothing is
+  pending: the schema itself already says the panel can never resolve, so there is no honest moment at
+  which "Loading…" is true. `save` takes the same one-line guard, for the one route the render branch
+  cannot close — a schema edited to drop `childObject` while rows are already dirty.
+  
+  A panel that names its child object loads, renders and saves exactly as before.
+- 1c19722: `object-master-detail-form` now renders a config hint naming `childObject` for a detail
+  collection whose child object never resolved, instead of `Loading columns…` forever
+  (objectui#6360).
+  
+  `MasterDetailForm` already declines to fetch the schema of such a detail (objectui#5940)
+  and returns the entry unresolved, which is correct — asking the data layer for an object
+  literally named `undefined` is what that guard removed. But the decline is precisely the
+  guarantee that the entry's columns can never arrive, and the render branch it fell into
+  read `!d.columns?.length ? <p>Loading columns…</p>`. The author was shown a
+  spinner-shaped message that was permanently, unfixably wrong, and that never named the
+  key they had to set.
+  
+  The `!d.childObject` case now takes its own branch, checked **before** the columns arm
+  because nothing is pending — there is no first paint where "loading" is honest. The copy
+  and structure are `LineItemsPanel`'s, which took the same branch for the same key in
+  objectui#6194 / PR #6359; the two components had been disagreeing about what an author
+  sees for the identical authoring mistake, and the weaker of the two was the one that read
+  as the precedent. The hint carries its own `data-testid` (`md-detail-no-child-object`).
+  
+  Two source comments — at the decline itself and at the resolver's `catch` — asserted that
+  "the grid card shows a config hint". They were false, and following them cost a reader a
+  run of the component. The first is now true and says so. The second is **corrected rather
+  than made true**: a detail whose schema fetch *threw* does name a child object, so it
+  skips the new branch and still lands on `Loading columns…`. Distinguishing that from
+  "still in flight" needs per-entry error state the resolver does not keep, so it is filed
+  as objectui#6372 and the comment now points at it instead of promising a hint that is not
+  rendered there.
+  
+  No spec or schema change: `childObject` is already REQUIRED on `MasterDetailDetailConfig`.
+  This is renderer-side reporting of an authoring error that the type system cannot catch,
+  because a detail entry reaches this renderer straight off an authored JSON schema.
+- faa863d: `MasterDetailForm` gives every detail collection a per-entry record carrying its own
+  identity and its own resolution status, closing two defects that both came from the same
+  absence (objectui#6372, objectui#6371).
+  
+  `resolvedDetails` was a plain `MasterDetailDetailConfig[]` with no per-entry metadata, so
+  both *what happened to this entry* and *which entry is this* were inferred from the
+  entry's position in the array. One record answers both, which is why they land together —
+  either one alone would have reshaped this structure and the second would then have
+  rewritten the first.
+  
+  **objectui#6372 — a detail whose schema fetch threw sat on "Loading columns…" forever.**
+  The resolver's `catch` returned the entry unchanged, and an entry with no `columns` is how
+  *still in flight* is represented too, so the two states were indistinguishable and the
+  render branch showed the same spinner-shaped message for both. For the failed one it never
+  ended: the fetch is not retried, so nothing could ever replace it. Entries now carry a
+  resolution status, and a failed one renders a refusal placeholder naming the child object
+  whose schema could not be loaded (shaped on `AdvancedChartImpl`'s refusal placeholders —
+  `role="status"`, because a refusal is a state, not an alert). Measured before the fix
+  rather than read from source: a detail whose `getObjectSchema` rejects rendered
+  `<p>Loading columns…</p>`.
+  
+  The thrown error is no longer discarded. The bare `catch` threw away the whole diagnosis,
+  so whoever debugged this had neither a message nor a stack; the decline arm next to it has
+  warned since objectui#5940, and this arm now matches it and passes the error object
+  through.
+  
+  ⭐ The fetch and the derive are caught **separately**, because they are different failures
+  with different truths to tell. A schema that loads fine and then yields no relationship
+  field is a configuration error, and calling it a load failure would be false. That arm's
+  render is deliberately unchanged; only its error stops being swallowed.
+  
+  **objectui#6371 — a declined entry had no identity across a reorder.** There was no
+  duplicate-key collision: the map index is unique among siblings by construction, so two
+  declined details keyed as `undefined-0` and `undefined-1`, distinct. The real defect is
+  that for a declined entry the data half of that key is `undefined`, leaving position as
+  the entry's whole identity — and the row-state store was addressed the same way, seeded
+  once at mount and never re-synced when the authored config changed. Reordering or removing
+  an entry therefore handed a collection a different collection's rows.
+  
+  Entries now carry an id synthesized once from the incoming config: the child object for a
+  named collection, and the authored position for a declined one, which has no other
+  identity to offer. Row state is keyed by that id, so a collection can only ever read its
+  own slot. Three reads were affected, not the one the report named:
+  
+  - the grid value, which showed the wrong collection's rows;
+  - the document **subtotal** reducer, so a reorder did not merely mis-associate a grid, it
+    mis-computed the total;
+  - the batch payload on save, which read
+    `details.filter(d => d.relationshipField).map((d, i) => state[i])` — after the filter `i`
+    indexed the filtered array while the row state was indexed against the full one, so a
+    declined entry above a real collection shifted every read below it by one and that
+    collection's rows were **silently dropped from the transaction**. Data loss on save, not
+    a display defect.
+- fd814d6: `MasterDetailForm` shows a config hint naming `relationshipField` for a detail collection
+  whose child schema **loaded fine but could not be derived from**, instead of a permanent
+  `Loading columns…` (objectui#6394).
+  
+  This is the third and last arm of the same resolver to be closed. `deriveDetail` throws
+  when no lookup/`master_detail` field on the child object references the parent — a
+  configuration error whose remedy is a key the author writes. The `catch` returned the
+  entry unresolved, so it fell through to `!d.columns?.length ? <p>Loading columns…</p>`,
+  and that message never ended: the derive is not retried, so those columns could never
+  arrive. Same unbounded-wait-shown-as-a-spinner family as objectui#5940 / objectui#6188 /
+  objectui#6194 / objectui#6360 / objectui#6372.
+  
+  The entry now carries `status: 'underivable'`, and the renderer gives it a branch of its
+  own that names both ends of the relationship it could not find and the key to set:
+  
+  > Could not work out how `po_line` links to `purchase_order`: no lookup or master_detail
+  > field on it references the parent. Set `relationshipField` on this collection to the
+  > field that holds the parent record.
+  
+  ⛔ Deliberately **not** objectui#6372's refusal placeholder, which states the schema could
+  not be loaded — false for a schema that loaded fine. The two failures keep separate copy
+  because they have different remedies: one is "check the object exists and reload", this one
+  is "set this key". The thrown error is still logged with its stack (objectui#6372), since
+  the placeholder shows the author the key rather than the raw message.
+  
+  Behaviour is unchanged for the other two arms and for a detail that is genuinely still
+  fetching — that one keeps `Loading columns…`, where the message is true.
+- 425762e: `object-master-detail-form` declares `formType` as a closed vocabulary instead of a bare `string`.
+  
+  The block declared `formType` as `type: 'string'` while the sibling `object-form` declared the
+  same key as an `enum`, and both funnel into the renderer that switches on those variant names. A
+  value outside the vocabulary therefore matched no branch and fell through to the flat field list
+  with no diagnostic — measured, a `formType` of `'wizzard'` renders the parent half with its
+  authored sections silently gone.
+  
+  The declared set is `simple | tabbed`, measured against the master-detail composition rather than
+  copied from the sibling's six: `drawer` and `modal` host the parent half in a portal dialog outside
+  the master-detail container, so its single bottom Save bar has no form to submit; `wizard` mounts
+  only the current step's fields and turns that Save bar into a `Next`; `split` renders inline but
+  persists through `dataSource.create` instead of the atomic batch.
+  
+  Authoring-surface only. The manifest, the JSX-page compiler and the save gate now report an
+  out-of-vocabulary value as `invalid-enum`; rejection at publish time remains `@objectstack/spec`'s.
+- 83ec618: `README.md`'s "Not a `FormField` key" table said a field-level `className` is
+  "read on exactly one pseudo-field, `type: 'section-divider'`". That quantifier
+  holds only for the renderer's *explicit* read — `className={fp.className}` on
+  the `section-divider` branch of
+  `packages/components/src/renderers/form/form.tsx`. The same renderer forwards
+  every key it did not destructure, and `className` is not among the names taken
+  off the field config, not among the ones `stripRendererOnlyProps` removes, and
+  so rides `{...fieldProps}` into `renderFieldComponent`, whose built-in `input`
+  branch spreads it onto `<Input>`. A field-level `className` therefore lands
+  visibly on ordinary built-in controls, and a reader taking "exactly one"
+  literally concludes the opposite of what the code does (objectui#5131).
+  
+  The cell now describes the contract rather than the reader count: an undeclared
+  key still rides the props spread down to whichever component the field resolves
+  to, nothing in the contract promises that, and a registered widget honours it
+  only if it happens to spread its leftover props — the wording the docs site
+  already ships, so the two sources agree again. The advice in the row is
+  unchanged and was never wrong (`span` / `colSpan` for width,
+  `FormSchema.fieldContainerClass` for the grid), and the explicit
+  `section-divider` read is kept, now named as explicit.
+  
+  This is a documentation fix to a file `plugin-form` publishes to npm, which is
+  why it carries a version: the npm landing page only picks up the correction on a
+  release. No behaviour, export, type, or `dist` byte changes.
+- 43ca9d5: `SimpleObjectForm`: consult a declared `submitHandler` before the inline-fields carve-out
+  
+  `ObjectFormSchema.submitHandler` is documented as handing the collected values to the host INSTEAD of calling `dataSource.create` / `dataSource.update`, so a form that declares it has a submit target with or without an adapter. `SimpleObjectForm.handleSubmit` nevertheless opened with the inline-fields carve-out (`hasInlineFields && !dataSource`), which returned before the persistence chain: a host that had declared it owns the write was never asked, and `onSuccess` confirmed a write that never happened (measured `onSuccess 1 / submitHandler 0`).
+  
+  The carve-out now fires only when no `submitHandler` is declared, and the "no submit target" refusal moved into the persistence chain after the seam — the shape the five variant renderers already use, reusing their shared refusal from `submitTarget.ts` rather than a private copy. A form with inline fields and no seam is unchanged: its `onSuccess` is still the write.
+- ba306e3: Honour the declared `submitHandler` seam in every form variant, not just the simple one.
+  
+  `ObjectFormSchema.submitHandler` is documented as the seam a host uses to own persistence: the form validates and hands the collected values over instead of calling `dataSource.create` / `dataSource.update`. `ObjectForm` forwarded the key into every variant it routes to, but only `SimpleObjectForm` read it — `TabbedForm`, `WizardForm`, `SplitForm`, `DrawerForm` and `ModalForm` persisted directly.
+  
+  **Behaviour change on a persistence path.** A master-detail parent half rendered `tabbed` (or `split`) now commits through the atomic `batchTransaction` together with its child collections, instead of writing the parent independently through `dataSource.create`. Previously the child leg was never attempted on those layouts: the parent was committed alone, the entered line items were silently discarded, no compensation ran, and a success toast confirmed the save. A failing child leg now leaves no committed parent, on every layout that renders the parent half inline.
+  
+  `WizardForm` additionally skips its own default success toast / redirect arms when a `submitHandler` is present, matching `ObjectForm`, so a host that owns the write also owns the outcome.
+  
+  The `object-master-detail-form.formType` vocabulary is unchanged and stays `simple | tabbed`.
+- 26a2238: `navigateOnSuccess` now honours a mounted host, and says so when its destination is refused
+  
+  `ObjectForm` and `WizardForm` consume `navigateOnSuccess` through
+  `resolveSuccessNavigate`, and both arms travelled to an accepted destination with a bare
+  `window.location.assign`. A rooted path such as `/apps/x/o/record/{id}` assigned that way
+  resolves against the ORIGIN root, so under a host mounted at a sub-path (the framework CLI
+  configures one for every embedded deployment) an authored in-app destination left the
+  application. Both arms now route an app-relative destination through the injected
+  navigation seam both components already held for `submitBehavior.url`, so a mounted host's
+  basename is applied. With no host seam the behaviour is byte-for-byte what it was — a host
+  with no router has no basename, so origin-rooted resolution is already correct there. A
+  same-origin ABSOLUTE destination also keeps browser-level navigation: the seam's declared
+  input is an application-relative path, and an author who spelled out a whole address asked
+  for that address.
+  
+  A declared `navigateOnSuccess` whose destination is refused — a mistyped value, or a written
+  record carrying no usable id — used to produce a success toast identical to the one a form
+  with no `navigateOnSuccess` produces, so the navigation failed with nobody told. That toast
+  now carries a note that the declared navigation did not happen, and the template the author
+  wrote is logged for them. The write genuinely succeeded, so this stays a success rather than
+  becoming an error state.
+  
+  Which destinations are ACCEPTED is unchanged: the same-origin guard, the `{id}` /
+  `{recordId}` dialect and the unescaped interpolation are the subject of an open contract
+  question and are deliberately untouched here.
+- 5d79faf: Variant forms refuse a submit that has nowhere to go, instead of reporting success
+  
+  `TabbedForm`, `WizardForm`, `SplitForm`, `DrawerForm` and `ModalForm` each opened
+  `handleSubmit` with `if (!dataSource) { await schema.onSuccess?.(data); return data; }`
+  — a success signal emitted without consulting a declared `submitHandler` and without
+  persisting anything. Through `MasterDetailForm`, whose parent schema declares both
+  `submitHandler: submitViaBatch` and `onSuccess: handleSaved`, that produced a success
+  toast and, in create mode, a form reset clearing values nobody wrote.
+  
+  All five now answer the question the same way `SimpleObjectForm` and the `object-form`
+  element gate already do. A form has a submit target when it has a `dataSource` or a
+  declared `submitHandler`; with neither, the one legitimate shape is inline fields —
+  a non-empty `customFields`, or `sections` whose fields are all inline runtime
+  `FormField` objects — whose `onSuccess` is the write. Anything else throws
+  `DataSource is required for form submission (inline mode not configured)`, which
+  reaches `schema.onError` and is rethrown. A declared `submitHandler` is consulted
+  first, so a host that owns the write is never bypassed for want of an adapter it
+  never needed.
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [8d3a529]
+- Updated dependencies [194fae1]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [b362c1b]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [3c9fca3]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [9a1fb41]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [a865c73]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [e4e9557]
+- Updated dependencies [7a28e1e]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [20e317c]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [4bb940b]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [f1690d4]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/fields@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+  - @object-ui/permissions@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/plugin-form/package.json b/packages/plugin-form/package.json
index c27f526da0..c028796385 100644
--- a/packages/plugin-form/package.json
+++ b/packages/plugin-form/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-form",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Form plugin for Object UI",
diff --git a/packages/plugin-gantt/CHANGELOG.md b/packages/plugin-gantt/CHANGELOG.md
index 88b03a3154..70ed3abdd9 100644
--- a/packages/plugin-gantt/CHANGELOG.md
+++ b/packages/plugin-gantt/CHANGELOG.md
@@ -1,5 +1,438 @@
 # @object-ui/plugin-gantt
 
+## 17.7.0
+
+### Minor Changes
+
+- 00f3eb5: `ObjectGanttSchema` declares the ten gantt keys `ObjectGantt` actually reads
+  (objectui#5903, triage 2026-08-24). Every one is a real, working, documented
+  feature — `readOnly`, `mobileReadOnly`, `markers`, `navigation`, `skipWeekends`,
+  `holidays`, `criticalPath`, `showBaselines`, `persistLayout`, `viewName` — and
+  none of them was discoverable from the published type, because all ten were read
+  as `(schema as any).K`. The cast was the load-bearing part: it kept the read
+  invisible to `tsc`, to the zod mirror and to the designer's registry `inputs`.
+  
+  Both halves move together. The TS declaration (`packages/types/src/objectql.ts`)
+  and its zod mirror (`src/zod/objectql.zod.ts`) gain the same ten keys at the same
+  requiredness — all optional — so the `zod-mirror-parity` ratchet stays at zero
+  drift for this pair and no `KnownDrift` entry is added. `navigation` is taken
+  from `@objectstack/spec`'s `NavigationConfigSchema` by reference rather than
+  restated, matching `ObjectGridSchema.navigation`.
+  
+  `ObjectGanttProps.schema` is retyped from `ObjectGridSchema` to
+  `ObjectGanttSchema`. That is what makes the declaration load-bearing: the ten
+  keys are not grid keys, so with the old prop type, dropping the casts would have
+  left the reads landing on `BaseSchema`'s index signature — the same invisibility
+  in different syntax. The grid-style `{ gantt: { … } }` block is unaffected;
+  `getGanttConfig` reads it through that index signature exactly as before, and the
+  registered renderer passes `schema: any`, so no runtime shape is turned away.
+  
+  Accept-set change, stated plainly: a **declared** key is now type-validated, so
+  `readOnly: 'yes'` is refused where it used to parse green — the same narrowing
+  objectui#5074 landed for `viewMode`. An **undeclared** key is still accepted:
+  `BaseSchema` is `.passthrough()` and carries an index signature (objectui#5155's
+  structural ceiling), so declaring these ten did not buy rejection of a
+  misspelling. `packages/types/src/__tests__/gantt-declared-keys.test.ts` pins both
+  halves so neither can be misread.
+  
+  The eleventh reported key, `label`, needed no declaration — `BaseSchema` already
+  carries it — so only its cast was dropped.
+- 75bd83d: `ObjectGanttSchema` declares the flattened `GanttConfig` face `ObjectGantt`
+  actually reads (objectui#6051). `getGanttConfig` has two branches: when
+  `startDateField` and `endDateField` are both present at the TOP level it builds
+  its config from top-level keys and returns early; otherwise it reads the `gantt`
+  block. Everything the first branch reads was undeclared — and unlike
+  objectui#5903's ten, none of it was hidden behind a cast. `BaseSchema` carries
+  `[key: string]: any` (objectui#5155's structural ceiling) and the helper's
+  parameter was `ObjectGridSchema | any`, so `schema.colorField` type-checked as
+  `any` with no syntax anywhere to grep for. That is also why the census here is an
+  AST enumeration and not a compile-and-observe: an index signature absorbs every
+  literal name, so annotating the parameter compiles clean while enforcing nothing.
+  
+  **27 keys join the declared surface, each additive and each with a live read
+  site.** 24 flattened `GanttConfig` members — `colorField`, `borderColorField`,
+  `dependenciesField`, `parentField`, `typeField`, `lockField`, `objectField`,
+  `summaryExtent`, `defaultCollapsedDepth`, `tooltipFields`, `baselineStartField`,
+  `baselineEndField`, `groupByField`, `resourceView`, `assigneeField`,
+  `effortField`, `capacity`, `quickFilters`, `autoZoomToFilter`, `timeSegments`,
+  `interactions`, `exportFileName`, `timeZone`, `dependencyTypes` — plus the three
+  query keys the fetch path reads, `staticData`, `filter` and `sort`. Nothing is
+  declared that the renderer does not consume.
+  
+  **`GanttConfig` itself gains nine members and is a published type**, exported by
+  name from `packages/types/src/index.ts`: `lockField`, `objectField`,
+  `summaryExtent`, `defaultCollapsedDepth`, `borderColorField`, `dependencyTypes`,
+  `timeZone`, `exportFileName`, `interactions`. The entry file's diff is empty only
+  because the export list already named the type — the widening happened at the
+  declaration.
+  
+  **The 28th measured key, `gantt` (the block face), is deliberately NOT declared**
+  — see the closing section.
+  
+  The 24 are DERIVED from `GanttConfig` rather than restated, so the flat spelling
+  cannot fork from the block spelling, and the invariant is pinned in the type
+  system: every key of `GanttConfig` must be declared at the node's top level.
+  Making that derivation possible moved nine members — `lockField`, `objectField`,
+  `summaryExtent`, `defaultCollapsedDepth`, `borderColorField`, `dependencyTypes`,
+  `timeZone`, `exportFileName`, `interactions` — out of `plugin-gantt`'s
+  package-private `GanttConfigEx` and into `@object-ui/types`' `GanttConfig`. They
+  are a MOVE, not new vocabulary: the `gantt` block already honoured all nine, and
+  a type private to the plugin could be referenced by neither authoring face.
+  
+  Both halves move together, as in objectui#5903: the TS declaration and its zod
+  mirror gain the same 27 keys at the same requiredness (all optional), the
+  spec-modelled ones taken from `GanttConfigSchema.shape` by reference, so the
+  `zod-mirror-parity` ratchet stays at zero drift for this pair and no `KnownDrift`
+  or `UnmirroredDeclared` entry is added. The mirror builds the flat face and the
+  `gantt` block from one field map, so they are one schema expressed twice.
+  
+  Accept-set change, stated plainly. All 27 keys are additive — every one is
+  optional, and nothing previously legal loses its slot. What changes is that a
+  **declared** key is now type-validated, so `capacity: 'one'` and
+  `summaryExtent: 'parent'` are refused where they used to parse green. An
+  **undeclared** key is still accepted — `BaseSchema` is `.passthrough()`, so this
+  bought no rejection of misspellings. There is no narrowing anywhere in this
+  change.
+  
+  **`gantt` is severed on purpose (objectui#6475), not overlooked.** It is the 28th
+  key of the measured residue and a genuine read — `getGanttConfig`'s second branch
+  honours it in full — but it is the one key whose declaration would NOT have been
+  additive. It has no mirror entry today, so a block rides through `.passthrough()`
+  unvalidated; declaring it as `GanttConfig` means it gets parsed against the spec's
+  `GanttConfigSchema`, which REQUIRES `startDateField`, `endDateField` and
+  `titleField`, and `ObjectGanttSchema` reaches the CLI's `validate` / `check`
+  through `AnyComponentSchema`. A published CLI's refusal behaviour is decided on
+  its own card, where reviewers can see what they are approving; objectui#6475
+  carries the full measurement, including the case FOR enforcing it (the renderer
+  already feeds that block to `GanttConfigSchema.safeParse` and warns, so enforcing
+  restores declared = enforced rather than inventing a contract). Today's behaviour
+  is pinned in the test file so the omission is a measured state, not a silent gap.
+  `packages/types/src/__tests__/gantt-flat-config-declared-keys.test.ts` pins both
+  halves so neither can be misread.
+  
+  Which face WINS is unchanged and was not decided here: the flat branch is checked
+  first and returns early, so a node carrying both spellings still renders the flat
+  one. (`plugin-map` had the opposite precedence ruled on in objectui#5018; no
+  equivalent ruling exists for gantt.)
+- d7acad6: **plugin-gantt: the `gantt` block now outranks the flat top-level spelling, and
+  the losing face's keys are named instead of dropped.**
+  
+  `getGanttConfig` checked the flattened top-level spelling first and returned
+  early, so a node carrying both spellings rendered the flat one and every key
+  inside an authored `gantt` block was discarded with **no diagnostic** — not even
+  the `GanttConfigSchema.safeParse` warning, which sat behind that early return.
+  
+  `plugin-map` had the identical two-faces shape ruled the other way (maintainer
+  ruling on objectui#5018, 2026-08-17, landed in PR #5156): the block wins, with a
+  dev-mode warning naming the ignored top-level keys. objectui#6469 inherits that
+  ruling, so the two sibling view plugins now answer the same question the same
+  way.
+  
+  What changes:
+  
+  - A node carrying **both** spellings now renders the **`gantt` block's** values.
+    The block is taken **whole** — the flat keys are not merged into it.
+  - In dev, `[ObjectGantt] … these top-level keys are IGNORED: …` names every
+    shadowed flat key, once per distinct shadowing.
+  - Nothing else moves. A node with only the flat spelling, or only a block, is
+    read exactly as before.
+  
+  **Producer-safe:** `ObjectView` (`case 'gantt'`) and `ListView` (`case 'gantt'`)
+  both flatten `options.gantt` onto top-level keys and emit **no** `gantt` key, so
+  every gantt reached through either view layer still takes the flat branch, and
+  the new warning cannot fire on that path. This is the same producer check the
+  `plugin-map` flip pinned, re-run on today's `main`.
+  
+  This **supersedes** the precedence sentence in the objectui#6051 changeset
+  (`.changeset/6051-gantt-flat-config-declared-keys.md`), which recorded the flat
+  branch winning — accurate for that change, which deliberately did not touch
+  precedence, and reversed by this one.
+- 199d31b: **`viewMode` is now declared authoring surface on `ObjectGanttSchema`, and both
+  gantt renderer branches honour it** (objectui#5074, maintainer ruling
+  2026-08-19: declare-and-wire; the spec half landed first upstream).
+  
+  - `ObjectGanttSchema` (TS interface and zod mirror) declares `viewMode`,
+    DERIVED from the pinned `@objectstack/spec` `GanttConfigSchema.viewMode`
+    enum by reference, so the member list cannot drift. Deliberately no
+    default: an omitted `viewMode` keeps letting a persisted layout
+    (`persistLayoutKey`) seed the timeline granularity before the renderer's
+    `'day'` fallback.
+  - The timeline branch (`GanttView`) now receives an authored `viewMode`.
+    Previously only the resource-workload branch (`resourceView` +
+    `assigneeField`) honoured it, so `viewMode: 'month'` on an ordinary gantt
+    view was silently ignored.
+  - The `(schema as any).viewMode` cast in `ObjectGantt` is retired; both
+    branches read the declared `ganttConfig.viewMode`, which also honours the
+    key when authored inside the spec's `gantt` config block.
+  - Accept-set note: `viewMode` is now a DECLARED key, so an off-enum value
+    (e.g. `viewMode: 'hour'`) becomes a zod validation error where it
+    previously passed through unvalidated. Values on the published spec enum
+    are unaffected.
+
+### Patch Changes
+
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- 9b61cf1: The package README stops documenting a `navigation` key the spec refuses, and the corrected example is now parsed by the schema that validates it.
+  
+  `README.md`'s record-navigation override read
+  `{ mode: 'page', basePath: '/console/apps/.../campaign' }`. `basePath` is not a
+  member of the spec's `NavigationConfig`, and nothing consumes it:
+  `useNavigationOverlay` — where a gantt's `navigation` lands — builds no URL out
+  of the config, and `ObjectGantt` calls the hook with no `onNavigate`, so a
+  page-mode click falls through to the host's `onRowClick`. The destination route
+  is owned by the host and was never authorable through this key, under any
+  spelling.
+  
+  That made the snippet worse than inert. `NavigationConfigSchema` is a strict
+  object with no passthrough, so the undeclared key did not fall away quietly — it
+  rejected the **whole** config with `unrecognized_keys`, taking down the
+  `mode: 'page'` the sentence was actually teaching. An author who copied the
+  documented snippet got a rejected navigation config and no page navigation, which
+  is the copy-the-snippet-get-rejected shape objectui#5057 / #5012 named on other
+  keys.
+  
+  The example is corrected to `{ "navigation": { "mode": "page" } }` — the shape
+  the sentence demonstrates — and the prose now says who owns the destination route
+  and points at `@objectstack/spec`'s `NavigationConfigSchema` for the member list
+  instead of restating it, matching the derivation `ObjectGanttSchema.navigation`'s
+  doc comment (objectui#5903) adopted for the same concept.
+  
+  `view` is **not** substituted for `basePath`. It is a declared member, but it
+  names a form view (the spec: *"Name of the form view to use for details"*) and is
+  forwarded to `onNavigate` as the action argument — it is not a route, so putting
+  it where `basePath` stood would have replaced an invented key with a wrong one.
+  It is documented for what it does.
+  
+  No gate in this repo could have caught the original defect, and that is why the
+  fix ships with a measurement rather than a re-reading: `check-doc-snippet-types`
+  compiles `ts`/`tsx` fences and `check-doc-component-types` reads `type` literals,
+  and both are structurally blind to a metadata key in a README — the former's own
+  header records schema-key validity as "a different question … left unruled on
+  purpose". `src/readme-navigation-example.test.ts` closes that hole for this
+  example by EXTRACTING the fence from the README on every run and parsing it
+  against `NavigationConfigSchema`, with a control asserting the same parse still
+  rejects an undeclared key by name, so the green cannot come from a schema that
+  accepts everything.
+  
+  `tsconfig.test.json` names `node` in `types` for that test to compile, and its
+  comment — which had recorded that no test in this package touches a Node global
+  — is corrected rather than left standing.
+- cbc8839: `ObjectGantt`'s export filename resolves a locale-map `label` instead of stringifying it
+  (objectui#6052). A gantt authored as
+  `{ "type": "object-gantt", "objectName": "task", "label": { "en": "Shift Plan", "zh-CN": "排班计划" } }`
+  exported its PNG/PDF as `[object Object]-20260825-1030.png`.
+  
+  `BaseSchema.label` is `string | I18nLabel` since #4580's revised Q1-A ruling — `I18nLabel`
+  being the spec's INLINE locale MAP — and the `exportFileName` chain handed that value
+  straight to `String(...)`. It now goes through `resolveI18nLabel` from `@objectstack/spec/ui`,
+  the producer's own resolver for that vocabulary, against the display locale the file already
+  reads via `useDisplayLocale()`. A zh-CN audience gets `排班计划-<stamp>.png`, an en audience
+  `Shift Plan-<stamp>.png`, and a plain-string label is unchanged.
+  
+  The next link in the same chain, `objectSchema?.label`, is deliberately left alone: that is
+  the DATA object's label, declared `z.string().optional()` on the spec's `ObjectSchemaBase`,
+  which is a `strictObject` — a locale map there is rejected by the producer rather than
+  resolved by the consumer, and wrapping it would be accepting a second vocabulary at a read
+  site. No filename sanitisation is added either; `GanttView` already strips
+  filesystem-hostile characters downstream, and a resolved map entry goes through the same
+  strip a plain string does.
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [f66072d]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [1117414]
+- Updated dependencies [6d63cd0]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [7c96c94]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [8d3a529]
+- Updated dependencies [194fae1]
+- Updated dependencies [63d54dd]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [b4393e5]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [d3005f7]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [b362c1b]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [3777538]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [d06fba8]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [9a1fb41]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [a865c73]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [0b12a33]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [e4e9557]
+- Updated dependencies [7a28e1e]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [6c1b105]
+- Updated dependencies [9d9040d]
+- Updated dependencies [20e317c]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [4bb940b]
+- Updated dependencies [17fbbaf]
+- Updated dependencies [d8cf1cb]
+- Updated dependencies [0d1e702]
+- Updated dependencies [0068348]
+- Updated dependencies [641543f]
+- Updated dependencies [8a44390]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [23705b7]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [f1690d4]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/fields@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/plugin-detail@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Patch Changes
diff --git a/packages/plugin-gantt/package.json b/packages/plugin-gantt/package.json
index 6ef13f936b..83ca6a4abf 100644
--- a/packages/plugin-gantt/package.json
+++ b/packages/plugin-gantt/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-gantt",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Gantt chart plugin for Object UI",
diff --git a/packages/plugin-grid/CHANGELOG.md b/packages/plugin-grid/CHANGELOG.md
index 06a5f2e8d0..699dd73eec 100644
--- a/packages/plugin-grid/CHANGELOG.md
+++ b/packages/plugin-grid/CHANGELOG.md
@@ -1,5 +1,609 @@
 # @object-ui/plugin-grid
 
+## 17.7.0
+
+### Minor Changes
+
+- beccf1c: fix(plugin-grid): type ObjectGrid's column emit against the `TableColumn[]` slot it fills
+  
+  `generateColumns()` had no return annotation and all four of its call sites cast
+  to `any`, so nothing checked what this producer wrote into
+  `DataTableSchema.columns: TableColumn[]`.
+  
+  Annotating it is not enough, and that is the substance of the change. Measured on
+  this program: `generateColumns(): TableColumn[]` raises **zero** diagnostics — the
+  emit literals reach the annotation through `.map()`, which strips the freshness
+  that excess-property checking depends on, so even an undeclared key written out
+  longhand is accepted. Underneath that sits the reason the annotation could not
+  bite at all: `objectSchema` is `useState<any>`, and an `any` spread into an object
+  literal collapses the **entire** literal to `any`.
+  
+  So the fix has three parts: name the four inference locals so `any` stops at the
+  boundary, carry ADR-0049 `?: never` tombstones **derived** from
+  `keyof ListColumn` (never hand-listed, so a future spec key is refused by
+  default), and drop the `any` at every call site — including a fourth the card's
+  census missed and a fifth (`const generatedColumns: any[]`) inside the producer.
+  
+  Key verdicts: `headerIcon`, `pinned` and `wrap` are HELD and now declared at the
+  seam; `options` is RETIRED — nothing on either side of the seam read it, and
+  every value it carried still reaches its consumer through the field metadata the
+  cell closure captures and the object schema the inline editor reads. `type` stays
+  objectui#5853's and `name` is not emitted here at all.
+  
+  No rendering change.
+- ebce5a3: `object-grid` / `object-form` / `detail-view` resolve their data source the same way, and a block that resolves none says so
+  
+  The three object-bound blocks disagreed about how the data-source adapter reached
+  them. `object-grid` and `object-form` were registered through wrappers that read
+  it from `SchemaRendererProvider` context; `detail-view` was registered as the raw
+  component, which reads a React `dataSource` prop. `SchemaRenderer` itself reads
+  only context, so the two wirings were mutually exclusive: measured with correct
+  keys in every cell, provider wiring gave the grid `find` 1 and the detail view
+  `findOne` 0, and prop wiring gave exactly the reverse. Neither reported anything.
+  
+  All three now resolve the adapter through one rule — an explicit `dataSource`
+  prop first, the provider context second. This is additive: `detail-view` keeps
+  its prop form (and direct `<DetailView dataSource={…} />` callers are untouched),
+  `object-form` gains a prop form it did not have, and `object-grid` no longer
+  throws `useSchemaContext must be used within a SchemaRendererProvider` when a
+  page has no provider.
+  
+  And the silence is over. A block in this family that resolves no adapter renders
+  a **No data source resolved** panel naming the block, the object it was about to
+  read, and the ancestor that injects the adapter — instead of a header-only grid,
+  a field-less form card, or nothing at all. The check is opt-in per block, so a
+  placement with inline rows, inline `customFields`, an inline record or an `api`
+  endpoint is untouched.
+  
+  New from `@object-ui/react`: `useResolvedDataSource`, `NoDataSourcePanel`,
+  `noDataSourceMessage`, and a `requiresDataSource` prop on `ElementDataSourceGate`.
+
+### Patch Changes
+
+- 9801765: The selection bar's built-in **Delete** now honours `userActions.delete.visibleWhen`
+  per selected record (objectui#4420). It used to read that key as a bare boolean — the
+  object-level verdict only — so ticking a record the author's predicate excludes still
+  offered the red Delete, and pressing it deleted the record the predicate was written to
+  protect. The row kebab on the same screen hid its Delete correctly, so one declared key
+  meant two different things on two surfaces.
+  
+  Ruled by the maintainer on 2026-08-17 (behaviour 1 of the card's three): **filter the
+  operation and report the skipped**. The bar evaluates the predicate once per selected
+  record, the delete runs over the allowed subset, and the excluded records are reported
+  rather than silently dropped. The button itself is never hidden or disabled by the
+  predicate — a mixed selection is not punished for one stray tick — and a selection where
+  every row is excluded is a legible refusal rather than an unexplained absence.
+  
+  - `@object-ui/core` gains `partitionRowsByPredicate`, the set-shaped counterpart of
+    `evalRowPredicate`: the fail-closed per-record fold a bulk gate needs, written once.
+    A bulk gate evaluates N records in a loop, which is why it can never be a hook.
+  - `@object-ui/plugin-grid`'s bulk bar routes an excluded selection through
+    `BulkActionDialog`, whose existing `bulk-skipped-notice` slot reports the skipped
+    count; a selection with nothing excluded keeps the consumer's own delete flow
+    untouched. `resolveRowCrudAffordances` now also returns `objectDeletePredicates` —
+    the bulk half of the same predicates, gated on the object verdict rather than on the
+    row `onDelete` wiring. The dialog declines to run over zero records.
+  - `@object-ui/plugin-list`'s non-grid bulk bar (kanban / calendar / gallery / …) filters
+    the built-in `delete` to the eligible subset and states the skipped count inline.
+  
+  Custom bulk action ids are untouched: they route through the action runner carrying
+  their own gates. This is a UI affordance — server enforcement was never the leak.
+- 062943f: `@object-ui/plugin-grid` and `@object-ui/plugin-kanban` now publish a stylesheet —
+  `"./style.css"`, mapped to `dist/index.css` and compiled at build time from the package's
+  own sources (objectui#4929, maintainer ruling 2026-08-17, Direction 1).
+  
+  **What was broken.** Only `@object-ui/components` and `@object-ui/fields` shipped CSS, and
+  each scans its own `src` only, so a class used exclusively by a plugin could not appear in
+  either sheet BY CONSTRUCTION. A published-state Vite app that installed one of these two
+  plugins and followed the quick-start rendered the grid or the board with **25 themed
+  utilities that had no source anywhere in the world** — `bg-muted/10`, `bg-card/60`,
+  `text-muted-foreground/60`, `ring-primary/40` and friends, ordinary appearance classes —
+  plus ~103 plain ones. Re-measured on the merged tree: the 21 the card listed all still hold,
+  and four more (`[&>h3]:text-foreground/80`, `border-l-primary/40`, `border-primary/30`,
+  `hover:text-primary`) that its literal-grep method could not see.
+  
+  The plain utilities a consumer could in principle regenerate by pointing `@source` at the
+  package's `dist`. The themed ones they cannot, at all: they resolve `@theme` tokens declared
+  in `packages/components/src/index.css`, which that package does not publish. A build inside
+  this monorepo is their only possible producer — which is why the fix is a stylesheet we
+  ship, not documentation teaching consumers to hand-declare the theme and scan
+  `node_modules` (the advice objectui#4858 had just retired from the guides).
+  
+  **The shape**, inherited from `@object-ui/fields` (objectui#4059): each package gains
+  `src/index.css` that `@reference`s the components entry — theme tokens, the class-based
+  `dark` variant and the animate plugin become available for resolution while emitting
+  nothing — plus `scripts/build-css.mjs`, which subtracts every rule components' published
+  sheet already ships. So these are **supplements, imported after** the components sheet, and
+  they are 16.30 kB and 11.41 kB rather than another ~170 kB each:
+  
+  ```css
+  @import 'tailwindcss';
+  @import '@object-ui/components/style.css';
+  @import '@object-ui/fields/style.css';
+  @import '@object-ui/plugin-grid/style.css';
+  @import '@object-ui/plugin-kanban/style.css';
+  ```
+  
+  Add a line only for the plugins you install; no other `@object-ui/plugin-*` package
+  publishes a stylesheet yet. The build step is shared
+  (`scripts/build-plugin-stylesheet.mjs`) so it is the pattern the next one inherits rather
+  than a file to copy, and it refuses to write a sheet that fails any of four assertions — no
+  rule may vanish, the subtraction must have removed something, the class count may not pass
+  a leak ceiling, and named themed utilities only this build can produce must still be
+  present.
+  
+  Nothing is removed and no existing import changes: a consumer who does not import the new
+  sheets is exactly where they were, and the guides' "do not scan `node_modules`" advice
+  stays correct — it is now correct for plugins too.
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- 490d9a9: Grid headers offer a sort click only on columns the PLATFORM says it will order by
+  (objectui#5729 — the consumer leg of objectstack#10235, maintainer ruling A, 2026-08-23:
+  the platform serves an explicit per-column sortability signal and the grid reads it,
+  rather than re-deriving "virtual ⇒ unsortable" from field type).
+  
+  `GET /api/v1/meta/object/:name` now answers with a `sortability` projection on its
+  ENVELOPE — `{ fields: { [name]: { sortable, reason?, caveat? } } }`, computed at serve
+  time from the platform's own storage predicates, deliberately beside `item` rather than
+  inside it so the key stays un-authorable. The signal was reaching the browser and being
+  discarded one line before its only consumer: `ObjectStackAdapter.getObjectSchema` unwraps
+  the envelope to `item`, so every UI reader saw a document with no signal on it. It now
+  survives that unwrap, carried on the schema under a symbol key — invisible to
+  `JSON.stringify`, to `Object.keys` and to a spread, so a schema handed back at a metadata
+  write endpoint can never take it into a body the server parses strictly.
+  
+  `@object-ui/core` gains the one spelling of the consumer contract:
+  `isPlatformSortableField(projection, name)` is `true` iff an entry EXISTS for the name and
+  says `sortable: true`. Absence is a refusal — it is how the platform encodes an unknown
+  name, a dotted path and an unprovisioned audit column, all three of which the runtime
+  doors reject — so the `!== false` spelling every other optional flag in this repo uses
+  would get exactly that family backwards. A projection that is absent ALTOGETHER is a
+  different question with a different answer (`undefined`: no signal was served) and is
+  typed apart from an empty one, so a deployment older than the upstream change keeps the
+  behaviour it had rather than being told, falsely, that nothing on the object is sortable.
+  
+  Three things follow in the grid. The header click on a refused column ceases to exist, so
+  neither the old silent-unordered result nor the `400 INVALID_SORT` that replaced it is
+  reachable from it. A sort PERSISTED before the signal existed is filtered out of both what
+  the grid renders and what it emits, so a restored personalization cannot ride back into
+  the next `persistViewPatch({ sort })` — the half-fix where the affordance is gone and the
+  PUT still fires. And the relational carve-out is untouched and deliberately not delegated
+  to this signal: the platform answers `sortable: true` for a `lookup` (it has a stored
+  foreign key and both runtime doors accept ordering by it), while the grid withholds that
+  header for a different reason — a column of names ordered by an invisible id.
+  
+  Columns carrying `caveat: 'unprovisioned-anchor'` keep their click. The runtime accepts
+  those sorts; refusing what the platform does not refuse would recreate declared-≠-enforced
+  drift in mirror image.
+- fc62bb4: `TableColumn.type` now has ONE canonical value set across all three ends that disagreed
+  (objectui#5853, maintainer ruling 2026-08-25, Option B: the 8-literal interface union is
+  canonical). The interface declared `'text' | 'number' | 'date' | 'datetime' | 'currency' |
+  'percent' | 'boolean' | 'action'`; the zod mirror declared `z.string()` and accepted
+  anything; the renderer branched on a third set and could only read the key through an
+  `as any` cast.
+  
+  ## ⚠️ Accept-set narrowing — these spellings stop validating
+  
+  `TableColumnSchema.type` was `z.string().optional()`. **Any string parsed green.** It is now
+  `z.enum(TABLE_COLUMN_TYPES).optional()`, so a value outside the eight is refused at parse
+  time with `type` named in the error path. Spellings that validated before and are **refused
+  now**, grouped by why they were being written:
+  
+  - **Typos and invented names** — `'money'`, `'datetime2'`, `'string'`, `'int'`, `'integer'`,
+    `'float'`, `'double'`, `'datetime-local'`, and every other free-form string. `'money'` is
+    the card's headline case: it validated, matched no renderer branch, and the column fell
+    through to plain text rendering with nothing reported. That silent fall-through is the
+    lenient-validation face that lets AI-authored metadata errors through, and it is now a
+    loud parse failure.
+  - **Object-schema field types written into a column slot** — `'select'`, `'lookup'`,
+    `'user'`, `'file'`, `'formula'`, `'textarea'`, `'email'` and the other 35 members of
+    `@objectstack/spec`'s `FieldType` that are not among the eight. These belong on the FIELD,
+    not on the column: a column gets its dedicated widget from the field definition behind its
+    `accessorKey`, never from `type`.
+  
+  **Authored metadata in this repo needs no migration.** Measured before tightening, across
+  `examples/`, `content/`, `apps/`, `e2e/`, `docs/` and every package (591 JSON schema files
+  plus the docs and playground sources): **zero** authored `TableColumn.type` values outside
+  the eight, and zero occurrences of `int` / `integer` / `float` / `double` in a column
+  position anywhere in the repository. If you author `type` on a table column, check it
+  against the eight; if the value describes the FIELD rather than the column, remove it.
+  
+  ## The renderer's undeclared vocabulary disappears instead of being declared
+  
+  `int` / `integer` / `float` / `double` were members of the data-table's `NUMERIC_EDIT_TYPES`
+  and `datetime-local` had its own editor branch, none of them declared. They arrived because
+  column-inference producers forwarded an object schema's field type **verbatim** into
+  `TableColumn.type`. Rather than publishing that dialect, producers now fold their inferred
+  value onto the declared vocabulary at their emit seam via the new
+  `normalizeTableColumnType()`: `int`/`integer`/`float`/`double` → `number`,
+  `datetime-local` → `datetime`, and **anything else drops the `type` annotation — never the
+  column**. Two producers do this, not the one the card named: `ObjectGrid` (`@object-ui/plugin-grid`)
+  and `ObjectDataTable` (`@object-ui/plugin-dashboard`), whose `buildFieldMeta` spread wrote
+  the raw field type into the same slot.
+  
+  Dropping the annotation is behaviour-preserving at the only consumer that reads the key.
+  `data-table`'s inline editor branches on `date`, `datetime` and the numeric set and
+  otherwise falls through to a text input — which is exactly the `undefined` path. The
+  dedicated widget a `select` or `lookup` column gets comes from the host's `renderCellEditor`,
+  which resolves the field through `column.accessorKey` and never reads `type`.
+  
+  ## New public API
+  
+  `@object-ui/types` exports `TABLE_COLUMN_TYPES` (the canonical tuple — the single
+  declaration the zod mirror builds its enum from, so the two cannot drift), the
+  `TableColumnType` union, and `normalizeTableColumnType()` for producers. The `as any` cast
+  in `data-table.tsx` is deleted and the read is typed, so re-introducing an undeclared
+  spelling is a tsc error rather than a silent widening.
+  
+  A value-level parity pin covers all three ends
+  (`packages/types/src/__tests__/table-column-type-canonical.test.ts` and
+  `packages/components/src/renderers/complex/__tests__/table-column-type-read-set.test.tsx`).
+  objectui#5684's guard is key-set only and cannot see value drift — `type` was present on
+  both sides the whole time — which is how this instance survived while its siblings were
+  caught. A future inference value turning that pin red is by design; the note at the pin says
+  so, and names the two correct repairs.
+- 129bcc5: Column width and order that a user drags in `ObjectGrid` now actually persist
+  (objectui#6175). Both halves of `saveColumnState`'s only two call sites were dead, so a
+  drag was written nowhere — not to `localStorage`, not through `onColumnStateChange` to the
+  host's `dataSource.updateViewConfig`. The saved state was read back correctly forever; it
+  was simply never written.
+  
+  Two independent breaks, one per package:
+  
+  - **`@object-ui/components`** — `DataTableSchema` has declared
+    `onColumnResize?: (columnKey, width) => void` all along, and `data-table.tsx` invoked it
+    **nowhere**: the resize drag updated the table's local `columnWidths` state and stopped
+    there. It now reports the settled width once, at `mouseup`. Once, deliberately — the host
+    turns this callback into a write to shared view config, so a per-`mousemove` callback
+    would be a write storm.
+  - **`@object-ui/plugin-grid`** — `ObjectGrid` emitted `onColumnReorder` (singular) while the
+    renderer invokes the near-duplicate `onColumnsReorder` (with the `s`), a different declared
+    key with a different signature. The producer now emits the spelling the renderer actually
+    invokes, mapping the reported `TableColumn[]` to the `accessorKey` order `columnState`
+    stores.
+  
+  **Nothing is retired.** Both spellings remain declared on `DataTableSchema`;
+  `onColumnReorder` stays declared and stays unwired, exactly as the `RuntimeOnlyDeclared`
+  ledger in `zod-mirror-parity.test.ts` records it. Which of the two survives is a
+  declared-surface ruling that stays open and is deliberately not settled here.
+  
+  ⚠️ Behavioural note for hosts: `onColumnStateChange` now fires where it previously never
+  did, which means `dataSource.updateViewConfig` is now reached on a column drag. That call
+  was unreachable by this path before, so any permission gate on that write now sees traffic
+  it never saw.
+  
+  The renderer's resize/reorder gestures, the inbound seeding of `columnState`, and the
+  declared surface are all unchanged.
+- c38162d: The batch-explain cap the row-verdict hook paginates under is now imported from
+  `@objectstack/spec/security` instead of re-declared locally (objectui#6286).
+  `useRecordCrudVerdicts` carried `const EXPLAIN_BATCH_MAX_RECORD_IDS = 200`, a hand copy of
+  a SERVER contract constant, under a doc comment that named its own expiry condition: the
+  pinned `@objectstack/spec@17.0.0-rc.6` predated the batch form, and the pin bump would
+  supersede the declaration. It has.
+  
+  **No value changes and no behaviour changes.** The spec exports `200`, which is what the
+  local copy said, verified by resolving the installed package and reading the export — both
+  statically (`dist/security/index.d.mts`) and at runtime through the same specifier the
+  source now uses. What changes is reference identity: if the server relaxes or tightens the
+  cap and the spec follows, the client follows too, instead of paginating at the old boundary
+  with no signal anywhere. The cap's whole point is that an over-cap request is refused with
+  `400 VALIDATION_FAILED` rather than truncated, so a client that silently disagrees with it
+  is exactly the drift `scripts/check-spec-symbol-derivation.mjs` argues about — and could
+  not catch here, because both of its scanners skip non-exported declarations and this const
+  was module-local (objectui#5899).
+  
+  The declared floor already carries the symbol, so no range moves: `@objectstack/spec@17.0.0`
+  — the minimum `^17.0.0` admits — exports `EXPLAIN_BATCH_MAX_RECORD_IDS = 200` from
+  `./security`. Measured against the published tarballs of `17.0.0-rc.6`, `17.0.0`, `17.1.0`
+  and `17.2.0`: only the rc lacks it. The declaration was therefore expired one release
+  earlier than the card that found it assumed.
+  
+  The half of the comment that explains *why* the cap exists and what the server does with an
+  over-cap request is kept and now sits on the import; only the half explaining why it was
+  declared LOCALLY is gone, since that is the part that stopped being true.
+  
+  Covered by a new reference-identity test rather than a value assertion. Every assertion on
+  `200` passes on both sides of this change — a ghost — so
+  `useRecordCrudVerdicts.batchCap.test.tsx` stands the spec module in at a cap no hand copy
+  could produce and asserts the request chunking follows it, with a control case proving the
+  stand-in installed and differs from the shipped value. The pre-existing cap assertion in
+  `rowRecordCrudVerdict.test.tsx` now derives its fixture and its bound from the same export
+  instead of re-typing `200`, which removes the last hand copy on this surface without
+  pretending to be a two-world test.
+- 9e22085: `ObjectGrid` lowers the deprecated `defaultFilters` through `toFilterNode` instead of
+  byte-copying it onto `$filter` (objectui#4082).
+  
+  The query assembly already lowered the canonical `filter` key through `toFilterNode` —
+  the repo's single "last hop before the wire" (objectui#4041) — while the legacy branch
+  beside it assigned `params.$filter = schema.defaultFilters` verbatim. That made this the
+  one leg on the chain reaching the wire unlowered: `plugin-list`'s `buildEffectiveFilter`
+  and `plugin-view`'s non-grid fetch both already route the same value through
+  `toFilterNode` / `mergeFilterNodes`.
+  
+  Byte-copying is refused on the wire for both shapes the slot carries. `defaultFilters` is
+  declared `Record<string, any>` (the MongoDB-style shape) and `isFilterAST` is false for a
+  plain object; an array of `ViewFilterRule` objects fails the same predicate. Either one
+  answers `400 INVALID_FILTER` — measured against a real backend in objectui#3431.
+  
+  `toFilterNode` handles both without new logic: objects route through
+  `convertFiltersToAST`, rule arrays lower element-wise, and an AST already in the slot
+  passes through untouched, so nothing is lowered twice. It also folds an absent or empty
+  source to `undefined`, which is why the truthiness guard is gone — `defaultFilters: {}`
+  used to send `$filter: {}`, asking the server a question with no content in a shape it
+  refuses; now `$filter` is omitted, matching the canonical key's documented behaviour.
+  
+  **Grade — this is less dormant than the card assumed.** objectui#4082 was filed
+  observation-class on "no measured producer", reasoning that `defaultFilters` is not in
+  `object-grid`'s registered `inputs` so an author writing it only draws a save-gate
+  warning. That reasoning covers authors, but not the framework: `plugin-view`'s
+  `ObjectView` writes the slot itself, forwarding an active named view's `filter` as
+  `defaultFilters: viewFilter || schema.table?.defaultFilters` in its `gridSchema` memo —
+  and `plugin-view`'s own README documents `listViews.<name>.filter` as
+  `[{ field, operator, value }, …]`, the exact shape objectui#3431 measured as
+  `400 INVALID_FILTER`. The registered `object-view` / `view` renderer passes no
+  `renderListView`, so that path falls through to `ObjectGrid` rather than to `ListView`,
+  and `ListView`'s lowering does not cover it. So a schema-registration host — the
+  documented authoring path — reached the raw assignment whenever an active named view
+  carried a filter. Not asserted here: a failing request captured against a running
+  deployment. `app-shell` is unaffected either way; it supplies `renderListView` and
+  delegates to `ListView`, which lowers.
+  
+  Not in scope, and deliberately not done: retiring `defaultFilters`. This is
+  consumer-side only — the key the schema admits is unchanged, and its precedence behind
+  the canonical `filter` is unchanged.
+  
+  The sibling legacy `defaultSort` leg was graded and needs no change; see the PR for the
+  measurements.
+- c574dfb: `ObjectGrid` says which column it dropped, instead of rendering a header-only grid in silence.
+  
+  objectui#5068 retired the undeclared `accessorKey` / `header` tolerance branch, so
+  `ListColumnSchema`'s `field` / `label` is now the only column spelling the renderer
+  reads. That was right — the spec refuses `accessorKey` and `header` by name, and the
+  census found zero authored usages. But it relocated a failure mode instead of removing
+  it: a column authored in a spelling the renderer does not read contributed nothing, and
+  nothing said so. No error, no warning, no empty state — the author got a grid with its
+  row-number column and no data columns, which is a success receipt for a disagreement
+  between the renderer and the author.
+  
+  An authored column that can never resolve now emits one `console.warn` naming the
+  address rather than the symptom: which block (`object-grid` or the `view:grid` alias),
+  which object and label, which `columns[i]`, the keys that entry actually carries, and the
+  rewrite that works — for a column authored `{ accessorKey: 'amount', header: 'Amount' }`
+  the message spells out `{ field: 'amount', label: 'Amount' }`. It reuses the channel `ObjectGrid` already had for "you declared it, the renderer dropped
+  it" (the export-format warning), rather than adding a second differently-shaped one.
+  
+  Rendering is unchanged in every case: this is additive. The diagnostic reads the
+  `columns` input and nothing else — it never asks whether the grid found rows, because
+  `object-grid` legitimately draws them from five different places (a bare `data` array,
+  `data.provider: 'value'`, legacy `staticData`, `bind`, or a host that owns the fetch and
+  passes the window down as a `data` React prop, which is what `plugin-list`'s `ListView`
+  does). All five are pinned by test, in both directions. A `hidden: true` column is
+  authored intent and is never reported, and so are the arms that legitimately produce no
+  columns of their own: no `columns` key, an empty `columns` array, and the `string[]`
+  spelling.
+  
+  A throw was rejected: a grid that renders nothing today would become a page that renders
+  nothing.
+- 02f48b6: `object-grid` harvests row-action predicate fields from the OBJECT's `userActions` block only — a view's toolbar policy can no longer shadow it.
+  
+  `userActions` names two different blocks. On a **view** it is toolbar policy —
+  the spec's `UserActionsConfigSchema` (`sort`, `search`, `filter`, `refresh`,
+  `rowHeight`, `addRecordForm`, `editInline`, `buttons`), which rejects `edit` by
+  name. On an **object** it is the CRUD-predicate block (`edit` / `delete` /
+  `create` carrying `visibleWhen` / `disabledWhen`, objectui#2614) — and that is
+  the only shape `listViewPredicates` can read, since its loop skips every
+  non-object value.
+  
+  `ObjectGrid` read the key view-first when building the `$select` projection
+  (`(schema as any).userActions ?? resolvedSchema.userActions`). A view carrying a
+  perfectly legal toolbar block therefore shadowed the object's CRUD predicates,
+  the harvest found none, and the predicate's operand left the projection. CEL then
+  faults on the absent key, fails closed, and the row Edit/Delete button disappears
+  for everyone with nothing pointing at the projection — objectui#3501's failure,
+  reached with a success receipt at every step.
+  
+  The view-level block is not hypothetical: `SpecBridge.transformListView` copies
+  it onto the `object-grid` node the renderer receives, and `app-shell`'s
+  `ObjectView` builds one unconditionally.
+  
+  The harvest now reads the resolved object block only. Both `userActions` read
+  sites carry a comment naming the collision, and
+  `__tests__/gridNonAuthorKeys.test.tsx` pins each clause of it: the two shapes,
+  the producer that writes the view one, the harvest's blindness to it, and the
+  projection that must keep the object's operand with a toolbar block present.
+  
+  Toolbar policy itself is untouched — it was never read through this path.
+- 591bf27: Guard `useRowColor`'s two object-literal lookups with `Object.prototype.hasOwnProperty.call`.
+  
+  Both `config.colors` (the authored map) and the module's `COLOR_TO_CLASS` literal inherit
+  `Object.prototype`, and both were reached with a bare index. A record whose colour field
+  held `constructor`, `toString`, `valueOf` or `hasOwnProperty` resolved to an inherited
+  function: the `if (!color)` guard passed it (functions are truthy) and `colorToClass` then
+  called `.startsWith` on it, throwing a `TypeError` inside the row-className resolver during
+  render — a grid crash triggered by record data rather than by metadata. The same shape one
+  call deeper in `colorToClass` did not throw; it handed an `Object.prototype` member back as
+  the row's `className`, which reached React as a class attribute. Both now resolve to
+  `undefined`, as an undeclared value always did.
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [8d3a529]
+- Updated dependencies [194fae1]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [b362c1b]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [3c9fca3]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [9a1fb41]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [a865c73]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [e4e9557]
+- Updated dependencies [7a28e1e]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [20e317c]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [4bb940b]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [f1690d4]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/fields@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/mobile@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+  - @object-ui/permissions@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/plugin-grid/package.json b/packages/plugin-grid/package.json
index 3fc6d8ff2a..07771be62f 100644
--- a/packages/plugin-grid/package.json
+++ b/packages/plugin-grid/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-grid",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Grid plugin for Object UI",
diff --git a/packages/plugin-kanban/CHANGELOG.md b/packages/plugin-kanban/CHANGELOG.md
index 055d641658..efe1b7ad3c 100644
--- a/packages/plugin-kanban/CHANGELOG.md
+++ b/packages/plugin-kanban/CHANGELOG.md
@@ -1,5 +1,377 @@
 # @object-ui/plugin-kanban
 
+## 17.7.0
+
+### Patch Changes
+
+- 062943f: `@object-ui/plugin-grid` and `@object-ui/plugin-kanban` now publish a stylesheet —
+  `"./style.css"`, mapped to `dist/index.css` and compiled at build time from the package's
+  own sources (objectui#4929, maintainer ruling 2026-08-17, Direction 1).
+  
+  **What was broken.** Only `@object-ui/components` and `@object-ui/fields` shipped CSS, and
+  each scans its own `src` only, so a class used exclusively by a plugin could not appear in
+  either sheet BY CONSTRUCTION. A published-state Vite app that installed one of these two
+  plugins and followed the quick-start rendered the grid or the board with **25 themed
+  utilities that had no source anywhere in the world** — `bg-muted/10`, `bg-card/60`,
+  `text-muted-foreground/60`, `ring-primary/40` and friends, ordinary appearance classes —
+  plus ~103 plain ones. Re-measured on the merged tree: the 21 the card listed all still hold,
+  and four more (`[&>h3]:text-foreground/80`, `border-l-primary/40`, `border-primary/30`,
+  `hover:text-primary`) that its literal-grep method could not see.
+  
+  The plain utilities a consumer could in principle regenerate by pointing `@source` at the
+  package's `dist`. The themed ones they cannot, at all: they resolve `@theme` tokens declared
+  in `packages/components/src/index.css`, which that package does not publish. A build inside
+  this monorepo is their only possible producer — which is why the fix is a stylesheet we
+  ship, not documentation teaching consumers to hand-declare the theme and scan
+  `node_modules` (the advice objectui#4858 had just retired from the guides).
+  
+  **The shape**, inherited from `@object-ui/fields` (objectui#4059): each package gains
+  `src/index.css` that `@reference`s the components entry — theme tokens, the class-based
+  `dark` variant and the animate plugin become available for resolution while emitting
+  nothing — plus `scripts/build-css.mjs`, which subtracts every rule components' published
+  sheet already ships. So these are **supplements, imported after** the components sheet, and
+  they are 16.30 kB and 11.41 kB rather than another ~170 kB each:
+  
+  ```css
+  @import 'tailwindcss';
+  @import '@object-ui/components/style.css';
+  @import '@object-ui/fields/style.css';
+  @import '@object-ui/plugin-grid/style.css';
+  @import '@object-ui/plugin-kanban/style.css';
+  ```
+  
+  Add a line only for the plugins you install; no other `@object-ui/plugin-*` package
+  publishes a stylesheet yet. The build step is shared
+  (`scripts/build-plugin-stylesheet.mjs`) so it is the pattern the next one inherits rather
+  than a file to copy, and it refuses to write a sheet that fails any of four assertions — no
+  rule may vanish, the subtraction must have removed something, the class count may not pass
+  a leak ceiling, and named themed utilities only this build can produce must still be
+  present.
+  
+  Nothing is removed and no existing import changes: a consumer who does not import the new
+  sheets is exactly where they were, and the guides' "do not scan `node_modules`" advice
+  stays correct — it is now correct for plugins too.
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- 7c96c94: Four more private copies of the reference-bearing field family converge onto
+  `@object-ui/core`'s `EXPANDABLE_FIELD_TYPES`, and the "fourth and last private copy" claim
+  that `paramToField` still stated is corrected (objectui#5874, objectui#5875).
+  
+  Each copy diverged from the published family in BOTH directions, so this is a behaviour
+  change on every face and not a refactor:
+  
+  - **`user` and `tree` are now treated as relations.** Both carry the same foreign-key
+    storage as `lookup` and resolve through the same expand path (objectui#2032), and each
+    face's own stated reason for special-casing `lookup` applied to them verbatim — so
+    gaining them restores the rule each face already meant. A `user` / `tree` field is now
+    read-only in the quick-look drawer (`RecordDetailDrawer`), where the drawer wires no
+    relation picker and a plain text input let a user overwrite the relation with a
+    free-form string; it gets the wide layout basis in the record header's highlights strip
+    (`HeaderHighlight`), whose inline editor is a record picker; and a field-backed action
+    param over one now inherits the picker config it needs (`resolveActionParams`).
+  - **`master_detail` is now treated as a relation by `resolveActionParams` too** — it was
+    the only face missing that member as well, so a field-backed `master_detail` action param
+    inherited no `referenceTo` at all and degraded to the unexplained "paste a record id"
+    text input that objectui#3405 exists to prevent.
+  - **The undeclarable `reference` spelling is gone from the three field-type faces.**
+    Measured against `@objectstack/spec`'s closed `FieldType` vocabulary with live controls
+    (`lookup` / `master_detail` / `user` / `tree`) and dead ones (the retired `owner`, plus a
+    nonsense spelling): `reference` is absent, so no spec-compliant object schema could
+    declare a field that reached those branches. It sat exactly where `owner` sat before
+    objectui#4814 retired it — dead weight that read as live capability.
+  
+  `resolveActionParams` keeps answering for `reference`, deliberately and by a different
+  route: it is refused by the spec's `ActionParamSchema` too, but the dialog still accepts it
+  from params already authored with it, and that acceptance belongs to the one alias table in
+  `paramToField` rather than to a hand-copied membership test. This face now asks the shared
+  family over the widget key that table produces — the same expression `paramToField`
+  evaluates one step later, so the half that populates a param's picker config and the half
+  that forwards it can no longer disagree.
+  
+  No face copies the set: each calls `.has()` on the object `@object-ui/core` exports, and
+  each carries an identity pin (a spy on that `has`) so a member-identical private copy fails
+  instead of quietly re-forking the table.
+- 3e853c9: Let a producer-marked refusal reach the drag-write surfaces (objectui#5902).
+  
+  The kanban card-move toast, the calendar drag-to-reschedule toast and the OCC
+  conflict dialog each substituted a generic string for a refusal the producer had
+  marked as user-facing (`userMessage`), so a user was told "Save failed" where the
+  application author had written a sentence addressed to them. All three now read
+  the marking through the shared `declaredUserMessage` reader, which covers both
+  places the adapter boundary parks it — the typed member on
+  `ConcurrentUpdateError` and the details bag on `DataApiValidationError`.
+  
+  Nothing unmarked changes: the reader answers `null` for it, so every existing
+  generic substitution — including the localized "not authorized" message that
+  keeps raw server diagnostics away from end users — still governs unmarked
+  refusals exactly as before.
+  
+  The two toasts substitute; the conflict dialog augments. Its description also
+  explains what the destructive "Overwrite" button does, which is affordance copy
+  that surface owns rather than a refusal message, so the marking leads and that
+  paragraph stays.
+- a76b18c: `ObjectKanban`'s `resolveDisplay` drops an unreachable relation-type guard, and the rule
+  that survives it is pinned (objectui#6063).
+  
+  The helper that builds card descriptions ended:
+  
+  ```ts
+  const isLookup = isExpandableFieldType(def);
+  if (isLookup && isOpaqueId(raw)) return undefined;
+  if (isOpaqueId(raw)) return undefined;
+  return raw;
+  ```
+  
+  The second line subsumes the first for every input — same `raw` (a `const`, unmodified
+  between the two lines), same predicate, and `OPAQUE_ID_RE` carries no `g`/`y` flag, so
+  repeated `.test()` on it is stateless. `isLookup` was computed, branched on and discarded.
+  
+  **No behaviour changes on any board.** The card named a second reading — that the
+  unconditional line was the mistake and only relation columns were meant to suppress
+  id-shaped values — and it was rejected on evidence rather than by tidying first: the
+  helper's own docblock declares both clauses, the same predicate is already applied with no
+  type gate to the incoming `description` a few lines down, and `objectDef` is optional at
+  that read, so a type gate would suppress nothing on exactly the boards whose object schema
+  is thin or absent. That reading is now a red test, not a comment.
+  
+  Deleting the branch also deleted this path's read of `@object-ui/core`'s
+  `EXPANDABLE_FIELD_TYPES`, so objectui#5874's identity pin for this face is re-anchored onto
+  the read that is live — `buildExpandFields`, on every fetch — where the membership delta is
+  observable on the wire (`$expand`) as well. That pairs the identity pin with the
+  behavioural counter-probe #5874 had to record as missing.
+- 7d2a689: `ObjectKanban` no longer queries twice on mount (objectui#6271). A standalone board issued
+  its first `find` before the object definition resolved — so `buildExpandFields` saw no
+  fields and that query carried no `$expand` at all — then issued a second, expanded one once
+  the definition landed:
+  
+  ```
+  ['deal', { $top: 100 }]
+  ['deal', { $top: 100, $expand: ['owner'] }]
+  ```
+  
+  The definition now GATES the query instead of refining it afterwards: one query per mount,
+  carrying the expansion the first time.
+  
+  Decided on measurement rather than on the two shapes' relative appeal. The first response
+  never reached the screen in the regimes that matter: with the schema resolving no slower
+  than the row query (profiles schema/find = 30/30, 30/60, 5/30 ms), the definition lands
+  first, the effect re-runs, its cleanup flips `isMounted` false, and the unexpanded rows are
+  discarded on arrival — a DOM probe polling every 2ms for a title only that response carried
+  never fired once. What the gate costs is one schema resolution ahead of the query, and that
+  read is cheap and shared: one small GET behind the same discovery call `find` already
+  awaits, served thereafter from `MetadataCache` (5-minute TTL, concurrent readers coalesced
+  onto one request). Measured against the real `ObjectStackAdapter` over loopback HTTP, 22
+  reads of one object produced exactly one metadata request and every read after the first
+  returned in 0.01ms. End to end the board is not slower for it — same harness, before →
+  after, time to the fully populated board: 156.9 → 145.2ms (30/30), 119.8 → 110.6ms (30/60),
+  54.7 → 52.4ms (5/30).
+  
+  The gate is on the definition read having **settled**, not on the definition being truthy:
+  an adapter that exposes no `getObjectSchema`, and a read that throws, both settle with
+  nothing to report and the board falls through to an unexpanded query rather than waiting
+  forever. Boards fed rows by a parent (`data`, `bind`, inline `schema.data`) are untouched —
+  they never ran this effect, and they still read the definition for lane titles and labels.
+  
+  The `isOpaqueId` suppression in the card-description path is unchanged and keeps its
+  comment beside it: part of what it hid was this fetch ordering, but unexpanded rows still
+  reach it from parents that pass rows they fetched without `$expand`, from author-supplied
+  data, and from backends that decline an expansion.
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [f66072d]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [1117414]
+- Updated dependencies [6d63cd0]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [7c96c94]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [8d3a529]
+- Updated dependencies [194fae1]
+- Updated dependencies [63d54dd]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [b4393e5]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [d3005f7]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [b362c1b]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [3777538]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [d06fba8]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [9a1fb41]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [a865c73]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [0b12a33]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [e4e9557]
+- Updated dependencies [7a28e1e]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [6c1b105]
+- Updated dependencies [9d9040d]
+- Updated dependencies [20e317c]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [4bb940b]
+- Updated dependencies [17fbbaf]
+- Updated dependencies [d8cf1cb]
+- Updated dependencies [0d1e702]
+- Updated dependencies [0068348]
+- Updated dependencies [641543f]
+- Updated dependencies [8a44390]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [23705b7]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [f1690d4]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/fields@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/plugin-detail@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Patch Changes
diff --git a/packages/plugin-kanban/package.json b/packages/plugin-kanban/package.json
index 1093e732f2..1c6f328994 100644
--- a/packages/plugin-kanban/package.json
+++ b/packages/plugin-kanban/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-kanban",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Kanban board plugin for Object UI, powered by dnd-kit",
diff --git a/packages/plugin-list/CHANGELOG.md b/packages/plugin-list/CHANGELOG.md
index b539389c42..7bb12eda2c 100644
--- a/packages/plugin-list/CHANGELOG.md
+++ b/packages/plugin-list/CHANGELOG.md
@@ -1,5 +1,537 @@
 # @object-ui/plugin-list
 
+## 17.7.0
+
+### Minor Changes
+
+- e2e8e68: **Behaviour change:** the spec's view-level `map` block on a list view is now read at
+  runtime. `ListMapConfigSchema` (objectstack#9340) has been authorable and validated since
+  the `@objectstack/spec` 17.1.0 pin — it flows into this repo's own `ListViewSchema` by
+  reference — but nothing consumed it: `ListView`'s `case 'map'` forwarded only the legacy
+  `schema.options.map` bag, so declaring `map: { titleField: 'title', locationField:
+  'location' }` on a view changed nothing and marker titles fell back to the renderer's
+  placeholder.
+  
+  The block now reaches `plugin-map` and drives every one of its seven reads — coordinate
+  extraction, marker title and description, and the initial camera. Precedence follows the
+  convention the sibling visualization blocks in the same file already set: the view-level
+  block wins over `options.map`, per key, exactly as `kanban` / `calendar` / `gallery` /
+  `timeline` / `gantt` each merge their spec config over the legacy bag. Both sources go
+  through the existing objectui#5177 key whitelist, and the branch still emits the flat
+  form, so `getMapConfig`'s objectui#5018 precedence rule ("neither flattener emits a `map`
+  key at all") stays true.
+  
+  The visualization switcher had the same gap with a sharper consequence: the capability
+  gate that decides which visualizations are offered also read `options.map` alone, so a
+  view binding its coordinates in the spec block was filtered out of its own
+  `appearance.allowedVisualizations` and fell back to `['grid']`. The gate now asks the same
+  merged config the render seam forwards, so the two cannot disagree — including for a
+  binding split across the two sources.
+  
+  `InterfaceListPage` (ADR-0047 interface pages) forwards the referenced view's `map` block
+  for the same reason. It is passed alongside the auto-derived `options.map` rather than
+  replacing it, so a partial authored block — `map: { titleField: 'title' }` — keeps the
+  derived coordinate binding instead of dropping it.
+  
+  No defaults are introduced for `zoom` / `center`: an undeclared camera stays undeclared,
+  so the fit-to-queried-records behaviour ruled in objectui#5000 is unchanged.
+- 2d36552: Pins `@objectstack/spec`, `@objectstack/client`, `@objectstack/formula` and `@objectstack/lint` to `17.1.0`, and adapts the two consumer surfaces the new build moves.
+  
+  The pin itself is a lockfile refresh — every manifest already declared `^17.0.0`, which admits `17.1.0`, so no dependency range changed. All four move together: a split resolution is what produced the dual-version spec graph that reddened `check:spec-symbols` in this repo's history.
+  
+  **A `icontains` filter now reaches the driver as a filter.** `icontains` is a canonical `VIEW_FILTER_OPERATORS` member as of `17.1.0`, so an author can declare it on a `ViewFilterRule` and the spec validates it — but `@object-ui/data-objectstack`'s alias table had no row for it, and an unmapped operator is how this adapter shipped an unfiltered query before (objectstack#3948). It is an identity row like `contains`: `icontains` is itself a member of `VALID_AST_OPERATORS`, so the spelling the author writes is the spelling the AST takes, and no case-sensitivity is translated away. Declared rather than left to the table's `?? op` fall-through, on the rule its own parity test states — the AST gate accepting a spelling is not the driver compiling it into a `WHERE` clause.
+  
+  The same operator reaches the list view's own bridge: `@object-ui/plugin-list`'s `mapOperator` gains an explicit `icontains` arm. The emitted spelling is identical to the input, but the arm is written out rather than left to the `default` passthrough — `icontains` is its own member of `VALID_AST_OPERATORS`, so a raw passthrough is accepted *today*, and depending on that coincidence is what the bridge's own parity test records as how it once stopped discriminating.
+  
+  `@object-ui/core` adds `onSuccess` to its spec key inventory, so an author writing the key `17.1.0` now declares is no longer warned that it is unknown. That is a diagnostic statement only — the four declared action surfaces still drop the key before it reaches the runner, which is tracked separately.
+  
+  **A stored view filtering case-insensitively still shows that operator when it is reopened.** `@object-ui/plugin-view`'s canonical-to-builder table is keyed by `ViewFilterOperator`, so `17.1.0` adding `icontains` failed to compile rather than letting the operator reach the FilterBuilder as a raw spelling its dropdown cannot select. It maps to the builder's `containsCaseInsensitive` — the id that authors the spec's `$icontains` — and deliberately not to `contains`, which would quietly rewrite a case-insensitive filter into a case-sensitive one the next time the view was saved.
+  
+  **The page-editor palette keeps one entry per renderer.** `17.1.0` retires `element:filter` from `PageComponentType` and adds `record:discussion`, leaving the member count at 34 either side — so the swap is invisible to any count-based reading. The stale `element:filter` exclusion is dropped, and `record:discussion` is excluded because it is the *same renderer* as the already-offered `record:chatter`, not because it is unauthorable. Nothing the palette offers changes.
+  
+  **The console eager-closure ceiling is re-baselined, by maintainer ruling.** The release is roughly 930 KB larger uncompressed and nearly all of it lands in `vendor-objectstack-*.js`, which put the closure past a ceiling that was deliberately sized to catch a 89 KiB regression — the gate refused the bump, correctly. Raising it was escalated rather than taken locally, because gate-strength policy had been ruled the maintainer's; the ruling on objectui#5531 authorised the raise. `MAX_EAGER_CLOSURE_GZIP_BYTES` and the `BASELINE` it is derived from move together in one commit, keeping headroom at 2.00% and below the 91,136-byte regression size the gate must still catch. The gate's *sensitivity* is untouched: a repeat of that regression from the new baseline still fails. No behaviour ships from this file — it is CI policy, recorded here because the version it governs is the one this changeset publishes.
+
+### Patch Changes
+
+- 9801765: The selection bar's built-in **Delete** now honours `userActions.delete.visibleWhen`
+  per selected record (objectui#4420). It used to read that key as a bare boolean — the
+  object-level verdict only — so ticking a record the author's predicate excludes still
+  offered the red Delete, and pressing it deleted the record the predicate was written to
+  protect. The row kebab on the same screen hid its Delete correctly, so one declared key
+  meant two different things on two surfaces.
+  
+  Ruled by the maintainer on 2026-08-17 (behaviour 1 of the card's three): **filter the
+  operation and report the skipped**. The bar evaluates the predicate once per selected
+  record, the delete runs over the allowed subset, and the excluded records are reported
+  rather than silently dropped. The button itself is never hidden or disabled by the
+  predicate — a mixed selection is not punished for one stray tick — and a selection where
+  every row is excluded is a legible refusal rather than an unexplained absence.
+  
+  - `@object-ui/core` gains `partitionRowsByPredicate`, the set-shaped counterpart of
+    `evalRowPredicate`: the fail-closed per-record fold a bulk gate needs, written once.
+    A bulk gate evaluates N records in a loop, which is why it can never be a hook.
+  - `@object-ui/plugin-grid`'s bulk bar routes an excluded selection through
+    `BulkActionDialog`, whose existing `bulk-skipped-notice` slot reports the skipped
+    count; a selection with nothing excluded keeps the consumer's own delete flow
+    untouched. `resolveRowCrudAffordances` now also returns `objectDeletePredicates` —
+    the bulk half of the same predicates, gated on the object verdict rather than on the
+    row `onDelete` wiring. The dialog declines to run over zero records.
+  - `@object-ui/plugin-list`'s non-grid bulk bar (kanban / calendar / gallery / …) filters
+    the built-in `delete` to the eligible subset and states the skipped count inline.
+  
+  Custom bulk action ids are untouched: they route through the action runner carrying
+  their own gates. This is a UI affordance — server enforcement was never the leak.
+- 41b7ce3: **View configuration is explicitly org-wide, and its write path is now gated (objectstack#7494's
+  ruling, maintainer 2026-08-12).** The `sort` / `hiddenFields` / `columnState` / `rowHeight` that a
+  list toolbar persists were never per-user: they are one shared row on the view, so an ordinary user
+  dragging a column or cycling density was re-styling that view for the entire organization. Nothing
+  in the console said so, and nothing stopped it. A per-user scope stays parked (objectstack#7611,
+  v18) and is deliberately not built here — which is precisely why the write has to be gated rather
+  than narrowed: there is no second, private store for it to fall back to.
+  
+  `ObjectStackAdapter.updateViewConfig` now refuses when the session's **reported** ADR-0066 capability
+  set does not contain `manage_metadata`, throwing the new `ViewConfigPermissionDeniedError`
+  (`VIEW_CONFIG_PERMISSION_DENIED`, with `isViewConfigPermissionDeniedError` and the
+  `VIEW_CONFIG_CAPABILITY` constant alongside it). The gate is the **first** statement in the method —
+  before `connect()`, before the payload is assembled — so a refused call puts nothing on the wire.
+  It is on the write rather than on the toolbar button on purpose: withholding the affordance would
+  leave the method still accepting the call from anything else holding the adapter, whereas a gate on
+  the write is inherited by every caller, present and future.
+  
+  `manage_metadata` is not a newly minted name. It is the capability this repo already treats as
+  metadata-authoring authority — `HomePage`'s `AUTHORING_CAPABILITY`, the one the server itself
+  refuses metadata writes without — and the gated write goes through `client.meta.saveItem`, the very
+  same ADR-0005 metadata door, so this applies the authority the server is already applying instead of
+  inventing a parallel one.
+  
+  **Unknown fails open, by doctrine.** A capability set that was never reported (a backend predating
+  ADR-0066, or no permission provider mounted) is not a denial: the server enforces regardless, so a
+  client-side refusal on missing data cannot protect anything and can only break a permitted user. A
+  *reported* empty grant gates strictly. Hosts push the session's capabilities in with the new
+  `setSystemCapabilities`; `ObjectView` wires it from `usePermissions()`.
+  
+  The refusal is also **said out loud**. `ObjectView`'s persist path previously swallowed every failure
+  into `console.error`, which for a debounced toggle whose UI has already moved would have left the
+  operator looking at a density they did not get; a denied write now raises a toast. And the "View
+  settings" popover — where density and field visibility are actually changed — now states the scope
+  before the operator acts: *"Grouping, color, density, and visible fields. Applies to everyone who
+  uses this view."*, translated in all ten packs.
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- b4393e5: The last three sort-axis consumers read the platform's per-column sortability signal instead
+  of re-deriving it from the field's type (objectui#6108, inheriting objectstack#10235 ruling A
+  through objectui#5729's landed contract). ListView's toolbar sort picker and both of
+  RelatedList's sort entry points — the embedded table's column headers and the `data-list`
+  sort-button row — now go through `isPlatformSortableField`, the same spelling the grid header
+  adopted; their `UNMATERIALIZED_FIELD_TYPES` / `isUnmaterializedFieldType` re-derivations are
+  deleted.
+  
+  The re-derivation was not wrong about `formula`: the platform computes its own projection from
+  the same `@objectstack/spec` storage fact, which is why the drift went unnoticed across two
+  cards. It parts company on everything the projection encodes as ABSENCE — an unknown name, a
+  dotted path a caller can put in a related list's `columns`, an unprovisioned audit column —
+  where a type read finds no field definition, answers "sortable", and offers a control the
+  runtime meets with `400 INVALID_SORT`. It parts company again on any refusal that carries no
+  `reason: virtual-type`, and it cannot follow the platform in the other direction either: a
+  field the platform now DOES order by stays withheld forever on its type alone.
+  
+  Two behaviours are deliberately unchanged. The relational carve-out stays separate from the
+  signal — the projection answers `sortable: true` for a `lookup` because the platform can order
+  by the stored foreign key, while the UI withholds because that order means nothing beside a
+  column of names — so a relational column does not get its sort back. And ListView's picker
+  still lists a field the CURRENT sort already names, which is the only way to remove a sort the
+  server refuses outright; that exception now covers platform-refused fields, not just formulas.
+  
+  A deployment that served no `sortability` key at all is a different case from "nothing is
+  sortable": that branch keeps the type read as a compatibility floor, so behaviour on a backend
+  older than objectstack#10235 (or an inline/mock data source) is byte-identical to before.
+- bd2f56a: `ListView`'s toolbar sort picker no longer persists a sort the platform refuses to order by.
+  
+  The picker keeps a platform-refused field listed while the CURRENT sort names it
+  (#6108). That exception is deliberate and stays: it is the only way a user can
+  REMOVE a sort the server answers `400 INVALID_SORT` for — withholding the option
+  unconditionally renders a blank row nobody can delete, and drops the sort silently
+  on the next edit.
+  
+  What was wrong is that the picker rendered and emitted from the same array. Editing
+  anything ELSE in that popover — adding a second sort key, resetting to the view's
+  default — re-emitted the whole array with the refused entry still in it, and the
+  host's `onSortChange` turned that into `persistViewPatch({ sort })`: a
+  personalization PUT storing a refused column, written by a user who never touched
+  that row. A view stored before the sortability signal existed therefore kept
+  re-persisting its refused `$orderby` indefinitely.
+  
+  Every `onSortChange` this component emits — the builder, the column-header sort and
+  "reset to default" — now crosses one boundary that drops what the served projection
+  refuses, while `currentSort` keeps the array whole. So what the picker LISTS and
+  what it PERSISTS are separate: the refused entry stays visible and removable,
+  removing it persists the removal, and no write carries it. This is the separation
+  #5729 already made at the grid seam (`ObjectGrid`'s `manualSort` /
+  `manualOnSortChange` pair); the picker was the second door onto the same stored
+  view state.
+  
+  Only under a served sortability projection (objectstack#10235 ruling A). `undefined`
+  means NO SIGNAL SERVED — an older deployment, an inline/mock data source — not
+  "nothing is sortable", and that branch is byte-identical in behaviour to before.
+- 15236e0: `list-view` harvests row-action predicate fields from the OBJECT's `userActions` block only — a view's toolbar policy can no longer shadow it.
+  
+  `userActions` names two different blocks. On a **view** it is toolbar policy —
+  the spec's `UserActionsConfigSchema` (`sort`, `search`, `filter`, `refresh`,
+  `rowHeight`, `addRecordForm`, `editInline`, `buttons`), which rejects `edit` by
+  name. On an **object** it is the CRUD-predicate block (`edit` / `delete` /
+  `create` carrying `visibleWhen` / `disabledWhen`, objectui#2614) — and that is
+  the only shape `listViewPredicates` can read, since its loop skips every
+  non-object value.
+  
+  `ListView` read the key view-first when building the `$select` projection
+  (`(schema as any).userActions ?? (objectDef as any)?.userActions`). A view
+  carrying a perfectly legal toolbar block therefore shadowed the object's CRUD
+  predicates, the harvest found none, and the predicate's operand left the
+  projection. CEL then faults on the absent key, fails closed, and the row
+  Edit/Delete button disappears for everyone with nothing pointing at the
+  projection — objectui#3501's failure, reached with a success receipt at every
+  step.
+  
+  This is the sibling of the `plugin-grid` read site fixed in objectui#5426, and
+  it was the worse of the two: `app-shell`'s `ObjectView` builds the view-level
+  `userActions` it hands down as an object literal of two spreads, so the left
+  operand was `{}` at worst — never nullish. The `??` never fell through, and the
+  object's CRUD predicates were never consumed at all on that path, whether or
+  not an author wrote any toolbar policy.
+  
+  The harvest now reads the object block only. Both `userActions` read sites in
+  `ListView.tsx` carry a comment naming the collision, and
+  `__tests__/ListView.userActionsCollision.test.tsx` pins each clause of it: the
+  two shapes, a producer that manufactures the view one, the harvest's blindness
+  to it, and the projection that must keep the object's operand with a toolbar
+  block — or an empty block — present on the view.
+  
+  Toolbar policy itself is untouched — it was never read through this path.
+- ec9fdaa: `ListView` now resolves the nested `aria.ariaLabel` against the audience's locale
+  instead of casting it to a string (objectui#5134).
+  
+  `@objectstack/spec`'s `AriaPropsSchema` types `ariaLabel` as `I18nLabel` — a plain
+  string **or** an inline locale map (`{ en: 'Accounts', 'zh-CN': '客户' }`). The only
+  read site in this repo spread it into the DOM as
+  `{ 'aria-label': schema.aria.ariaLabel as string }`, and `as string` is a cast, not a
+  conversion: a map-valued label reached the DOM as `aria-label="[object Object]"`, which
+  a screen reader announces as the list view's accessible name — in every locale. The
+  read now goes through the spec's own `resolveI18nLabel` (the resolver four other
+  in-repo read sites already use) against `useDisplayLocale()`.
+  
+  Reachability, stated plainly: the path is **live but unexercised**. `I18nLabel` was a
+  plain `string` through `@objectstack/spec` 17.0.0-rc.5, so no stored map-valued label
+  predates rc.6, and no measured author writes one today — but map values are legitimate
+  and arrive via API/import, so an imported list view carrying
+  `aria: { ariaLabel: { en: …, 'zh-CN': … } }` is spec-valid metadata that renders a wrong
+  accessible name. This is the map form working as declared, not a defect users are
+  currently hitting.
+  
+  Behaviour on the string arm is byte-identical, including `''` (falsy before and after,
+  so no attribute). One edge changes for the better: a map that matches no locale used to
+  render `aria-label="[object Object]"` (`{}` is truthy) and now omits the attribute — an
+  unnamed region beats a garbage-named one.
+  
+  The **flat** `schema.ariaLabel` is deliberately untouched: it carries a different
+  vocabulary (objectui's keyed `{ key, defaultValue?, params? }` ref, resolved by
+  `SchemaRenderer`'s `resolveKeyedI18nLabel`), and neither resolver accepts the other's
+  shape.
+- d6613a2: Two comment corrections in `ListView.tsx` (objectui#4559, objectui#4966). No runtime
+  behaviour changes and the emitted bundle is byte-identical; the published `.d.ts` does
+  change, which is why this is a `patch` rather than an empty frontmatter.
+  
+  **objectui#4559 — the sort rationale stopped prescribing a formula field.** The comment
+  block above the `sortFields` memo still called a formula field "the supported
+  alternative (… which sorts like any text column)". Since objectui#4294 the
+  `list.sortRelationalHint` string in this same file says the opposite ("Not a formula
+  field: it is virtual, so no column is stored for it and the server refuses to sort by
+  one"), the memo underneath filters formula out via `UNMATERIALIZED_FIELD_TYPES`, and the
+  server answers such a sort with `400 INVALID_SORT` (objectstack#6994). The parenthetical
+  now names the remedy the hint, the server's refusal and the README already share — a
+  stored field that denormalizes the name onto this object, written when the source
+  changes. This was the last copy of the retired advice in the repo.
+  
+  **objectui#4966 — `formatActionLabel`'s docblock now sits above `formatActionLabel`.**
+  It had drifted two declarations up, so the exported `parseSortConfig` carried two
+  stacked leading comments and the helper carried none. This one was not cosmetic: because
+  `parseSortConfig` is exported, `vite-plugin-dts` copied the misattributed block into
+  `dist/ListView.d.ts`, so every consumer's editor hover and TypeDoc introduced the sort
+  parser with a sentence about action labels. Moving the block removes it from the `.d.ts`;
+  `formatActionLabel` is module-private, so its now-correct docblock does not appear there.
+  It also matters to `scripts/check-spec-symbol-derivation.mjs`, whose rule 2 reads the
+  comment block *attached* to a declaration — a misattributed docblock is the mechanism by
+  which a claim gets scored against the wrong symbol. This block carries no spec-alignment
+  phrase, so nothing fired today.
+  
+  No tests accompany this change and none could: both edits are comment-only, and there is
+  no runtime behaviour to pin. The `.d.ts` delta was measured with the package's real
+  `vite build` before and after, not asserted.
+- 6c6cee7: A RETIRED field-type spelling is now refused — out loud, once — by every
+  field-type predicate in the renderer, not just by the widget road
+  (objectui#4914, maintainer ruling B of 2026-08-18).
+  
+  `@object-ui/fields` exports a single `isRetiredFieldType(t)` gate, and it runs
+  ahead of six predicate faces that previously granted a retired spelling
+  first-class treatment: the filter builder's operator buckets and its value
+  control (`@object-ui/components`), the detail page's highlight-strip picker
+  (`@object-ui/plugin-detail`), `normalizeFieldType` (`@object-ui/plugin-view`),
+  the dashboard's `$expand` whitelist and `isLookupType`
+  (`@object-ui/plugin-dashboard`), and the list toolbar's lookup-like filter
+  control (`@object-ui/plugin-list`). Each one now fires the migration
+  prescription on the console — once per spelling across all of them, never once
+  per predicate — and then answers as it would for a spelling it does not
+  recognise.
+  
+  This closes the whole CLASS rather than one word: the gate is quantified over
+  `RETIRED_FIELD_TYPES`, so the next retirement covers all seven consumers on the
+  day it lands. It is the shape objectui#4932 and objectui#4942 already
+  established for the form and inline-edit roads.
+  
+  Measured before the change, and the reason the fix is a gate rather than a
+  deletion: `owner` was not dead in these faces. `operatorsForFieldType('owner')`
+  equalled the `user` bucket item for item, `computeLookupExpand` actively
+  requested `$expand` for it, `isLookupType('owner')` was `true` alongside
+  `reference`, and `normalizeFieldType('owner')` answered `'select'` exactly as
+  `picklist` does. Deleting the members alone would have traded a visible
+  contradiction for a SILENT degradation — a filter picker collapsing to a bare id
+  box, `$expand` quietly stopping so cells show raw foreign-key ids — which is
+  verbatim the failure mode `RETIRED_FIELD_TYPES`' own docblock exists to prevent.
+  The gate keeps that fallback and adds the half that was missing: the author is
+  told.
+  
+  The boundary question is answered on record: `owner` arriving through a
+  backend-vocabulary normalizer is an authoring error to refuse loudly, not
+  legitimate foreign input to tolerate. The open backend vocabulary those
+  normalizers exist for is untouched — `reference`, `picklist`, `money`, `int`,
+  `datetime_tz` and the rest are equally absent from the spec's closed `FieldType`
+  and are equally unretired, so they classify exactly as before.
+  
+  `RETIRED_FIELD_TYPES`, `reportRetiredFieldType` and `resetRetiredFieldTypeReports`
+  move to `@object-ui/core` and are re-exported from `@object-ui/fields`, so that
+  package's published surface is unchanged apart from the newly ruled gate.
+  `@object-ui/components` is a consumer of the gate and `@object-ui/fields`
+  depends on it, so a single shared table could not live in `fields` — and a
+  second copy would have meant a second dedupe set and two console lines for one
+  spelling. No package gained a new dependency.
+  
+  A retired spelling never loses a stored value: `retypeFilterValue` is
+  deliberately not gated, and the refused filter row stays operable rather than
+  drawing a blank operator trigger.
+- 42887e0: Repair five retired lucide icon spellings that reach a record-reading resolver, and pin
+  the names against the runtime `icons` record so the next lucide bump goes red instead of
+  silently blanking a glyph (objectui#5622).
+  
+  lucide retires a spelling by dropping it from its runtime `icons` record while KEEPING it
+  as a deprecated named export. A retired name therefore still imports, still type-checks,
+  and still renders wherever it is used as a COMPONENT — and resolves to `null` wherever it
+  is used as a STRING, because every string lookup here reads that record. Nothing goes red
+  either way. Measured against the installed `lucide-react@1.31.0` (1767 record entries) at
+  implementation time.
+  
+  What a user sees change:
+  
+  - `DetailView`'s mobile Edit action (`icon: 'edit'` → `'square-pen'`) draws its icon
+    again. Its items become an `action:bar` schema whose renderers resolve `icon` through
+    `renderers/action/resolve-icon.ts`, so the touch-breakpoint edit affordance had been
+    drawing a label with nothing beside it. `Edit === SquarePen`, so the glyph is unchanged.
+  - The `ui:icon` renderer's own declared default (`'smile'` → `'face-slightly-smiling'`, in
+    both the registration `icon` and the `name` input's `defaultValue`) resolves again: the
+    designer palette entry's glyph was blank, and an `icon` dropped from that palette
+    rendered nothing plus a `console.warn`. `Smile === FaceSlightlySmiling`, so the palette
+    looks exactly as it did.
+  - `plugin-list`'s `ViewSwitcher` moves `Grid` → `Grid3x3`, `BarChart3` → `ChartColumn`
+    (both identical objects, no visual change) and `GanttChartSquare` → `ChartGantt`. The
+    gantt one IS a glyph change: it matches the spelling the sibling `plugin-view` switcher
+    landed in objectui#5586, so one view type no longer draws two different icons depending
+    on which switcher is on screen.
+  
+  Four resolvability pins are added — in `plugin-detail`, `plugin-list`, `components` and
+  alongside the `DeclaredActionsBar` fixtures. Each asserts `icons`-record MEMBERSHIP rather
+  than resolvability, because every retired spelling repaired here is the SAME component
+  object as its replacement (`Edit === SquarePen`, `Smile === FaceSlightlySmiling`,
+  `Grid === Grid3x3`, `BarChart3 === ChartColumn`, `CheckCircle === CircleCheckBig`,
+  `XCircle === CircleX` are all true): a pin that rendered the glyph, or reached for the
+  export, would pass on the broken name. That is the blindness that let this ship.
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [8d3a529]
+- Updated dependencies [194fae1]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [b362c1b]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [3c9fca3]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [9a1fb41]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [a865c73]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [e4e9557]
+- Updated dependencies [7a28e1e]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [20e317c]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [4bb940b]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [f1690d4]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/fields@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/mobile@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+  - @object-ui/permissions@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/plugin-list/package.json b/packages/plugin-list/package.json
index ac9e756364..ebbb513429 100644
--- a/packages/plugin-list/package.json
+++ b/packages/plugin-list/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-list",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "ListView plugin for Object UI - unified view component with view type switching",
diff --git a/packages/plugin-map/CHANGELOG.md b/packages/plugin-map/CHANGELOG.md
index e03920fb69..882767c3aa 100644
--- a/packages/plugin-map/CHANGELOG.md
+++ b/packages/plugin-map/CHANGELOG.md
@@ -1,5 +1,327 @@
 # @object-ui/plugin-map
 
+## 17.7.0
+
+### Patch Changes
+
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- 0a2918f: The package README stops documenting a marker-title fallback that objectui#5953 replaced.
+  
+  `README.md`'s `map` block table described `titleField` as: "Omitted, markers are
+  titled `Marker`." That was true of the pre-#5953 read site, which bound the
+  marker title to a field name directly. objectui#5953 moved the marker title onto
+  `@object-ui/core`'s `getRecordDisplayName`, and `'Marker'` is now passed only as
+  that resolver's `fallback` option — a position the resolver reaches **only for a
+  record carrying no id at all**. A record with an id and no resolvable name reads
+  `Record #<id>`; a record whose object declares a `nameField` or a `titleFormat`,
+  or which simply carries a name-ish key, reads that. So "omitted ⇒ `Marker`" was
+  true in one narrow corner and false in the common case, and an author reading the
+  row would either under-specify `titleField` for a reason that stopped being true
+  or over-specify it to avoid a `Marker` that would never have appeared.
+  
+  The row now names the precedence an omitted `titleField` hands the decision to:
+  the declared `nameField`, its deprecated `displayNameField` alias, the legacy
+  `titleFormat` template, a type-aware pick from the object's fields, then
+  name-ish keys read straight off the record — with `Record #<id>` as the floor and
+  `Marker` reached only by an id-less record.
+  
+  Two details the row states deliberately:
+  
+  - It does **not** describe an object-level `objectDef.titleField` rung. The
+    resolver consulted one at step 0 as a second `??` leg, but objectui#6531 (PR
+    #6560) removes it — `@objectstack/spec`'s object schema is a `strictObject`
+    that rejects the key with `unrecognized_keys`, so no producer can ship it.
+    What survives is `options.titleField`, which is exactly what `map.titleField`
+    becomes at `ObjectMap`'s call site, so "a declared `titleField` wins" stays
+    true either way and the row does not go stale when that lands.
+  - It names the record-key probe (the resolver's step 4b) as its own rung. That
+    is not a footnote for this component: `ObjectMap` fetches an object schema
+    only when `!hasInlineData && dataSource`, so for `staticData` or an inline
+    `data` array no object definition ever reaches the resolver and the record-key
+    probe is the only rung that can produce a title —
+    `ObjectMap.markerTitle.test.tsx` pins exactly that case.
+  
+  A second row falsified by the same commit goes with it. Two lines below the table,
+  the field-name defaults paragraph listed what an unconfigured map falls back to as
+  "`latitude` / `longitude` / `location` / `name` / `description`". objectui#5953 removed
+  the title default: `getMapConfig`'s default branch returns coordinate keys and
+  `descriptionField` only, under a comment that spells out why — "Deliberately NO
+  `titleField` (objectui#5953)… `getRecordDisplayName` resolves it from the object
+  definition, and it does so better than any literal here could". The paragraph now
+  lists the four defaults that exist and says where an unconfigured marker's title
+  actually comes from. Left alone in the same sentence: `map: { titleField: 'name' }`
+  still names no coordinate field and still renders an empty map, which is accurate.
+  
+  Prose only: no behaviour changes, and the placeholders were already pinned in
+  order by `ObjectMap.markerTitle.test.tsx`.
+- ff7543c: `ObjectMapProps.clusterRadius`'s JSDoc said "in pixels"; `clusterMarkers` has
+  always used it as a coordinate-degree grid cell edge (`radius / 2 ** zoom`,
+  divided into the marker's `[lng, lat]` degrees), not a screen-space radius —
+  a host tuning clustering granularity by the documented unit would get a
+  completely different result than intended (objectui#5020).
+  
+  No behavior, default, or name changes: clustering, the >100-visible-marker
+  auto-threshold, and tap-through zoom are unaffected, and `clusterRadius` has
+  no call sites outside `plugin-map/src` today (re-confirmed repo-wide,
+  including `apps/`, `examples/`, and the `objectstack` spec/server repo — the
+  default of `50` is what runs everywhere). This is a doc-comment correction
+  only, bringing the JSDoc in line with the README's already-correct wording
+  (post objectui#5002).
+  
+  The latitude-anisotropy trade-off (a degree grid distorts east-west as
+  latitude rises) is a known design trade-off, not part of this fix.
+- 2aac61f: `ObjectMap` now resolves marker titles through `@object-ui/core`'s
+  `getRecordDisplayName` (ADR-0079), instead of reading a hard-coded `'name'` key.
+  
+  `getMapConfig` used to fill an absent title binding with the string literal
+  `'name'`, and the marker transform then did a bare `record[titleField]` read. For
+  every object whose display field is not literally `name`, that read was
+  `undefined`, so each marker popup titled itself `undefined`. The literal is gone
+  from both branches that carried it, and the read site hands the decision to the
+  same resolver `ObjectKanban`, `ObjectCalendar` and `ObjectGantt` already title
+  their items through — `ObjectMap` was the fourth renderer and the only one still
+  outside it.
+  
+  An authored `map.titleField` keeps winning outright: it is passed through as the
+  resolver's explicit `titleField` option, which it checks first. What is new
+  underneath is everything a static field-name binding cannot express — the
+  object's declared `nameField`, its deprecated `displayNameField` alias, a legacy
+  `titleFormat` template, type-aware field derivation, and a name-ish probe over
+  the record's own keys for the inline-data case where no object definition is
+  fetched at all.
+  
+  Records with no resolvable name now read `Record #<id>` rather than `undefined`
+  or a uniform `Marker`; the `Marker` placeholder is kept only for a record that
+  carries no id either. No authoring surface changes and no new map config keys.
+- b180a64: `ObjectMap` reads `schema.data` in one place again, so an array-shorthand map stops
+  making a metadata request it never uses.
+  
+  The fetch effect carried a second short-circuit beside the `props.data` one
+  objectui#5003 fixed: it read `schema.data` directly and tested whether that value was
+  itself an array. eslint reported it as `missing dependency: schema.data` — the last
+  `react-hooks/exhaustive-deps` warning on that effect.
+  
+  The dependency was never actually missing. `getDataConfig(schema)` already returns
+  `schema.data` verbatim, and the result is memoized on `JSON.stringify(rawDataConfig)`
+  into `dataConfig`, which **is** one of the effect's declared dependencies. The authored
+  rows therefore reached the effect before this change; the direct read was a duplicate of
+  an already-threaded value, which is why neither adding a dependency nor deleting the
+  branch was right.
+  
+  The array handling moved into `getDataConfig`, where `ObjectGrid`'s own `getDataConfig`
+  already pins the same normalization (`"Check if data is an array (shorthand format)"`).
+  Same rows render, and the effect now reads only `dataConfig`.
+  
+  One behavioural consequence, and it is the point: an array under `data` now yields
+  `provider: 'value'`, so `hasInlineData` is true and the sibling effect no longer calls
+  `dataSource.getObjectSchema()` for it. That request's only read site is
+  `buildExpandFields()` inside the object-provider fetch branch, which an inline schema
+  never reaches — so the call was pure waste, and the shorthand now behaves exactly like
+  the declared `{ provider: 'value', items }` form it is shorthand for.
+  
+  Deleting the branch instead was measured, not assumed: with no producer-side handling,
+  an array-shorthand map renders `Error: DataSource required for object/api providers`
+  rather than its markers. The shorthand is a live convention in six sibling blocks
+  (`ObjectGrid`, `ListView`, `ObjectTree`, `ObjectChart`, `ObjectDataTable`,
+  `calendar-view-renderer`), so `object-map` would have become the one block in the family
+  that answers it with an error box.
+- 538ed92: `ObjectMap`: make the marker `useMemo` actually memoize.
+  
+  `getMapConfig(schema)` ran unmemoized in the render body, so `mapConfig` carried
+  a fresh object identity on every render. The marker transform names `mapConfig`
+  in its dependency array, so it recomputed on every single render — walking every
+  record through `extractCoordinates` and the display-name resolver, and re-running
+  `ObjectMapConfigSchema.safeParse` on each pass — while declaring that it does not.
+  The invalidation cascaded on into `filteredMarkers`, `clusteredData`,
+  `markerBounds` and `initialViewState`.
+  
+  `mapConfig` is now memoized on `schema`, the one value `getMapConfig` reads.
+  Behaviour is unchanged; the config is still rebuilt whenever the schema
+  genuinely changes.
+- cfcff30: Each package's README now states, up front, that it needs a bundler: importing it from plain Node ESM fails, and that is a supported-configuration boundary rather than a defect.
+  
+  `@object-ui/plugin-dashboard` imports `react-grid-layout/css/styles.css` at module
+  scope and `@object-ui/plugin-map` imports `maplibre-gl/dist/maplibre-gl.css`;
+  `@object-ui/app-shell` reaches the first of those through the static
+  `@object-ui/plugin-dashboard` imports in `DashboardView` and `ReportView`. Node has
+  no loader for `.css` at all, so all three resolve and then die during evaluation:
+  
+  ```
+  TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".css"
+    for .../react-grid-layout/css/styles.css
+  ```
+  
+  Nothing about how these packages load has changed — every supported host bundles
+  them (Vite, webpack, or Next with the package in `transpilePackages`), and that is
+  still the only supported way to consume them. What changed is that the boundary is
+  now written where a consumer meets it, instead of being learned from a red import.
+  
+  objectui#5384 ruled unbundled Node consumption **unsupported** for style-carrying
+  plugin packages — permanently, over the three packages as a group — rather than
+  moving the stylesheet imports out of module scope. No unbundled-Node consumer
+  exists, and buying permanent machinery to close a capability gap nobody is pulling
+  on was the trade the ruling declined. A real consumer request reopens it as a
+  design question, not as a defect: the READMEs say so and name the issue.
+- 2aa2c22: `ObjectMap` no longer serializes its data config on every render.
+  
+  `getDataConfig(schema)` was called bare in the render body and its result
+  re-serialized with `JSON.stringify` on every render, purely to give `dataConfig`
+  the stable identity its fetch effect depends on. `getDataConfig` is a pure
+  function of `schema`, so `useMemo(() => getDataConfig(schema), [schema])` gives
+  the same identity with no serialize and no per-render rebuild.
+  
+  This also fixes a crash. `JSON.stringify` throws on a value it cannot serialize,
+  and the config's passthrough branch returns the author's own `schema.data`
+  object verbatim — inline rows included. A map handed inline records carrying a
+  back-reference (an `$expand`-ed lookup) or a `BigInt` id threw from the render
+  body and took the whole map subtree down with it. Comparing identities never
+  serializes, so the config no longer has to be serializable at all.
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [194fae1]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/types@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/plugin-map/package.json b/packages/plugin-map/package.json
index 8411170892..3ae88bfecf 100644
--- a/packages/plugin-map/package.json
+++ b/packages/plugin-map/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-map",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Map visualization plugin for Object UI",
diff --git a/packages/plugin-markdown/CHANGELOG.md b/packages/plugin-markdown/CHANGELOG.md
index 71b4108666..f29c40700b 100644
--- a/packages/plugin-markdown/CHANGELOG.md
+++ b/packages/plugin-markdown/CHANGELOG.md
@@ -1,5 +1,156 @@
 # @object-ui/plugin-markdown
 
+## 17.7.0
+
+### Patch Changes
+
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [194fae1]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/types@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Patch Changes
diff --git a/packages/plugin-markdown/package.json b/packages/plugin-markdown/package.json
index 85553a5afc..9bf6bbca12 100644
--- a/packages/plugin-markdown/package.json
+++ b/packages/plugin-markdown/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-markdown",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Markdown rendering plugin for Object UI, powered by react-markdown",
diff --git a/packages/plugin-report/CHANGELOG.md b/packages/plugin-report/CHANGELOG.md
index d46584102e..df3e3aed0e 100644
--- a/packages/plugin-report/CHANGELOG.md
+++ b/packages/plugin-report/CHANGELOG.md
@@ -1,5 +1,239 @@
 # @object-ui/plugin-report
 
+## 17.7.0
+
+### Patch Changes
+
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- 854222c: `@object-ui/plugin-report` now registers its three components under namespace
+  **`plugin-report`**, the spelling its consumers already declare (objectui#6416).
+  
+  It used to register `report`, `spec-report` and `report-viewer` under namespace
+  `report`, while `apps/console` declared the lazy stubs for the same three short
+  names under `plugin-report` and the CLI's known-type whitelist shipped the
+  `plugin-report:*` spellings as renderable. Two things followed from the
+  disagreement:
+  
+  - **`plugin-report:report`, `plugin-report:report-viewer` and
+    `plugin-report:spec-report` could never be satisfied.** `Registry.register`
+    clears the lazy stub for the type IT registers, and that type was
+    `report:report`, so those three stubs were never cleared and no component was
+    ever stored under them: `get('report', 'plugin-report')` returned `undefined`
+    and `hasLazy('report', 'plugin-report')` stayed `true` forever. A schema
+    authored with any of the three whitelisted keys resolved to nothing — the
+    gate handed authors a green light for a key the runtime could not satisfy.
+  - **The bare `report` key was claimed twice under two different namespaces.**
+    `Registry.register` and `Registry.registerLazy` share the
+    `meta?.namespace && !meta?.skipFallback` branch, so what bare `report`
+    *declared* depended on whether the plugin chunk had loaded yet — the
+    objectui#6353 shape.
+  
+  **No authored metadata changes.** The direction was chosen by measurement:
+  nothing in this repository, and nothing in the sibling `objectstack` checkout,
+  authors a `report:*` spelling (0 hits), while the bare spellings are authored in
+  48 places. `type: 'report'`, `type: 'spec-report'` and `type: 'report-viewer'`
+  resolve exactly as before; the three unreachable `report:*` keys are retired and
+  the three `plugin-report:*` keys now name real components for the first time.
+  
+  `packages/cli/src/utils/known-schema-types.ts` is regenerated from the
+  registrations, dropping `report:report`, `report:report-viewer` and
+  `report:spec-report`.
+  
+  Two pins are the half that outlives the fix:
+  `packages/plugin-report/src/__tests__/report-bare-key-ownership.test.ts` replays
+  this package's real declared metadata and a console-shaped lazy stub into a
+  fresh `Registry` in **both** registration orders, checking the bare key's
+  declared namespace after every step, so order- and phase-independence are
+  properties under test rather than properties of the file the test imports.
+  `scripts/__tests__/report-namespace-agreement-6416.test.ts` re-derives both
+  sites from source and fails if the plugin, the console stubs and the generated
+  whitelist ever disagree again.
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [2d7304d]
+- Updated dependencies [062943f]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [8d3a529]
+- Updated dependencies [194fae1]
+- Updated dependencies [beccf1c]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [c38162d]
+- Updated dependencies [b362c1b]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [9a1fb41]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [9e22085]
+- Updated dependencies [b655a9d]
+- Updated dependencies [c574dfb]
+- Updated dependencies [02f48b6]
+- Updated dependencies [a865c73]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [e4e9557]
+- Updated dependencies [7a28e1e]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [20e317c]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [4bb940b]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [f1690d4]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [591bf27]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/fields@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/plugin-grid@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/plugin-report/package.json b/packages/plugin-report/package.json
index e138a63545..c3ead0a029 100644
--- a/packages/plugin-report/package.json
+++ b/packages/plugin-report/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-report",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "main": "dist/index.umd.cjs",
   "module": "dist/index.js",
diff --git a/packages/plugin-timeline/CHANGELOG.md b/packages/plugin-timeline/CHANGELOG.md
index 1752c39e3a..54bb05a957 100644
--- a/packages/plugin-timeline/CHANGELOG.md
+++ b/packages/plugin-timeline/CHANGELOG.md
@@ -1,5 +1,259 @@
 # @object-ui/plugin-timeline
 
+## 17.7.0
+
+### Minor Changes
+
+- e4559d1: `TimelineSchema` now declares the presentational keys the timeline renderer actually reads
+  (objectui#6170, maintainer ruling 2026-08-25 — the same family rule adopted on
+  objectui#6172: the exported type aligns to the measured authored + read set).
+  
+  Before this, `TimelineSchema` declared `events` (required), `orientation` and `position`,
+  and nothing else. `TimelineRenderer` is annotated `schema: TimelineSchema` and reads nine
+  keys off that node — `variant`, `items`, `dateFormat`, `onItemClick`, `minDate`, `maxDate`,
+  `rowLabel`, `scale`, `timeScale` — and **none** of the three that were declared. The docs
+  property table and the registration's own designer `inputs` had agreed with the renderer
+  all along; only the exported type disagreed. It was invisible to `tsc` because `BaseSchema`
+  carries `[key: string]: any`, so every undeclared key resolved as `any` and the annotation
+  constrained nothing.
+  
+  The most visible casualty was the docs page's own TypeScript example, which did not
+  compile: `Property 'events' is missing in type '{ type: "timeline"; variant: string; items:
+  … }' but required in type 'TimelineSchema'`. The page taught an authoring form its own
+  published type refused.
+  
+  **Declared now** (TS interface and the `@object-ui/types/zod` mirror together): `variant`,
+  `items`, `dateFormat`, `scale`, `timeScale`, `rowLabel`, `minDate`, `maxDate`. `onItemClick`
+  is deliberately left undeclared — it is a runtime slot `ObjectTimeline` installs, and this
+  package keeps callback-shaped keys off the authored surface.
+  
+  **`scale` is the canonical axis key.** It is `@objectstack/spec`'s `ui/TimelineConfig.json`
+  spelling and the one `resolveTimelineScale` reads first (`scale ?? timeScale`). The designer
+  now offers it, with all six buckets: `hour` / `quarter` / `year` have rendered correctly
+  since objectui#2942 but were offered by neither the designer (which listed three) nor the
+  exported type (which listed none), so they were authorable and undiscoverable. `timeScale`
+  stays as a deprecated alias so stored JSON keeps working; retiring it is routed separately.
+  
+  **`events` is now optional.** It was required, which is why the documented authoring form
+  did not type-check. That widening is the only non-additive change here — strictly more
+  programs compile and strictly more input parses than before. `events`, `orientation` and
+  `position` remain declared and remain read by nothing; a timeline authored with `events`
+  still renders an empty rail. Their removal is a breaking narrowing of a published type and
+  is routed through ADR-0049 enforce-or-remove as its own change, not smuggled into this one.
+  
+  Accept-set note for consumers: keys that previously resolved as `any` are now typed, so a
+  value the renderer never implemented — `variant: 'diagonal'`, `dateFormat: 'medieval'`,
+  `scale: 'fortnight'` — is a type error and a Zod rejection where it used to pass silently.
+  Nothing that renders today stops rendering. `BaseSchema`'s index signature is untouched, so
+  an undeclared key is still accepted by both halves (objectui#5155 / objectui#6269 own that
+  ceiling).
+
+### Patch Changes
+
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- d813e8b: The bare `timeline` component key is now owned by DECLARATION rather than by
+  module-evaluation order (objectui#6353).
+  
+  `packages/plugin-timeline` registers the same short name twice —
+  `plugin-timeline:timeline` (`src/renderer.tsx`, the presentational renderer) and
+  `view:timeline` (`src/index.tsx`, the object-bound `ObjectTimelineRenderer`). Neither
+  passed `skipFallback`, so under `Registry.register` both also claimed the **bare**
+  `timeline` key and the last module to evaluate won it. `src/index.tsx` re-exports
+  `./renderer` (line 300) before its own `import` (line 307), so the presentational one
+  registered first and the object-bound one overwrote it.
+  
+  The resolved outcome was the intended one and **does not change here**: `type:
+  'timeline'` still renders `ObjectTimelineRenderer`, which delegates inward to the
+  presentational renderer. What changes is that it is now decided rather than inherited.
+  Reordering those two lines would previously have handed `type: 'timeline'` to the
+  presentational renderer, which reads none of the object-bound keys (`object`, `filter`,
+  `sort`, `limit`) — an authored timeline would have stopped fetching, with no error and
+  no failing test. The registry's own collision guard names this remedy in its warning
+  text; this applies it.
+  
+  `src/renderer.tsx` now registers with `skipFallback: true`, so only `view:timeline`
+  claims the bare key, in any evaluation order. The presentational renderer stays
+  reachable under its explicit `plugin-timeline:timeline` key, which is the lookup a
+  presentational host already uses — no consumer-visible resolution changes.
+  
+  `src/__tests__/timeline-bare-key-ownership.test.ts` is the half that outlives the fix:
+  it fails if the declaration is dropped, if a third registration starts claiming the bare
+  key, or if resolution becomes order-dependent again. It reads both registrations' real
+  declared metadata back out of the registry and replays them into a fresh `Registry` in
+  **both** orders, so order-independence is a property under test rather than a property
+  of the file the test happens to import.
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [8d3a529]
+- Updated dependencies [194fae1]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [b362c1b]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [20e317c]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/mobile@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Patch Changes
diff --git a/packages/plugin-timeline/package.json b/packages/plugin-timeline/package.json
index 2dd25ee316..88d00f1e31 100644
--- a/packages/plugin-timeline/package.json
+++ b/packages/plugin-timeline/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-timeline",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Timeline component plugin for Object UI",
diff --git a/packages/plugin-tree/CHANGELOG.md b/packages/plugin-tree/CHANGELOG.md
index 70c8973ff7..772f89b373 100644
--- a/packages/plugin-tree/CHANGELOG.md
+++ b/packages/plugin-tree/CHANGELOG.md
@@ -1,5 +1,224 @@
 # @object-ui/plugin-tree
 
+## 17.7.0
+
+### Patch Changes
+
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- b00fcba: `ObjectTree` formats its cells the way the flat table does: a lookup column renders the
+  referenced record's display name and a select column renders its translated option label,
+  instead of a raw record id and the raw stored value (objectui#6014).
+  
+  Reported against the built-in 业务单元 (`sys_business_unit`) page, whose 「组织架构」 tree tab
+  showed the manager column as a bare user id and the type column as `department`, while the
+  flat-table tab on the same page — over the same expanded records — showed the user's name
+  and 「部门」.
+  
+  The card carried its own control, and it pointed at the fetch rather than the formatter. The
+  tree treated "the host passed inline `data`" as "I do not need the object schema" and skipped
+  `getObjectSchema`, but its record-fetch branch prefers a live object dataSource over any
+  inline data. On the one mount shape `ListView` actually uses — `objectName` + a dataSource +
+  its own pre-fetched `data` — the tree therefore issued its OWN query with
+  `buildExpandFields(undefined)` → `[]` → no `$expand` at all, and had no field definitions to
+  format cells from. Both reported symptoms fall out of that single gap, which is why the flat
+  tab was unaffected and why the tree's existing tests (inline data, no dataSource — a path
+  that never runs the tree's own fetch) could not see it.
+  
+  Three changes, all inside `packages/plugin-tree`:
+  
+  - The object schema is fetched whenever the dataSource can serve one, not only when no host
+    passed inline data. The guard inside the fetch already no-ops without a dataSource, so the
+    pure inline/static path is unaffected.
+  - Records are no longer fetched until that schema has settled — settled, not necessarily
+    successful, so a rejected or inapplicable schema fetch can never block the tree. This also
+    removes a wasted first query whose lookup columns came back as bare ids and were painted
+    for a moment before the real query landed.
+  - Cell values route through a field-aware formatter that delegates both decisions rather than
+    re-deciding them: option labels through the `translateOptions` seam `ObjectGrid` already
+    uses for the flat tab (so both tabs read one `fieldOptions.*` i18n key, with the same
+    exact-then-case-insensitive match and `humanizeLabel` fallback as `SelectCellRenderer`), and
+    expanded references through `getRecordDisplayName`, the unified display-name resolver
+    (ADR-0079), with the family judged by `isExpandableFieldType` — the same predicate that
+    decided what to put in `$expand`.
+  
+  No new exports and no new package dependencies: both resolvers were already published from
+  `@object-ui/core`, and `translateOptions` was already reachable through the `useSafeFieldLabel`
+  hook this component calls for its column headers.
+  
+  One visible consequence beyond the report: an expanded record that comes back with no name-ish
+  field now reads as ADR-0079's `Record #<id>` floor — the string every other surface shows for
+  it — rather than as the bare id.
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [8d3a529]
+- Updated dependencies [194fae1]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [b362c1b]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [20e317c]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Patch Changes
diff --git a/packages/plugin-tree/package.json b/packages/plugin-tree/package.json
index 3efeb26d07..579ff23a7a 100644
--- a/packages/plugin-tree/package.json
+++ b/packages/plugin-tree/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-tree",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Tree / tree-grid visualization plugin for Object UI",
diff --git a/packages/plugin-view/CHANGELOG.md b/packages/plugin-view/CHANGELOG.md
index e0af743c3d..46b0b8e73d 100644
--- a/packages/plugin-view/CHANGELOG.md
+++ b/packages/plugin-view/CHANGELOG.md
@@ -1,5 +1,541 @@
 # @object-ui/plugin-view
 
+## 17.7.0
+
+### Minor Changes
+
+- 53dc89d: **Breaking (shipped as `minor` per AGENTS.md §版本号策略).** `ObjectViewProps.views[].sort`
+  now spells its direction key **`order`**. The retired spelling is **`direction`** — named
+  here so that a host still writing it can find this entry by searching the old key
+  (objectui#5293).
+  
+  ```diff
+    <ObjectView
+      views={[{
+        id: 'recent', label: 'Recent', type: 'grid',
+  -     sort: [{ field: 'created_at', direction: 'desc' }],
+  +     sort: [{ field: 'created_at', order: 'desc' }],
+      }]}
+    />
+  ```
+  
+  **Nothing that worked stops working on this surface, because on the `views` prop
+  `direction` never worked.** All three consumers of the resolved `activeView.sort` read
+  `order`: the non-grid fetch lowers it through the shared sink `convertSortToQueryParams`,
+  whose `entry.order === 'desc'` is false for a missing key; the grid path forwards it to
+  `ObjectGridSchema.sort`, where `ObjectGrid` builds the wire string `` `${s.field} ${s.order}` ``
+  — literally `"created_at undefined"` — and `parseSchemaSort` reads a missing `order` as
+  ascending, so the column header even drew an ascending arrow; `mergedSort` hands the same
+  value to the delegated list view.
+  
+  So a host writing the exact shape the prop declared got an **ascending** list with no
+  failure signal anywhere: the declaration said the value was well-formed, and the direction
+  was dropped at three independent readers rather than rejected at one. This rename does not
+  take away a feature — it converts a silent wrong answer into a loud type error at the one
+  place that can still be fixed cheaply.
+  
+  **Scope — one published export still accepts `direction`, and this release does not retire
+  it.** `toSortItems` (`packages/plugin-view/src/config/view-config-utils.ts`, re-exported
+  from the package root and listed in the README) folds `s.order || s.direction || 'asc'`.
+  It serves a different surface — the studio inspector-draft that feeds `SortBuilder` — and
+  it is not reachable from the `views` prop, so it neither affects nor is affected by this
+  rename. If you migrate by searching for the old key, that is the other hit you will find:
+  it is dormant (nothing in this repo calls it outside a test), and removing it would be a
+  separate break on a separate public export, tracked as objectui#6011. It is not a partial
+  retirement of this one.
+  
+  `order` is the spelling every other sort surface already uses (`SortConfig`,
+  `NamedListView.sort`, `ObjectGridSchema.sort` / `.defaultSort`, and the shared
+  `QuerySortEntry` sink), so the prop now has one spelling repo-wide and declared equals
+  enforced.
+  
+  ⛔ Deliberately **not** a tolerant dual-read (`direction ?? order`): that is the tolerance
+  layer objectui#4869 ruled against, and admitting the old key as an alias would rebuild the
+  drift this change removes. `SortUI` is untouched — it legitimately owns `direction` on its
+  own `SortUISchema` and converts at its boundaries.
+- c5fbe0b: **Breaking (shipped as `minor` per AGENTS.md §版本号策略).** The published `toSortItems`
+  export now reads its sort direction from **`order`** only. The retired spelling is
+  **`direction`** — named here so that a host still writing it can find this entry by
+  searching the old key (objectui#6011).
+  
+  ```diff
+    import { toSortItems } from '@object-ui/plugin-view';
+  
+  - toSortItems([{ field: 'created_at', direction: 'desc' }]);
+  + toSortItems([{ field: 'created_at', order: 'desc' }]);
+  ```
+  
+  **What changed, exactly.** `toSortItems` folded `s.order || s.direction || 'asc'`: two
+  spellings for one key, silently preferring the canonical one. It now folds
+  `s.order || 'asc'`. Everything else about the helper is unchanged — `id` is still
+  preserved when present and minted with `crypto.randomUUID()` otherwise, `field` still
+  defaults to `''`, and a non-array draft still yields `[]`.
+  
+  **The failure mode if you do not migrate is silent.** A draft entry spelled
+  `{ field: 'created_at', direction: 'desc' }` used to produce
+  `{ field: 'created_at', order: 'desc' }`; it now produces
+  `{ field: 'created_at', order: 'asc' }` — the documented default for an entry that names
+  no direction. Nothing throws and nothing warns: the `SortBuilder` row renders, and it
+  renders **ascending**. If you have a studio inspector draft, a persisted view body, or any
+  other producer that still writes `direction`, grep for the key and re-spell it to `order`.
+  
+  **Why the tolerant read went rather than staying.** objectui#4869 ruled that a spelling the
+  sink does not recognise gets ruled into the contract or rejected at the producer, never
+  absorbed by a tolerance layer. objectui#5293 retired the same word on
+  `ObjectViewProps.views[].sort` and shipped it as a `minor`; this entry finishes the job on
+  the sort family's public surface, so `order` is now the one spelling repo-wide and declared
+  equals enforced. The scope note in the objectui#5293 entry — that this export was *not*
+  retired by that change — described that release's scope correctly and is superseded here.
+  
+  `SortUI` is untouched. Its own file-local `toSortItems` is a different symbol, and
+  `direction` is the key `SortUISchema` legitimately declares.
+- 4ef29f0: Remove the inert `showRefresh` designer input from the `object-view` registration (objectui#5567).
+  
+  The `object-view` designer no longer offers a "Show Refresh Button" toggle, and the registration no longer defaults `showRefresh: true`. The key was declared, documented, and defaulted, but `ObjectView` never read it — an author who wrote `showRefresh: false` on an `object-view` node always got a no-op. **Behaviour is unchanged for every existing app**, because nothing ever consumed the key.
+  
+  Migration: nothing to do. If you wrote `showRefresh` on an `object-view` node, the key simply disappears from the designer's property panel; it never controlled anything. The live refresh channel is `userActions.refresh` (rendered by the list toolbar in `@object-ui/plugin-list`), which is unaffected. `showRefresh` on other surfaces (e.g. `CRUDToolbar`) is also unaffected.
+  
+  `@object-ui/app-shell` only drops its two producer writes of the dead key (the app `ObjectView` wrapper and the metadata-admin `ViewPreview`) — no user-visible change.
+- 2d36552: Pins `@objectstack/spec`, `@objectstack/client`, `@objectstack/formula` and `@objectstack/lint` to `17.1.0`, and adapts the two consumer surfaces the new build moves.
+  
+  The pin itself is a lockfile refresh — every manifest already declared `^17.0.0`, which admits `17.1.0`, so no dependency range changed. All four move together: a split resolution is what produced the dual-version spec graph that reddened `check:spec-symbols` in this repo's history.
+  
+  **A `icontains` filter now reaches the driver as a filter.** `icontains` is a canonical `VIEW_FILTER_OPERATORS` member as of `17.1.0`, so an author can declare it on a `ViewFilterRule` and the spec validates it — but `@object-ui/data-objectstack`'s alias table had no row for it, and an unmapped operator is how this adapter shipped an unfiltered query before (objectstack#3948). It is an identity row like `contains`: `icontains` is itself a member of `VALID_AST_OPERATORS`, so the spelling the author writes is the spelling the AST takes, and no case-sensitivity is translated away. Declared rather than left to the table's `?? op` fall-through, on the rule its own parity test states — the AST gate accepting a spelling is not the driver compiling it into a `WHERE` clause.
+  
+  The same operator reaches the list view's own bridge: `@object-ui/plugin-list`'s `mapOperator` gains an explicit `icontains` arm. The emitted spelling is identical to the input, but the arm is written out rather than left to the `default` passthrough — `icontains` is its own member of `VALID_AST_OPERATORS`, so a raw passthrough is accepted *today*, and depending on that coincidence is what the bridge's own parity test records as how it once stopped discriminating.
+  
+  `@object-ui/core` adds `onSuccess` to its spec key inventory, so an author writing the key `17.1.0` now declares is no longer warned that it is unknown. That is a diagnostic statement only — the four declared action surfaces still drop the key before it reaches the runner, which is tracked separately.
+  
+  **A stored view filtering case-insensitively still shows that operator when it is reopened.** `@object-ui/plugin-view`'s canonical-to-builder table is keyed by `ViewFilterOperator`, so `17.1.0` adding `icontains` failed to compile rather than letting the operator reach the FilterBuilder as a raw spelling its dropdown cannot select. It maps to the builder's `containsCaseInsensitive` — the id that authors the spec's `$icontains` — and deliberately not to `contains`, which would quietly rewrite a case-insensitive filter into a case-sensitive one the next time the view was saved.
+  
+  **The page-editor palette keeps one entry per renderer.** `17.1.0` retires `element:filter` from `PageComponentType` and adds `record:discussion`, leaving the member count at 34 either side — so the swap is invisible to any count-based reading. The stale `element:filter` exclusion is dropped, and `record:discussion` is excluded because it is the *same renderer* as the already-offered `record:chatter`, not because it is unauthorable. Nothing the palette offers changes.
+  
+  **The console eager-closure ceiling is re-baselined, by maintainer ruling.** The release is roughly 930 KB larger uncompressed and nearly all of it lands in `vendor-objectstack-*.js`, which put the closure past a ceiling that was deliberately sized to catch a 89 KiB regression — the gate refused the bump, correctly. Raising it was escalated rather than taken locally, because gate-strength policy had been ruled the maintainer's; the ruling on objectui#5531 authorised the raise. `MAX_EAGER_CLOSURE_GZIP_BYTES` and the `BASELINE` it is derived from move together in one commit, keeping headroom at 2.00% and below the 91,136-byte regression size the gate must still catch. The gate's *sensitivity* is untouched: a repeat of that regression from the new baseline still fails. No behaviour ships from this file — it is CI policy, recorded here because the version it governs is the one this changeset publishes.
+
+### Patch Changes
+
+- 39f4309: Published typings from every `vite-plugin-dts` package now carry an explicit extension on
+  every relative specifier, and a type error in the declaration build now fails the build
+  instead of being printed and ignored (objectui#5439, objectui#5483).
+  
+  **Consumers on `moduleResolution: nodenext` or `node16` may see NEW type errors, and that
+  is the fix working.** These packages re-export mostly through NAMED re-exports —
+  `export { useObjectChat } from './useObjectChat'`. TypeScript could not follow the
+  extensionless hop, but it still DECLARED the name, so the symbol resolved to a silent
+  `any`. Nothing errored; consumers simply got no types. With the extension emitted, the
+  symbol carries its real type, and any call site that was relying on the `any` now type
+  checks for the first time. This is the mode that produced the 21 residual `TS7006` on
+  `@object-ui/app-shell` reported against objectui#5365 — a type hole that opened quietly,
+  unlike objectui#5365's own `export * from './ui'` packages where the same defect surfaced
+  immediately as `TS2305: has no exported member`.
+  
+  410 extensionless relative specifiers across 19 packages were emitted before this change;
+  the count is now 0 in all 22 packages that build typings through `vite-plugin-dts`.
+  `@object-ui/fields` was already clean — its sources write explicit `.js` specifiers — and
+  is wired so it stays that way.
+  
+  The second half changes no emitted output today: 22/22 packages built green unmodified, so
+  making the declaration step's exit code honest turns nothing red. It changes what a FUTURE
+  regression does — print and exit 0, versus fail the build.
+- 9caa7d4: `ObjectView` wraps `table.defaultSort` before handing it to a delegated list view, so a
+  view whose only ordering is the deprecated key actually sorts (objectui#6235).
+  
+  `ObjectGridSchema.defaultSort` is declared a SINGLE `{ field, order }` object — the zod
+  mirror agrees (`z.object({ field, order })`, not a union) — while the `list-view` node's
+  `sort` slot is declared `string | SortConfig[]`, imported by reference from the spec's own
+  `ListViewSchema`. `mergedSort`'s last branch forwarded the bare object into that slot
+  unwrapped. The three branches ahead of it all produce an array or a string, so this was the
+  one shape the slot never declared.
+  
+  Nothing crashed and nothing warned: every reader of that slot drops an unparseable sort
+  silently. `ListView.parseSortConfig` and `ObjectGrid.parseSchemaSort` both open
+  `typeof sort === 'string' ? [sort] : Array.isArray(sort) ? sort : []`, so a bare object
+  yields `[]`; the shared sink `convertSortToQueryParams` returns `undefined` for it. Both
+  in-tree hosts feed the slot straight into `ListView` (`app-shell`'s `fullSchema` and
+  Studio's `renderStudioGridList`), so the symptom was an unsorted list with no error —
+  while the SAME metadata sorted correctly as a grid, because `ObjectGrid` performs this
+  lowering for the same pair.
+  
+  The wrap is verbatim the one the non-grid fetch path in this same file already applies
+  (`|| (schema.table?.defaultSort ? [schema.table.defaultSort] : undefined)`), so all three
+  consumers now agree and no fourth dialect is introduced. The shared sink is deliberately
+  NOT widened to accept a bare `{ field, order }`: that is the widening the maintainer ruling
+  of 2026-08-22 rejected on the merits, because the same slot legitimately carries
+  `$orderby`'s own `Record<field, direction>` map, in which `{ field: 'desc' }` is a legal
+  ordering by a column literally named `field`.
+  
+  Precedence is unchanged — a named view's sort still outranks `table.sort`, which still
+  outranks `table.defaultSort`. Only the final branch changes shape.
+  
+  One behaviour note for hosts writing off-schema metadata: an ARRAY in `table.defaultSort`
+  was previously forwarded verbatim by this path alone and is now lowered like every other
+  resolver in the repo, which leaves it unreadable rather than rescuing it. That input is
+  already refused by the zod mirror and already behaves this way on the fetch path and in
+  `ObjectGrid`; the canonical slot for an array is `table.sort`.
+- e929c56: `ObjectView`'s non-grid fetch now carries `$expand` (objectui#6419). The effect built its
+  expand set from `objectSchemaRef.current` — a ref assigned in the render body, deliberately
+  kept out of the effect's dependency list so the effect would run exactly once per mount. On
+  that one run the ref was still `null`, so `buildExpandFields` saw no fields and the query
+  went out as `{ $top: 100 }` with no `$expand` at all; because the effect never re-ran on the
+  schema's arrival, it never went out with one either.
+  
+  `ObjectView` hands the rows it fetches to the child view as `data={data}`, which suppresses
+  that child's own fetch. So every lookup / master_detail / user / tree field in the six
+  non-grid views it hosts — kanban, calendar, gallery, timeline, gantt, map — rendered from
+  raw foreign-key ids: blank on the kanban (its `resolveDisplay` suppresses opaque ids) and
+  potentially the raw id on the other five.
+  
+  The object schema and the fact that its read has SETTLED are now one piece of state, keyed
+  by object name, and the record query waits on it — the shape `ObjectKanban` adopted in
+  objectui#6271. The gate is on the read having settled, **not** on a truthy schema: a view
+  whose adapter exposes no `getObjectSchema`, or whose read threw, still queries (unexpanded)
+  rather than waiting forever, and switching objects closes the gate in the same commit rather
+  than sending the previous object's expand set.
+  
+  The trade was measured on this effect rather than inherited, because it has five more
+  dependencies than the board's. With an instrumented adapter (schema and `find` both 30ms)
+  across four host regimes: before, one query with no `$expand` and one raw delivery to the
+  child; with `objectSchema` merely added to the dependency list, two queries and two
+  deliveries — `raw` then `expanded`, a visible two-step paint, because here the raw rows
+  settle into state *before* the re-run's cleanup rather than being discarded as they were on
+  the board; gated, one query carrying `$expand` the first time and a single expanded
+  delivery, with correct rows landing at the same wall clock as the dependency version.
+- 6a7893d: `ObjectView`'s non-grid fetch no longer re-queries once per parent render when the host
+  passes an inline `views` array (objectui#6460).
+  
+  The effect that fetches rows for the six non-grid view types (kanban, calendar, gallery,
+  timeline, gantt, map) listed `activeView` — an **element of the `views` prop array** — among
+  its dependencies. A host writing `views={[{ id: 'cal', type: 'calendar', label: … }]}`, which
+  is how this component's own docs write it, produces a fresh element object on every one of
+  its own renders, so the dependency changed identity every render and a new `find()` went out
+  each time. Measured with an instrumented adapter and three parent re-renders: **4 queries
+  where a hoisted array gives 1**. Because `ObjectView` hands its rows to the child view as
+  `data={data}`, each extra query also re-delivered a fresh row array downstream — the
+  "duplicate events in child views like the calendar" hazard, from the re-run direction.
+  
+  The effect now depends on the **values it reads** — the active view's `filter` and `sort`,
+  plus its `id` — held at a steady reference while they are structurally unchanged, instead of
+  on the view object's identity. Asking hosts to hoist the array was considered and rejected:
+  that is a contract change on every caller of a published component, and it leaves the defect
+  live for every host that does not comply.
+  
+  Nothing about precedence moves: a named `listViews` config's `filter`/`sort` still outrank
+  the view's, which still outrank `table.filter`/`table.sort` and their deprecated aliases.
+  Changing a view's filter, changing its sort, and switching the active view all still
+  re-fetch. The comparison never serializes, so it stays correct for filter and sort values
+  that have no faithful stringification — a `Date`, a function, a `Map`, `NaN`, or plain
+  key-order instability — and every case it cannot model resolves to "changed", which costs a
+  redundant query rather than withholding a needed one.
+- cad512f: A host-composed `tree` view is now labelled with the tree icon in `ObjectView`'s
+  view switcher instead of the grid one, and the `tree` / `chart` view types are
+  recorded as host-composition-only surfaces (objectui#5321).
+  
+  `viewSwitcherSchema`'s `iconMap` carried an entry for every view type except
+  `tree`, so a tree view fell through to the `|| 'table'` fallback and was drawn
+  with the grid glyph. objectui#2916 fixed exactly this once, for `chart`, by
+  adding a single key — nothing recorded that the map had to be COMPLETE, so the
+  next missing member went unnoticed. The map is now typed
+  `Record<ViewType, string>`, which is how `ViewSwitcher`'s own
+  `DEFAULT_VIEW_ICONS` (the consumer of these strings) has always been declared:
+  a future `ViewType` member fails `type-check` rather than silently rendering as
+  a grid. The `tree` value is `'list-tree'`, the same `ListTree` glyph
+  `DEFAULT_VIEW_ICONS` already names for this view type, and the runtime fallback
+  stays for host props that carry an unrecognised type. Reached in practice by
+  the console, whose `CreateViewDialog` offers `tree` among the view types a user
+  can create.
+  
+  No authoring surface changes. `generateViewSchema` renders eight view types
+  while `ObjectViewSchema.defaultViewType` and `NamedListView.type` admit six of
+  them, so `tree` and `chart` are selectable only through the component's `views`
+  prop. The maintainer ruled on 2026-08-20 that both stay recorded as
+  host-composition-only rather than being added to those unions, following the
+  objectui#5097 precedent; the record now lives beside that one, with the branch
+  set derived from a source fence, the authored unions pinned at the type level,
+  and host reachability measured.
+- cfc2c7a: **Bug fix:** a non-grid `object-view` (calendar / kanban / gallery / timeline)
+  whose sort came from the deprecated `table.defaultSort` no longer comes back
+  empty. `ObjectGridSchema.defaultSort` is declared a single `{ field, order }`
+  object, and `ObjectView`'s own fetch handed it to `$orderby` verbatim — where
+  the ObjectStack adapter reads it as an `$orderby` map and folds it with
+  `Object.entries`, so the request went out sorting by two columns literally
+  named `field` and `order`. The server answers `400 INVALID_SORT`, `ObjectView`
+  swallows the error, and the view rendered with no records — while the *same*
+  metadata sorted correctly as a grid, because `ObjectGrid` lowers that pair
+  before using it (objectui#4869, maintainer ruling 2026-08-22).
+  
+  `ObjectView` now performs the same legacy-to-canonical lowering `ObjectGrid`
+  already does (`sort ?? (defaultSort ? [defaultSort] : undefined)`) and routes
+  the whole chain — named view sort, `views` prop sort, `table.sort`,
+  `table.defaultSort` — through the shared `convertSortToQueryParams` sink. This
+  was the last object-bound read site sending an authored sort to `$orderby`
+  unlowered; every other block (gantt, map, calendar, timeline,
+  `record:line_items`) already did, so an adapter that implements `find` itself
+  now receives one normalized `Record<field, direction>` from all of them instead
+  of two different dialects.
+  
+  Precedence is unchanged, and both spellings of the pair keep working. The
+  shared sink was deliberately **not** widened to accept a bare `{ field, order }`:
+  its input slot also legitimately carries `$orderby`'s own map, in which
+  `{ field: 'desc' }` is a valid ordering by a column named `field`, so widening
+  it would make one shared function guess.
+  
+  Two visible shape changes on the wire, both semantically identical to before: a
+  string `table.sort` such as `'name desc'` now serializes as `-name` rather than
+  riding through as `name desc`, and a `SortConfig[]` arrives as a map rather than
+  as an array.
+- 6c6cee7: A RETIRED field-type spelling is now refused — out loud, once — by every
+  field-type predicate in the renderer, not just by the widget road
+  (objectui#4914, maintainer ruling B of 2026-08-18).
+  
+  `@object-ui/fields` exports a single `isRetiredFieldType(t)` gate, and it runs
+  ahead of six predicate faces that previously granted a retired spelling
+  first-class treatment: the filter builder's operator buckets and its value
+  control (`@object-ui/components`), the detail page's highlight-strip picker
+  (`@object-ui/plugin-detail`), `normalizeFieldType` (`@object-ui/plugin-view`),
+  the dashboard's `$expand` whitelist and `isLookupType`
+  (`@object-ui/plugin-dashboard`), and the list toolbar's lookup-like filter
+  control (`@object-ui/plugin-list`). Each one now fires the migration
+  prescription on the console — once per spelling across all of them, never once
+  per predicate — and then answers as it would for a spelling it does not
+  recognise.
+  
+  This closes the whole CLASS rather than one word: the gate is quantified over
+  `RETIRED_FIELD_TYPES`, so the next retirement covers all seven consumers on the
+  day it lands. It is the shape objectui#4932 and objectui#4942 already
+  established for the form and inline-edit roads.
+  
+  Measured before the change, and the reason the fix is a gate rather than a
+  deletion: `owner` was not dead in these faces. `operatorsForFieldType('owner')`
+  equalled the `user` bucket item for item, `computeLookupExpand` actively
+  requested `$expand` for it, `isLookupType('owner')` was `true` alongside
+  `reference`, and `normalizeFieldType('owner')` answered `'select'` exactly as
+  `picklist` does. Deleting the members alone would have traded a visible
+  contradiction for a SILENT degradation — a filter picker collapsing to a bare id
+  box, `$expand` quietly stopping so cells show raw foreign-key ids — which is
+  verbatim the failure mode `RETIRED_FIELD_TYPES`' own docblock exists to prevent.
+  The gate keeps that fallback and adds the half that was missing: the author is
+  told.
+  
+  The boundary question is answered on record: `owner` arriving through a
+  backend-vocabulary normalizer is an authoring error to refuse loudly, not
+  legitimate foreign input to tolerate. The open backend vocabulary those
+  normalizers exist for is untouched — `reference`, `picklist`, `money`, `int`,
+  `datetime_tz` and the rest are equally absent from the spec's closed `FieldType`
+  and are equally unretired, so they classify exactly as before.
+  
+  `RETIRED_FIELD_TYPES`, `reportRetiredFieldType` and `resetRetiredFieldTypeReports`
+  move to `@object-ui/core` and are re-exported from `@object-ui/fields`, so that
+  package's published surface is unchanged apart from the newly ruled gate.
+  `@object-ui/components` is a consumer of the gate and `@object-ui/fields`
+  depends on it, so a single shared table could not live in `fields` — and a
+  second copy would have meant a second dedupe set and two console lines for one
+  spelling. No package gained a new dependency.
+  
+  A retired spelling never loses a stored value: `retypeFilterValue` is
+  deliberately not gated, and the refused filter row stays operable rather than
+  drawing a blank operator trigger.
+- 6b348d2: `ViewSwitcher` draws an icon for `chart` and `gantt` views again, and both
+  icon maps in the package now name only spellings lucide still resolves
+  (objectui#5586).
+  
+  `ViewSwitcher.resolveIcon` turns an icon NAME into a component by looking it up
+  in lucide's runtime `icons` record. lucide retires a spelling by dropping it
+  from that record while KEEPING it as a deprecated named export, so a retired
+  name still imports, still type-checks and still renders as a component — and
+  silently resolves to nothing as a string. `ObjectView` composes the switcher
+  from names, and two of them had been retired on lucide-react 1.31.0:
+  `chart: 'bar-chart-3'` and `gantt: 'gantt-chart'`. Both view types rendered as a
+  label with no icon at all while every sibling type had one, and nothing went red
+  because no lucide symbol appears in that map for the compiler to check. Measured
+  against the installed package: `BarChart3` and `GanttChart` are absent from
+  `icons`, while `ChartColumn` and `ChartGantt` are present.
+  
+  - `ObjectView`'s `iconMap`: `bar-chart-3` → `chart-column`,
+    `gantt-chart` → `chart-gantt`.
+  - `ViewSwitcher`'s `DEFAULT_VIEW_ICONS`: the adjacent entries that named
+    deprecated aliases move to the names the record carries —
+    `BarChart3` → `ChartColumn`, `GanttChartSquare` → `ChartGantt`,
+    `Grid` → `Grid3x3`. `ChartColumn`/`Grid3x3` are the same components the
+    aliases already pointed at, so those two glyphs are unchanged; the `gantt`
+    default picks up the plain gantt glyph, which is what `iconMap` now supplies
+    for that view type.
+  
+  The regression pin widens from `tree` alone to EVERY name both maps supply: a
+  pin scoped to the two names that broke would not have caught this and would not
+  catch the next lucide bump.
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [2d7304d]
+- Updated dependencies [062943f]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [3e853c9]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [17ccec9]
+- Updated dependencies [8d3a529]
+- Updated dependencies [194fae1]
+- Updated dependencies [beccf1c]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [5173a5e]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [c9a7252]
+- Updated dependencies [5f19b92]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [c38162d]
+- Updated dependencies [b362c1b]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [1c19722]
+- Updated dependencies [5961030]
+- Updated dependencies [faa863d]
+- Updated dependencies [fd814d6]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [3c9fca3]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [9e22085]
+- Updated dependencies [b655a9d]
+- Updated dependencies [c574dfb]
+- Updated dependencies [02f48b6]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [20e317c]
+- Updated dependencies [425762e]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [83ec618]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [591bf27]
+- Updated dependencies [38a9568]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [43ca9d5]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [ba306e3]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [26a2238]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [5d79faf]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/plugin-grid@17.7.0
+  - @object-ui/plugin-form@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/plugin-view/package.json b/packages/plugin-view/package.json
index aedb1d31f4..4d5bf4139a 100644
--- a/packages/plugin-view/package.json
+++ b/packages/plugin-view/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/plugin-view",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Object View plugin for Object UI",
diff --git a/packages/providers/CHANGELOG.md b/packages/providers/CHANGELOG.md
index 06d4ccf643..86d3f5751f 100644
--- a/packages/providers/CHANGELOG.md
+++ b/packages/providers/CHANGELOG.md
@@ -1,5 +1,103 @@
 # @object-ui/providers — Changelog
 
+## 17.7.0
+
+### Minor Changes
+
+- c9327c9: Localize the theme document types: `@object-ui/types` now owns `Theme`, `ThemeMode` and `ColorPalette` (objectui#5716 ruling, 2026-08-23). The spec retired its theme module (objectstack#10485) while ObjectUI retained the theme system, so the types are hand-written from the last-published `@objectstack/spec` 17.1.0 shapes instead of re-exported — a spec dependency refresh past the retirement no longer breaks these packages.
+  
+  Published-name REMOVALS from `@object-ui/types` (zero in-repo readers, deleted under the same ruling's rider):
+  
+  - `Typography` — the shape lives on as the inline `Theme['typography']` member.
+  - `BorderRadius` — lives on as inline `Theme['borderRadius']`.
+  - `Shadow` — lives on as inline `Theme['shadows']`.
+  - `ThemeDefinition` — the deprecated alias of `Theme`; use `Theme`.
+  
+  Also added: `THEME_MODES`, a runtime tuple witness of the theme mode vocabulary (`['auto', 'light', 'dark']`).
+  
+  The `UI` protocol namespace (`import { UI } from '@object-ui/types'`) now resolves `UI.Theme` / `UI.ThemeMode` / `UI.ColorPalette` to the local owners, so they survive the upcoming spec refresh; the rest of the namespace continues to track `@objectstack/spec/ui`. After that refresh, retired spec/ui members (`UI.ThemeSchema`, `UI.ThemeModeSchema`, `UI.ThemeParsed`, `UI.Typography`, `UI.BorderRadius`, `UI.Shadow`, `UI.defineTheme`) drop out of the namespace.
+  
+  `@object-ui/providers`: `ThemePreference` is now derived from `@object-ui/types`' `ThemeMode` instead of the retired spec `ThemeModeSchema` (same union: `'auto' | 'light' | 'dark' | 'system'`).
+
+### Patch Changes
+
+- a1c41c5: `@object-ui/providers` no longer declares `@objectstack/spec` as a dependency. Nothing
+  in the package imports it, so consumers stop installing it on this package's account
+  (objectui#5753).
+  
+  The edge was live for exactly one release cycle. It was promoted from `devDependencies`
+  to `dependencies` when `ThemePreference` was derived from the spec's `ThemeMode` union,
+  because the package's public `.d.ts` then referenced the spec. objectui#5716 re-pointed
+  that derivation at `@object-ui/types` (`ThemeMode` / `THEME_MODES`), which removed the
+  last three import sites — `src/types.ts` and the two retirement-era test files — and
+  left the declaration behind with no reader.
+  
+  Re-measured on `origin/main` at `ad0f5f11f` before removal, with a positive control so
+  the empty result is a real absence rather than a broken command: the import-shaped grep
+  (`from` / `require(` / `import(` / `vi.mock(` against `@objectstack/spec`, bare name and
+  every subpath) returns **0** hits under `packages/providers/` and **434** across
+  `packages/` + `apps/` — same command, same invocation. The only surviving mentions in
+  the package are the declaration itself, immutable `CHANGELOG.md` history, and a prose
+  comment in `tsconfig.test.json` that this change corrects.
+  
+  No API change and no behaviour change: `dist/types.d.ts` imports only `react` and
+  `@object-ui/types`, and no emitted file references a spec symbol. Consumers on an
+  isolated `node_modules` (pnpm) never had supported access to the spec through this
+  package, so nothing they could legitimately import goes away — the change is to the
+  install graph only, which is why it is scored `patch` rather than `minor`.
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [69a2163]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [e4559d1]
+- Updated dependencies [6f81384]
+- Updated dependencies [dddb942]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [d7acad6]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [100547e]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [0e05aac]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [199d31b]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [515f171]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [3c73d99]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/types@17.7.0
+
 ## 17.6.0
 
 ### Patch Changes
diff --git a/packages/providers/package.json b/packages/providers/package.json
index 2c698bed77..60a157d976 100644
--- a/packages/providers/package.json
+++ b/packages/providers/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/providers",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "Reusable context providers for ObjectUI applications",
diff --git a/packages/react-runtime/CHANGELOG.md b/packages/react-runtime/CHANGELOG.md
index 761adb0e2e..c092a21a84 100644
--- a/packages/react-runtime/CHANGELOG.md
+++ b/packages/react-runtime/CHANGELOG.md
@@ -1,5 +1,55 @@
 # @object-ui/react-runtime
 
+## 17.7.0
+
+### Patch Changes
+
+- 0b1326d: Documentation no longer teaches the "JSX/HTML + Tailwind" framing for a page's
+  `source`, which ADR-0080's own 2026-06-30 header amendment (under ADR-0065,
+  Accepted) retracted. objectui#5461 corrected three sites; a multiline census
+  found eight more, in three spellings a line-oriented grep could not see.
+  
+  A page's `source` is *runtime metadata*. The console's Tailwind is compiled at
+  build time by scanning the console's own `src`, and there is no safelist, so it
+  never sees your page: an authored utility class produces CSS only by coincidence
+  (when objectui already ships that exact class) and otherwise produces nothing,
+  with no error anywhere. That is the ADR-0065 "works only by coincidence" failure
+  mode, and it is how a modal's `bg-black/50` backdrop reached production fully
+  transparent. `os validate` reports it as `page-source-className-tailwind`, a
+  warning on kinds `html`, `react` and `jsx`, shipped in `@objectstack/lint@11.5.0`.
+  
+  The tiers themselves are unchanged and every load-bearing claim survives —
+  parse-never-execute, the untrusted-author safety argument for `html`, and the
+  deprecated `'jsx'` alias. Only the styling primitive is corrected, to the wording
+  `content/docs/guide/react-pages.md` §Styling already uses:
+  
+  | `kind` | Style with |
+  |---|---|
+  | `"html"` | The blocks' own structured props (`` `<flex direction gap>` ``, `` `<grid columns>` ``) plus a JSON `style` object. |
+  | `"react"` | Inline `style` objects. |
+  
+  Colors on both tiers come from the theme as `hsl(var(--token))`.
+  
+  Why each package has an entry — each was measured against its built artefact, not
+  assumed:
+  
+  - **`@object-ui/react-runtime`**: `README.md` is published to npm (npm includes
+    `README.md` in the tarball regardless of `files`). Its "no sandbox" callout is
+    the paragraph that routes untrusted-author work to the `html` tier, and it
+    carried the retracted framing line-wrapped across `:17-18`. It also gains the
+    §Styling section it was missing — the absence is why the framing survived here.
+  - **`@object-ui/sdui-parser`**: the corrected header of `src/types.ts` projects
+    verbatim into the published `dist/types.d.ts`.
+  - **`@object-ui/components`**: the corrected header of
+    `src/renderers/basic/html-elements.tsx` projects verbatim into the published
+    `dist/renderers/basic/html-elements.d.ts`. The `kind === 'html'` dispatch-arm
+    comment in `src/renderers/layout/page.tsx` does **not** project (it is inside a
+    function body) and is included here only because the same package already owes
+    an entry.
+  
+  No behaviour change: this is prose only. `CHANGELOG.md` occurrences are
+  deliberately untouched — immutable release history.
+
 ## 17.6.0
 
 ## 17.5.0
diff --git a/packages/react-runtime/package.json b/packages/react-runtime/package.json
index f2f6f79ac0..2c748e790a 100644
--- a/packages/react-runtime/package.json
+++ b/packages/react-runtime/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/react-runtime",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "sideEffects": false,
   "license": "MIT",
diff --git a/packages/react/CHANGELOG.md b/packages/react/CHANGELOG.md
index c6d1af825c..6763096a2c 100644
--- a/packages/react/CHANGELOG.md
+++ b/packages/react/CHANGELOG.md
@@ -1,5 +1,716 @@
 # @object-ui/react
 
+## 17.7.0
+
+### Minor Changes
+
+- 30c73cd: A `disabled` / `disabledOn` predicate that cannot be evaluated is now reported on the console, in development **and** in production — and the message says what this gate's fail-soft default actually did.
+  
+  `SchemaRenderer` routes six visibility legs (`visibleWhen`, `visible`, `visibleOn`, `visibility`, `hidden`, `hiddenOn`) through one reporter, and called `evaluateCondition` **bare** on the two enablement legs — the only uninstrumented predicate pair in the file. A faulting `disabled` predicate had therefore never been reported in any build, in any dialect that does not report on its own.
+  
+  It is also the pair whose fail-soft answer **bites**. `evaluateCondition` answers an unevaluable predicate with `true`; on the negated visibility legs that means SHOWN, here it means GREYED OUT. So the user got a control they could see and could not use, and the author got nothing to grep for.
+  
+  - **Wiring only, one engine call.** Both legs pass `EvaluationOptions.onFault` (objectui#6038's seam), which hands back the fault the evaluator has already caught. No `throwOnError`, no second evaluation, no `__DEV__` split — dev and production print identical bytes.
+  - **No verdict moves.** The fail-soft `true` is preserved deliberately: a faulting `disabled` predicate still disables, exactly as before. Flipping that is a shipped-behaviour change and is not part of this.
+  - **Its own copy, not the visibility reporter's.** The shipped line says the safe default meant the gate "did NOT bite", which is written about a gate that shows the node. This gate's line says the opposite, because the opposite is true: `[ObjectUI] An enablement predicate could not be evaluated`, then the node, the key, the source, the engine's reason, and that the node renders disabled — on screen, greyed out — with nothing else on screen to say a predicate failed. One reporter, one dedupe, one severity; a second message.
+  - **Rate-limited exactly as the visibility gate is**, per `(node type, key, predicate source)`: two hundred rows of one broken predicate print one line, a second distinct source still prints, and the same source authored on `disabled` and on `visibleWhen` prints two — the gates cannot silence each other.
+- 830ed58: The record page's approval band offers its **Recall** button to the approval's submitter
+  only (objectui#6464).
+  
+  Field report on `@objectstack/*@17.2.0`: user A submits a record into a 4-level approval;
+  user B — not the submitter, read access, not an admin — opens the record and the band still
+  lights a clickable recall button. The click cannot succeed. The recall endpoint authorizes
+  on submitter identity and refuses everyone else, so the only outcome available to that
+  button was a failure toast. Record state was never at risk; this was purely a
+  writability-feedback mismatch, the same family as objectui#3794.
+  
+  The button's only gate was `dataSource.cancelPendingApproval` — "can this adapter recall at
+  all" — which is a question about the DataSource, not about the viewer. Identity now joins
+  it, threaded the way every other signal on that band already travels: the HOST resolves it
+  and passes it through `InlineEditProvider`, so the renderer stays DataSource-agnostic and
+  never re-derives who submitted what.
+  
+  - `@object-ui/react` — `InlineEditProvider` accepts `approvalIsSubmitter`, surfaced on
+    `InlineEditContextValue`. Additive and optional; no existing prop changes.
+  - `@object-ui/plugin-detail` — the band's recall button is withdrawn when that signal is a
+    resolved `false`.
+  - `@object-ui/app-shell` — `RecordDetailView` resolves the verdict from its existing
+    approvals read and threads it.
+  
+  **The signal is tri-state, and the third state is the load-bearing one.** `true` offers
+  recall, `false` withdraws it, and **`undefined` — a host that resolves no approval identity
+  — renders exactly as it did before this release.** Omission preserving prior behaviour
+  mirrors how `approvalPending` falls back to `locked`. Defaulting the unknown case to "hide"
+  would have traded a cosmetic defect for a functional loss: every host whose band runs off
+  the record's `approval_status` mirror alone would silently lose its submitter's only way to
+  unlock their own record.
+  
+  **Withdrawn rather than disabled-with-reason.** The card offered either. For a
+  non-submitter this control is never actionable on any pending record, so a permanently
+  disabled button is standing clutter rather than a lesson; and the two sibling submitter
+  levers already hide — the approvals panel's Remind button, and the declared
+  `approval_recall` action's `visible` predicate. The band, its quorum tally and the
+  approvals timeline still tell a non-submitter exactly what state the record is in. Only the
+  lever they can never pull is gone.
+  
+  **This changes no permission.** Nothing about what the server allows moves, `canEdit` and
+  the approval lock are untouched, and nothing downstream reads `approvalIsSubmitter` as an
+  authorization verdict — the recall endpoint remains the sole authority, and it refused
+  these callers before this change and refuses them after. There is deliberately **no admin
+  carve-out** (the reporter ruled that case out, cf. objectstack#9464).
+  
+  The derivation itself is now one function, `isSubmitterOf` — server-resolved
+  `viewer.is_submitter` first (framework#3310), an id comparison as the fallback for backends
+  that predate it, joined with `??` so a server that resolved `false` is believed rather than
+  re-litigated client-side. The approvals panel's Remind gate, which already carried that
+  expression inline and whose behaviour is unchanged, now reads the same answer: two copies
+  would have been two definitions of who submitted.
+  
+  The **untranslated refusal text** the reporter also saw ("No pending approval request found
+  for this record", concatenated after a localized prefix) is a separate defect and is not
+  addressed here; it is tracked on objectstack#11993.
+- c71e14d: **The unresolvable-visibility-predicate report now names the roots of the tier the
+  predicate was actually evaluated against** (objectui#6487). An app-shell author
+  whose nav, area or field `visible` faulted was told to check `record` and
+  `page.<var>` — two roots that tier does not bind at all.
+  
+  `formatUnresolvableVisibilityMessage` and `reportUnresolvableVisibilityPredicate`
+  (both exported from `@object-ui/react`) take a new **optional sixth argument**, a
+  `PredicateScopeTier` — also exported — selecting the closing advice paragraph.
+  Everything above that paragraph is unchanged on every surface, and so is every
+  verdict: this is diagnostics copy only.
+  
+  **The published signature grew; nothing existing breaks.** The argument defaults
+  to `'page-component'`, so a five-argument call keeps printing the bytes it
+  printed before. All three in-repo call sites pass their tier explicitly rather
+  than lean on that default.
+  
+  Each tier's root set was derived from the code that builds the bag, not from the
+  prose that described it:
+  
+  - **`'page-component'`** — `SchemaRenderer`'s node gate and `page:tabs` item
+    predicates. Both bind `record`, `current_user` and `page.<var>` (the roots
+    `@objectstack/spec`'s `ui/page.zod.ts` declares for the tier). Its paragraph is
+    byte-for-byte what it was.
+  - **`'app-shell'`** — the chrome gate `ExpressionProvider.evaluateVisibility`
+    runs, wired onto this reporter by objectui#6443. Its evaluator is built from
+    `{ current_user, user, ctx: { user }, os: { user }, app, data, features }`, so
+    the line now names `current_user` with its three ADR-0068 alias spellings,
+    `app`, and `features` — the deployment-flag root that provider documents for
+    exactly this kind of predicate — and states outright that `record` and
+    `page.<var>` do not exist there.
+  
+  **Why not generalise the copy instead.** Dropping the concrete root names would
+  have made one paragraph true everywhere at the cost of making it useful nowhere:
+  an author who mistyped a root needs to know which roots exist *at their tier*,
+  which is the whole reason the paragraph is read.
+  
+  `data` is bound at the app-shell tier but is deliberately not advertised there —
+  every mount of `ExpressionProvider` in this repo passes `data={{}}` or omits it,
+  so naming it would point an author at a root that answers nothing.
+- 748494b: The unresolvable-predicate diagnostic tells `hidden` / `hiddenOn` authors what actually
+  happened to their node (objectui#6503). Those two legs are the only ones in
+  `SchemaRenderer`'s visibility chain whose verdict is NOT negated: `evaluateCondition`
+  answers an unevaluable predicate with `true` on every path, the four negated legs turn that
+  into SHOWN, and these two return it as-is, so the same `true` sets `_hidden` and the
+  component returns `null`. Both were handed the consequence paragraph written for the negated
+  legs — "the gate did NOT bite - a predicate that cannot be evaluated reads on screen exactly
+  like one that said yes" — which is the opposite of what an author whose block VANISHED is
+  looking at. That line exists to name their predicate, and instead it sent them to hunt a
+  rendering bug that does not exist.
+  
+  The two legs now print their own paragraph: the safe default is the one that BITES here, the
+  node was REMOVED and is not on the page at all, an absent node is indistinguishable from
+  metadata that meant to hide it, and nothing is wrong with the renderer.
+  
+  Copy only — no verdict moved. The node still vanishes, which is the shipped fail-soft the
+  neighbouring family (objectui#3862 / #3955 / #6443 / #6487 / #6445) preserved deliberately,
+  and every case in the new suite pins the verdict beside the sentence.
+  
+  `PredicateGateKind` — re-exported from `@object-ui/react`'s entry — gains a third member,
+  `'concealment'`, joining `'visibility'` and `'enablement'`. The opening line is deliberately
+  UNCHANGED (`UNRESOLVABLE_VISIBILITY_PREFIX`): these are visibility predicates, and an app or
+  a test filtering the console by that constant must go on catching them. Consumers that
+  switch EXHAUSTIVELY over the union, or key a `Record` by it, gain a third case to answer;
+  no runtime signature moved and every value accepted before still is.
+- ae61ad4: The console form now renders a refusal message the producer explicitly marked
+  as user-facing, instead of always substituting a generic string
+  (objectui#5210).
+  
+  An application's hook guards could not talk to their users. When a hook refused
+  a write with 403, the form replaced the server's text with
+  `form.noPermissionToSave` unconditionally — the recorded objectstack#3821 fix,
+  which exists because a raw refusal body puts untranslated platform diagnostics
+  (`FORBIDDEN: insufficient privileges to update showcase_private_note
+  pi-TgoJ4_DM55Fqz`) in front of end users. The external report behind this change
+  had 11 guards whose deliberate, localized guidance — which role owns the action,
+  whom to ask — never reached anyone, and named the incentive that creates:
+  returning 400 instead of 403 for permission failures, degrading the status
+  semantics logs, monitoring and API consumers depend on.
+  
+  The maintainer ruling (2026-08-19) was a producer-side opt-in rather than a
+  chattier 403 branch, and the platform half shipped as objectstack#9934: a hook
+  marks its refusal text with `userMessage` at throw time. This is the consumer
+  half.
+  
+  - `@object-ui/react` gains `declaredUserMessage(err)` — the one "is this
+    marked?" read. It answers the marking verbatim, from the two places the
+    adapter boundary parks the envelope (the error itself, where
+    `@objectstack/client` lifts it, and `details`), and `null` for everything
+    else.
+  - The form prefers a marked message over both its generic strings, on ANY
+    status — the marking is status-agnostic; 403 is where this was reported, not
+    a fence the contract draws.
+  
+  **Unmarked refusals are unchanged**: a 403 with no marking still shows the
+  generic `form.noPermissionToSave`, and the raw text still goes to the browser
+  console only. objectstack#3821's protection is preserved by construction, not
+  by re-guessing which 403 bodies are presentable — the mark and the marked text
+  are one field, so no boundary that rewraps or substitutes `message` can promote
+  platform prose into the user-facing channel, and platform code never sets it.
+- ebce5a3: `object-grid` / `object-form` / `detail-view` resolve their data source the same way, and a block that resolves none says so
+  
+  The three object-bound blocks disagreed about how the data-source adapter reached
+  them. `object-grid` and `object-form` were registered through wrappers that read
+  it from `SchemaRendererProvider` context; `detail-view` was registered as the raw
+  component, which reads a React `dataSource` prop. `SchemaRenderer` itself reads
+  only context, so the two wirings were mutually exclusive: measured with correct
+  keys in every cell, provider wiring gave the grid `find` 1 and the detail view
+  `findOne` 0, and prop wiring gave exactly the reverse. Neither reported anything.
+  
+  All three now resolve the adapter through one rule — an explicit `dataSource`
+  prop first, the provider context second. This is additive: `detail-view` keeps
+  its prop form (and direct `<DetailView dataSource={…} />` callers are untouched),
+  `object-form` gains a prop form it did not have, and `object-grid` no longer
+  throws `useSchemaContext must be used within a SchemaRendererProvider` when a
+  page has no provider.
+  
+  And the silence is over. A block in this family that resolves no adapter renders
+  a **No data source resolved** panel naming the block, the object it was about to
+  read, and the ancestor that injects the adapter — instead of a header-only grid,
+  a field-less form card, or nothing at all. The check is opt-in per block, so a
+  placement with inline rows, inline `customFields`, an inline record or an `api`
+  endpoint is untouched.
+  
+  New from `@object-ui/react`: `useResolvedDataSource`, `NoDataSourcePanel`,
+  `noDataSourceMessage`, and a `requiresDataSource` prop on `ElementDataSourceGate`.
+- cac64b3: The spec-bridge's form-view input now accepts everything `@objectstack/spec`'s
+  FormViewSchema accepts — three key types had drifted narrower, and one of them
+  had inverted (objectui#5652).
+  
+  `bridges/form-view.ts` held a third hand-written description of the FormViewSchema
+  contract, after the leaf (objectui#5542) and the two containers (objectui#5596)
+  were converged elsewhere. A description nothing compares is one spec release from
+  being a fork, and this one had already drifted on the keys that decide whether a
+  legal document renders:
+  
+  - `FormSection.columns` refused the string spelling of a column count, which the
+    contract admits and folds to a number in its own pipe. It is now the contract's
+    type, and the bridge performs the fold — the `object-form` node's section
+    declares `columns` as a number and its container indexes a grid-class map by
+    it, so forwarding `'2'` handed every downstream renderer a value outside the
+    type it declares.
+  - `FormField.dependsOn` was declared `string[]`, which is the exact inverse of the
+    contract: it admitted only the array arm the contract rejects, and refused the
+    bare parent-field name that is the one configuration making `field-selector`
+    and `dynamic-config` work (objectui#5040).
+  - `visibleWhen`, on both fields and sections, was declared `string`, so the
+    ADR-0089 expression object — the arm `evalFieldPredicate` reads — could not be
+    described at all. Both arms now travel whole onto the node.
+  
+  A section's `fields` may also be a bare object-field name, the spec shorthand the
+  list bridge already honours. The form bridge ran it through the object mapper
+  instead, producing a field with no identity (`{ name: undefined }`) for the most
+  ordinary section a form can declare; it is now forwarded verbatim, which is what
+  the node's own `fields` slot admits.
+  
+  Each drift-prone key's type is now bound to the `@objectstack/spec` symbol that
+  owns it rather than restated, so it cannot drift again, and the compile-time pins
+  in `FormViewWidenedArms.test.ts` fail if a future edit restates any of them by
+  hand. The documented subset itself is unchanged: the keys this bridge does not
+  declare, including the retirement ledger it keeps, stay exactly as they were.
+- d1ab06f: Row predicates declare a canon: `record.*`. The bare shorthand and `data.*` now
+  warn once, and are unchanged otherwise.
+  
+  A row predicate (`visible` / `disabled` / `enabled` on an action renderer, a row
+  scope, a `record:alert`) has bound the row three ways since objectui#4075 —
+  `record.status`, bare `status`, and `data.status` — without any of them being
+  declared the contract. The maintainer ruled that question on 2026-08-20
+  (objectui#5330, option B), mirroring the objectstack#7917 option-② precedent for
+  the identical renderer-tolerance shape: **the canon is `record.*`**, and the
+  other two enter a deprecation window.
+  
+  The canon states the **server's** accept set, which was this card's first
+  measurement and turns out to be strictly narrower than the renderer's. Measured
+  against `@objectstack/formula@17.1.0`, the engine the server evaluates with:
+  
+  | spelling | server runtime | server authoring oracle |
+  |---|---|---|
+  | `record.status` | `{ ok: true, value: true }` | accepted |
+  | bare `status` | `Unknown variable: status` | refused |
+  | `data.status` | `Unknown variable: data` | **silently accepted** |
+  
+  `buildScope({ record })` mounts exactly `['record']` — `data` is never bound and
+  the row's fields are never flattened to top level. The three-way binding is a
+  client tolerance with no server counterpart, which is why the warning belongs on
+  this side.
+  
+  `data.*` is the dangerous one, and the reason the warning exists. `data` is in
+  `@objectstack/formula`'s `SCOPE_ROOTS`, so the server's bare-identifier oracle
+  waves it through — that list is a deliberately generous "never faults" lint
+  baseline, not the runtime accept set. A `data.*` row predicate therefore passes
+  every authoring gate the platform has and then binds nothing at runtime: not an
+  error, a constant `false`. A `visible` that is constantly false is a button that
+  silently never appears — the objectui#4075 fail-closed signature.
+  
+  What ships:
+  
+  - `@object-ui/core` exports `detectNonCanonicalRowSpelling`,
+    `warnNonCanonicalRowSpelling`, `resetRowPredicateCanonWarnings` and
+    `ROW_PREDICATE_CANONICAL_ROOT` from a new `evaluator/rowPredicateCanon.ts`,
+    which carries the canon statement and the measurement.
+  - Both evaluation tiers report once, in dev: `evalRowPredicate` (core) and
+    `useCondition` (react, for bags bound by `usePredicateRecordContext`).
+  - Detection reuses the server's own oracles (`collectCelRootIdentifiers`,
+    `firstUndeclaredReference`) rather than a regex, so no second dialect
+    judgement is invented client-side.
+  
+  **No spelling is removed and no behaviour changes.** Every predicate that
+  resolved before resolves now — the ruling defers removal behind a stored-metadata
+  survey, and the warning is what makes that survey possible (ADR-0078: a
+  tolerance nothing ever reports can never be retired).
+  
+  The deprecation is scoped to the **runtime record layer**. `data` remains the
+  canonical root one layer over, in a metadata-editing form (ADR-0089 D3
+  `CANONICAL_ROOT_BY_LAYER`), and the detector stands down there.
+- c86185e: Bind `record` into the node-level visibility evaluator, and stop a hoisted
+  `properties.visible` swallowing a declared `visibleWhen`.
+  
+  `@objectstack/spec` has declared since ADR-0089 that a page component's
+  `visibleWhen` binds the row — `ui/page.zod.ts`: *"Binds `record`,
+  `current_user`, `page.<var>`"*. `SchemaRenderer` bound no `record` at all. Its
+  evaluator was built from the ambient predicate scope, `data: dataSource` (the
+  connector **adapter**, not the row) and `page: pageVariables`; the row lives in
+  `RecordContext`, which that evaluator never read.
+  
+  Because the surface is fail-soft, a `record.*` predicate did not misfire — it
+  resolved to **shown**. Both polarities of the same predicate returned the same
+  verdict, so a visibility gate silently did not gate, on every block on every
+  record page. Measured on `record:alert`, `record:path`, `page:card` and
+  `element:text`.
+  
+  Three changes, all in `SchemaRenderer`'s evaluation memo:
+  
+  - **`record` is bound**, as the `record` root only — the three roots the
+    describe promises and nothing more. Not as bare fields, and never over
+    `data`, which is what `${data.*}` in a props bag resolves against. Bound
+    conditionally, so "no row" binds nothing rather than shadowing a `record` a
+    host supplied through the ambient scope.
+  - **`visibleWhen` is tested before `visible`.** The memo hoists `properties.*`
+    onto the node, so a node carrying `properties.visible` short-circuited the
+    declared node predicate — the one key the spec tells authors to write was the
+    one key that could be silently ignored. The two deprecated aliases
+    (`visibleOn` / `visibility`) deliberately keep their rank: they normalize into
+    `visibleWhen` at parse, so a spec-parsed page never reaches them.
+  - **An unresolvable predicate is loud** (dev builds). Fail-soft answered "this
+    predicate is broken" and "this predicate said yes" with the same word. The
+    verdict is unchanged on every path — `evaluateCondition` already returned
+    `true` for every unevaluable predicate, including the non-negated `hidden` /
+    `hiddenOn` legs where that `true` means HIDE — so only the silence moved.
+  
+  **Behaviour change, stated plainly:** a shipped page whose node-level
+  `record.*` predicate was previously inert now evaluates. A block that was
+  permanently visible may begin to hide — which is the point, but it is a verdict
+  change, not a no-op. `properties.visible` is unaffected in verdict: an
+  in-tree census found **zero** node-level `record.*` predicates on page
+  components, so nothing in this repository changes verdict.
+
+### Patch Changes
+
+- 546ddf7: A node-gate visibility predicate that FAULTS now says so in a production build, once per
+  distinct predicate source (objectui#6038, maintainer ruling 2026-08-25, option B: "the
+  silence is no longer an accepted property"). Observability only — no verdict moves.
+  
+  `SchemaRenderer`'s visibility chain is fail-open: a predicate that cannot be evaluated
+  resolves to the same answer as one that said yes, so a gate that stops biting looks
+  exactly like a gate the author got right. The diagnostic that names it (objectui#5454 /
+  objectui#5687) sat behind a `__DEV__` short-circuit, because the only fault-detection
+  channel available was `throwOnError`, and on the CEL branch `evaluateCelCondition`
+  implements that by evaluating **twice** — too expensive to ship for every predicate of
+  every node.
+  
+  **What production actually printed before, measured per dialect on the built evaluator**
+  — the card's premise held for one dialect of three, and the other two failed in opposite
+  directions:
+  
+  | dialect | production console, before |
+  |---|---|
+  | bare string | **nothing** |
+  | `{ dialect: 'cel' }` envelope | one generic line, deduped per source |
+  | `${…}` template | one generic line **per evaluation**, never deduped |
+  
+  So the dialect objectstack#11254 measured a live gate breaking on was the silent one,
+  while the template dialect was the console flood the ruling's rate-limit clause exists to
+  prevent.
+  
+  **The fix reports the fault the evaluator already detected, at the same number of engine
+  calls.** `EvaluationOptions.onFault` is a new passback on `@object-ui/core`'s
+  `ExpressionEvaluator`: every fault site is already inside a `catch`, or already holds the
+  canonical engine's failure reason, so nothing is evaluated twice. It mirrors, one layer
+  up, the seam `FieldPredicateDiagnostic` already documents (`warn: false` plus a reason
+  passback), and supplying it transfers reporting to the caller so one fault stays one
+  line. Pinned: the CEL branch performs the same number of record reads with the passback
+  as without it, and strictly fewer than the `throwOnError` probe.
+  
+  `SchemaRenderer` passes it in production and reports through the **same** reporter the dev
+  branch uses — same message, same severity, same dedupe `Set`, same key. Development and
+  production now print the identical line for the identical fault; the `__DEV__` gate no
+  longer decides *whether* a fault is reported, only *how* it is detected.
+  
+  `page:tabs` item-level `visibleWhen` (`@object-ui/components`) is covered by the same
+  reporter and the same rate limit. It swallowed the identical fault under a different
+  helper, and it was the worse of the two: the node gate at least reported in development,
+  while a faulting item predicate was silent in *both* builds on a gate whose false verdict
+  removes an entire tab, header and panel.
+  
+  **Rate limit:** deduped per (node type, gate key, predicate source) — never per render and
+  never per node instance. A two-hundred-row list of one broken predicate is one line; a
+  second distinct predicate source still gets its own line. Both halves are pinned, because
+  a test that asserts only "a warning was emitted" is equally green on an implementation
+  that emitted fifty, and one that asserts only "exactly one" is equally green on an
+  implementation that suppresses everything.
+  
+  **Not changed by this card, deliberately:** the fail-open semantics themselves; the
+  objectui#5687 adapter-only `data.*` report, which stays development-only under its own
+  2026-08-22 ruling (that path is not a fault — the predicate evaluated perfectly, against
+  the wrong object); and the `/forms/:name` scope wiring of objectui#6262, which lands in
+  its own PR.
+  
+  `reportUnresolvableVisibilityPredicate`, `formatUnresolvableVisibilityMessage`,
+  `UNRESOLVABLE_VISIBILITY_PREFIX` and `__resetVisibilityPredicateWarnings` are now exported
+  from `@object-ui/react` so every surface that evaluates a node `visibleWhen` shares one
+  reporter and one rate limit — a second copy would mean a second dedupe `Set`, and one
+  authored predicate would be entitled to one line per package instead of one line.
+- 12402a9: Drop the undeclared object-level `titleField` from the object page's five
+  remaining view-config seams, and from the record-search memo key
+  
+  `ObjectView` resolves a title field for seven view kinds. Two of them —
+  calendar and gantt — already read `viewDef.<kind>?.titleField || 'name'`. The
+  other five (timeline, kanban, map, gallery, tree) carried a three-rung chain
+  with `objectDef.titleField` in the middle, so one file answered the same
+  question two different ways. This converges the five on the shape the two
+  siblings already had; it is a convergence, not a removal.
+  
+  The middle rung could never fire for legal metadata. `@objectstack/spec`'s
+  object schema is a `strictObject`, so
+  `ObjectSchema.safeParse({ …, titleField: 'x' })` is rejected with
+  `unrecognized_keys` — the same issue code a nonsense key gets — while
+  `nameField`, `displayNameField` and `titleFormat` all parse (measured against
+  `@objectstack/spec@17.2.0`, the dist this repo installs). objectui#6531
+  established that measurement and dropped the twin read inside
+  `getRecordDisplayName`. Reading a key no producer can ship is the
+  consumer-side alias AGENTS.md Commandment #0.1 bans.
+  
+  Behaviour for every legal config is unchanged, and both directions are pinned:
+  a view that declares its own `titleField` still wins on every kind, a view that
+  declares none still floors at `'name'`, and an object carrying the
+  contract-rejected key is now honoured by no kind. Re-pointing the middle rung
+  at the declared `nameField` was considered and rejected: it would have added a
+  rung calendar and gantt do not have — increasing the divergence — and, unlike
+  this change, it would have altered behaviour for legal configs.
+  
+  `useRecordSearch`'s candidate signature — the memo key that decides when the
+  cross-object fanout re-runs — appended `o?.titleField ?? ''` to every entry.
+  Because no legal object definition can carry the key, that half was permanently
+  `''`: a constant suffix in a cache signature, and the last thing in the repo
+  that read as evidence some producer supplies it. The signature is now the object
+  name alone, which is the only field of an object definition the effect actually
+  consumes. Change detection is unaffected — a changed candidate name still
+  re-runs the fanout, and a new array with identical content still does not.
+- 98c3a74: Fix `createLazyPlugin`'s JSDoc example, which taught a call that does not compile.
+  
+  The `@example` block passed `() => import('@object-ui/plugin-grid')` as the
+  `importFn`. ObjectUI plugin packages export their components by name and have no
+  `default`, so that call supplies the module namespace object — rejected by the
+  compiler (`Property 'default' is missing`) and, at runtime, handed to
+  `React.lazy` as the component. The examples now unwrap the named export via the
+  `async` spelling, which is the form that actually type-checks. This ships in the
+  published `.d.ts`, so it is what editors show on hover.
+- 9850c6e: `SchemaRenderer`'s node visibility gate now emits a dev-only warning when a
+  predicate reads `data.*` and the data-source adapter cannot answer that read, so
+  an author who wrote `properties: { visible: "data.status == 'draft'" }` sees the
+  constant they authored instead of shipping it (objectui#5687).
+  
+  At the node tier `data` is the data-source **adapter** — the object `${data.total}`
+  in a props bag resolves against — and it has never been the row. A predicate
+  written with the deprecated `data.*` spelling therefore resolves `undefined ==
+  'draft'`, which is a perfectly good `false`: the block is hidden on every row, and
+  because it does not throw, the unresolvable-predicate reporter added for
+  objectui#5454 never fired. Measured on this base, the same predicate written as a
+  `{ dialect: 'cel' }` envelope *does* throw and *was* already reported — so whether
+  an author heard about the identical mistake depended on which dialect they happened
+  to write it in, which is the arbitrariness objectui#5454 existed to remove.
+  
+  **No verdict changes and no interpolation changes** (maintainer ruling,
+  2026-08-22, option A). The node tier keeps its documented `data` = adapter
+  semantics; objectui#5330's row binding does not extend here. The evaluator's answer
+  is returned exactly as computed and `${data.*}` interpolation is untouched — only
+  the silence moved.
+  
+  The report fires on a `data.*` read the bound adapter answers with `undefined`, not
+  on the spelling. A genuine adapter read stays silent (`data.total > 0` against an
+  adapter carrying `total`), a canonical `record.*` predicate stays silent, and a
+  correctly-hiding gate stays silent. Dev builds only, `console.warn`, deduped per
+  node type + key + predicate source — the same module, Set and lifecycle as the
+  objectui#5454 reporter.
+  
+  This loudness is temporary by design: it dissolves when objectui#5330's deprecation
+  window for the `data.*` row spelling closes.
+- b2ea297: `ObjectSchemaMetadata` is now derived from `@objectstack/spec`'s `ServiceObject`
+  instead of being a hand-written copy (objectui#5362; maintainer ruling
+  2026-08-20: the object document type belongs to the spec).
+  
+  What changes on the published type surface:
+  
+  - **Gained:** the full spec object-document surface, including the three keys
+    the runtime already reads but the old interface rejected as excess
+    properties: `icon`, `titleFormat`, `listViews` (plus `pluralLabel`,
+    `nameField`, `displayNameField`, `managedBy` as a spec key, and the rest of
+    the spec document).
+  - **Removed:** nine members the old interface declared that no objectui
+    runtime code reads and the spec document does not know: `extends`,
+    `triggers`, `primary_key`, `relationships`, `name_field` (the spec spelling
+    is `nameField`), `soft_delete`, `audit_trail`, `version`, `cache`.
+    `ObjectTrigger` and `ObjectRelationship` remain exported unchanged.
+  - **Kept:** `editMode` — the one measured client-side member the runtime reads
+    (`recordFormNavigation` / `AppContent`) — now declared on the new
+    `ObjectSchemaClientExtensions` interface, which the derivation intersects.
+    Note the spec's strict parse rejects `editMode` on published documents
+    (`unrecognized_keys`); it is a client-type member only.
+  
+  Spelling settlement: `listViews` (camelCase) is canonical — `list_views`
+  appears nowhere in `@objectstack/spec` 17.2.0. Runtime read sites in
+  `@object-ui/app-shell` and `@object-ui/react` keep a documented snake-spelling
+  READ fallback for stored pre-settlement documents (that stock has never been
+  censused — objectstack#7917); the CRUD guide and its pinned transcription now
+  author the canonical spelling.
+- 4f14ad7: `SchemaRenderer`'s node visibility gate now also catches the `${…}`-templated
+  spelling of the objectui#5454/#5687 diagnostics when it is written inside
+  `properties`, e.g. `properties: { visible: "${data.status == 'draft'}" }`
+  (objectui#5756).
+  
+  The `properties.*` evaluation loop runs, and interpolates every `${…}` template it
+  finds, **before** the visibility gate ever sees the value — so by the time the
+  existing diagnostics ran, a template-spelled predicate had already collapsed into a
+  plain boolean and there was no predicate text left to inspect. The bare-string
+  spelling of the exact same gate (`properties: { visible: "data.status == 'draft'"
+  }`) was unaffected — nothing interpolates a string with no `${` in it — and was
+  already reported; only the template spelling was structurally invisible.
+  
+  Reached by moving the diagnostic check to inside the `properties` evaluation loop,
+  on the predicate's raw (pre-interpolation) text, gated on the key being one of the
+  six visibility keys the render chain consults (`visibleWhen` / `visible` /
+  `visibleOn` / `visibility` / `hidden` / `hiddenOn`) — a `properties.content`
+  interpolation, or any other non-visibility key, is untouched and stays silent.
+  
+  Reports only the key that actually **decides** the node's visibility, mirroring
+  objectui#5454's own leg semantics (its reporter is likewise only ever invoked on
+  the leg the chain's early-return sequence actually reaches): a `properties.visible`
+  template that a co-declared `visibleWhen` outranks is not reported for deciding
+  nothing.
+  
+  **No verdict changes and no interpolation changes.** The diagnostic call's return
+  value is discarded; the real verdict is still computed afterward, off the
+  post-evaluation, post-hoist schema, by the same code path as before this change.
+  Same two reporters as objectui#5454/#5687 (unresolvable-predicate / adapter-only-data
+  predicate), same dedupe `Set`, same `console.warn` severity, same dev-only gate —
+  only the silence moved, one render-step earlier.
+- f90b8fb: `toRenderableSchema`'s header now says the bridge is permanent, instead of instructing
+  callers to remove it (objectui#4622).
+  
+  No executable line changes — but the artifact is **not** unchanged, and that is worth
+  stating plainly rather than rounding to "comment-only". This package builds with plain
+  `tsc`, and `tsconfig.base.json` sets `"removeComments": false` deliberately, so the JSDoc
+  is emitted into `dist/schema-input.js` as well as `dist/schema-input.d.ts` — it is both
+  what an editor shows on hover at every call site and bytes that ship.
+  
+  Measured by building the package the way the repo builds it, at both revisions:
+  `dist/schema-input.js` grows from 1,486 to 2,377 bytes (1.45 KB to 2.32 KB), and from 850
+  to 1,266 bytes gzipped (0.83 KB to 1.24 KB) — **+891 bytes raw, +416 gzipped**. All 19
+  differing lines in the emitted file are JSDoc continuations and the three executable lines
+  are byte-identical, so the growth is the paragraph and nothing else. The trade is
+  deliberate: roughly 0.4 KB gzipped, against the five-hour `Build Docs` outage the old
+  paragraph's instruction produced once already.
+  
+  The old closing paragraph said the two competing repo-wide `SchemaNode` spellings "have
+  not been reconciled" and that "when it lands, the call sites using this can go back to
+  forwarding directly". Both halves went false when PR #4608 merged, and the second half is
+  the harmful one: it is an instruction whose trigger condition has now fired, sitting
+  directly above the function a future author is about to call.
+  
+  The reconciliation (objectui#4580 / PR #4608) resolved the collision in favour of
+  `@object-ui/types`' union — `@object-ui/core` now re-exports it rather than hand-declaring
+  an interface — while `SchemaRenderer`'s prop stays deliberately narrow per objectui#4548
+  ruling Q2 (`schema: BaseSchema | string | null | undefined`, no `number` / `boolean`). So
+  a `SchemaNode` became *less* assignable to that prop, not more, and the bridge is a
+  permanent crossing between two intentionally different types rather than scaffolding
+  awaiting a merge.
+  
+  Following the old instruction has a measured cost: five `apps/site` call sites were
+  forwarding directly when PR #4608 landed, and `Build Docs` was red on `main` for roughly
+  five hours until PR #4621 routed all five through this function (objectui#4617).
+- f53a8d0: fix(react): stop the form-view bridge silently dropping 18 spec keys
+  
+  `spec-bridge/bridges/form-view.ts` promised (#2545) that "every serializable
+  spec key is either mapped onto the `object-form` node or listed here with an
+  explicit reason for being ignored". Measured against `@objectstack/spec` 17.2.0
+  the promise was false for 18 keys, because the conformance test enforcing it ran
+  its completeness loop over its own hand-written fixture rather than the
+  contract's key set.
+  
+  Seventeen of them now reach the node, at the destinations the receiving layer
+  already reads:
+  
+  - `FormViewSchema.buttons` / `.defaults` — `ObjectFormSchema` declares both and
+    `ObjectForm` folds them at render (action-button visibility/labels, and
+    create-mode initial values).
+  - `FormSection.pane` — explicit split-pane placement; without it a spec-authored
+    split form fell back to the positional rule, so reordering sections moved them
+    across the divider.
+  - `FormSection.visibleOn` — the deprecated spelling now folds onto `visibleWhen`,
+    matching the contract's own parse-time normalisation and the field path.
+  - Thirteen `FormFieldSchema` keys — `maxLength`, `minLength`, `min`, `max`,
+    `precision`, `scale`, `multiple`, `immutable`, `span`, `language`, `keyField`,
+    `disclosure`, `fields` — so authored constraints, composite config and field
+    width survive the bridge instead of ending there.
+  
+  `publicPicker` is deliberately not carried and now says so: it is a server-side
+  public-lookup authorization opt-in with no client destination.
+  
+  The conformance test's key set is now derived from the contract's own shape at
+  all three levels, so a spec key that is neither mapped nor explained fails the
+  suite by construction.
+- d91aed9: Name the case-only spelling when a component type misses the registry.
+  
+  Registry lookup is exactly case-sensitive, so a node typed `Page` misses a registered `page` and falls through to the OBJUI-001 "Unknown component type" panel. Because the mistake is usually uniform across a document, the symptom is not one broken widget — it is the whole page rendering as error panels, with nothing in the message pointing at the cause.
+  
+  Both surfaces that report the miss now name the spelling that would have resolved. `SchemaRenderer`'s panel reads `Unknown component type: Page — did you mean 'page'?`, and `objectui check` reports `Unknown schema type "Page" in <file> — did you mean "page"?`. When no known type differs by case alone, neither says anything extra — `zzz` gains no bogus suggestion, and this is case matching, not an edit distance, so `pge` suggests nothing either.
+  
+  **Lookup itself does not change.** `Page` still misses, still fails, and still renders the panel; only the message teaches. Normalising the lookup was considered and rejected (objectui#5247, maintainer ruling 2026-08-19): it would make two spellings valid everywhere, permanently, and legalise the typo class (`PAGE`, `pAge`) along with the PascalCase convention.
+  
+  Each surface reads its candidates from the set it can actually trust — the renderer from the live `ComponentRegistry` (including pending lazy stubs), the CLI from the registration-derived `KNOWN_SCHEMA_TYPES` snapshot — so neither can suggest a type nothing registers.
+- Updated dependencies [b06e374]
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [594704f]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [41b7ce3]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [94e2fa7]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [95f8704]
+- Updated dependencies [69a2163]
+- Updated dependencies [8d3a529]
+- Updated dependencies [b08b7eb]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [5fa06c4]
+- Updated dependencies [e4559d1]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [5d3a2d1]
+- Updated dependencies [b362c1b]
+- Updated dependencies [dddb942]
+- Updated dependencies [00c665e]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [9602dc8]
+- Updated dependencies [299102e]
+- Updated dependencies [d7acad6]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [b2e85a9]
+- Updated dependencies [c7cd2b6]
+- Updated dependencies [b2065e7]
+- Updated dependencies [77f846a]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [100547e]
+- Updated dependencies [3a58149]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [6ce89da]
+- Updated dependencies [0e05aac]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [b470e91]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [c40f3b8]
+- Updated dependencies [199d31b]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [20e317c]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [8e00bfd]
+- Updated dependencies [8d37efb]
+- Updated dependencies [9118a31]
+- Updated dependencies [de570cc]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [1e66879]
+- Updated dependencies [c5200f0]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [38a9568]
+- Updated dependencies [91783c4]
+- Updated dependencies [2d36552]
+- Updated dependencies [b2437a7]
+- Updated dependencies [7a90afd]
+- Updated dependencies [eddc1dd]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [3c73d99]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [fb96ecb]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/i18n@17.7.0
+  - @object-ui/types@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/data-objectstack@17.7.0
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/react/package.json b/packages/react/package.json
index 780971cbe1..e1bc72683e 100644
--- a/packages/react/package.json
+++ b/packages/react/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/react",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "license": "MIT",
   "description": "React bindings and SchemaRenderer component for Object UI",
diff --git a/packages/runner/CHANGELOG.md b/packages/runner/CHANGELOG.md
index 63cb4bab68..17a071d192 100644
--- a/packages/runner/CHANGELOG.md
+++ b/packages/runner/CHANGELOG.md
@@ -1,5 +1,143 @@
 # @object-ui/runner
 
+## 17.7.0
+
+### Patch Changes
+
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [2d7304d]
+- Updated dependencies [062943f]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [39f4309]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [7cd3987]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [7c96c94]
+- Updated dependencies [3e853c9]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [f8cdbf2]
+- Updated dependencies [69a2163]
+- Updated dependencies [194fae1]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [a76b18c]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [6fd2cf7]
+- Updated dependencies [e4559d1]
+- Updated dependencies [129bcc5]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [7d2a689]
+- Updated dependencies [f8c70f4]
+- Updated dependencies [f9c34df]
+- Updated dependencies [dddb942]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [f24de8b]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [299102e]
+- Updated dependencies [30c73cd]
+- Updated dependencies [830ed58]
+- Updated dependencies [d7acad6]
+- Updated dependencies [c71e14d]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [748494b]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [12402a9]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [3c76801]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [dd19463]
+- Updated dependencies [894d103]
+- Updated dependencies [100547e]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [2c8474c]
+- Updated dependencies [0e05aac]
+- Updated dependencies [ae61ad4]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [fe76ece]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [58770f3]
+- Updated dependencies [aefe428]
+- Updated dependencies [485f096]
+- Updated dependencies [199d31b]
+- Updated dependencies [b655a9d]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [d7bd274]
+- Updated dependencies [98c3a74]
+- Updated dependencies [ebce5a3]
+- Updated dependencies [9d9040d]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [9850c6e]
+- Updated dependencies [b2ea297]
+- Updated dependencies [6c5ee71]
+- Updated dependencies [6f017e9]
+- Updated dependencies [a691c0b]
+- Updated dependencies [0b1326d]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [4f14ad7]
+- Updated dependencies [cac64b3]
+- Updated dependencies [fa140b8]
+- Updated dependencies [71cba28]
+- Updated dependencies [190fbd0]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [72ffc34]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [42887e0]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [f90b8fb]
+- Updated dependencies [91783c4]
+- Updated dependencies [5a07e67]
+- Updated dependencies [2d36552]
+- Updated dependencies [490f482]
+- Updated dependencies [27308c5]
+- Updated dependencies [8689166]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [f53a8d0]
+- Updated dependencies [3c73d99]
+- Updated dependencies [d91aed9]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [c86185e]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/types@17.7.0
+  - @object-ui/core@17.7.0
+  - @object-ui/plugin-kanban@17.7.0
+  - @object-ui/components@17.7.0
+  - @object-ui/plugin-charts@17.7.0
+  - @object-ui/react@17.7.0
+
 ## 17.6.0
 
 ### Patch Changes
diff --git a/packages/runner/package.json b/packages/runner/package.json
index ac0769d5de..428a214379 100644
--- a/packages/runner/package.json
+++ b/packages/runner/package.json
@@ -1,7 +1,7 @@
 {
   "name": "@object-ui/runner",
   "private": false,
-  "version": "17.6.0",
+  "version": "17.7.0",
   "description": "Universal Object UI Application Runner",
   "type": "module",
   "homepage": "https://www.objectui.org/docs/utilities/runner",
diff --git a/packages/sdui-parser/CHANGELOG.md b/packages/sdui-parser/CHANGELOG.md
index 195115f84a..a4c833e1c8 100644
--- a/packages/sdui-parser/CHANGELOG.md
+++ b/packages/sdui-parser/CHANGELOG.md
@@ -1,5 +1,93 @@
 # @object-ui/sdui-parser
 
+## 17.7.0
+
+### Minor Changes
+
+- 8d58f46: `validateTree` now reports a dashboard widget `options` key that no renderer
+  consumes as a `unconsumed-widget-option` **warning** naming the consumed set
+  (objectui#5709 ruling). The census behind the accepted set — the spec's five
+  declared query keys (`dateGranularity`, `sortBy`, `sortOrder`, `limit`,
+  `stageOrder`) plus the `description` sub-caption convention key — is
+  re-measured on every test run against `@objectstack/spec` and the
+  `plugin-dashboard` renderer sources. The check fires only on dataset-bound
+  shorthand widgets (the spec-legal form) hosted by `dashboard` /
+  `dashboard-grid` nodes, and honours the spec's per-widget
+  `suppressWarnings: ['unconsumed-widget-option']` escape hatch. Warning
+  severity only: documents keep parsing, saving and rendering. Exported for
+  other surfaces: `checkDashboardWidgetOptions`, `CONSUMED_WIDGET_OPTION_KEYS`,
+  `DASHBOARD_WIDGET_HOST_TYPES`, `UNCONSUMED_WIDGET_OPTION`.
+
+### Patch Changes
+
+- 0b1326d: Documentation no longer teaches the "JSX/HTML + Tailwind" framing for a page's
+  `source`, which ADR-0080's own 2026-06-30 header amendment (under ADR-0065,
+  Accepted) retracted. objectui#5461 corrected three sites; a multiline census
+  found eight more, in three spellings a line-oriented grep could not see.
+  
+  A page's `source` is *runtime metadata*. The console's Tailwind is compiled at
+  build time by scanning the console's own `src`, and there is no safelist, so it
+  never sees your page: an authored utility class produces CSS only by coincidence
+  (when objectui already ships that exact class) and otherwise produces nothing,
+  with no error anywhere. That is the ADR-0065 "works only by coincidence" failure
+  mode, and it is how a modal's `bg-black/50` backdrop reached production fully
+  transparent. `os validate` reports it as `page-source-className-tailwind`, a
+  warning on kinds `html`, `react` and `jsx`, shipped in `@objectstack/lint@11.5.0`.
+  
+  The tiers themselves are unchanged and every load-bearing claim survives —
+  parse-never-execute, the untrusted-author safety argument for `html`, and the
+  deprecated `'jsx'` alias. Only the styling primitive is corrected, to the wording
+  `content/docs/guide/react-pages.md` §Styling already uses:
+  
+  | `kind` | Style with |
+  |---|---|
+  | `"html"` | The blocks' own structured props (`` `<flex direction gap>` ``, `` `<grid columns>` ``) plus a JSON `style` object. |
+  | `"react"` | Inline `style` objects. |
+  
+  Colors on both tiers come from the theme as `hsl(var(--token))`.
+  
+  Why each package has an entry — each was measured against its built artefact, not
+  assumed:
+  
+  - **`@object-ui/react-runtime`**: `README.md` is published to npm (npm includes
+    `README.md` in the tarball regardless of `files`). Its "no sandbox" callout is
+    the paragraph that routes untrusted-author work to the `html` tier, and it
+    carried the retracted framing line-wrapped across `:17-18`. It also gains the
+    §Styling section it was missing — the absence is why the framing survived here.
+  - **`@object-ui/sdui-parser`**: the corrected header of `src/types.ts` projects
+    verbatim into the published `dist/types.d.ts`.
+  - **`@object-ui/components`**: the corrected header of
+    `src/renderers/basic/html-elements.tsx` projects verbatim into the published
+    `dist/renderers/basic/html-elements.d.ts`. The `kind === 'html'` dispatch-arm
+    comment in `src/renderers/layout/page.tsx` does **not** project (it is inside a
+    function body) and is included here only because the same package already owes
+    an entry.
+  
+  No behaviour change: this is prose only. `CHANGELOG.md` occurrences are
+  deliberately untouched — immutable release history.
+- 305205a: `kind:'html'` page sources keep the space between a text run and an adjacent
+  inline element: `A <strong>x</strong> page` now compiles to `A `/`<strong>`/`
+  page` and renders as `A x page` rather than `Axpage` (objectui#5661).
+  
+  The parser collapsed each text run's whitespace to a single space — correct, and
+  what HTML itself does — and then `.trim()`ed it, which is not: HTML collapses a
+  whitespace run to one space, it does not delete it. The deleted space was
+  precisely the separator between a run and its inline sibling, so every authored
+  sentence carrying emphasis or a link in the tier the guide recommends by default
+  rendered with its words run together. It was silent: the page rendered, the
+  structure was right, no diagnostic fired.
+  
+  The rule is deliberately mechanical rather than a block/inline taxonomy invented
+  for a schema tree that has none: keep one leading space when a sibling precedes
+  the run, and one trailing space when a sibling element follows it. The parent's
+  own start and end still drop their edge space, so `<p>  hi  </p>` is unchanged.
+  
+  Its one bounded cost: a whitespace-only run BETWEEN two siblings survives as a
+  single space, so a pretty-printed `<ul>` gains one `' '` string child per gap
+  between its `<li>`s — one space per gap, never the source's newline and
+  indentation, never at the container's own edges, and never inside an item's own
+  text. That bound is pinned by a test rather than left as a claim.
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/sdui-parser/package.json b/packages/sdui-parser/package.json
index 756e4ee6a7..1928d43ec7 100644
--- a/packages/sdui-parser/package.json
+++ b/packages/sdui-parser/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/sdui-parser",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "type": "module",
   "sideEffects": false,
   "license": "MIT",
diff --git a/packages/types/CHANGELOG.md b/packages/types/CHANGELOG.md
index ee6986d27e..aa42bcb2c4 100644
--- a/packages/types/CHANGELOG.md
+++ b/packages/types/CHANGELOG.md
@@ -1,5 +1,1850 @@
 # @object-ui/types
 
+## 17.7.0
+
+### Minor Changes
+
+- 6a91586: Retire the `ActionCondition` `{ expression, then, else }` branch shape from
+  `ActionSchema.condition` (objectui#3917, maintainer ruling 2026-08-09 route B,
+  enforce-or-remove).
+  
+  `@object-ui/types` declared `condition` as a branch DSL — `expression` plus `then` /
+  `else` sub-actions — and shipped a zod mirror (`ActionConditionSchema`) that accepted it.
+  **Nothing ever read `expression`, `then` or `else`**: a repo-wide grep for
+  `condition.expression|then|else` has zero non-test hits. The only consumer of the key is
+  `ActionRunner.execute`, which reads it as a **predicate gate** (boolean / bare CEL /
+  `${...}` template / `{ dialect, source }` envelope). A branch object carries no `source`,
+  so the runner's normalizer read it as "no gate declared" and executed the action
+  unconditionally: the predicate was never evaluated, `then` / `else` were never dispatched,
+  and `os validate` / `os build` stayed green with zero diagnostics. Two docs pages taught
+  the shape with worked examples, so an author following the documentation
+  ("amounts over 1000 go to manager approval") got unconditional execution.
+  
+  What changes:
+  
+  - `ActionCondition` is removed from `@object-ui/types` (and from the barrel export).
+  - `ActionSchema.condition` is retyped to the predicate the runtime actually honours:
+    `boolean | string | { dialect?: string; source: string }` — the same three arms
+    `ActionRunner`'s own `ActionDef.condition` carries, and the same vocabulary `visible`
+    and `disabled` use.
+  - `ActionConditionSchema` is removed from `@object-ui/types/zod` (and from the zod
+    barrel); the `condition` key now validates against that predicate union.
+  - The two teaching sites (`content/docs/core/enhanced-actions.mdx` Conditional Execution,
+    `content/docs/api/schema-reference.md` ActionSchema table) are rewritten to the live
+    vocabulary: `condition` is a gate; a branch is expressed as separate actions with
+    mutually exclusive `condition`s.
+  
+  **The zod parse verdict flips in both directions**, measured on `origin/main` @ `2aff580b5`
+  against this branch: the branch object went from **accepted** to **refused**
+  (`invalid_union` on `condition`), and every live predicate spelling — `false`,
+  `'data.amount > 1000'`, `'${data.amount > 1000}'`, `{ dialect: 'cel', source: ... }` —
+  went from **refused** to **accepted**. The old schema required `expression`, so the shape
+  the runtime honours was the one the schema rejected.
+  
+  **Breaking for TypeScript authors of `ActionCondition` and for metadata authoring
+  `condition: { expression, then, else }`** — marked `minor` per this repo's
+  version-alignment rule, which reserves `major` for following `@objectstack` across a major
+  (AGENTS.md 版本号策略; same classification as the `MobileOverrides` retirement,
+  objectui#4919). Runtime behaviour is unchanged: an authored branch object did nothing
+  before and does nothing now. What changes is that the contract no longer claims otherwise
+  — the mistake now surfaces at authoring time as a type error and a named zod refusal,
+  instead of a silent no-op that type-checks, validates and runs the action anyway.
+- 2d7304d: Retire the `MobileOverrides` type and its `mobileOverrides` mount point (objectui#4919,
+  maintainer ruling 2026-08-19, ADR-0049 enforce-or-remove).
+  
+  `MobileOverrides` published a six-key mobile override surface — `layout`, `columns`,
+  `useBottomSheet`, `fullScreen`, `touchTarget` and a three-value `navigation` vocabulary
+  (`'bottom-tabs' | 'hamburger' | 'drawer'`) — from `@object-ui/types` and, re-exported,
+  from `@object-ui/mobile`. Nothing read any of it. Measured on current `main`: the type had
+  exactly four mentions repo-wide — its own declaration, the single
+  `MobileComponentConfig.mobileOverrides` mount point, and the two barrel re-exports — and
+  the lower-case property name (the spelling a renderer would actually read) appeared only
+  in that declaration. No renderer, hook or adapter resolved it, and a sweep of the example
+  apps and the `objectstack` sibling checkout found zero authors. The three `navigation`
+  values were three spellings of the same no-op.
+  
+  The declared surface is removed rather than narrowed. The #3985 lineage's rule is "narrow
+  to the implemented values"; here the implemented set is empty, so that rule terminates in
+  deletion — a config that type-checks, builds and silently does nothing is the
+  declare-without-enforce shape the platform doctrine forbids.
+  
+  Removal rather than a `?: never` tombstone follows this package's own discriminator. A
+  tombstone exists to steer authors to a named live replacement — `crud.ts` `confirm` →
+  `confirmText` (objectui#4314), `data-display.ts` `hoverable` / `striped` → `data-table`
+  (objectui#5474) — or to keep a key loud that the docs had actively taught as working.
+  Neither applies: there is no replacement key to steer to, no documentation ever described
+  the surface, and there is no successor spelling. That is the same zero-pull, no-successor
+  shape as the retired `AccordionItem.icon` (objectui#4652) and `ToggleGroupItem.icon`
+  (objectui#4632), both of which were removed outright rather than tombstoned.
+  
+  **Breaking for TypeScript authors of `MobileOverrides` / `mobileOverrides` only** (marked
+  `minor` per this repo's version-alignment rule, which reserves `major` for following
+  `@objectstack` across a major — see AGENTS.md's 版本号策略, and the identical
+  classification used for `AccordionItem.icon`). Runtime behaviour is unchanged: an authored
+  `mobileOverrides` did nothing before and does nothing now. What changes is that the
+  contract no longer claims otherwise, so the mistake surfaces at authoring time — importing
+  the type is now a "has no exported member" error, and authoring the key on a
+  `MobileComponentConfig` object literal is an excess-property error, instead of a silent
+  no-op that type-checks and builds.
+  
+  If real mobile-override renderer work is ever wanted it re-enters deliberately, as designed
+  product surface on its own card, with the renderer landing in the same change as the
+  declaration — not by resurrecting this declaration.
+- 636b236: `navigateOnSuccess` is relative-only, escapes the interpolated id, and is deprecated in favour of `submitBehavior`
+  
+  The url contract for this key was undeclared: it was same-origin-guarded (so a same-origin
+  ABSOLUTE value was accepted), it interpolated `{id}` / `{recordId}` without escaping the
+  substituted value, and nothing said which of those was intended. The maintainer ruled it on
+  2026-08-17: `navigateOnSuccess` is the pre-ruling ancestor of the `submitBehavior` family
+  rather than a second dialect, so as a compat alias it runs under the semantics
+  objectstack#7496 ruled for that family.
+  
+  **Relative paths only.** A same-origin absolute such as `https://own-host/record/{id}` is
+  now refused like any other out-of-contract value, rather than accepted and navigated at
+  browser level. The destination is authored metadata, which is exactly where an address
+  somebody else chose gets copied in. Cross-origin and protocol-relative values were already
+  refused and still are; every relative shape that worked before still works.
+  
+  **The interpolated id is URL-escaped.** `/r/{id}` with an id of `a/b c` resolved to
+  `/r/a/b c`, silently growing a path segment, and a template of `{id}` let the id become the
+  whole destination. The substituted value now goes through `encodeURIComponent`, so a token
+  is a value in the path and never a way to add path structure. The template is the author's
+  and is untouched — only the id, which is data read off the written record, is escaped.
+  
+  Both halves are needed and neither implies the other: relative-only is a rule about where a
+  destination starts, so it cannot see structure injected further along; escaping runs only on
+  the substituted value, so it cannot see an absolute the author wrote out.
+  
+  This can only narrow what is reachable. Every destination the key now accepts is a relative
+  reference, and a relative reference cannot carry an authority, so it was already accepted by
+  the same-origin guard this replaces — no value that was refused is now followed. With every
+  accepted destination relative, the browser-level `window.location.assign` fallback at both
+  call sites became unreachable and was removed; an accepted destination goes to the injected
+  navigation seam, and the absent-seam fallback inside the shared hook is unchanged.
+  
+  **Deprecation.** `navigateOnSuccess` is marked `@deprecated` in favour of `submitBehavior`,
+  which already takes precedence over it and carries the richer `{{record.field_name}}`
+  interpolation. The `{id}` / `{recordId}` dialect keeps working for forms that already
+  declare it — the ruling converges the documentation and the semantics, not the spelling.
+- d2fb6ef: **BREAKING (authoring): `ui:icon` names its glyph with `icon`, not `name`**
+  
+  `{ "type": "icon", "name": "check" }` no longer renders an icon. Write
+  `{ "type": "icon", "icon": "check" }`. Stored metadata authored before this
+  release needs converting — see the migration below.
+  
+  Marked `minor` per AGENTS.md §版本号策略 (this repo never publishes `major`
+  outside an `@objectstack` major sync); the break is real and is stated here.
+  
+  **Why**
+  
+  `name` is the SDUI identity key every authored node carries, alongside `id` —
+  it is not `ui:icon`'s private prop. So an ordinary node like
+  `{ type: 'icon', id: 'save_icon', name: 'save_icon' }` asked lucide for a glyph
+  called `SaveIcon`, missed, and rendered **nothing at all**: silent to a human,
+  and clean to a DOM gate, because a renderer that renders nothing spreads no
+  attributes to find. `action:*` already reads `icon`, so this is the vocabulary's
+  existing answer, and it leaves no node type on which the identity key is
+  unusable.
+  
+  **What changed**
+  
+  - `IconSchema` (types + its zod mirror) declares `icon: string` **required**,
+    exactly as `name` was required before it — a key rename at constant
+    strictness. `name` reverts to the optional identity inherited from
+    `BaseSchema`. The mirror previously *required* `name`, which is why the
+    renderer could not be migrated on its own: the published contract refused the
+    correct shape.
+  - `ui:icon` resolves its glyph from `schema.icon`. There is deliberately **no**
+    `icon ?? name` fallback: a key meaning "identity" or "glyph" depending on
+    whether a lucide lookup happened to hit is the ambiguity being removed.
+  - The registry's `inputs` entry and `content/docs/components/basic/icon.mdx`
+    moved in the same change as the resolver.
+  - All 98 authored icon nodes in this repo are converted.
+  
+  **The break is loud in three places, never silent**
+  
+  1. `IconSchema` **refuses** a legacy node, with a message that names the rename
+     and points at the converter — not zod's default `expected string, received
+     undefined`.
+  2. A legacy node that reaches the renderer unvalidated draws the visible
+     placeholder shipped in the previous release, and its `console.warn` now
+     carries the exact rename (`icon: "save_icon"`) plus the converter's name.
+     Its accessible name says so too, and it gains a
+     `data-objectui-icon-legacy-name-key` marker so a gate can tell
+     "unmigrated node" from "glyph that does not resolve".
+  3. **Migration for stored metadata** — `migrateIconNodeKeys` from
+     `@object-ui/types`:
+  
+     ```ts
+     import { migrateIconNodeKeys } from '@object-ui/types';
+  
+     const { document, converted, warnings } = migrateIconNodeKeys(storedPage);
+     if (warnings.length) console.warn(warnings.map((w) => w.message).join('\n'));
+     if (document !== storedPage) await save(document);
+     ```
+  
+     It walks the whole document and lifts `name` to `icon` on every icon node.
+     It is a one-shot conversion a deployer runs over stored documents — **not** a
+     read-path fallback; nothing calls it during rendering or parsing. It
+     **reports rather than guesses** for the two cases it will not touch: a node
+     already declaring both keys (`icon` wins, `name` stays the identity it is),
+     and a node naming no glyph at all.
+- fc62bb4: `TableColumn.type` now has ONE canonical value set across all three ends that disagreed
+  (objectui#5853, maintainer ruling 2026-08-25, Option B: the 8-literal interface union is
+  canonical). The interface declared `'text' | 'number' | 'date' | 'datetime' | 'currency' |
+  'percent' | 'boolean' | 'action'`; the zod mirror declared `z.string()` and accepted
+  anything; the renderer branched on a third set and could only read the key through an
+  `as any` cast.
+  
+  ## ⚠️ Accept-set narrowing — these spellings stop validating
+  
+  `TableColumnSchema.type` was `z.string().optional()`. **Any string parsed green.** It is now
+  `z.enum(TABLE_COLUMN_TYPES).optional()`, so a value outside the eight is refused at parse
+  time with `type` named in the error path. Spellings that validated before and are **refused
+  now**, grouped by why they were being written:
+  
+  - **Typos and invented names** — `'money'`, `'datetime2'`, `'string'`, `'int'`, `'integer'`,
+    `'float'`, `'double'`, `'datetime-local'`, and every other free-form string. `'money'` is
+    the card's headline case: it validated, matched no renderer branch, and the column fell
+    through to plain text rendering with nothing reported. That silent fall-through is the
+    lenient-validation face that lets AI-authored metadata errors through, and it is now a
+    loud parse failure.
+  - **Object-schema field types written into a column slot** — `'select'`, `'lookup'`,
+    `'user'`, `'file'`, `'formula'`, `'textarea'`, `'email'` and the other 35 members of
+    `@objectstack/spec`'s `FieldType` that are not among the eight. These belong on the FIELD,
+    not on the column: a column gets its dedicated widget from the field definition behind its
+    `accessorKey`, never from `type`.
+  
+  **Authored metadata in this repo needs no migration.** Measured before tightening, across
+  `examples/`, `content/`, `apps/`, `e2e/`, `docs/` and every package (591 JSON schema files
+  plus the docs and playground sources): **zero** authored `TableColumn.type` values outside
+  the eight, and zero occurrences of `int` / `integer` / `float` / `double` in a column
+  position anywhere in the repository. If you author `type` on a table column, check it
+  against the eight; if the value describes the FIELD rather than the column, remove it.
+  
+  ## The renderer's undeclared vocabulary disappears instead of being declared
+  
+  `int` / `integer` / `float` / `double` were members of the data-table's `NUMERIC_EDIT_TYPES`
+  and `datetime-local` had its own editor branch, none of them declared. They arrived because
+  column-inference producers forwarded an object schema's field type **verbatim** into
+  `TableColumn.type`. Rather than publishing that dialect, producers now fold their inferred
+  value onto the declared vocabulary at their emit seam via the new
+  `normalizeTableColumnType()`: `int`/`integer`/`float`/`double` → `number`,
+  `datetime-local` → `datetime`, and **anything else drops the `type` annotation — never the
+  column**. Two producers do this, not the one the card named: `ObjectGrid` (`@object-ui/plugin-grid`)
+  and `ObjectDataTable` (`@object-ui/plugin-dashboard`), whose `buildFieldMeta` spread wrote
+  the raw field type into the same slot.
+  
+  Dropping the annotation is behaviour-preserving at the only consumer that reads the key.
+  `data-table`'s inline editor branches on `date`, `datetime` and the numeric set and
+  otherwise falls through to a text input — which is exactly the `undefined` path. The
+  dedicated widget a `select` or `lookup` column gets comes from the host's `renderCellEditor`,
+  which resolves the field through `column.accessorKey` and never reads `type`.
+  
+  ## New public API
+  
+  `@object-ui/types` exports `TABLE_COLUMN_TYPES` (the canonical tuple — the single
+  declaration the zod mirror builds its enum from, so the two cannot drift), the
+  `TableColumnType` union, and `normalizeTableColumnType()` for producers. The `as any` cast
+  in `data-table.tsx` is deleted and the read is typed, so re-introducing an undeclared
+  spelling is a tsc error rather than a silent widening.
+  
+  A value-level parity pin covers all three ends
+  (`packages/types/src/__tests__/table-column-type-canonical.test.ts` and
+  `packages/components/src/renderers/complex/__tests__/table-column-type-read-set.test.tsx`).
+  objectui#5684's guard is key-set only and cannot see value drift — `type` was present on
+  both sides the whole time — which is how this instance survived while its siblings were
+  caught. A future inference value turning that pin red is by design; the note at the pin says
+  so, and names the two correct repairs.
+- 41df893: `ObjectTrigger` and `ObjectRelationship` are removed from `@object-ui/types` — two
+  hand-written interfaces orphaned by the `ObjectSchemaMetadata` derivation
+  (objectui#5859, triage adjudication 2026-08-24; the derivation itself was
+  objectui#5362).
+  
+  **Breaking for anyone importing either name.** The two symbols are, verbatim:
+  
+  - `ObjectTrigger` — the `{ name, when, on, condition?, action, config? }` trigger
+    configuration
+  - `ObjectRelationship` — the `{ name, object, type, foreign_key?, cascade_delete? }`
+    relationship configuration
+  
+  Both existed solely to type members of the retired hand-written object-document mirror:
+  `triggers?: ObjectTrigger[]` and `relationships?: ObjectRelationship[]`. objectui#5362
+  replaced that mirror by deriving `ObjectSchemaMetadata` from `@objectstack/spec/data`'s
+  `ServiceObject`, and the spec's object document declares neither member — so the two
+  interfaces have had nothing to type since. objectui#5362 deliberately left them standing
+  because cutting published exports is a separate decision from the ruled derivation; this
+  is that decision.
+  
+  Measured before removing, on `main`: zero references in this repo outside the declaration
+  and the `src/index.ts` re-export (`packages/`, `apps/`, `examples/`, `*.ts`/`*.tsx`,
+  `node_modules` and `dist` excluded), and zero in the sibling `objectstack` checkout, which
+  does import `@object-ui/types` in eleven files. Absence of a spec correspondence was
+  verified at type level against the installed `@objectstack/spec` 17.2.0 rather than
+  inherited from the card: neither `triggers` nor `relationships` is a key of
+  `ServiceObject`. `DataModelDesigner`'s `relationships` state is its own local model and
+  never referenced these types.
+  
+  **That measurement cannot see npm.** In-repo zero is not consumer zero — an external
+  application importing either name from `@object-ui/types` will fail to compile after this
+  release, and nothing in this repository can detect that. Both names are spelled out above
+  so a host can search its own sources for them. If you were importing either, the shapes
+  were client-side vocabulary with no runtime behaviour and no spec backing: copy the
+  interface into your own code, or model the concept against `@objectstack/spec`, which owns
+  the object document.
+  
+  Type-only change; nothing is emitted and no runtime behaviour moves. Ships `minor`, not
+  `major`, per the version-alignment convention in AGENTS.md — objectui's major tracks
+  `@objectstack`'s, and breaking changes of objectui's own carry `minor` with the semantics
+  stated in the body.
+- 00f3eb5: `ObjectGanttSchema` declares the ten gantt keys `ObjectGantt` actually reads
+  (objectui#5903, triage 2026-08-24). Every one is a real, working, documented
+  feature — `readOnly`, `mobileReadOnly`, `markers`, `navigation`, `skipWeekends`,
+  `holidays`, `criticalPath`, `showBaselines`, `persistLayout`, `viewName` — and
+  none of them was discoverable from the published type, because all ten were read
+  as `(schema as any).K`. The cast was the load-bearing part: it kept the read
+  invisible to `tsc`, to the zod mirror and to the designer's registry `inputs`.
+  
+  Both halves move together. The TS declaration (`packages/types/src/objectql.ts`)
+  and its zod mirror (`src/zod/objectql.zod.ts`) gain the same ten keys at the same
+  requiredness — all optional — so the `zod-mirror-parity` ratchet stays at zero
+  drift for this pair and no `KnownDrift` entry is added. `navigation` is taken
+  from `@objectstack/spec`'s `NavigationConfigSchema` by reference rather than
+  restated, matching `ObjectGridSchema.navigation`.
+  
+  `ObjectGanttProps.schema` is retyped from `ObjectGridSchema` to
+  `ObjectGanttSchema`. That is what makes the declaration load-bearing: the ten
+  keys are not grid keys, so with the old prop type, dropping the casts would have
+  left the reads landing on `BaseSchema`'s index signature — the same invisibility
+  in different syntax. The grid-style `{ gantt: { … } }` block is unaffected;
+  `getGanttConfig` reads it through that index signature exactly as before, and the
+  registered renderer passes `schema: any`, so no runtime shape is turned away.
+  
+  Accept-set change, stated plainly: a **declared** key is now type-validated, so
+  `readOnly: 'yes'` is refused where it used to parse green — the same narrowing
+  objectui#5074 landed for `viewMode`. An **undeclared** key is still accepted:
+  `BaseSchema` is `.passthrough()` and carries an index signature (objectui#5155's
+  structural ceiling), so declaring these ten did not buy rejection of a
+  misspelling. `packages/types/src/__tests__/gantt-declared-keys.test.ts` pins both
+  halves so neither can be misread.
+  
+  The eleventh reported key, `label`, needed no declaration — `BaseSchema` already
+  carries it — so only its cast was dropped.
+- 69a2163: **`@object-ui/types/zod` now accepts seven spellings its own TypeScript declarations already declared**
+  
+  Seven keys across five hand-written zod mirrors refused values the published TS
+  types invite and the renderer implements — `declared !== enforced` on a published
+  validator. The mirrors are widened to their declarations. Nothing is narrowed and
+  nothing previously accepted is rejected, so this is additive for every author and
+  every host: schemas that parsed before still parse.
+  
+  The newly-accepted spellings, so a host can search for them:
+  
+  | schema (`@object-ui/types/zod`) | key | now also accepts |
+  |---|---|---|
+  | `ButtonGroupSchema` | `variant` | `secondary`, `destructive`, `ghost`, `link` |
+  | `ButtonGroupSchema` | `size` | `icon` |
+  | `ObjectChartSchema` | `chartType` | `column`, `horizontal-bar`, `donut` |
+  | `FormSchema` | `validationMode` | `onTouched`, `all` |
+  | `SelectSchema` | `defaultValue`, `value` | `boolean` |
+  | `DataTableSchema` | `selectable` | `'single'`, `'multiple'` (alongside `boolean`) |
+  | `ViewSwitcherSchema` / `ViewTypeSchema` | `defaultView`, `activeView`, `views[].type` | `chart` |
+  
+  **Each one was decided by measuring the renderer, not by matching the declaration.**
+  Widening a mirror to its declaration is only correct where the running code
+  implements the missing spelling; where a spelling is dead, the right fix is to
+  withdraw it from the declaration (ADR-0049 enforce-or-remove), not to teach the
+  validator to accept something that renders nothing. The read sites:
+  `buttonVariants`' `cva` map (`components/src/ui/button.tsx`) carries all six
+  variants and all four sizes; `AdvancedChartImpl` normalizes `column` to `bar`,
+  maps `horizontal-bar` to a real `BarChart` layout and gives `donut` its own inner
+  radius; `useForm({ mode })` hands `validationMode` straight to react-hook-form,
+  whose `isOnTouch` / `isOnAll` branches implement `onTouched` and `all`;
+  `toControlValue` / `matchOptionValue` (#3090) round-trip a boolean option value
+  with its type intact; `resolveSelectionMode` implements `'single'` as
+  replace-on-select with no select-all header, distinct from `'multiple'`; and
+  `chart` is a rendered view type with its own `case` in both `ListView` and
+  `ObjectView`.
+  
+  Consumer-visible type effect: `z.infer` of these schemas widens accordingly.
+  Widening an input contract cannot break a caller that was already passing a
+  narrower value, but code that exhaustively switches on the inferred union — e.g.
+  a `switch` over `chartType` with no `default` — will want the new arms.
+  
+  Refs objectui#5927 (group A of the 17 measured mirror drifts). The remaining
+  classes are rulings rather than edits and stay in the `KnownDrift` ledger.
+- 864154e: The Field Designer no longer offers a formula-expression textarea, and no designer write
+  path emits a `formula` key (objectui#6043).
+  
+  **This is a behaviour change on an authoring surface: a control is removed.** A field's
+  `type` may still be set to `formula` — that is a valid spec `FieldType` and stays in the
+  palette — but the expression itself is no longer authored here. Authors write formula
+  expressions in metadata-admin's field inspector, where they are checked.
+  
+  The control wrote `formula`, which is not in `FieldSchema`'s accept set. Measured against
+  the installed `@objectstack/spec` 17.2.0:
+  
+  ```
+  FieldSchema.safeParse({ type:'formula', label:'Tax', formula:'price * quantity' })
+    => success = false
+    => unrecognized_keys ['formula']   "Did you mean `formula` -> `expression`?"
+  ```
+  
+  so `PUT /api/v1/meta/object/:name` returned a hard 422 `INVALID_METADATA` — and because
+  the key was then stored, it blocked **every later save of that object**, not just the one
+  that introduced it.
+  
+  **The key was deliberately NOT renamed to the spec's `expression`.** `FieldSchema` judges
+  the key name and never the expression LANGUAGE — measured, it accepts
+  `expression: 'price * quantity'` and even `expression: '!!!not cel at all!!!'`; only the
+  empty string is refused. Spec `expression` is CEL rooted at `record`
+  (`record.amount * 0.1`), whereas this control's own placeholder taught `price * quantity`
+  — bare field refs, which under the scope formulas bind evaluate to null silently. A rename
+  would therefore have converted a loud, immediate 422 into a formula that saves clean and
+  then quietly computes nothing, which is strictly worse than the bug it appears to fix.
+  
+  Making refusals loud *in the control* would need CEL lint, autocomplete and `returnType`
+  inference — that is `CelPredicateField`, which lives in `@object-ui/app-shell`, and
+  app-shell depends on `@object-ui/plugin-designer`, so it cannot be imported back without a
+  dependency cycle. Growing a second formula-authoring surface inside plugin-designer is a
+  feature, not this fix. `returnType` is likewise not authored here: it is only derivable by
+  inferring the CEL result type, and with no expression control there is nothing to infer
+  from.
+  
+  `formula` joins the retired-key tombstone in `MetadataFieldsPage`, so an object already
+  carrying the key is stripped clean on its next save instead of staying blocked forever —
+  which matters more than usual here, because with the control gone an author would
+  otherwise have no way left to clear it. It is dropped rather than migrated to `expression`,
+  for the same reason the rename was refused. A `expression` authored in metadata-admin is
+  **not** touched: it is a real `FieldSchema` key and rides through the designer's
+  round-trip untouched.
+  
+  Also removes the now-unreachable `formula` read/write from
+  `views/metadata-admin/previews/object-fields-bridge.ts`, which was a third emit site for
+  the key that neither the card nor the parity gate named.
+  
+  The `formula` entry is removed from `check-designer-field-key-parity.mjs`'s
+  `KNOWN_UNPARSEABLE_KEYS` ledger, which ratchets in both directions — a resolved key that
+  left a stale entry behind would be as red as a new offender.
+- b023625: The field metadata payload no longer emits `sortOrder`, the key `FieldSchema` refuses by
+  name (objectui#6045). Field-level sibling of objectui#6223, same objectui#5761 family.
+  
+  Measured against the installed `@objectstack/spec` 17.2.0, whose `FieldSchema` accept set
+  is 71 keys:
+  
+  ```
+  FieldSchema.safeParse({ type:'text', label:'L' })                  => success = true   (control)
+  FieldSchema.safeParse({ type:'text', label:'L', sortOrder: 3 })    => unrecognized_keys ["sortOrder"]
+  
+  FieldSchema.safeParse({ type:'text', label:'L', sortable: true })  => success = true   (control)
+  FieldSchema.safeParse({ type:'text', label:'L', sortable: 3 })     => success = false
+  ```
+  
+  The control is what makes that a key-by-key result rather than a schema refusing
+  everything, and the `sortable` pair is what shows the near-spelling is a *different
+  concept* — a boolean ("whether field is sortable in list views"), not this key's spec
+  name.
+  
+  **The resolution was deletion, not a rename**, which is objectui#4687's shape rather than
+  objectui#6041's. The spec has no field-level ordering key at all: it models field order by
+  **declaration order** in the object's `fields` record, so a designer that wants explicit
+  ordering reorders that record rather than carrying an index. There was nothing to map onto,
+  and nothing was invented to map onto.
+  
+  **It was latent, and that is confirmed on today's tree.** Neither of the two sites that
+  construct a `DesignerFieldDefinition` — `FieldDesigner`'s create/update handlers and
+  `MetadataFieldsPage.toDesignerField` — ever named the key, so `toFieldPayload` emitted
+  `sortOrder: undefined` and `JSON.stringify` dropped it. The key never reached the wire. It
+  was one reorder feature away from doing so, which is the objectui#4644 shape: a hard 422
+  `INVALID_METADATA` that blocks every subsequent save of the object, with nothing in the UI
+  to say which key caused it.
+  
+  Removed in one go from the wire shape (`FieldMetadataPayload`), its writer
+  (`toFieldPayload`) and the UI model (`DesignerFieldDefinition`), so no declaration is left
+  behind that no writer fills and no schema accepts.
+  
+  **Breaking for TypeScript consumers**: `sortOrder` is gone from `DesignerFieldDefinition`
+  (`@object-ui/types`) and from `FieldMetadataPayload` (app-shell), so code that set either
+  stops compiling.
+  
+  Two keys share this spelling and are untouched, which is why the census was on the *shape*
+  — a field-metadata payload key `FieldSchema` refuses — rather than on the identifier: the
+  **object-level** `sortOrder` (`ObjectSchema`'s, removed from the object wire shape by
+  objectui#6223 and deliberately kept on the `ObjectDefinition` UI model) and the
+  **saved-view** `sortOrder` in `ObjectView`, which is per-view display order on a different
+  document entirely.
+  
+  The `KNOWN_UNPARSEABLE_KEYS` entry in `scripts/check-designer-field-key-parity.mjs` goes
+  with the fix — that ledger ratchets in both directions, so an entry left behind for a
+  resolved key is as red as a missing one.
+- 75bd83d: `ObjectGanttSchema` declares the flattened `GanttConfig` face `ObjectGantt`
+  actually reads (objectui#6051). `getGanttConfig` has two branches: when
+  `startDateField` and `endDateField` are both present at the TOP level it builds
+  its config from top-level keys and returns early; otherwise it reads the `gantt`
+  block. Everything the first branch reads was undeclared — and unlike
+  objectui#5903's ten, none of it was hidden behind a cast. `BaseSchema` carries
+  `[key: string]: any` (objectui#5155's structural ceiling) and the helper's
+  parameter was `ObjectGridSchema | any`, so `schema.colorField` type-checked as
+  `any` with no syntax anywhere to grep for. That is also why the census here is an
+  AST enumeration and not a compile-and-observe: an index signature absorbs every
+  literal name, so annotating the parameter compiles clean while enforcing nothing.
+  
+  **27 keys join the declared surface, each additive and each with a live read
+  site.** 24 flattened `GanttConfig` members — `colorField`, `borderColorField`,
+  `dependenciesField`, `parentField`, `typeField`, `lockField`, `objectField`,
+  `summaryExtent`, `defaultCollapsedDepth`, `tooltipFields`, `baselineStartField`,
+  `baselineEndField`, `groupByField`, `resourceView`, `assigneeField`,
+  `effortField`, `capacity`, `quickFilters`, `autoZoomToFilter`, `timeSegments`,
+  `interactions`, `exportFileName`, `timeZone`, `dependencyTypes` — plus the three
+  query keys the fetch path reads, `staticData`, `filter` and `sort`. Nothing is
+  declared that the renderer does not consume.
+  
+  **`GanttConfig` itself gains nine members and is a published type**, exported by
+  name from `packages/types/src/index.ts`: `lockField`, `objectField`,
+  `summaryExtent`, `defaultCollapsedDepth`, `borderColorField`, `dependencyTypes`,
+  `timeZone`, `exportFileName`, `interactions`. The entry file's diff is empty only
+  because the export list already named the type — the widening happened at the
+  declaration.
+  
+  **The 28th measured key, `gantt` (the block face), is deliberately NOT declared**
+  — see the closing section.
+  
+  The 24 are DERIVED from `GanttConfig` rather than restated, so the flat spelling
+  cannot fork from the block spelling, and the invariant is pinned in the type
+  system: every key of `GanttConfig` must be declared at the node's top level.
+  Making that derivation possible moved nine members — `lockField`, `objectField`,
+  `summaryExtent`, `defaultCollapsedDepth`, `borderColorField`, `dependencyTypes`,
+  `timeZone`, `exportFileName`, `interactions` — out of `plugin-gantt`'s
+  package-private `GanttConfigEx` and into `@object-ui/types`' `GanttConfig`. They
+  are a MOVE, not new vocabulary: the `gantt` block already honoured all nine, and
+  a type private to the plugin could be referenced by neither authoring face.
+  
+  Both halves move together, as in objectui#5903: the TS declaration and its zod
+  mirror gain the same 27 keys at the same requiredness (all optional), the
+  spec-modelled ones taken from `GanttConfigSchema.shape` by reference, so the
+  `zod-mirror-parity` ratchet stays at zero drift for this pair and no `KnownDrift`
+  or `UnmirroredDeclared` entry is added. The mirror builds the flat face and the
+  `gantt` block from one field map, so they are one schema expressed twice.
+  
+  Accept-set change, stated plainly. All 27 keys are additive — every one is
+  optional, and nothing previously legal loses its slot. What changes is that a
+  **declared** key is now type-validated, so `capacity: 'one'` and
+  `summaryExtent: 'parent'` are refused where they used to parse green. An
+  **undeclared** key is still accepted — `BaseSchema` is `.passthrough()`, so this
+  bought no rejection of misspellings. There is no narrowing anywhere in this
+  change.
+  
+  **`gantt` is severed on purpose (objectui#6475), not overlooked.** It is the 28th
+  key of the measured residue and a genuine read — `getGanttConfig`'s second branch
+  honours it in full — but it is the one key whose declaration would NOT have been
+  additive. It has no mirror entry today, so a block rides through `.passthrough()`
+  unvalidated; declaring it as `GanttConfig` means it gets parsed against the spec's
+  `GanttConfigSchema`, which REQUIRES `startDateField`, `endDateField` and
+  `titleField`, and `ObjectGanttSchema` reaches the CLI's `validate` / `check`
+  through `AnyComponentSchema`. A published CLI's refusal behaviour is decided on
+  its own card, where reviewers can see what they are approving; objectui#6475
+  carries the full measurement, including the case FOR enforcing it (the renderer
+  already feeds that block to `GanttConfigSchema.safeParse` and warns, so enforcing
+  restores declared = enforced rather than inventing a contract). Today's behaviour
+  is pinned in the test file so the omission is a measured state, not a silent gap.
+  `packages/types/src/__tests__/gantt-flat-config-declared-keys.test.ts` pins both
+  halves so neither can be misread.
+  
+  Which face WINS is unchanged and was not decided here: the flat branch is checked
+  first and returns early, so a node carrying both spellings still renders the flat
+  one. (`plugin-map` had the opposite precedence ruled on in objectui#5018; no
+  equivalent ruling exists for gantt.)
+- 971d387: ⚠️ **Behaviour change: an authored `FormSection.visibleWhen` that has been doing nothing
+  will now START HIDING SECTIONS.** Read this before upgrading if any of your metadata
+  authors a section predicate.
+  
+  `@objectstack/spec` declares `FormSection.visibleWhen` and this repo's spec bridge maps it
+  through, but every plugin-form layout renders a section header as a virtual
+  `section-divider` pseudo-field and none of them copied the predicate onto it. On the
+  object-view chain — the create/edit modal, the drawer, the split form, and the full-page
+  record form — the key was declared, mapped, carried, and then dropped one hop before
+  anything could evaluate it. The section rendered unconditionally, with no diagnostic
+  (objectui#6111).
+  
+  **Why nobody noticed, and why the fix is felt as a regression.** `visibleWhen` fails OPEN:
+  a section that renders is what you get when the predicate resolves TRUE, when the predicate
+  never arrives, *and* when the predicate faults. Those three worlds were indistinguishable,
+  so an app that authored a section predicate saw its section render and had no way to tell
+  that the rule was inert. Every such app has been running with the rule switched off, and
+  some will have been authored — or simply grown used to — that state. After this change the
+  predicate is evaluated for real, and sections that have always been visible will disappear
+  for the users the rule excludes.
+  
+  This is the intended ADR-0089 contract being delivered, not a new capability: the key was
+  already declared, already documented, and already honoured by the console form renderer.
+  The object-view chain was the one that silently ignored it.
+  
+  **Before upgrading**, audit any `sections[].visibleWhen` in your form-view metadata and
+  confirm each predicate says what you actually want, evaluated against `record` +
+  `current_user`. A predicate that was written speculatively, or left behind after a rework,
+  now takes effect.
+  
+  **Measured scope of the hide.** The predicate gates the section's HEADER row. The renderer
+  treats `section-divider` as presentational and holds no association between it and the
+  fields that follow it, so a false predicate removes the heading and the section's fields
+  keep rendering. The console renderer (`apps/console`) drops the whole `<section>`, fields
+  included. That divergence is real, is pinned honestly by this change's tests rather than
+  implied away, and is filed separately — it needs a renderer-side grouping contract, not
+  another line in a layout.
+  
+  Two hops were dropping the key and both are repaired: `ObjectForm` rebuilds each section
+  key by key when it delegates to Split/Drawer/Modal (and `ModalForm`'s own `groups` map does
+  it again), so a key those maps did not copy never reached the layout at all; and the six
+  `section-divider` synthesis sites across the four layout files.
+  
+  `@object-ui/types` gains the matching `ObjectFormSection.visibleWhen` declaration.
+- db3a600: `StackSchema` now SHIPS the members it declares (objectui#6151). Its emitted declaration
+  carried one property — `type` — where it was meant to carry twenty-five.
+  
+  The interface was written `extends Omit<FlexSchema, 'type'>`: "everything `FlexSchema` has,
+  with a different `type`". That spelling erases every named member. `Omit` of a type over a
+  key set is `Pick` over `Exclude` of `keyof` that type, and `keyof` a type carrying a string
+  index signature is `string | number` — the literal member names are absorbed. `FlexSchema`
+  inherits `BaseSchema`'s `[key: string]: any` (objectui#5155), so excluding `'type'` from
+  `string | number` still leaves `string | number`, and the `Pick` rebuilt a type holding the
+  index signature and none of the named members. Measured against the built `dist`:
+  `FlexSchema` declared 25 properties, `StackSchema` declared 1.
+  
+  Nothing errored, which is why it survived four releases: the index signature keeps every
+  absent key assignable and readable as `any`. The cost fell entirely on the tools that READ
+  the declaration. Editor completion on a `stack` node offered `type` and nothing else — no
+  `gap`, no `align`, no `justify`, no `children`. And a docs-versus-type sweep read
+  `stack.mdx` as documenting keys that do not exist: objectui#6143 flagged `gap`, `children`
+  and `className` there as divergences when the docs were right and the type was wrong.
+  
+  Fixed at the mechanism rather than by restating the members. The six flex/stack members now
+  live in a new exported interface, `FlexLayoutProps`, which does NOT inherit `BaseSchema`,
+  and `FlexSchema` and `StackSchema` each extend `BaseSchema` and `FlexLayoutProps`. No
+  `Omit` crosses the index signature any more, and the members are declared once rather than
+  duplicated. Extending `FlexSchema` directly was measured unavailable: an interface may
+  narrow an inherited property only to a subtype, and `'stack'` is not a subtype of
+  `FlexSchema`'s `type: 'flex'` (TS2430).
+  
+  `FlexSchema` is unchanged — its six member declarations moved byte-identically, and its
+  emitted member set is the same 25 names before and after. The only declaration whose shape
+  changes is `StackSchema`, which goes from 1 property to the same 25.
+  
+  **The one way this can newly error**, and why it ships as `minor`: keys on a `stack` node
+  were previously answered by the index signature as `any`, so `gap: 'large'` type-checked.
+  `gap` is now `number | undefined` and that line is a `tsc` error. Every value this newly
+  rejects is one the renderer never honoured — `stack.tsx` feeds `gap` to a Tailwind numeric
+  scale — so the change reports a defect that was already there rather than removing a
+  capability. All three in-repo packages that name `StackSchema` or `FlexSchema`
+  (`@object-ui/components`, `@object-ui/core`, the schema-catalog example) type-check green
+  unchanged.
+  
+  Guarded by `packages/types/src/__tests__/stack-schema-emitted-members.test.ts`, which
+  asserts against the EMITTED declaration rather than the source. That distinction is the
+  whole point: a source-level assertion passes on the broken code, because the index
+  signature answers for the missing key with `any`. The guard emits declarations with the
+  package's own tsconfig and asserts (1) `StackSchema` declares exactly what `FlexSchema`
+  declares, and (2) no member of the `LayoutSchema` union has lost any of `BaseSchema`'s
+  named members — so the next heritage clause that collapses under the index signature reds
+  for the whole class, not just for this one interface.
+- e4559d1: `TimelineSchema` now declares the presentational keys the timeline renderer actually reads
+  (objectui#6170, maintainer ruling 2026-08-25 — the same family rule adopted on
+  objectui#6172: the exported type aligns to the measured authored + read set).
+  
+  Before this, `TimelineSchema` declared `events` (required), `orientation` and `position`,
+  and nothing else. `TimelineRenderer` is annotated `schema: TimelineSchema` and reads nine
+  keys off that node — `variant`, `items`, `dateFormat`, `onItemClick`, `minDate`, `maxDate`,
+  `rowLabel`, `scale`, `timeScale` — and **none** of the three that were declared. The docs
+  property table and the registration's own designer `inputs` had agreed with the renderer
+  all along; only the exported type disagreed. It was invisible to `tsc` because `BaseSchema`
+  carries `[key: string]: any`, so every undeclared key resolved as `any` and the annotation
+  constrained nothing.
+  
+  The most visible casualty was the docs page's own TypeScript example, which did not
+  compile: `Property 'events' is missing in type '{ type: "timeline"; variant: string; items:
+  … }' but required in type 'TimelineSchema'`. The page taught an authoring form its own
+  published type refused.
+  
+  **Declared now** (TS interface and the `@object-ui/types/zod` mirror together): `variant`,
+  `items`, `dateFormat`, `scale`, `timeScale`, `rowLabel`, `minDate`, `maxDate`. `onItemClick`
+  is deliberately left undeclared — it is a runtime slot `ObjectTimeline` installs, and this
+  package keeps callback-shaped keys off the authored surface.
+  
+  **`scale` is the canonical axis key.** It is `@objectstack/spec`'s `ui/TimelineConfig.json`
+  spelling and the one `resolveTimelineScale` reads first (`scale ?? timeScale`). The designer
+  now offers it, with all six buckets: `hour` / `quarter` / `year` have rendered correctly
+  since objectui#2942 but were offered by neither the designer (which listed three) nor the
+  exported type (which listed none), so they were authorable and undiscoverable. `timeScale`
+  stays as a deprecated alias so stored JSON keeps working; retiring it is routed separately.
+  
+  **`events` is now optional.** It was required, which is why the documented authoring form
+  did not type-check. That widening is the only non-additive change here — strictly more
+  programs compile and strictly more input parses than before. `events`, `orientation` and
+  `position` remain declared and remain read by nothing; a timeline authored with `events`
+  still renders an empty rail. Their removal is a breaking narrowing of a published type and
+  is routed through ADR-0049 enforce-or-remove as its own change, not smuggled into this one.
+  
+  Accept-set note for consumers: keys that previously resolved as `any` are now typed, so a
+  value the renderer never implemented — `variant: 'diagonal'`, `dateFormat: 'medieval'`,
+  `scale: 'fortnight'` — is a type error and a Zod rejection where it used to pass silently.
+  Nothing that renders today stops rendering. `BaseSchema`'s index signature is untouched, so
+  an undeclared key is still accepted by both halves (objectui#5155 / objectui#6269 own that
+  ceiling).
+- d7acad6: **plugin-gantt: the `gantt` block now outranks the flat top-level spelling, and
+  the losing face's keys are named instead of dropped.**
+  
+  `getGanttConfig` checked the flattened top-level spelling first and returned
+  early, so a node carrying both spellings rendered the flat one and every key
+  inside an authored `gantt` block was discarded with **no diagnostic** — not even
+  the `GanttConfigSchema.safeParse` warning, which sat behind that early return.
+  
+  `plugin-map` had the identical two-faces shape ruled the other way (maintainer
+  ruling on objectui#5018, 2026-08-17, landed in PR #5156): the block wins, with a
+  dev-mode warning naming the ignored top-level keys. objectui#6469 inherits that
+  ruling, so the two sibling view plugins now answer the same question the same
+  way.
+  
+  What changes:
+  
+  - A node carrying **both** spellings now renders the **`gantt` block's** values.
+    The block is taken **whole** — the flat keys are not merged into it.
+  - In dev, `[ObjectGantt] … these top-level keys are IGNORED: …` names every
+    shadowed flat key, once per distinct shadowing.
+  - Nothing else moves. A node with only the flat spelling, or only a block, is
+    read exactly as before.
+  
+  **Producer-safe:** `ObjectView` (`case 'gantt'`) and `ListView` (`case 'gantt'`)
+  both flatten `options.gantt` onto top-level keys and emit **no** `gantt` key, so
+  every gantt reached through either view layer still takes the flat branch, and
+  the new warning cannot fire on that path. This is the same producer check the
+  `plugin-map` flip pinned, re-run on today's `main`.
+  
+  This **supersedes** the precedence sentence in the objectui#6051 changeset
+  (`.changeset/6051-gantt-flat-config-declared-keys.md`), which recorded the flat
+  branch winning — accurate for that change, which deliberately did not touch
+  precedence, and reversed by this one.
+- bf3a03c: `ToastSchema` now declares the two trigger-button keys the `toast` renderer actually reads
+  (objectui#6496, triage scope cut 2026-08-26 — the same declare-what-runs family as
+  objectui#6170).
+  
+  `renderers/feedback/toast.tsx` renders a `<Button>` that raises the toast, and reads two
+  keys off the node to do it: `variant={schema.buttonVariant}` and
+  `{schema.buttonLabel || 'Show Toast'}`. `ToastSchema` declared **neither**, on the TS face
+  or in the `@object-ui/types/zod` mirror. The registration's own designer `inputs` offered
+  `buttonLabel` (with `defaultValue: 'Show Toast'`), so the designer shipped a control for a
+  key the published type did not have; `buttonVariant` was read by the renderer and named by
+  nothing at all. `SonnerSchema` — the sibling with the identical trigger mechanism —
+  declared both all along, so only one of the two components was expressible.
+  
+  The visible cost was on objectui#6250: with `buttonLabel` undeclared, its seven corrected
+  toast demos could not author a per-demo trigger label the way the corrected sonner demos
+  could, and all seven render the default `Show Toast`. Those demos are unblocked by this.
+  
+  **`buttonVariant` is declared as the six Button variants, on both faces.** The model this
+  card was told to copy disagrees with itself: `SonnerSchema` spells the key `z.string()` in
+  the zod mirror and `'default' | 'secondary' | 'destructive' | 'outline' | 'ghost' | 'link'`
+  in TS. Matching by symmetry picks nothing, so the shape was taken from what the value
+  *reaches* — the renderer passes it straight into `<Button variant={…}>`, whose prop type is
+  `VariantProps<typeof buttonVariants>['variant']`, exactly those six. The TS face is the
+  correct one and both faces here carry it.
+  
+  An open `string` is not merely under-validation. Measured on `cva` 0.7.1: an unrecognised
+  variant key contributes **no** variant class, and `defaultVariants` applies only when the
+  value is *absent* — so `buttonVariant: 'primary'` renders a button with no background and
+  no text colour, silently, while `buttonVariant: undefined` renders the default look
+  correctly. `primary` is the likeliest wrong spelling precisely because the default
+  variant's own class is `bg-primary`. And `buttonVariant: ''` is silently resolved to
+  `default` by the same falsy fallback — the one wrong value that does not *look* wrong,
+  which an open `string` would accept and never signal. That the declared six are the Button's own vocabulary
+  is pinned in both directions in `components/src/__tests__/toast-button-variant-parity.test.ts`
+  — `@object-ui/types` has zero deps and cannot import the Button, so the list there is
+  necessarily hand-copied, and that file is what stops it being a copy that can drift.
+  
+  **`SonnerSchema`'s own two faces are left disagreeing.** Its mirror stays `z.string()`.
+  That is a real defect on a published surface, and it is filed as objectui#6541 rather than
+  fixed here —
+  this card's face is `ToastSchema`, and narrowing a second published key is its own
+  accept-set change with its own consumers to measure.
+  
+  **Direction 2 of the finding is untouched.** `action` and `onDismiss` are declared on
+  `ToastSchema` and read by no renderer; they sit immediately adjacent to this edit and are
+  byte-identical after it. They are enforce-or-remove on a published type and belong to the
+  objectui#6124 unsatisfiable-mirror census feeding the objectui#6182 handler-dialect
+  decision; they are deliberately not pinned here either, so that family's ruling lands
+  without a test of this card's to negotiate with.
+  
+  Accept-set note for consumers: both keys are **optional** and materialise no default, so
+  nothing that renders today stops rendering and no stored toast JSON becomes invalid. Two
+  keys that previously resolved as `any` through `BaseSchema`'s index signature are now
+  typed, so `buttonLabel: 42` and a `buttonVariant` outside the six are a type error and a
+  Zod rejection where they used to pass silently — values that never rendered correctly in
+  the first place. `BaseSchema` is untouched, so an *undeclared* key is still accepted by
+  both halves (objectui#5155 / objectui#6269 own that ceiling); declaring these two bought
+  validation of the declared keys, not rejection of misspellings.
+- ce503e5: **Accept-set NARROWING on a published surface.** `SonnerSchema.buttonVariant` in the zod
+  mirror (`@object-ui/types/zod`) was `z.string()`; it is now
+  `z.enum(['default', 'secondary', 'destructive', 'outline', 'ghost', 'link'])`. Values
+  outside those six — `'primary'`, `'danger'`, `'Default'`, `''` — used to validate and now
+  fail. Stated as a narrowing rather than as a fix, because it removes values the published
+  mirror accepted (objectui#6541).
+  
+  **What was wrong.** The same key on the same component shipped as two disagreeing published
+  faces: an open string to anyone validating (`@object-ui/types/zod`), and a closed
+  six-member union to anyone type-checking (`@object-ui/types`, `SonnerSchema.buttonVariant`
+  in `feedback.ts`). The TS face was already correct — only the mirror is changed here, so
+  this is the mirror being made to agree with a declaration that sat beside it all along.
+  
+  **Why the wide face was wrong and not merely wide.** `renderers/feedback/sonner.tsx` passes
+  the value straight into `<Button variant={…}>`, whose vocabulary is exactly those six keys
+  of `buttonVariants`. Measured on `cva` 0.7.1, an unrecognised key contributes **no** variant
+  class, and `defaultVariants` applies only when the value is absent *or falsy*:
+  
+  ```
+  buttonVariants({ variant: undefined }) -> "… bg-primary text-primary-foreground …"  default look
+  buttonVariants({ variant: 'ghost'   }) -> "… hover:bg-accent …"                     real variant
+  buttonVariants({ variant: 'primary' }) -> "…"                                       NO colour at all
+  buttonVariants({ variant: ''        }) -> "… bg-primary …"                          silently 'default'
+  ```
+  
+  So the mirror was validating values the renderer visibly breaks on: `'primary'` — the
+  likeliest wrong spelling, since the default variant's own class is `bg-primary` — rendered a
+  button with no background and no text colour, and `''` was silently reinterpreted as
+  `default`. Nothing that renders correctly today stops validating.
+  
+  **Blast radius, measured.** The key stays optional, so every published `sonner` node that
+  omits it keeps parsing. The two fixtures in the repo that set it
+  (`examples/schema-catalog/src/schemas/components-feedback-sonner/{error,promise-based-toast}.json`)
+  use `destructive` and `outline` — both inside the six. No consumer was found relying on a
+  seventh spelling.
+  
+  **Model inherited, not invented.** objectui#6496 landed exactly this spelling on
+  `ToastSchema` for the same trigger mechanism, matched to `ButtonProps['variant']` as ground
+  truth. This card applies the settled shape to the sibling that still disagreed with itself.
+- b55a346: `'agenda'` leaves `CalendarViewMode` and the zod `CalendarViewModeSchema`
+  (objectui#5740 — the value-level residue of objectui#5667's key-level
+  convergence of `CalendarViewSchema` on the registered `calendar-view`
+  renderer's measured read set; ADR-0049 enforce-or-remove).
+  
+  The union declared a value nothing enforced: the registered renderer's `view`
+  input declares `enum: ['month','week','day']`, `resolveAuthoredView` resolves
+  any off-enum value — `'agenda'` included — to `undefined` (the component's
+  `'month'` default), and `CalendarView` renders no agenda view. An author
+  writing the type-legal, zod-valid `view: 'agenda'` got a month calendar with
+  no error or warning. No in-repo, example, or catalog app authors
+  `view: 'agenda'` (measured during objectui#5667's sweep and re-measured for
+  this change, including the objectstack tree).
+  
+  **This narrows the accept set — unlike #5667's key retirements, which created
+  no new rejections.** `view` is a declared key, and declared keys are validated
+  even under `.passthrough()`, so `view: 'agenda'` is now a **validation error
+  that previously parsed green** (an `invalid_value` issue on the `view` path,
+  offering `month`/`week`/`day`). Undeclared keys still pass through unchanged.
+  Breaking on the published zod surface; ships as `minor` per this repo's
+  version-alignment policy (majors track `@objectstack`).
+  
+  The runtime boundary is unchanged: an off-union `view` in raw metadata still
+  falls back to the component's `'month'` default at the renderer, and the
+  registry input already declared the three-value enum. Docblocks, the schema
+  reference table, and the zod `describe` no longer teach an `'agenda'`
+  fallback.
+- 065bba7: `CalendarViewSchema` (TS interface and zod mirror) converges on the registered
+  `calendar-view` renderer's measured read set (objectui#5667, maintainer ruling
+  option A — the renderer is authoritative).
+  
+  **Breaking for consumers of the published type** (deliberate; per-repo policy
+  breaking changes ship as `minor` — the fixed group's `major` tracks
+  `@objectstack`):
+  
+  - Nine inert keys are retired: `events` (the interface's only required key,
+    which the renderer deliberately drops — objectui#4433), `defaultView`,
+    `defaultDate`, `date`, `views`, `editable`, `onEventCreate`,
+    `onEventUpdate`, `onDateChange`. None had a read site on the authored-node
+    path and no measured app authors them (ADR-0049 enforce-or-remove).
+  - The type now declares what the renderer actually reads: `data`, `titleField`,
+    `startDateField`, `endDateField`, `allDayField`, `colorField`, `view`,
+    `currentDate`, `allowCreate`, `className`, plus the two host-only function
+    hatches it forwards (`onEventClick`, `onViewChange`).
+  - Practical radius, measured: `BaseSchema` carries an index signature and the
+    zod `BaseSchema` is `.passthrough()`, so nodes still authoring retired keys
+    neither fail to compile nor get rejected at validation — they are simply no
+    longer declared, documented, or type-checked. The material accept change is
+    that zod no longer **requires** `events`: a `{ "type": "calendar-view" }`
+    node without it now validates (previously the one key validation demanded
+    was the one key guaranteed to do nothing).
+  
+  Runtime renderer behaviour is unchanged. `@object-ui/plugin-calendar`'s README
+  and `content/docs/api/schema-reference.md` are repaired to the converged
+  surface in the same change, so no copy of the old contradiction survives.
+- 6d1c155: `ComponentMeta` is now declared once and re-exported, and `PluginComponentMeta` is
+  deprecated in favour of `ComponentMeta` (objectui#5893).
+  
+  ## The convergence
+  
+  `@object-ui/types` published `ComponentMeta` twice, from two different declarations:
+  `base.ts` and `plugin-scope.ts` (the latter published as `PluginComponentMeta`). They
+  were structural copies, not an alias pair. `plugin-scope.ts`' `ComponentMeta` is now
+  `export type { ComponentMeta } from './base.js'` — the disposition objectui#4580 ruled
+  for the identical shape, *a structural copy would reproduce the defect the moment either
+  side moved*, and the same move objectui#5671 made for the sibling type `ComponentInput`
+  in the same file.
+  
+  Either side had already moved. `base.ts` declared eleven keys; the plugin-scoped copy
+  declared nine — the same nine, **minus `tags` and `description`**. So a plugin author
+  typing against the plugin-facing declaration could not write two keys the main surface
+  advertises, and which the runtime validator already accepted: `ComponentMetaSchema` in
+  `zod/base.zod.ts` declares all eleven, so two of the three authorities agreed and the
+  plugin-facing one did not. `resizeConstraints`' six members were identical in both, so
+  the delta was exactly those two keys.
+  
+  What changes for a consumer: `tags` and `description` become writable on the
+  plugin-facing type. Nothing narrows — no key is removed and no key's type changes, so no
+  existing registration stops compiling. The convergence buys **acceptance** of two keys;
+  it buys no rejection of anything. `ComponentMetaSchema` is a plain `z.object` with no
+  `.strict()`, so it strips unknown keys rather than refusing them, and that is unchanged
+  here.
+  
+  ## The alias deprecation, sequenced after it
+  
+  `PluginComponentMeta` — the published alias for the plugin-scoped declaration — is now
+  `@deprecated` in favour of `ComponentMeta`. **`PluginComponentMeta` is the name to search
+  for** if you import it; replace it with `ComponentMeta` from the same entry point.
+  
+  This is stage 1 of objectui#5674's two-stage retirement (maintainer ruling, 2026-08-22:
+  deprecate for a release, then remove). Nothing is removed here — the export still exists
+  and still names the same type.
+  
+  The ordering is deliberate and is why the two halves ship together. Until the convergence
+  above, the alias named a genuinely different nine-key interface; deprecating it then
+  would have warned consumers about a name that was still about to change meaning. It is
+  deprecated now, at its final meaning.
+  
+  **Why a deprecation window rather than a deletion.** The measurement that licenses
+  deleting an export from a published package is *"no importer"*, and what can be measured
+  from inside this repository is only *"no importer here"*. In-repo, `PluginComponentMeta`
+  has exactly one occurrence — its own export line — searched across every root
+  (`packages/`, `apps/`, `content/`, `docs/`, `skills/`, `examples/`, `e2e/`, `scripts/`,
+  `eslint-rules/`, `public/`, `.changeset/` and the root docs) plus the sibling
+  `objectstack` framework checkout, with controls searched identically so a broken search
+  could not read as a clean one. What no search here can see is a consumer on npm. **That
+  external caveat is unchanged from objectui#5674 and is not being dropped:** the window
+  converts a silent break into a warned one before stage 2 lands. Stage 2 removes the alias
+  and the now-dead re-export in `plugin-scope.ts` that exists only to feed it, and ships as
+  a `minor` under this repo's policy that its own breaking changes never declare `major`.
+  
+  ## Pinned by identity, not by member set
+  
+  A new test asserts that `plugin-scope.ts` re-exports the declaration and declares no
+  `ComponentMeta` of its own. A member-set assertion cannot do this job: TypeScript is
+  structurally typed, so a local re-declaration carrying the same eleven keys is mutually
+  assignable with the imported one and passes every type-level check. A member-identical
+  structural copy is exactly what objectui#4580 predicted would drift and exactly the state
+  this card recorded — this copy started identical and acquired its two-key delta later.
+  The member-set checks are kept alongside the identity pin, labelled as the control that
+  shows what it cannot see.
+- d7573b3: `ComponentInput` is now declared once and re-exported, instead of restated in three
+  places (objectui#4972).
+  
+  `@object-ui/core`'s `ComponentInput` (`registry/Registry.ts`) and `@object-ui/types`'
+  plugin-scoped `ComponentInput` (`plugin-scope.ts`, published as `PluginComponentInput`)
+  were structural copies of the interface in `@object-ui/types`' `base.ts`. Both are now
+  re-exports of that one declaration, which is the disposition objectui#4580 ruled for the
+  identical shape — *a structural copy would reproduce the defect the moment either side
+  moved* — and the way `core/src/types/index.ts` already handles `SchemaNode`.
+  
+  Either side had already moved. `base.ts` declared thirteen keys; both copies declared
+  nine, so `min` / `max` / `step` / `placeholder` were missing from **the copy every
+  component registration actually imports**. Those four keys were unwritable at any real
+  registration — a plain TypeScript error at the call site — while `ComponentInputSchema`
+  (the zod schema) and `ComponentMeta.inputs` both accepted them. The publication face
+  advertised four keys the authoring face rejected. Measured over the repository, no
+  registration had tried to write one yet, so nothing a user hits was broken today; what
+  changes is that the four keys become writable, and there is no longer a second
+  declaration for the next widening to miss.
+  
+  `ComponentInput`'s arm vocabulary (`ComponentInputControlType`) was already a single
+  declaration imported by all three sites (objectui#3832); this converges the rest of the
+  interface.
+  
+  Measured, not assumed: `@object-ui/core`'s published entry `dist/index.d.ts` is
+  byte-identical across the change (sha256 `f6494f80…`, both legs). That gauge is reported
+  here only with its control — a probe that added a *required* key to `ComponentInput` left
+  the same file byte-identical, because `dist/index.d.ts` is a 63-line barrel of
+  `export *` lines that names `ComponentInput` zero times. The gauge that can actually fail
+  is the emitted declaration file: `dist/registry/Registry.d.ts` changes, as does
+  `@object-ui/types`' `dist/plugin-scope.d.ts`, and those two files are the *only* emitted
+  declarations that change in either package.
+  
+  `WidgetInput`'s union-arm capability is deliberately untouched — a different gate path
+  and a separate judgment.
+- 18a8e7d: **Published TS surface narrowed:** `DashboardComponentSchema` no longer declares
+  the `aria` member (`{ ariaLabel?, ariaDescribedBy?, role? }`). Its doc comment
+  claimed alignment with `@objectstack/spec AriaPropsSchema`, but the spec removed
+  `dashboard.aria` at the #3896 audit close-out — `DashboardSchema.shape.aria` is
+  a tombstone that refuses any value and tells authors to delete the key — and no
+  dashboard renderer ever read `schema.aria` (objectui#5830).
+  
+  What an author loses is the **type-level suggestion** only: the key was already
+  refused at parse (the Zod twin inherits the spec tombstone by reference), and
+  `BaseSchema`'s index signature means an existing `aria:` line still compiles.
+  There is **no runtime behaviour change** — the key never rendered, and stored
+  documents carrying it already failed validation before this release.
+- e7957ab: **Retired the designer-surface dashboard `aria` pair — `DashboardConfig.aria` and `DashboardConfigSchema.aria`** (objectui#5852).
+  
+  Both spellings are named verbatim above so a host can grep its own sources: the
+  retired member is `aria`, on the TypeScript interface `DashboardConfig`
+  (`@object-ui/types`, `designer.ts`) and on its Zod mirror `DashboardConfigSchema`
+  (`@object-ui/types/zod`). It declared `{ label?: string; description?: string }`.
+  
+  **Why.** The spellings `label`/`description` match neither `@objectstack/spec`'s
+  `AriaProps` vocabulary (`ariaLabel` / `ariaDescribedBy` / `role`) nor anything a
+  renderer maps, so no read point could have consumed them even in principle.
+  Re-measured on `main` at the retirement: zero `.aria` reads in
+  `packages/plugin-designer/src`, `packages/plugin-dashboard/src` and
+  `apps/console/src`; zero occurrences of either name anywhere in the `objectstack`
+  repo; and `DashboardConfigPanel.tsx` — the panel the interface's own doc comment
+  says it serves — imports neither name.
+  
+  **The two directions differ, and neither is a no-op:**
+  
+  - **TypeScript (a narrowed suggestion, not a compile break).** `DashboardConfig`
+    carries a `[key: string]: any` catch-all, so an existing `aria:` line still
+    compiles; what is gone is the editor suggestion and the false implication that
+    the key was part of the contract.
+  - **Zod (a behaviour change — read this one).** `aria` is now an ADR-0049
+    retirement tombstone (`z.never().optional()`), following this package's
+    existing convention. Previously an authored `aria` was **accepted and
+    preserved** in `safeParse` output; it is now **refused by name**, with `aria`
+    in the issue path and a message telling the author to delete the key. A plain
+    deletion was deliberately not taken: `DashboardConfigSchema` is a bare
+    `z.object` with no `.strict()`, so deleting the key would have made an
+    authored `aria` **silently disappear** from the parsed output instead — a
+    quiet data loss in place of a loud refusal.
+  
+  **External caveat.** In-repo consumer count is zero, but that is not the npm
+  count: `@object-ui/types` is published, and stored dashboard configuration is
+  not reachable from this repo. A host that authored `aria` on a `DashboardConfig`
+  document will now see a validation error naming the key where it previously saw
+  a silently carried value. The remedy is to delete the key — it never reached a
+  renderer.
+- f7e34ca: Close the dashboard widget `type` vocabulary, and admit `metric-card` as objectui's own component extension.
+  
+  `DashboardWidgetSchema.type` was `string` on the TypeScript interface and `z.string()` in the Zod twin — an unbounded hatch. A typo'd family, a chart type the spec retired, and a component type nothing registers all type-checked and validated, surfacing only as the renderer's red `OBJUI-001` panel at runtime.
+  
+  It is now the CLOSED `DashboardWidgetTypeName` / `DashboardWidgetTypeSchema`: the spec's own `ChartTypeSchema` families **by reference**, plus two named, closed objectui extension sets — `DASHBOARD_WIDGET_TYPE_EXTENSIONS` (`list`, `custom`: objectui-only widget families) and `DASHBOARD_COMPONENT_WIDGET_TYPES` (`metric-card`: an objectui SDUI **component** type the widget slot holds directly, per the maintainer ruling of 2026-08-14 — objectui's own component enum, explicitly not the spec widget enum).
+  
+  Three drifts the closure surfaced and this change fixes: the dashboard designer's palette offered `grid`, which is not a widget family in either contract and was refused at publish; the metadata-admin widget inspector and the designer both wrote an unvalidated `string` from their select boxes; and a `@object-ui/types` fixture pinned `bar-chart`, a `plugin-charts` component type, on a dataset-bound widget that could never render as one.
+- fa429cf: The register-meta key `defaultChildren` is retired (objectui#5051).
+  
+  It was declared in four places, produced in eleven, and read in **none**. The designer's
+  drop path builds a new node from its twin key only — `PageDesigner.tsx`,
+  `props: paletteItem?.defaultProps ?? {}` — with no `children:` line, so a palette item
+  that declared `defaultChildren` dropped an **empty** node and the declared children never
+  materialised. Nothing rendered the wrong thing; an entire declaration surface was simply
+  inert, which is the declared-but-unenforced shape ADR-0049 targets. Per the maintainer
+  ruling of 2026-08-19, the key is removed rather than wired up; if designer
+  default-children UX is ever product-wanted it returns as its own designed card.
+  
+  **If you author plugins against the published register-meta table, drop the key.** It is
+  gone from `skills/objectui/guides/plugin-development.md`, which had been teaching it. A
+  meta that still declares it stays *valid*: `ComponentMetaSchema` is a plain `z.object`,
+  and measured on zod 4.4.3 that STRIPS unknown keys rather than rejecting them — so the
+  key is silently dropped from the parse output instead of failing validation. TypeScript
+  authors get the loud signal instead: all three `ComponentMeta` declarations
+  (`@object-ui/types` `base.ts` and `plugin-scope.ts`, `@object-ui/core` `Registry.ts`) no
+  longer offer it, so re-declaring it is now a compile error.
+  
+  **No runtime behaviour changes in either direction.** No code path read the key before
+  this change, and the eleven producers that set it (`sidebar.tsx` x10, `span.tsx`) were
+  feeding a reader that did not exist. Dropping a `span` or any of the ten sidebar types
+  into the designer produces exactly the node it produced yesterday.
+  
+  Two suites keep it retired, one per package: `packages/types` pins the zod twin (the key
+  is absent from the parse output, with a surviving sibling asserted present through the
+  same parse as the control) plus the two TS twins with `@ts-expect-error`, and
+  `packages/core` pins the registration surface the eleven producers were written against.
+  Both are compile-time-enforced through each package's chained `tsconfig.test.json`.
+- ed8df3e: `'agenda'` leaves `defaultView` on all three of its declaration faces
+  (objectui#5784 — the `defaultView` sibling of objectui#5740's retirement on
+  `CalendarViewSchema.view`; ADR-0049 enforce-or-remove): the
+  `ObjectCalendarSchema` TS interface (an inline union `#5740`'s
+  `CalendarViewMode` narrowing could not reach), the zod `ObjectCalendarSchema`,
+  and the list-view `calendar` config's objectui-only `defaultView` extension.
+  All three are now `['month', 'week', 'day']`.
+  
+  The declarations admitted a value nothing enforced: `ObjectCalendar`'s props
+  declare `defaultView?: 'month' | 'week' | 'day'`, its schema read casts to the
+  same three values, and `CalendarView` renders no agenda view. An author
+  writing the type-legal, zod-valid `defaultView: 'agenda'` on an
+  `object-calendar` node or in a list view's `calendar` config got a month
+  calendar with no error or warning. The spec side already agrees:
+  `@objectstack/spec`'s `ObjectCalendarProps.defaultView` is
+  `['month', 'week', 'day']`. No in-repo, example, or catalog app authors
+  `defaultView: 'agenda'` (measured for objectui#5784 with positive controls,
+  including the objectstack tree — its only `agenda` token is the Agenda
+  job-scheduler library).
+  
+  **This narrows the accept set: an author who writes `defaultView: 'agenda'`
+  will now be refused at validation.** `defaultView` is a declared key, and
+  declared keys are validated even under `.passthrough()`, so
+  `defaultView: 'agenda'` is a **validation error that previously parsed
+  green** (an `invalid_value` issue on the `defaultView` /
+  `calendar.defaultView` path, offering `month`/`week`/`day`). Undeclared keys
+  still pass through unchanged. Breaking on the published zod surface; ships as
+  `minor` per this repo's version-alignment policy (majors track
+  `@objectstack`).
+  
+  The runtime boundary is unchanged: `ObjectCalendar` still resolves an
+  off-union raw `defaultView` away to its `'month'` default. Docblocks and both
+  zod `describe` strings now teach the three-value set.
+- 199d31b: **`viewMode` is now declared authoring surface on `ObjectGanttSchema`, and both
+  gantt renderer branches honour it** (objectui#5074, maintainer ruling
+  2026-08-19: declare-and-wire; the spec half landed first upstream).
+  
+  - `ObjectGanttSchema` (TS interface and zod mirror) declares `viewMode`,
+    DERIVED from the pinned `@objectstack/spec` `GanttConfigSchema.viewMode`
+    enum by reference, so the member list cannot drift. Deliberately no
+    default: an omitted `viewMode` keeps letting a persisted layout
+    (`persistLayoutKey`) seed the timeline granularity before the renderer's
+    `'day'` fallback.
+  - The timeline branch (`GanttView`) now receives an authored `viewMode`.
+    Previously only the resource-workload branch (`resourceView` +
+    `assigneeField`) honoured it, so `viewMode: 'month'` on an ordinary gantt
+    view was silently ignored.
+  - The `(schema as any).viewMode` cast in `ObjectGantt` is retired; both
+    branches read the declared `ganttConfig.viewMode`, which also honours the
+    key when authored inside the spec's `gantt` config block.
+  - Accept-set note: `viewMode` is now a DECLARED key, so an off-enum value
+    (e.g. `viewMode: 'hour'`) becomes a zod validation error where it
+    previously passed through unvalidated. Values on the published spec enum
+    are unaffected.
+- 105f3c5: Retire `CRUDSchema` and the `type: 'crud'` node spelling (objectui#5373,
+  maintainer ruling 2026-08-20, route 2) under ADR-0049 enforce-or-remove.
+  
+  `crud` had four declaration faces and no registered renderer, for the whole
+  life of the key: the TS interface (`packages/types/src/crud.ts`), the zod
+  mirror (`packages/types/src/zod/crud.zod.ts`), a dedicated branch in
+  `validateSchema` that affirmatively PASSED it, and `CRUDBuilder` in
+  `@object-ui/core`. A node spelling it painted the OBJUI-001 "Unknown component
+  type" panel, and `content/docs/api/schema-reference.md` published it as
+  reference material — so a reader (or an AI author) who copied the page got a
+  red panel.
+  
+  Removed from `@object-ui/types`: the `CRUDSchema` interface and its zod
+  mirror, the four shapes that existed only to type its keys — `CRUDOperation`,
+  `CRUDFilter`, `CRUDToolbar`, `CRUDPagination` and their zod mirrors and
+  `…SchemaType` aliases — and `CRUDSchema` as a member of `CRUDComponentSchema`,
+  which is what took it off the node union `AnySchema`. `ActionSchema`,
+  `DetailSchema` and `CRUDDialogSchema` are unchanged and remain the union's
+  members.
+  
+  Removed from `@object-ui/core`: `CRUDBuilder` and the `crud()` factory.
+  
+  Authoring `crud` is now REFUSED BY NAME rather than passed or silently
+  ignored. `validateSchema` returns an `error` with `code: 'RETIRED_TYPE'` on
+  `schema.type` — at any depth, since it is what `validateChildren` recurses
+  with — so `assertValidSchema` throws and `isValidSchema` answers `false`. The
+  message names the migration: `object-grid` for the record table with its
+  toolbar, filters, pagination and row/batch actions, `object-form` for the
+  create/edit form, and `detail` for the record view. `api/schema-reference.md`
+  is rewritten around those shapes.
+  
+  Note on blast radius: the repository itself contains zero authored `crud`
+  nodes and zero registrations of the key (measured on the merge base against
+  the doc gate's own 659-key registry derivation, which reads `register` and
+  `registerLazy` alike). That is an IN-REPO zero, not an npm zero — a published
+  consumer that imported the `CRUDSchema` type, called `crud()` / `CRUDBuilder`,
+  or authored `type: 'crud'` will see a compile error or a validation error
+  respectively. Both are the intended, loud replacement for a shape that has
+  never rendered.
+- 3ccd9e8: Split the static `table` column type off the rich shared `TableColumn`
+  (objectui#5474, maintainer ruling 2026-08-22: Option C), so declared =
+  enforced holds per renderer.
+  
+  `TableColumn` is unchanged and remains the rich shape `data-table`,
+  `CRUDSchema` and detail-view relations honour. The static `table` renderer's
+  `TableSchema.columns` now declares the new narrow `StaticTableColumn`
+  (`header`, `accessorKey`, `className`, `cellClassName`, `width` — exactly the
+  keys that renderer reads). The eleven keys the static renderer never read are
+  retired from its surface as ADR-0049 tombstones: `hoverable` / `striped` on
+  `TableSchema`, and `minWidth` / `align` / `fixed` / `type` / `sortable` /
+  `filterable` / `resizable` / `editable` / `cell` on its columns.
+  
+  Breaking for authored metadata that wrote those keys on a `type: 'table'`
+  node: they were silently inert before and are now refused loudly — a tsc
+  error on the interface (`?: never`) and a parse rejection naming the key in
+  `@object-ui/types/zod`. That loud refusal is the ruled outcome. Migration:
+  nodes that wanted the interactive behaviour move to `type: 'data-table'`
+  (whose columns keep the rich `TableColumn`); right-aligned columns on the
+  static table use `cellClassName: 'text-right'`; alternate-row styling uses
+  Tailwind on `className`.
+- b2ea297: `ObjectSchemaMetadata` is now derived from `@objectstack/spec`'s `ServiceObject`
+  instead of being a hand-written copy (objectui#5362; maintainer ruling
+  2026-08-20: the object document type belongs to the spec).
+  
+  What changes on the published type surface:
+  
+  - **Gained:** the full spec object-document surface, including the three keys
+    the runtime already reads but the old interface rejected as excess
+    properties: `icon`, `titleFormat`, `listViews` (plus `pluralLabel`,
+    `nameField`, `displayNameField`, `managedBy` as a spec key, and the rest of
+    the spec document).
+  - **Removed:** nine members the old interface declared that no objectui
+    runtime code reads and the spec document does not know: `extends`,
+    `triggers`, `primary_key`, `relationships`, `name_field` (the spec spelling
+    is `nameField`), `soft_delete`, `audit_trail`, `version`, `cache`.
+    `ObjectTrigger` and `ObjectRelationship` remain exported unchanged.
+  - **Kept:** `editMode` — the one measured client-side member the runtime reads
+    (`recordFormNavigation` / `AppContent`) — now declared on the new
+    `ObjectSchemaClientExtensions` interface, which the derivation intersects.
+    Note the spec's strict parse rejects `editMode` on published documents
+    (`unrecognized_keys`); it is a client-type member only.
+  
+  Spelling settlement: `listViews` (camelCase) is canonical — `list_views`
+  appears nowhere in `@objectstack/spec` 17.2.0. Runtime read sites in
+  `@object-ui/app-shell` and `@object-ui/react` keep a documented snake-spelling
+  READ fallback for stored pre-settlement documents (that stock has never been
+  censused — objectstack#7917); the CRUD guide and its pinned transcription now
+  author the canonical spelling.
+- 78cbdb5: Retire `ThemeComponentSchema` (`type: 'theme'`) — a component kind no renderer
+  implemented (objectui#5489).
+  
+  `packages/types/src/theme.ts` declared a theme-manager **component** carrying
+  `themes[]`, `activeTheme`, `allowSwitching`, `persistPreference` and
+  `storageKey`, and `packages/types/src/zod/theme.zod.ts` published the matching
+  Zod object as a member of `ThemeUnionSchema` and therefore of
+  `AnyComponentSchema`. Nothing rendered it: `'theme'` appears at no
+  `ComponentRegistry.register(...)` / `registerLazy(...)` site in `packages/*/src`,
+  and in neither `PROTOCOL_COMPONENTS` nor `PALETTE_PLACEHOLDER_BLOCKS`
+  (`packages/components/src/renderers/placeholders.tsx`), so it did not even
+  resolve to a placeholder — a page declaring one got the registry's "Unknown
+  component type" panel (OBJUI-001) instead of a theme manager. Declared-but-
+  unenforced, removed under the maintainer ruling of 2026-08-21 on
+  objectstack#10485 (option B).
+  
+  Removed from the published surface: the `ThemeComponentSchema` type
+  (`@object-ui/types`), the `ThemeComponentSchema` Zod object
+  (`@object-ui/types/zod`), the `ThemeComponentSchemaType` inference alias, and the
+  `'theme'` member of `ThemeUnionSchema` / `AnyComponentSchema`. A schema spelling
+  `type: 'theme'` is now REFUSED by `AnyComponentSchema.safeParse` rather than
+  accepted and then rendered as an error panel, which is pinned by a test.
+  
+  **The theme system is unchanged.** `Theme` (the spec's authoring theme
+  document), `ThemeDefinitionSchema`, `ThemeModeSchema`, `ThemeEngine`
+  (`@object-ui/core`) and `ThemeProvider` (`@object-ui/react`) are all retained and
+  untouched — the same ruling retains them explicitly. Author a theme as a
+  document handed to `ThemeProvider`; that path never went through the removed
+  component kind.
+- b7543a9: Retire `ThemeSwitcherSchema` (`type: 'theme-switcher'`) and
+  `ThemePreviewSchema` (`type: 'theme-preview'`) — the two remaining theme
+  component kinds, which no renderer implemented — together with
+  `ThemeUnionSchema`, the union that after objectui#5489 held only these two
+  members (objectui#5647).
+  
+  `packages/types/src/theme.ts` declared a theme-switcher control (`variant`,
+  `showMode`, `showThemes`, `lightIcon`, `darkIcon`) and a theme-preview panel
+  (`showColors`, `showTypography`, `showComponents`), and
+  `packages/types/src/zod/theme.zod.ts` published the matching Zod objects as
+  the two members of `ThemeUnionSchema` and therefore of `AnyComponentSchema`.
+  Nothing rendered either: neither literal appears at any
+  `ComponentRegistry.register(...)` / `registerLazy(...)` site in
+  `packages/*/src` (202 registered keys enumerated; positive control on the same
+  pipeline: `tooltip` → 1), nor in `PROTOCOL_COMPONENTS` /
+  `PALETTE_PLACEHOLDER_BLOCKS`
+  (`packages/components/src/renderers/placeholders.tsx`), and no fixture
+  declares either kind (control: `"type": "form"` → 81) — so a page declaring
+  one got the registry's "Unknown component type" panel (OBJUI-001), never a
+  switcher or a preview. Declared-but-unenforced, removed under the 2026-08-21
+  maintainer ruling (option B) on objectstack#10485, extended to these siblings
+  by inheritance on identical evidence (objectui#5647).
+  
+  Removed from the published surface: the `ThemeSwitcherSchema` /
+  `ThemePreviewSchema` types (`@object-ui/types`), the matching Zod objects and
+  `ThemeUnionSchema` (`@object-ui/types/zod`), and the `ThemeSwitcherSchemaType`
+  / `ThemePreviewSchemaType` inference aliases. `zod/theme.zod.ts` now exports
+  nothing and stands as the tombstone module. A schema spelling
+  `type: 'theme-switcher'` or `type: 'theme-preview'` is now REFUSED by
+  `AnyComponentSchema.safeParse` rather than accepted and then rendered as an
+  error panel, which is pinned by a test.
+  
+  **The theme system is unchanged.** `Theme` (the theme document vocabulary,
+  owned by `@object-ui/types` since objectui#5716), `ThemeEngine`
+  (`@object-ui/core`) and `ThemeProvider` (`@object-ui/react`) are retained and
+  untouched — the rulings retain them explicitly. Author a theme as a document
+  handed to `ThemeProvider`; that path never went through the removed component
+  kinds.
+- c9327c9: Localize the theme document types: `@object-ui/types` now owns `Theme`, `ThemeMode` and `ColorPalette` (objectui#5716 ruling, 2026-08-23). The spec retired its theme module (objectstack#10485) while ObjectUI retained the theme system, so the types are hand-written from the last-published `@objectstack/spec` 17.1.0 shapes instead of re-exported — a spec dependency refresh past the retirement no longer breaks these packages.
+  
+  Published-name REMOVALS from `@object-ui/types` (zero in-repo readers, deleted under the same ruling's rider):
+  
+  - `Typography` — the shape lives on as the inline `Theme['typography']` member.
+  - `BorderRadius` — lives on as inline `Theme['borderRadius']`.
+  - `Shadow` — lives on as inline `Theme['shadows']`.
+  - `ThemeDefinition` — the deprecated alias of `Theme`; use `Theme`.
+  
+  Also added: `THEME_MODES`, a runtime tuple witness of the theme mode vocabulary (`['auto', 'light', 'dark']`).
+  
+  The `UI` protocol namespace (`import { UI } from '@object-ui/types'`) now resolves `UI.Theme` / `UI.ThemeMode` / `UI.ColorPalette` to the local owners, so they survive the upcoming spec refresh; the rest of the namespace continues to track `@objectstack/spec/ui`. After that refresh, retired spec/ui members (`UI.ThemeSchema`, `UI.ThemeModeSchema`, `UI.ThemeParsed`, `UI.Typography`, `UI.BorderRadius`, `UI.Shadow`, `UI.defineTheme`) drop out of the namespace.
+  
+  `@object-ui/providers`: `ThemePreference` is now derived from `@object-ui/types`' `ThemeMode` instead of the retired spec `ThemeModeSchema` (same union: `'auto' | 'light' | 'dark' | 'system'`).
+- 920165d: Remove the six retired `@objectstack/spec/ui` theme-schema re-exports from `@object-ui/types/zod` — `ColorPaletteSchema`, `TypographySchema`, `BorderRadiusSchema`, `ShadowSchema`, `ThemeModeSchema`, `ThemeDefinitionSchema` (the spec's `ThemeSchema`) — plus their `…SchemaType` inference helpers, and the `theme` / `mode` props of `ThemePreviewSchema` (zod and interface) that consumed them.
+  
+  objectstack#10485 (ADR-0049 enforce-or-remove, PR objectstack#10695) retired the spec's whole `ui/theme.zod.ts` module, and the maintainer's ruling on objectstack#10856 (Options A + C) has objectui remove the dangling imports first so the Console Pin Gate can build objectui against the framework tree; restoring the spec exports (Option B) was explicitly not taken. Breaking in effect for anyone importing those six names from `@object-ui/types/zod`: there is no replacement — the validators retired upstream with no successor. The theme TYPE surface (`Theme`, `ThemeMode`, `ColorPalette`, … re-exported from `@object-ui/types`) and the ThemeEngine/ThemeProvider runtime are unchanged.
+- 4d73b07: The zod `BaseSchema` mirror now accepts everything its TypeScript declaration
+  declares — five keys had drifted narrower (objectui#4605).
+  
+  `@object-ui/types/zod` is a published runtime validator hand-written to mirror the
+  `BaseSchema` interface. As the interface widened, the mirror did not, so five keys
+  refused at parse time a spelling the published types invite and the renderer
+  implements — "declared = enforced" inverted. `.passthrough()` rescued none of them:
+  passthrough admits UNDECLARED keys, and all five are explicitly declared, so the
+  narrow declaration won.
+  
+  Measured against the unmodified mirror before the change, these were the refusals:
+  
+  | key | authored input | old mirror said |
+  |---|---|---|
+  | `visible` | `'${data.status === "open"}'` | `expected boolean, received string` |
+  | `disabled` | `'${data.status === "locked"}'` | `expected boolean, received string` |
+  | `ariaLabel` | `{ key, defaultValue }` | `expected string, received object` |
+  | `label` | `{ en: 'Owner', 'zh-CN': '负责人' }` | `expected string, received object` |
+  | `description` | `{ en: 'The record owner' }` | `expected string, received object` |
+  
+  `visible`/`disabled` now take `boolean | string` — what `evaluateCondition` accepts,
+  no wider. `ariaLabel` takes the KEYED reference through a new exported
+  `KeyedI18nLabelSchema`; `label`/`description` take the spec's own `I18nLabelSchema`
+  BY REFERENCE, so a change to the spec's label contract is picked up rather than
+  re-typed. Every spelling that parsed before still parses.
+  
+  The two i18n vocabularies are kept apart rather than merged into "some object".
+  `label`/`description` are the spec's INLINE locale map (resolved by
+  `resolveI18nLabel(label, locale)`); `ariaLabel` is the KEYED reference (resolved by
+  `resolveKeyedI18nLabel`, which returns `undefined` for a locale map and would render
+  an EMPTY aria-label). Widening both slots to accept either shape would have
+  reproduced objectui#4167's confusability hazard inside the validator that exists to
+  catch it, so each slot admits only its own vocabulary and both cross pairings are
+  pinned as rejections.
+  
+  The new pin is DERIVED rather than a hand-written key list: it reads the mirror's own
+  `.shape` and compares each key against the declaration, so the next widening of
+  `base.ts` that forgets this file turns it red with no list to maintain. It reads
+  `.shape` and not `keyof z.input<…>` because that spelling was measured vacuous —
+  `.passthrough()` collapses the inferred key union to bare `string`, and a pin written
+  over it resolved `never` while five keys were demonstrably narrow. Two guards pin the
+  derivation against both degenerations (`never` and `string`).
+
+### Patch Changes
+
+- 06a8af5: `QueryParams.$filter` now declares both shapes the data sources actually accept — the
+  MongoDB-style field-keyed record, or a `FilterArray`, the ObjectQL AST sugar bound from
+  `@objectstack/spec/data` (objectui#3909).
+  
+  **Nothing is narrowed and no accepted value changes.** `Record<string, any>` already
+  accepted arrays structurally — they satisfy its string index — so the union documents
+  shapes that were always legal rather than admitting new ones. Measured both ways under
+  `tsc --strict`: all five inputs `translateFilterToAST` enumerates assign to the old and
+  new declarations alike, and both reject a bare number and a bare string identically. A
+  downstream `turbo run build` over all 43 dependent packages is green, which is the
+  evidence a published type change breaks no consumer.
+  
+  The harm was entirely on the type face, and it was two-sided. The declaration blocked
+  nothing while describing one legal shape as though it were the only one — objectui#3831
+  is what that cost, a rule array accepted by a `Record<string, any>` slot, object-spread
+  flattened to `{"0": {...}}`, types green, and the query filtering on a column literally
+  named `0`. And someone writing a new consumer would read the type and its record-only
+  `@example`, conclude the array path was illegal, and add a tolerant conversion for it —
+  the "widen the consumer to tolerate the producer" shape AGENTS.md #0.1 forbids. Two
+  producers have fed arrays through this slot all along: `plugin-list`'s
+  `buildEffectiveFilter` (grid and export) and `plugin-view`'s `ObjectView` (calendar /
+  kanban / gallery / timeline). The runtime was right; the declaration was narrow.
+  
+  The array half is **bound** to the spec's `FilterArray` rather than restated locally, so
+  it cannot fork from the vocabulary the servers parse — the same failure two hand-written
+  operator lists had in objectui#3948. The doc comment names `translateFilterToAST` as the
+  authoritative accepted set instead of carrying a second list to drift from.
+  
+  `@object-ui/fields` drops the local cast this defect forced. PR objectui#3908 wrote
+  `filter as Record<string, any>` at one assignment in `useRecordQuery`, deliberately, as
+  debt rather than widening the shared type. `hasFilter` is now a type predicate narrowing
+  to the `$filter` slot's own type, so the assignment needs no cast and the guard cannot
+  drift from the declaration it guards. Type-only throughout; no runtime behaviour changes.
+- 6f81384: `ObjectViewSchema`'s `table` and `form` slots now ship the members they promise
+  (objectui#6269). Both were declared by deriving from the schema they document — `table?:
+  Partial<Omit<ObjectGridSchema, 'type' | 'objectName'>>`, `form?: Partial<Omit<ObjectFormSchema,
+  'type' | 'objectName' | 'mode'>>` — and both derived types declared **zero** properties.
+  
+  `Omit<T, K>` is `Pick<T, Exclude<keyof T, K>>`, and `keyof T` on a type carrying a string index
+  signature is `string | number` — the literal member names are absorbed. `ObjectGridSchema` and
+  `ObjectFormSchema` both inherit `BaseSchema`'s `[key: string]: any` (objectui#5155), so each
+  `Pick` rebuilt a type holding the index signature and none of the named members. Measured
+  through the TypeScript checker: `ObjectGridSchema` 61 members, the `Omit` of it 0;
+  `ObjectFormSchema` 67, the `Omit` of it 0. This is objectui#6151's collapse in *property*
+  position — #6151's guard walks the `LayoutSchema` union and cannot see properties on
+  `ObjectViewSchema`.
+  
+  Nothing errored, because the index signature answered every key as `any`. The visible costs
+  were the ones only a reader of the declaration meets: `table: { colunms: 3 }` type-checked,
+  `table: { pageSize: 'ten' }` type-checked, and editor completion inside `table: { … }` offered
+  nothing at all for a slot documented as "inherits from ObjectGridSchema".
+  
+  Each `Omit` is now a `Partial<Pick<…>>` over an explicit key list — 59 keys for `table`, 64 for
+  `form`, i.e. every declared member minus the identity keys the view itself fixes. `Pick` with
+  literal keys never computes `keyof T`, so it cannot collapse the same way. The key lists are
+  pinned against silent drift by `packages/types/src/__tests__/object-view-slot-key-lists.test.ts`,
+  which recomputes each source schema's declared members through the TypeScript checker and
+  requires set equality; a member added to `ObjectGridSchema` and not to the list turns it red.
+  
+  **Tightening, deliberately.** Restoring named members re-enables excess-property checks on
+  object literals assigned into these two slots, so a misspelled key there is now an error
+  instead of silently doing nothing. That is the intent of the fix. The slots' member *types* are
+  unchanged — every key that resolved to a real declared type before still does.
+  
+  The `Pick` lists exist only because `BaseSchema` carries a root string index signature. When an
+  objectui#5155 phase removes it, `Omit` stops collapsing and the lists (plus their pin) become
+  removable; the pin's own comment records the condition, and one of its assertions is the
+  tripwire that will notice.
+- dddb942: Delete the dead `metadata-admin/previews/object-fields-bridge.ts` module, and the three
+  prose references that still described it as wired.
+  
+  The module exported `bridgeFromDraft`, `commitToDraft` and `FieldsBridgeResult` and had
+  **zero importers** — re-measured on the merged base, not inherited from the filing. Nothing
+  in the repository could reach it either: `@object-ui/app-shell`'s `exports` map declares
+  only `.` and `./styles.css`, so the file was not addressable as a deep import even from
+  outside the workspace.
+  
+  Removing it is not the whole change. Three comments — in `types/src/designer.ts`, `types`'
+  `designer-field-types.test.ts` (twice) and `fields`' `richtext-cell-renderer-5452.test.tsx`
+  — cited the bridge as a live corroborating source. Left behind, they would have swapped
+  dead code for false documentation: three in-repo pointers telling a future reader that this
+  bridge mediates between the framework field record and `FieldDesigner`, and nothing telling
+  them it is unreachable. The two that named it as the consumer deriving an editable-subset
+  check from `DESIGNER_FIELD_TYPES` now name `MetadataFieldsPage`, which does exactly that
+  with the same idiom and the same `objectui#3017` anchor. The third cited the bridge's
+  `richtext` → `html` mapping as one of three corroborations that `richtext` stores HTML; the
+  other two (the showcase seed and the field-type decision tree) are live and carry the point
+  on their own, so that clause is dropped rather than repointed.
+  
+  No behaviour changes: nothing imported the module, so there is nothing to migrate.
+- c8ea8af: `PartialSchema<T>` is pinned as collapsed, and its doc comment now says so
+  (objectui#6397). Nothing about the type changes — the declaration is deliberately
+  left exactly as written.
+  
+  The alias promises "all properties optional except the type" and does not deliver
+  it. Every instantiation declares exactly ONE property, `type`, and carries a live
+  `[key: string]: any`, so it accepts any key at `any`. Measured through the
+  TypeScript checker against the emitted `index.d.ts` — the same instrument that
+  produced objectui#6269's 61 -> 0 reading:
+  
+      PartialSchema<ObjectGridSchema>  -> 1 declared property: type   (source: 61)
+      PartialSchema<ObjectFormSchema>  -> 1 declared property: type   (source: 67)
+      PartialSchema<ObjectViewSchema>  -> 1 declared property: type   (source: 42)
+      PartialSchema<ButtonSchema>      -> 1 declared property: type   (source: 27)
+  
+  `Omit<T, K>` is `Pick<T, Exclude<keyof T, K>>`, and `keyof T` on a type carrying a
+  string index signature is `string | number` — the literal member names are
+  absorbed. Every `T extends BaseSchema` inherits `BaseSchema`'s `[key: string]: any`
+  (objectui#5155), so `Partial<Omit<T, 'type'>>` rebuilds a type holding the index
+  signature and none of the named members. This is objectui#6151's collapse
+  (heritage clause) and objectui#6269's (property position) in a third position: a
+  generic mapped-type alias, which is why neither of their guards sees it — #6151's
+  walks the `LayoutSchema` union, #6269's reads `ObjectViewSchema`'s two slots.
+  
+  **Why a pin and not a repair or a retirement.** Triage ruled on 2026-08-25 that
+  retiring the alias is a removal of a published export of `@object-ui/types` — a
+  breaking removal of published capability, which sits on the human floor — and that
+  escalating it today would spend the maintainer's attention on a question
+  objectui#5155 is expected to moot. Repair in place is unavailable: `T` is generic,
+  so there is no literal key list to `Pick` the way #6269 could for its two concrete
+  schemas, and every generic re-spelling collapses for the same `keyof T` reason.
+  Once #5155 removes the root index signature, the alias starts working as written
+  with no edit at all. What this ships is the removal of the one impermissible
+  state — *declared, published, collapsed, and unpinned*.
+  
+  No runtime code, no type declaration and no accepted value changes; a consumer's
+  `PartialSchema<X>` means exactly what it meant before. Declared `patch` rather
+  than as a no-release so the doc-comment warning actually reaches the published
+  `.d.ts` a consumer reads — that warning is the deliverable half of the card.
+- f20dcf0: `ObjectGanttSchema`'s flattened gantt face documents `colorField`, `parentField`,
+  `tooltipFields` and `quickFilters` in its own words, instead of pointing at a type that
+  says nothing about them (objectui#6547).
+  
+  Those four members carried a bare `See {@link GanttConfig}.` pointer. `GanttConfig` is
+  `SpecGanttConfig & { … }`, and all four arrive from the **spec** half: the local half of
+  that intersection declares exactly ten top-level members (`timeSegments`, `lockField`,
+  `objectField`, `summaryExtent`, `defaultCollapsedDepth`, `borderColorField`,
+  `dependencyTypes`, `timeZone`, `exportFileName`, `interactions`) and none of these four is
+  among them. `SpecGanttConfig` is `z.input<typeof GanttConfigSchema>`, and the spec's
+  emitted `.d.ts` carries no per-member JSDoc — its 19 members are bare `z.ZodOptional`
+  entries under one type-level "Gantt Settings" docblock. So the pointer was not merely
+  unhelpful, it was misdirecting: a reader who followed it landed on a type documenting
+  nothing about the key and concluded the key was undocumented.
+  
+  Verified on the built artifact rather than the source: all four bare pointers were present
+  in `dist/objectql.d.ts` before this change and none is after, so the defect was on the
+  published surface and the repair reaches it.
+  
+  **Prose only — the published shape is unchanged, and that is the point.** The natural
+  repair, writing the prose onto `GanttConfig`, means re-declaring these members inside the
+  intersection; PR objectui#6546 measured that as a widened published surface on the built
+  `dist/index.d.ts` and it was rejected there. So the shape was measured, not asserted:
+  `ObjectGanttSchema`'s 45 members and their checker-resolved types are byte-identical
+  before and after, and the built face's 51 declaration lines diff clean with comments
+  stripped. Only comment bytes moved.
+  
+  The seven **member-qualified** pointers (`See {@link GanttConfig.borderColorField}`,
+  `.lockField`, `.summaryExtent`, `.defaultCollapsedDepth`, `.timeSegments`,
+  `.interactions`, `.exportFileName`) name members of that ten-member local half, resolve to
+  real prose, and are deliberately left alone — the defect is the bare form, and a substring
+  search for `{@link GanttConfig` hits both.
+  
+  The prose is taken from the renderer's live read sites in `plugin-gantt`, not invented:
+  `colorField`'s status/state/priority/severity fallback chain and the platform default
+  blue, `parentField`'s unknown-id-renders-as-root rule, `tooltipFields`' drop-empty-rows
+  behaviour (which is what lets a mixed-object tree list the union of every level's fields)
+  and its replacement of the default date · duration · progress tooltip line, and
+  `quickFilters`' schema-resolved option domains. No behaviour change, no runtime code.
+- 100547e: `objectui validate` now refuses a form field whose widget id names a namespace
+  other than `field:`, matching the verdict `@object-ui/core`'s `validateSchema`
+  has given since objectui#5375 (objectui#5449).
+  
+  The CLI reaches `FormFieldSchema` through `safeValidateSchema`, and that schema
+  declared `type` and `widget` as bare optional strings — so a field typed
+  `ui:password` validated clean while the runtime validator rejected the same
+  document with `UNRESOLVABLE_FIELD_WIDGET_NAMESPACE`. The CLI is the surface an
+  author actually runs before shipping, so it was the one handing out the false
+  green: an author did exactly the diligence objectui#5375 asks for and still
+  shipped metadata that renders a secret into a plain text box.
+  
+  A `superRefine` on `FormFieldSchema` now states the rule, mirroring core's
+  precedence (`widget` before `type`), the key it blames, its error code and its
+  message verbatim, so the two entry points cannot describe one defect two ways.
+  
+  **This rejects documents that previously validated.** Only colon-qualified
+  field widget ids outside the `field:` namespace are affected — `field:`-prefixed
+  ids and bare names such as `password` still pass, registered or not. A field
+  carrying, say, `type: 'ui:password'` must be rewritten as `password` or
+  `field:password`; it never rendered as a password box in any case.
+  
+  Which of the repo's authoring-time validators is canonical remains open
+  (objectui#4631) — this states the rule on the zod side rather than unifying
+  them.
+- 0e05aac: The console's cold load no longer asks `/api/v1/runtime/config` or
+  `/auth/me/localization` twice (objectui#5544).
+  
+  Two pairs of boot callers were racing each other for the same URL, with no shared
+  provider between them, so no guard inside either component could see the other:
+  
+  - `GET /api/v1/runtime/config` — the pre-React branding script inlined in
+    `apps/console/index.html` (it runs during HTML parse so the tab title and
+    favicon are the operator's before the bundle is fetched) and
+    `initRuntimeConfig()`. Measured ×2 on prod and on staging. This is the
+    expensive one: the console `await`s `initRuntimeConfig()` before
+    `createRoot().render()`, so the duplicate sat on the critical path to first
+    paint, and at the control plane's ~0.5–1.4 s for this endpoint it also pushed
+    boot concurrency further past the server's pool knee.
+  - `GET /api/v1/auth/me/localization` — `seedTenantLanguage()` on a device's true
+    first visit and `LocalizationFetchProvider` on every boot. The seed keeps
+    running past its 500 ms race by design and the provider mounts the moment that
+    race resolves, so on a first visit the two overlap. Measured ×2 on staging.
+  
+  `@object-ui/types` gains `sharedGetJson()`: callers that ask for the same GET
+  while one is already in flight join that request instead of starting another. It
+  shares the in-flight promise and nothing else — the entry is deleted the instant
+  the request settles, so there is no cache, no TTL and no stale window, and a
+  caller arriving after settle fetches fresh exactly as before. Rejections fan out
+  to every sharer with the status intact (`LocalizationFetchProvider`'s retry
+  policy still sees its own 503), each caller receives its own copy of the parsed
+  body, and only GETs are eligible — a non-GET is refused rather than quietly
+  rewritten.
+  
+  Requests that differ in credentials mode or headers keep separate identities, so
+  the console's two deliberate `auth/get-session` calls — one Bearer-only with the
+  cookie omitted to detect a stale token, then one through the cookie — stay two
+  requests. Collapsing those would have destroyed the signal the first one exists
+  to read.
+  
+  No component receives anything different: same payloads, same errors, one fewer
+  round trip.
+- f9e4f91: `DashboardComponentSchema.dateRange.defaultRange` is now bound to
+  `DateRangeDefaultRange` from `@objectstack/spec/ui` instead of restating it as a
+  hand-written 14-member union (objectui#4984).
+  
+  The union was byte-faithful to the spec — all 14 members, same order — so nothing
+  a user hits changes today. What was missing is the tie that keeps it faithful:
+  `resolveDashboardFilterDefs` takes `Pick<DashboardComponentSchema, 'globalFilters' |
+  'dateRange'>`, so this union is what typechecks every TS-constructed dashboard, and
+  a preset the spec ADDS would have been a legal document that objectui's own types
+  said could not exist — the "narrower than the contract it implements" shape whose
+  consequence in objectui#4163 was that the bad reads were invisible to `tsc`.
+  
+  No gate reported it: `check:spec-symbols` rule 1 matches by NAME and an inline union
+  on an interface member has no symbol to collide with, while rule 2's claim heuristic
+  was waved through by the `SpecGlobalFilter` reference a few lines above. Binding makes
+  the file's existing "Aligned with @objectstack/spec" comment structural rather than
+  prose.
+  
+  The emitted `.d.ts` collapses the inline union to the imported alias; the published
+  type surface is unchanged — measured with the TypeScript checker over the emitted
+  declarations (679 reachable exports from `dist/index.d.ts`, 22 from `dist/complex.d.ts`,
+  and `defaultRange` resolving to the same 14 string-literal members before and after).
+- 4e8622b: `ActionParam`'s doc block no longer claims that spec 17 narrowed `I18nLabel` to a
+  plain string (objectui#4611).
+  
+  The paragraph explaining why `label` / `options[].label` are inherited rather than
+  locally overridden justified itself with a claim about `@objectstack/spec` that was
+  never true: "in spec 17 `I18nLabelSchema` is `z.ZodString` — inline per-locale objects
+  were dropped in favour of translation files". Measured against the installed GA pin
+  `@objectstack/spec@17.0.0` (`dist/ui/index.d.ts:614`), `I18nLabelSchema` is a union of
+  a string and a string-to-string record, and the schema's own doc block states two
+  authorized forms with "Both are real; neither is deprecated by this schema". Executed
+  against `dist/ui/index.mjs`: plain string accepted, inline locale map accepted,
+  `{ key, defaultValue }` rejected. A reader who believed the comment would have taken a
+  widening to `string | I18nLabel` for a no-op — which is what the finding recorded, one
+  seat having nearly done exactly that.
+  
+  The replacement describes what `I18nLabel` admits and cites the spec's own doc block
+  rather than restating a zod expression; where today's spelling is named it is scoped as
+  a measurement against 17.0.0 with its file and line, so it ages as a reading rather than
+  as a standing fact. The decision itself is unchanged and never depended on the false
+  premise — `label` flows in by reference through the spec's schema, and a local
+  `string | I18nLabel` collapses to `I18nLabel` whichever forms the union holds.
+  
+  Documentation only, and the release-visible surface is the declaration file: measured
+  with the package's real `tsc` build (`removeComments: false`, per `tsconfig.base.json`),
+  108 emitted files on both sides, `dist/ui-action.d.ts` 29,176 → 31,026 bytes, and every
+  other file byte-identical — including `dist/ui-action.js` (3,480 bytes, unchanged sha),
+  because the comment documents an `interface`, which is erased at emit along with its
+  leading comment. No behaviour changes; hover text and the shipped `.d.ts` do.
+- dffd752: The `I18nLabel` "inverted pin" now watches the premise it claims to watch, and
+  `ui-action.ts` no longer imports a symbol it never uses (objectui#5612, objectui#5613).
+  
+  Both are residue of the same removed local `label` / `options[].label` override.
+  
+  The `it(...)` case in `packages/types/src/__tests__/page-nav-misc-spec-parity.test.ts`
+  that called itself an inverted pin on the spec's `I18nLabel` rested on one assertion,
+  `const label: SpecI18nLabel = 'Priority'`, under a comment claiming spec 17 had narrowed
+  `I18nLabel` to a plain string and that a re-widening would stop it compiling. A plain
+  string is assignable under the narrow shape *and* under the wide one, so that assignment
+  could only ever fail if the plain-string form were removed — the opposite of the event it
+  was written to catch. The widening had already landed: `@objectstack/spec@17.0.0`
+  declares `I18nLabelSchema` as a union of a string and a string-to-string record
+  (`dist/ui/index.d.ts:614`), and the pin stayed green through it. It reported protection
+  it did not provide, and asserted a false premise in its own name.
+  
+  It is retargeted at what actually holds the decision up — not which single form the spec
+  has, but that **both** authorized forms stay assignable, on the spec type and on the
+  inherited `ActionParam['label']` and `options[].label`. It now fails when either form is
+  withdrawn, and deliberately does not fail on a further widening, since inheriting by
+  reference is exactly what stays correct as the authorized set moves. The comment is
+  rewritten against the schema's own doc block (two authorized forms, "Both are real;
+  neither is deprecated by this schema") instead of the false premise. Verified by
+  construction: against a locally built narrow `type I18nLabel = string` the new assertions
+  fail with `TS2344` and `TS2322`, where the old assignment compiles clean under both
+  shapes.
+  
+  `ui-action.ts`'s `I18nLabel` type import is deleted — no type position had used it since
+  the override was removed, and nothing re-exported it — and the doc paragraph that
+  recorded the pin as `NOT guarded` is corrected, since the same change makes it a guard.
+  
+  No behaviour changes; the release-visible surface is the declaration file. Measured with
+  the package's real `tsc` build, both legs building from a cleared `dist/` and cleared
+  composite build info: 108 emitted files on both sides, exactly one differing —
+  `dist/ui-action.d.ts`, 31,026 → 31,117 bytes, JSDoc prose only, no declaration changed.
+  Every other file is byte-identical, including `dist/ui-action.js` (3,480 bytes, unchanged
+  sha), because the comment documents an `interface`, which is erased at emit along with
+  its leading comment. The deleted type import contributes no emitted delta at all, and the
+  rewritten test file is not part of the build.
+- 689b979: Add `editable` to the rich `TableColumnSchema` zod mirror. The `TableColumn` interface declares `editable?: boolean` and `data-table` honours it, but the mirror omitted the key, so a non-strict parse silently stripped it — and since the renderer treats absence as `true`, a column an author locked with `editable: false` came out of validation editable again. Columns locked with `editable: false` now stay locked through any pipeline that parses metadata via `@object-ui/types/zod` (including the CLI `validate` route).
+- 0fce2ef: `maxToolRoundtrips` on `ChatbotSchema` is deprecated: it is inert, and an author
+  who sets it is now told so instead of being left believing the documented cap
+  applies (objectui#5605).
+  
+  The key was declared authorable in `@object-ui/types` (interface and zod, with a
+  description), threaded from the authored document through the chatbot renderer at
+  three call sites, accepted by `useObjectChat`, given a default — and then dropped.
+  Measuring the installed chat runtime says it cannot be honoured from here rather
+  than that someone forgot to wire it: `@ai-sdk/react`'s `useChat` takes `ChatInit`
+  plus throttle/resume, and `ChatInit` declares exactly one loop control — the
+  boolean predicate `sendAutomaticallyWhen` — and no numeric cap under any
+  spelling. The numeric knob was removed from `useChat` in a major, and its
+  successor was renamed through `continueUntil` to `stopWhen` / `stepCountIs`,
+  which the installed `ai` package declares only on `generateText`, `streamText`
+  and the tool-loop agent settings — all server-side. ObjectUI is backend-agnostic,
+  so it owns no server loop to cap either, and putting the number in the request
+  body would only move the same dead key one hop onto a wire contract no backend
+  reads.
+  
+  This is stage one of a two-stage retirement, so nothing an author already wrote
+  breaks: the key still parses, still carries its declared shape, and the renderer
+  still threads it. What changes is that it is now marked `@deprecated` in the
+  interface, the zod description and the docs, and that authoring it logs a
+  one-time notice naming the knob that does work — `planning.maxIterations` on the
+  agent. A follow-up removes the declaration once this deprecation has shipped in a
+  release.
+- a691c0b: `PageSchema.kind`'s TSDoc names the real per-tier styling primitive for source-authored pages instead of the "HTML + Tailwind" framing ADR-0080's own amendment retracted.
+  
+  This is a published type surface: the TSDoc ships in `@object-ui/types`'s built
+  `.d.ts` and is what an author reads on hover over `kind`. It said a `kind:'html'`
+  page is "constrained JSX/HTML + Tailwind" — and it links
+  `content/docs/guide/react-pages.md`, which objectui#5413 has already corrected to
+  say the opposite. Shipped type documentation was contradicting the guide it points
+  readers to.
+  
+  ADR-0080's header amendment (2026-06-30, under ADR-0065, Accepted) supersedes that
+  framing on styling: a page's `source` is *runtime metadata*, the console's Tailwind
+  is compiled at build time by scanning the console's own `src`, and there is no
+  safelist — so an authored utility class produces CSS only by coincidence, when
+  objectui already ships that exact class, and otherwise produces nothing with no
+  error anywhere. That is the ADR-0065 failure mode verbatim ("works only by
+  coincidence"), and it is how a modal's `bg-black/50` backdrop reached production
+  fully transparent.
+  
+  The tiers themselves are unchanged, and every load-bearing claim in the TSDoc
+  survives verbatim — parse-never-execute and untrusted-author safety for `html`,
+  the deprecated `'jsx'` alias, EVALUATED-in-the-main-tree with no sandbox behind the
+  `react-pages` host capability for `react`, the ADR-0080 citation and the guide
+  link. Only the styling conclusion changes, to the primitive each tier actually has:
+  
+  | `kind` | Style with |
+  |---|---|
+  | `"html"` | The blocks' own structured props (`` `<flex direction gap>` ``, `` `<grid columns>` ``) plus a JSON `style` object. |
+  | `"react"` | Inline `style` objects. |
+  
+  Colors on both tiers come from the theme as `hsl(var(--token))`, so a page follows
+  light/dark and whatever theme the deployment installs. The TSDoc now also names the
+  rule that reports a violation — `page-source-className-tailwind`, shipped in
+  `@objectstack/lint@11.5.0` as `validatePageSourceStyling` and reported by
+  `os validate` as a warning on both tiers.
+  
+  No behaviour change, and the accepted `kind` set is untouched.
+  
+  `packages/components/src/renderers/layout/react-page.tsx` carries the same
+  correction on its two source comments (the injected-scope note and
+  `buildComponentScope`), and gains the styling note the file was missing. Those are
+  internal comments — they do not project into any `.d.ts` and change no export — so
+  they get no entry of their own; there is nothing an `@object-ui/components`
+  consumer could read in a CHANGELOG and act on.
+- 515f171: `PluginComponentInput` is deprecated in favour of `ComponentInput` (objectui#5674).
+  
+  This is stage 1 of a two-stage retirement the maintainer ruled on 2026-08-22: deprecate
+  for a release, then remove. Nothing is removed here — the export still exists and still
+  names the same type.
+  
+  `@object-ui/types`' entry point publishes `ComponentInput as PluginComponentInput`. Until
+  objectui#4972 that alias pointed at a genuinely different declaration: `plugin-scope.ts`
+  restated its own nine-key `ComponentInput`. objectui#5671 converged that declaration onto
+  `base.ts`, so the alias became a second published name for the *same* type, carrying no
+  information the first does not. Two published names for one type is a shape that costs
+  readers a step and gives AI-authored code a coin-flip between spellings.
+  
+  **Why a deprecation window rather than a deletion.** The measurement that licenses
+  deleting an export from a published package is *"no importer"*, and what can be measured
+  from inside this repository is only *"no importer here"*. In-repo the name has zero
+  importers — searched across every root (`packages/`, `apps/`, `content/`, `docs/`,
+  `skills/`, `examples/`, `e2e/`, `scripts/`, and the root docs), plus the sibling framework
+  repository, with a control name searched identically so a broken search could not read as
+  a clean one; the only occurrences are the alias itself and prose about it. What no search
+  here can see is a consumer on npm. The deprecation window is the answer to that
+  unmeasurable half: it converts a silent break into a warned one before the removal lands.
+  
+  **Reversibility, deliberately.** Deprecating is undoable; deleting a published export is
+  not. Where the evidence is one-sided, the retirement takes the reversible step first.
+  
+  The tag reaches consumers rather than only the source: a JSDoc block on an export
+  specifier survives declaration emit and lands attached to that specifier in the emitted
+  `index.d.ts`, which was measured for this change rather than assumed. With comments
+  stripped, the emitted entry point is byte-identical before and after — the published
+  *type* surface does not move, it only gains the notice.
+  
+  Stage 2 (removing the alias, and the now-dead re-export in `plugin-scope.ts` that exists
+  only to feed it) is filed as a follow-up and ships as a `minor`, per this repo's policy
+  that its own breaking changes never declare `major`.
+- 3c73d99: Corrects the `@deprecated` prescription on `UniquenessValidation` in
+  `packages/types/src/data-protocol.ts`, which pointed authors at spellings the platform
+  no longer accepts (objectui#4765).
+  
+  Comment-only — no runtime behaviour changes. `patch` rather than an empty frontmatter
+  because the JSDoc sits on an **exported** declaration and therefore ships to consumers:
+  measured with the package's own build (`tsc`, and `tsconfig.base.json` deliberately sets
+  `removeComments: false`), `dist/data-protocol.d.ts` goes 40218 → 41781 bytes and the new
+  prose is present in the emitted `.d.ts`. What a consumer reads on hover changes, so it
+  is declared. The emitted `dist/data-protocol.js` is byte-identical (sha256
+  `a3de34c5…`, 207 bytes both ways) — that file is a types-only module whose entire JS
+  output is the license banner plus `export {}`, so a comment on an erased `interface`
+  reaches the declaration file and nothing else.
+  
+  Two of the three spellings it prescribed were wrong, measured against the installed
+  `@objectstack/spec@17.0.0` (the report was written against `17.0.0-rc.6`):
+  
+  - **`indexes[].partial`** was retired in spec 17.0.0 under ADR-0049. It is a tombstone
+    (`z.never()`) that the parse rejects at any value, so "`partial` for a scoped
+    constraint" named a key that cannot be declared. A predicated unique constraint is
+    built at the database layer by a runtime migration issuing
+    `CREATE UNIQUE INDEX … WHERE`; the prescription now says so.
+  - **`{ fields, unique: true }`** on `ObjectSchema.indexes` is the deprecated positional
+    spelling of `unique: 'global'` under ADR-0120 — lint `unique/unscoped-declared-index`
+    warns in 17.x and protocol 18 rejects it. The prescription now states the scope:
+    `unique: 'global' | 'organization'`.
+  
+  The measurement also refined the report, and the refinement is the reason the rewrite is
+  not a uniform find-and-replace. The third spelling — **field-level** `unique: true` — is
+  NOT deprecated. `unique` is scope vocabulary shared by two surfaces on which the same
+  bare `true` means different things: at index level it stays verbatim (`isGlobalUnique`
+  and `isOrganizationUnique` both return `false`), which is why it is the positional
+  spelling of `'global'` and is being retired; at field level it is the positional spelling
+  of `'organization'` and, in the spec's own words, "stays valid indefinitely … no trap".
+  Rewriting both occurrences the same way would have replaced one piece of false guidance
+  with another, so the comment now names the per-surface difference explicitly.
+  
+  The interface's own deprecation is untouched and remains correct: `ValidationRuleSchema`
+  rejects `type: 'unique'` at the discriminator (accepted discriminants are `script`,
+  `state_machine`, `format`, `cross_field`, `json_schema`, `conditional`), so a rule in
+  this shape cannot reach the server.
+  
+  The replacement closes with what would falsify it — `UniqueScopeSchema` and
+  `IndexSchema` in `@objectstack/spec` — so the next reader checks the schemas rather than
+  trusting the paragraph. This is the fourth piece of false guidance found in this
+  campaign (strictness ledger finding 18), and prose that cannot be checked is how the
+  first three survived.
+- 1170ed1: `WidgetInput.type` now uses the shared arm vocabulary `ComponentInputControlType`
+  instead of restating its eleven literals inline (objectui#5675).
+  
+  That vocabulary has had a name since objectui#3832, and objectui#4972 converged the
+  last structural copy of the surrounding `ComponentInput` interface onto one
+  declaration. `WidgetInput` was the remaining site spelling the arms out — a third
+  copy of one list, with nothing tying it to the other two.
+  
+  **No value a widget author may write changes.** The inline restatement was measured
+  member-equal to the shared declaration in both directions before it was replaced
+  (eleven arms each, same set, and in the same order), so this is a convergence rather
+  than a widening or a narrowing. `WidgetInput.type` also stays the SINGLE-kind form:
+  `ComponentInput.type` additionally accepts an array of arms for a union-typed key
+  (objectui#3832), and importing that capability here would have been a widening, so
+  it was deliberately left out — the same disposition objectui#4972 recorded when it
+  left this face alone.
+  
+  What the convergence buys is that one of the two drift directions was **silent**.
+  `WidgetRegistry.load()` in `@object-ui/core` translates each `WidgetInput` into a
+  `ComponentInput` and passes `type` straight through, so an arm REMOVED from the
+  shared vocabulary would have broken that assignment loudly at compile time — but an
+  arm ADDED to it produced no error anywhere. Widget authoring would just have stayed
+  narrower than component registration, with nothing in the tree saying so. After this
+  change neither direction is expressible.
+  
+  The pin is source-text, deliberately: a TS type alias erases at runtime, so a
+  member-identical restatement is indistinguishable from the derived type by any
+  assignability or runtime check. Both kinds of assertion are kept in
+  `__tests__/widget-input-control-vocabulary.test.ts`, and the ablation showing the
+  value assertions stay green on the defect while the identity pin turns red is quoted
+  in the PR body.
+  
+  Two divergences between `WidgetInput` and `ComponentInput` are deliberately **not**
+  repaired here, and are now recorded in `WidgetInput`'s doc block instead of living
+  only in a closed card's body: the enum slot is spelled `options` on one face and
+  `enum` on the other (adapted at the `WidgetRegistry` seam, so nothing fails to
+  arrive), and `ComponentInput` carries five keys — `inputType`, `min`, `max`, `step`,
+  `placeholder` — that a widget manifest cannot express. Both are surface questions
+  about published keys and are raised on objectui#5675 rather than answered by this
+  change.
+
 ## 17.6.0
 
 ### Minor Changes
diff --git a/packages/types/package.json b/packages/types/package.json
index e65f4efde7..f0192cddbd 100644
--- a/packages/types/package.json
+++ b/packages/types/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@object-ui/types",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "description": "Pure TypeScript type definitions for Object UI - The Protocol Layer",
   "type": "module",
   "sideEffects": false,
diff --git a/packages/vscode-extension/CHANGELOG.md b/packages/vscode-extension/CHANGELOG.md
index c9ae926d1f..e164910597 100644
--- a/packages/vscode-extension/CHANGELOG.md
+++ b/packages/vscode-extension/CHANGELOG.md
@@ -1,5 +1,87 @@
 # Changelog
 
+## 17.7.0
+
+### Patch Changes
+
+- Updated dependencies [06a8af5]
+- Updated dependencies [6a91586]
+- Updated dependencies [9801765]
+- Updated dependencies [2d7304d]
+- Updated dependencies [636b236]
+- Updated dependencies [053fdc8]
+- Updated dependencies [d2fb6ef]
+- Updated dependencies [490d9a9]
+- Updated dependencies [fc62bb4]
+- Updated dependencies [41df893]
+- Updated dependencies [00f3eb5]
+- Updated dependencies [69a2163]
+- Updated dependencies [546ddf7]
+- Updated dependencies [864154e]
+- Updated dependencies [b023625]
+- Updated dependencies [75bd83d]
+- Updated dependencies [44d075b]
+- Updated dependencies [971d387]
+- Updated dependencies [db3a600]
+- Updated dependencies [e4559d1]
+- Updated dependencies [a26b9e4]
+- Updated dependencies [6f81384]
+- Updated dependencies [dddb942]
+- Updated dependencies [3c2b6f7]
+- Updated dependencies [5961030]
+- Updated dependencies [c8ea8af]
+- Updated dependencies [299102e]
+- Updated dependencies [d7acad6]
+- Updated dependencies [bf3a03c]
+- Updated dependencies [831be72]
+- Updated dependencies [ce503e5]
+- Updated dependencies [f20dcf0]
+- Updated dependencies [81c0bc4]
+- Updated dependencies [b55a346]
+- Updated dependencies [065bba7]
+- Updated dependencies [100547e]
+- Updated dependencies [6d1c155]
+- Updated dependencies [d7573b3]
+- Updated dependencies [bf3edfe]
+- Updated dependencies [0e05aac]
+- Updated dependencies [18a8e7d]
+- Updated dependencies [e7957ab]
+- Updated dependencies [f7e34ca]
+- Updated dependencies [e719ebd]
+- Updated dependencies [f9e4f91]
+- Updated dependencies [fa429cf]
+- Updated dependencies [ed8df3e]
+- Updated dependencies [8ebd57f]
+- Updated dependencies [199d31b]
+- Updated dependencies [7138bc1]
+- Updated dependencies [cef27e2]
+- Updated dependencies [4e8622b]
+- Updated dependencies [dffd752]
+- Updated dependencies [105f3c5]
+- Updated dependencies [3ccd9e8]
+- Updated dependencies [689b979]
+- Updated dependencies [0fce2ef]
+- Updated dependencies [b2ea297]
+- Updated dependencies [a691c0b]
+- Updated dependencies [af3861f]
+- Updated dependencies [515f171]
+- Updated dependencies [c00bf28]
+- Updated dependencies [f2158ec]
+- Updated dependencies [78cbdb5]
+- Updated dependencies [b7543a9]
+- Updated dependencies [6c6cee7]
+- Updated dependencies [d1ab06f]
+- Updated dependencies [91783c4]
+- Updated dependencies [2d36552]
+- Updated dependencies [c9327c9]
+- Updated dependencies [920165d]
+- Updated dependencies [3c73d99]
+- Updated dependencies [ed71d9e]
+- Updated dependencies [1170ed1]
+- Updated dependencies [4d73b07]
+  - @object-ui/types@17.7.0
+  - @object-ui/core@17.7.0
+
 ## 17.6.0
 
 ### Patch Changes
diff --git a/packages/vscode-extension/package.json b/packages/vscode-extension/package.json
index 110f58c299..8d0ae06aee 100644
--- a/packages/vscode-extension/package.json
+++ b/packages/vscode-extension/package.json
@@ -2,7 +2,7 @@
   "name": "object-ui",
   "displayName": "Object UI",
   "description": "VSCode extension for Object UI - Schema-driven UI development with IntelliSense, validation, and live preview",
-  "version": "17.6.0",
+  "version": "17.7.0",
   "publisher": "objectui",
   "private": true,
   "icon": "icon.svg",