@object-ui/core 17.5.0 → 17.6.0

package/dist/utils/debug.js

@@ -92,9 +92,15 @@ export function debugLog(category, message, data) {
     if (!isDebugEnabled())
         return;
     if (data !== undefined) {
+        // objectui#4029 — this IS the repo's debug channel (opt-in via
+        // globalThis.OBJECTUI_DEBUG, gated by isDebugEnabled() above), not a
+        // leaked module-scope log; no-console's blanket ban would otherwise
+        // block the function whose entire job is to console.log.
+        // eslint-disable-next-line no-console
         console.log(`[ObjectUI Debug][${category}] ${message}`, data);
     }
     else {
+        // eslint-disable-next-line no-console -- see comment above
         console.log(`[ObjectUI Debug][${category}] ${message}`);
     }
 }
@@ -116,6 +122,7 @@ export function debugTimeEnd(label) {
     const start = timers.get(label);
     if (start !== undefined) {
         const elapsed = (performance.now() - start).toFixed(2);
+        // eslint-disable-next-line no-console -- objectui#4029, see debugLog above
         console.log(`[ObjectUI Debug][perf] ${label}: ${elapsed}ms`);
         timers.delete(label);
     }

package/dist/utils/expand-fields.d.ts

@@ -11,17 +11,107 @@
  * list / grid / detail cell can render the related record's display name
  * instead of a bare id placeholder ("—").
  *
- * This mirrors the form layer's `DATA_SOURCE_FIELD_TYPES`
- * (`lookup` / `master_detail` / `tree`) and additionally covers `user` — a
- * lookup specialised to `sys_user`. The server resolves `user` through the
- * same expand path as `lookup` / `master_detail` (it carries the same
- * `reference` + id storage), so a `user` column that is NOT requested for
- * expansion comes back as a raw user id and renders as "—". Keeping the set
- * here as the single source of truth is what closes that gap.
+ * `user` is a lookup specialised to `sys_user`: it carries the same `reference`
+ * + id storage and the server resolves it through the same expand path as
+ * `lookup` / `master_detail`, so a `user` column that is NOT requested for
+ * expansion comes back as a raw user id and renders as "—" (objectui#2032).
  *
  * Note on `tree`: a self-referencing hierarchy field is a reference too, so it
  * belongs in this set; whether the backend materialises the expanded object
  * for it is a server concern — requesting it is harmless and forward-compatible.
+ *
+ * ## One family, many consumers — and NO reliable count of them
+ *
+ * This section used to open "One family, four consumers" and enumerate four.
+ * That count was hand-kept, and hand-kept counts of this table are exactly what
+ * keeps going wrong: it was already stale by two when objectui#5692 measured it
+ * (`paramToField` in `app-shell` had joined with objectui#5312, and
+ * `ListView`'s relational-sort rule reads the set directly), and objectui#5312's
+ * claim to have converted "the LAST private copy" was false by two MORE — see
+ * the falsification note at the end. Read the list below as the lineage of the
+ * conversions, not as a census; the mechanical fact is the identity pins.
+ *
+ * This is the reference-bearing FAMILY, not the `$expand` builder's private
+ * list, and these concerns read it under several different words:
+ *
+ *  - `$expand` construction — `buildExpandFields` below ("expandable");
+ *  - predicate-record projection — `predicate-record.ts` ("relational");
+ *  - the object form's data-source wiring — `needsDataSourceWiring` in
+ *    `packages/components/src/renderers/form/form.tsx`, which decides which
+ *    registered widget gets `dataSource` / `dependentValues` /
+ *    `dependsOnLabels` threaded to it;
+ *  - the grid's bulk-action dialog — `widgetNeedsDataSource` in
+ *    `packages/plugin-grid/src/components/bulkParamToField.ts`, which decides
+ *    which param widget is handed the grid's `DataSource` and which param field
+ *    shape carries `reference_to` / `display_field`;
+ *  - the action-param dialog — `paramToField` in
+ *    `packages/app-shell/src/utils/paramToField.ts`, which decides which param
+ *    carries a reference target (objectui#5312);
+ *  - the list view's relational-sort rule — `ListView.tsx`, which will not offer
+ *    a server-side sort on a field whose stored value is a foreign key;
+ *  - the dashboard table's `$expand` whitelist — `computeLookupExpand` in
+ *    `packages/plugin-dashboard/src/ObjectDataTable.tsx` (objectui#5692);
+ *  - the dashboard's relation/link test — `isLookupType` in
+ *    `packages/plugin-dashboard/src/recordFields.tsx` (objectui#5692).
+ *
+ * The third one used to be a second hand-maintained copy, and this comment used
+ * to claim the set "mirrors the form layer's `DATA_SOURCE_FIELD_TYPES`
+ * (`lookup` / `master_detail` / `tree`)". That was true for 15 days. The form's
+ * copy then gained `capability-multiselect` (objectui#2403) and, the same day,
+ * `object-ref` / `filter-condition` / `recipient-picker` (objectui#2421), after
+ * which the two sets were not in a subset relation in EITHER direction — `user`
+ * only here, three picker names only there — and no gate could say so
+ * (objectui#4790). The form now DERIVES from this set instead of restating it:
+ *
+ *     form's data-source rule  ==  EXPANDABLE_FIELD_TYPES
+ *                                  + three widget-hint-only picker names
+ *
+ * The extension is one-directional and cannot fold back into this set:
+ * `object-ref` / `filter-condition` / `recipient-picker` are widget HINTS, never
+ * declarable field types (`widgetHintOnly: true` in
+ * `app-shell/src/utils/paramValueShape.ts`), so no object schema can produce a
+ * field whose `type` is one of them.
+ *
+ * The fourth was a hand-maintained copy too, one member set removed from BOTH
+ * of the above (`lookup` / `master_detail` / `user` — no `tree`, no pickers, and
+ * for a while a fifth spelling, `owner`, that objectui#4814 retired). It now
+ * derives from this set with NO extension, because the bulk dialog's params
+ * cannot produce the three widget-hint names (objectui#4815):
+ *
+ *     bulk dialog's data-source rule  ==  EXPANDABLE_FIELD_TYPES
+ *
+ * Neither consumer copies the set — both call `.has()` on THIS object, and both
+ * carry an identity pin (a spy on this `has`) so a member-identical private copy
+ * fails rather than quietly re-forking the table.
+ *
+ * ## The "LAST private copy" claim was false — objectui#5692
+ *
+ * objectui#5312 converted `paramToField` (`app-shell`) and recorded it as the
+ * fourth and LAST private copy of this rule. `packages/plugin-dashboard` held
+ * two more the whole time — `LOOKUP_TYPES` in `recordFields.tsx` and an inline
+ * disjunction inside `computeLookupExpand` in `ObjectDataTable.tsx` — which
+ * predate that sweep and were outside its file surface, so nothing contradicted
+ * the claim. Both now derive from this set with NO extension and carry the same
+ * identity pin.
+ *
+ * Those two were NOT member-identical to this set, in either direction: they
+ * lacked `tree` and carried a fifth spelling, `reference`. Converging them was
+ * therefore a behaviour change in two directions, and the direction that could
+ * have widened THIS set was settled by measurement rather than by preference:
+ * `reference` is absent from `@objectstack/spec`'s closed `FieldType`
+ * vocabulary and is refused by `FieldSchema.safeParse` — measured with `lookup`
+ * / `master_detail` / `user` / `tree` as live controls and the retired `owner`
+ * plus a nonsense spelling as dead ones — so no spec-compliant object schema can
+ * declare a field whose stored type is `reference`, and the dashboard's copies
+ * were carrying a dead spelling, not a member this set was missing. This set is
+ * unchanged by objectui#5692; the two dashboard faces simply stopped answering
+ * for a type no producer can emit.
+ *
+ * Stated so it reads as a decision rather than a surprise: **adding a member
+ * here also grants that type the form's data-source wiring.** That is the
+ * intended coupling — a type whose stored value is a foreign key needs a
+ * `DataSource` to resolve that key on the read path (expand) and on the edit
+ * path (the picker) alike.
  */
 export declare const EXPANDABLE_FIELD_TYPES: ReadonlySet<string>;
 /**

package/dist/utils/expand-fields.js

@@ -12,17 +12,107 @@ import { columnIdentity } from './column-identity.js';
  * list / grid / detail cell can render the related record's display name
  * instead of a bare id placeholder ("—").
  *
- * This mirrors the form layer's `DATA_SOURCE_FIELD_TYPES`
- * (`lookup` / `master_detail` / `tree`) and additionally covers `user` — a
- * lookup specialised to `sys_user`. The server resolves `user` through the
- * same expand path as `lookup` / `master_detail` (it carries the same
- * `reference` + id storage), so a `user` column that is NOT requested for
- * expansion comes back as a raw user id and renders as "—". Keeping the set
- * here as the single source of truth is what closes that gap.
+ * `user` is a lookup specialised to `sys_user`: it carries the same `reference`
+ * + id storage and the server resolves it through the same expand path as
+ * `lookup` / `master_detail`, so a `user` column that is NOT requested for
+ * expansion comes back as a raw user id and renders as "—" (objectui#2032).
  *
  * Note on `tree`: a self-referencing hierarchy field is a reference too, so it
  * belongs in this set; whether the backend materialises the expanded object
  * for it is a server concern — requesting it is harmless and forward-compatible.
+ *
+ * ## One family, many consumers — and NO reliable count of them
+ *
+ * This section used to open "One family, four consumers" and enumerate four.
+ * That count was hand-kept, and hand-kept counts of this table are exactly what
+ * keeps going wrong: it was already stale by two when objectui#5692 measured it
+ * (`paramToField` in `app-shell` had joined with objectui#5312, and
+ * `ListView`'s relational-sort rule reads the set directly), and objectui#5312's
+ * claim to have converted "the LAST private copy" was false by two MORE — see
+ * the falsification note at the end. Read the list below as the lineage of the
+ * conversions, not as a census; the mechanical fact is the identity pins.
+ *
+ * This is the reference-bearing FAMILY, not the `$expand` builder's private
+ * list, and these concerns read it under several different words:
+ *
+ *  - `$expand` construction — `buildExpandFields` below ("expandable");
+ *  - predicate-record projection — `predicate-record.ts` ("relational");
+ *  - the object form's data-source wiring — `needsDataSourceWiring` in
+ *    `packages/components/src/renderers/form/form.tsx`, which decides which
+ *    registered widget gets `dataSource` / `dependentValues` /
+ *    `dependsOnLabels` threaded to it;
+ *  - the grid's bulk-action dialog — `widgetNeedsDataSource` in
+ *    `packages/plugin-grid/src/components/bulkParamToField.ts`, which decides
+ *    which param widget is handed the grid's `DataSource` and which param field
+ *    shape carries `reference_to` / `display_field`;
+ *  - the action-param dialog — `paramToField` in
+ *    `packages/app-shell/src/utils/paramToField.ts`, which decides which param
+ *    carries a reference target (objectui#5312);
+ *  - the list view's relational-sort rule — `ListView.tsx`, which will not offer
+ *    a server-side sort on a field whose stored value is a foreign key;
+ *  - the dashboard table's `$expand` whitelist — `computeLookupExpand` in
+ *    `packages/plugin-dashboard/src/ObjectDataTable.tsx` (objectui#5692);
+ *  - the dashboard's relation/link test — `isLookupType` in
+ *    `packages/plugin-dashboard/src/recordFields.tsx` (objectui#5692).
+ *
+ * The third one used to be a second hand-maintained copy, and this comment used
+ * to claim the set "mirrors the form layer's `DATA_SOURCE_FIELD_TYPES`
+ * (`lookup` / `master_detail` / `tree`)". That was true for 15 days. The form's
+ * copy then gained `capability-multiselect` (objectui#2403) and, the same day,
+ * `object-ref` / `filter-condition` / `recipient-picker` (objectui#2421), after
+ * which the two sets were not in a subset relation in EITHER direction — `user`
+ * only here, three picker names only there — and no gate could say so
+ * (objectui#4790). The form now DERIVES from this set instead of restating it:
+ *
+ *     form's data-source rule  ==  EXPANDABLE_FIELD_TYPES
+ *                                  + three widget-hint-only picker names
+ *
+ * The extension is one-directional and cannot fold back into this set:
+ * `object-ref` / `filter-condition` / `recipient-picker` are widget HINTS, never
+ * declarable field types (`widgetHintOnly: true` in
+ * `app-shell/src/utils/paramValueShape.ts`), so no object schema can produce a
+ * field whose `type` is one of them.
+ *
+ * The fourth was a hand-maintained copy too, one member set removed from BOTH
+ * of the above (`lookup` / `master_detail` / `user` — no `tree`, no pickers, and
+ * for a while a fifth spelling, `owner`, that objectui#4814 retired). It now
+ * derives from this set with NO extension, because the bulk dialog's params
+ * cannot produce the three widget-hint names (objectui#4815):
+ *
+ *     bulk dialog's data-source rule  ==  EXPANDABLE_FIELD_TYPES
+ *
+ * Neither consumer copies the set — both call `.has()` on THIS object, and both
+ * carry an identity pin (a spy on this `has`) so a member-identical private copy
+ * fails rather than quietly re-forking the table.
+ *
+ * ## The "LAST private copy" claim was false — objectui#5692
+ *
+ * objectui#5312 converted `paramToField` (`app-shell`) and recorded it as the
+ * fourth and LAST private copy of this rule. `packages/plugin-dashboard` held
+ * two more the whole time — `LOOKUP_TYPES` in `recordFields.tsx` and an inline
+ * disjunction inside `computeLookupExpand` in `ObjectDataTable.tsx` — which
+ * predate that sweep and were outside its file surface, so nothing contradicted
+ * the claim. Both now derive from this set with NO extension and carry the same
+ * identity pin.
+ *
+ * Those two were NOT member-identical to this set, in either direction: they
+ * lacked `tree` and carried a fifth spelling, `reference`. Converging them was
+ * therefore a behaviour change in two directions, and the direction that could
+ * have widened THIS set was settled by measurement rather than by preference:
+ * `reference` is absent from `@objectstack/spec`'s closed `FieldType`
+ * vocabulary and is refused by `FieldSchema.safeParse` — measured with `lookup`
+ * / `master_detail` / `user` / `tree` as live controls and the retired `owner`
+ * plus a nonsense spelling as dead ones — so no spec-compliant object schema can
+ * declare a field whose stored type is `reference`, and the dashboard's copies
+ * were carrying a dead spelling, not a member this set was missing. This set is
+ * unchanged by objectui#5692; the two dashboard faces simply stopped answering
+ * for a type no producer can emit.
+ *
+ * Stated so it reads as a decision rather than a surprise: **adding a member
+ * here also grants that type the form's data-source wiring.** That is the
+ * intended coupling — a type whose stored value is a foreign key needs a
+ * `DataSource` to resolve that key on the read path (expand) and on the edit
+ * path (the picker) alike.
  */
 export const EXPANDABLE_FIELD_TYPES = new Set([
     'lookup',

package/dist/utils/filter-tokens.js

@@ -116,7 +116,6 @@ export function resolveContextTokens(filter, scope = {}) {
         ? () => { }
         : scope.onUnresolved ??
             ((message) => {
-                // eslint-disable-next-line no-console
                 console.warn(`[object-ui] ${message}`);
             });
     const values = {

package/dist/utils/freeze-schema.d.ts

@@ -36,6 +36,33 @@ export declare const SYSTEM_VIEW_MARKER: unique symbol;
 export type DeepReadonly<T> = T extends (...args: any[]) => any ? T : T extends ReadonlyArray<infer U> ? ReadonlyArray<DeepReadonly<U>> : T extends object ? {
     readonly [K in keyof T]: DeepReadonly<T[K]>;
 } : T;
+/**
+ * The inverse of `DeepReadonly<T>`: recursively strip `readonly` at every depth.
+ *
+ * Named `DeepMutable` rather than `Mutable` for the same reason the type above
+ * is not called `Readonly` — TS' built-in `Readonly<T>` is SHALLOW, so a bare
+ * `Mutable` would understate what this does by exactly the depth gap that made
+ * `cloneAsOverride` wrong in the first place. A type whose name misreports its
+ * own reach is the defect this pair exists to close, not a naming preference.
+ *
+ * Symmetric with `DeepReadonly` arm for arm, deliberately including its two
+ * limits: a tuple widens to an array (`DeepReadonly` widens it the same way, so
+ * an inverse that preserved tuples would not be an inverse), and `Date`,
+ * `RegExp`, `Map` and `Set` are mapped as plain objects even though
+ * `isFreezableObject` skips them at runtime.
+ *
+ * One thing it deliberately does NOT do: drop the `SYSTEM_VIEW_MARKER` key.
+ * `cloneAsOverride` never copies the symbol, so a clone's marker is always
+ * absent — but the key is declared optional (`?: true`), and carrying it
+ * therefore states "may be absent", which is true. Excluding it needs
+ * `Exclude<keyof T, typeof SYSTEM_VIEW_MARKER>`, a NON-homomorphic mapped type
+ * that drops the `?` modifier from every other property and turns optional keys
+ * required — a strictly worse type, and a real break for callers, traded for
+ * removing a key that already reads as optional.
+ */
+export type DeepMutable<T> = T extends (...args: any[]) => any ? T : T extends ReadonlyArray<infer U> ? DeepMutable<U>[] : T extends object ? {
+    -readonly [K in keyof T]: DeepMutable<T[K]>;
+} : T;
 /**
  * A schema that has been frozen by `defineSystemView()`. The marker symbol is
  * non-enumerable and therefore invisible to consumers, but its presence
@@ -87,8 +114,18 @@ export declare function isSystemView(value: unknown): boolean;
  * Produce a deep, mutable clone of a System View so callers can apply
  * Tenant/User overrides without touching the source schema.
  *
+ * Returns `DeepMutable<T>`, not `T`. The declaration used to hand back the
+ * input type unchanged, which meant cloning a `SystemView<S>` returned
+ * something still typed deep-readonly even though the implementation had always
+ * produced a plain mutable object — so the override flow this function exists
+ * for, `draft.columns.push(...)`, did not type-check (TS2339). The return type
+ * now relaxes TOWARD what the runtime already does, never away from it, which
+ * is why the change adds capability to a caller's type rather than removing it.
+ *
  * Implementation note: uses `structuredClone` when available (Node 17+, all
  * evergreen browsers) and falls back to a JSON round-trip. The marker
  * symbol is intentionally NOT copied — the clone is no longer a System View.
+ * Neither path can copy it by accident: `structuredClone` ignores symbol keys,
+ * and `JSON.stringify` never sees them.
  */
-export declare function cloneAsOverride<T>(view: T): T;
+export declare function cloneAsOverride<T>(view: T): DeepMutable<T>;

package/dist/utils/freeze-schema.js

@@ -140,9 +140,19 @@ export function isSystemView(value) {
  * Produce a deep, mutable clone of a System View so callers can apply
  * Tenant/User overrides without touching the source schema.
  *
+ * Returns `DeepMutable<T>`, not `T`. The declaration used to hand back the
+ * input type unchanged, which meant cloning a `SystemView<S>` returned
+ * something still typed deep-readonly even though the implementation had always
+ * produced a plain mutable object — so the override flow this function exists
+ * for, `draft.columns.push(...)`, did not type-check (TS2339). The return type
+ * now relaxes TOWARD what the runtime already does, never away from it, which
+ * is why the change adds capability to a caller's type rather than removing it.
+ *
  * Implementation note: uses `structuredClone` when available (Node 17+, all
  * evergreen browsers) and falls back to a JSON round-trip. The marker
  * symbol is intentionally NOT copied — the clone is no longer a System View.
+ * Neither path can copy it by accident: `structuredClone` ignores symbol keys,
+ * and `JSON.stringify` never sees them.
  */
 export function cloneAsOverride(view) {
     if (view == null || typeof view !== 'object')

package/dist/utils/humanize-label.d.ts

@@ -0,0 +1,60 @@
+/**
+ * ObjectUI — value-fallback label prettifier
+ * Copyright (c) 2024-present ObjectStack Inc.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+/**
+ * humanize-label — the ONE home for the VALUE fallback: a stored value becomes
+ * a display string when nothing else resolves it (objectui#5444).
+ *
+ * Two byte-identical copies preceded this module: `@object-ui/fields` (read by
+ * `plugin-grid`, `plugin-gantt`, `plugin-detail`, and by the field renderers in
+ * that package itself) and a deliberate local copy in `plugin-charts`'
+ * `ObjectChart.tsx`, whose comment said it existed "to avoid a dependency on
+ * `@object-ui/fields`". `@object-ui/core` is the shared ancestor both packages
+ * already depend on, so the convention gets a single home without a new
+ * dependency edge and without React reaching core — objectui#4389's ruling for
+ * this family: core-canonical logic, plugins consume; never core importing
+ * react. Both former sites now re-export THIS function, so there is one
+ * implementation and two doorways.
+ *
+ * ## Why this is NOT `humanizeFieldKey`, and why the two are kept apart
+ *
+ * The renderer carries a second prettifier — `humanizeFieldKey` in
+ * `@object-ui/plugin-dashboard`, the single home for the KEY fallback (a field
+ * key becomes a column header). It is a DIFFERENT convention, not a stale copy
+ * of this one: it additionally splits camelCase.
+ *
+ *   input                humanizeFieldKey     humanizeLabel (here)
+ *   ──────────────────   ──────────────────   ──────────────────
+ *   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
+ *
+ * They are fed different inputs, which is why their outputs may differ. A field
+ * KEY is authored in the codebase and is expected to carry a machine spelling,
+ * so splitting camelCase recovers words its author meant. A stored VALUE is
+ * arbitrary tenant data — a picklist member, an object name, a code from
+ * another system — where a mid-token capital is not reliably a word boundary,
+ * and splitting it rewrites what the tenant wrote (`McDonald` -> `Mc Donald`).
+ * Note also that the two conventions do not nest: on the last row above each
+ * leaves alone the separator the other rewrites, so "converge" would have to
+ * pick a winner per input class rather than adopt one side wholesale.
+ *
+ * Kept distinct DELIBERATELY, and this paragraph is the write-down whose
+ * absence made the split read as drift. Converging them is a decision, not a
+ * refactor: this function is read by grid, gantt, detail and charts, so any
+ * change to what it RETURNS moves rendered output in four packages at once.
+ * That change is explicitly out of scope for the convergence that created this
+ * module; it needs its own card.
+ *
+ * Examples:
+ *   "in_progress"   -> "In Progress"
+ *   "high-priority" -> "High Priority"
+ *   "active"        -> "Active"
+ */
+export declare function humanizeLabel(value: string): string;

package/dist/utils/humanize-label.js

@@ -0,0 +1,62 @@
+/**
+ * ObjectUI — value-fallback label prettifier
+ * Copyright (c) 2024-present ObjectStack Inc.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+/**
+ * humanize-label — the ONE home for the VALUE fallback: a stored value becomes
+ * a display string when nothing else resolves it (objectui#5444).
+ *
+ * Two byte-identical copies preceded this module: `@object-ui/fields` (read by
+ * `plugin-grid`, `plugin-gantt`, `plugin-detail`, and by the field renderers in
+ * that package itself) and a deliberate local copy in `plugin-charts`'
+ * `ObjectChart.tsx`, whose comment said it existed "to avoid a dependency on
+ * `@object-ui/fields`". `@object-ui/core` is the shared ancestor both packages
+ * already depend on, so the convention gets a single home without a new
+ * dependency edge and without React reaching core — objectui#4389's ruling for
+ * this family: core-canonical logic, plugins consume; never core importing
+ * react. Both former sites now re-export THIS function, so there is one
+ * implementation and two doorways.
+ *
+ * ## Why this is NOT `humanizeFieldKey`, and why the two are kept apart
+ *
+ * The renderer carries a second prettifier — `humanizeFieldKey` in
+ * `@object-ui/plugin-dashboard`, the single home for the KEY fallback (a field
+ * key becomes a column header). It is a DIFFERENT convention, not a stale copy
+ * of this one: it additionally splits camelCase.
+ *
+ *   input                humanizeFieldKey     humanizeLabel (here)
+ *   ──────────────────   ──────────────────   ──────────────────
+ *   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
+ *
+ * They are fed different inputs, which is why their outputs may differ. A field
+ * KEY is authored in the codebase and is expected to carry a machine spelling,
+ * so splitting camelCase recovers words its author meant. A stored VALUE is
+ * arbitrary tenant data — a picklist member, an object name, a code from
+ * another system — where a mid-token capital is not reliably a word boundary,
+ * and splitting it rewrites what the tenant wrote (`McDonald` -> `Mc Donald`).
+ * Note also that the two conventions do not nest: on the last row above each
+ * leaves alone the separator the other rewrites, so "converge" would have to
+ * pick a winner per input class rather than adopt one side wholesale.
+ *
+ * Kept distinct DELIBERATELY, and this paragraph is the write-down whose
+ * absence made the split read as drift. Converging them is a decision, not a
+ * refactor: this function is read by grid, gantt, detail and charts, so any
+ * change to what it RETURNS moves rendered output in four packages at once.
+ * That change is explicitly out of scope for the convergence that created this
+ * module; it needs its own card.
+ *
+ * Examples:
+ *   "in_progress"   -> "In Progress"
+ *   "high-priority" -> "High Priority"
+ *   "active"        -> "Active"
+ */
+export function humanizeLabel(value) {
+    return value.replace(/[_-]/g, ' ').replace(/\b\w/g, c => c.toUpperCase());
+}

package/dist/utils/managedBy.d.ts

@@ -51,8 +51,33 @@ export type UserActionOverride = boolean | {
     disabledWhen?: RowCrudPredicates['disabledWhen'];
 };
 export interface UserActionsOverride {
-    create?: boolean;
-    import?: boolean;
+    /**
+     * Bare boolean or the object form. Widened from `boolean` in objectui#4646:
+     * `@objectstack/spec@17.0.0` types this key
+     * `z.union([z.boolean(), RowCrudActionOverrideSchema])`, and the spec's
+     * resolver emits the parsed predicates as `CrudAffordances.createPredicates`.
+     * The local type said `boolean` — so an author writing the shape the spec
+     * accepts, and that the related-list toolbar now honours
+     * (`RelatedRecordActionsBridge`, objectui#4646), was rejected by objectui's
+     * own type while the runtime handled it.
+     */
+    create?: UserActionOverride;
+    /**
+     * Bare boolean or the object form — the SAME union as `create` above, which
+     * is how `@objectstack/spec@17.0.0` types the two toolbar keys
+     * (`z.union([z.boolean(), RowCrudActionOverrideSchema])` for each), and its
+     * resolver emits `CrudAffordances.importPredicates` beside
+     * `createPredicates`.
+     *
+     * Widened in objectui#5142, deliberately IN THE SAME change that gave the
+     * object-list toolbar's Import button a consumer for those predicates
+     * (`ObjectView`). objectui#4646 left this key narrow on purpose and said why:
+     * widening a type ahead of its consumer re-declares the inert-metadata defect
+     * — objectui would have *claimed* to accept the object form while still
+     * dropping the predicate. Type and consumer travel together, so the
+     * declaration stays an honest statement of what this renderer honours.
+     */
+    import?: UserActionOverride;
     edit?: UserActionOverride;
     delete?: UserActionOverride;
     exportCsv?: boolean;

package/dist/utils/normalize-list-view.d.ts

@@ -125,5 +125,15 @@ export declare function rowHeightToDensityMode(rowHeight: unknown): DensityMode
  *    breaking change with no inventory. Runs AFTER the `fields` → `columns` fold
  *    above, so a view that spells its column list the legacy way still gets its
  *    entries canonicalized.
+ *  - the four PER-VIEW-TYPE config aliases phase 3 carried over
+ *    ({@link PER_VIEW_CONFIG_ALIASES}): `kanban.groupField` → `groupByField`,
+ *    `kanban.cardFields` → `columns`, `gallery.imageField` → `coverField`,
+ *    `timeline.dateField` → `startDateField`. One read-site changes behaviour
+ *    as a result, and it is a CORRECTION of the same inverted precedence A2
+ *    fixed for `densityMode`: `ListView`'s kanban adapter resolves
+ *    `cardFields || columns`, i.e. legacy over canonical, so a config carrying
+ *    BOTH used to render the legacy value. After the fold the canonical
+ *    `columns` reaches it. Every other reader of these four was already
+ *    canonical-first and is unaffected.
  */
 export declare function normalizeListViewSchema<T>(schema: T): T;

package/dist/utils/normalize-list-view.js

@@ -101,6 +101,32 @@ const ARIA_KEY_ALIASES = {
     label: 'ariaLabel',
     describedBy: 'ariaDescribedBy',
 };
+/**
+ * Per-view-type config aliases → the spec key each one aliases (#2890, the
+ * phase-3 carry-over).
+ *
+ * Phase 3 derived `kanban` / `gallery` / `timeline` from the spec configs but
+ * kept the pre-#2231 objectui spellings declared alongside the spec keys so
+ * stored view metadata would keep validating
+ * (`packages/types/src/zod/objectql.zod.ts`, each marked `@deprecated legacy
+ * alias for the spec's X`). Folding them here is what lets a read-site stop
+ * carrying its own `canonical || legacy` pair — the same move A1–A5 made for
+ * the top-level vocabulary.
+ *
+ * `calendar` is deliberately absent: its one local key, `defaultView`, is not
+ * an alias of anything. It has no spec counterpart at all, so it wants
+ * PROMOTION upstream, not a rename — folding it would delete an authored value
+ * with nowhere to put it.
+ *
+ * Note `kanban.columns` is the spec's "fields shown on each card", NOT the
+ * table columns that the same word names at the ListView top level. The fold
+ * is scoped to the nested config, so the two never meet.
+ */
+const PER_VIEW_CONFIG_ALIASES = {
+    kanban: { groupField: 'groupByField', cardFields: 'columns' },
+    gallery: { imageField: 'coverField' },
+    timeline: { dateField: 'startDateField' },
+};
 /**
  * ObjectUI's `list-view` node historically used a different vocabulary from
  * `@objectstack/spec` for the same concepts (`fields` where the spec says
@@ -164,6 +190,16 @@ const ARIA_KEY_ALIASES = {
  *    breaking change with no inventory. Runs AFTER the `fields` → `columns` fold
  *    above, so a view that spells its column list the legacy way still gets its
  *    entries canonicalized.
+ *  - the four PER-VIEW-TYPE config aliases phase 3 carried over
+ *    ({@link PER_VIEW_CONFIG_ALIASES}): `kanban.groupField` → `groupByField`,
+ *    `kanban.cardFields` → `columns`, `gallery.imageField` → `coverField`,
+ *    `timeline.dateField` → `startDateField`. One read-site changes behaviour
+ *    as a result, and it is a CORRECTION of the same inverted precedence A2
+ *    fixed for `densityMode`: `ListView`'s kanban adapter resolves
+ *    `cardFields || columns`, i.e. legacy over canonical, so a config carrying
+ *    BOTH used to render the legacy value. After the fold the canonical
+ *    `columns` reaches it. Every other reader of these four was already
+ *    canonical-first and is unaffected.
  */
 export function normalizeListViewSchema(schema) {
     if (!schema || typeof schema !== 'object')
@@ -195,9 +231,22 @@ export function normalizeListViewSchema(schema) {
             : undefined;
     const foldedColumns = normalizeColumnIdentities(columnsSource);
     const foldColumnIdentity = foldedColumns !== columnsSource;
+    // Per-view-type config aliases (#2890 phase-3 carry-over). Collected before
+    // the early return so an otherwise-canonical view carrying only a nested
+    // legacy key still folds — and so a view carrying none still returns by
+    // reference.
+    const perViewFolds = Object.entries(PER_VIEW_CONFIG_ALIASES)
+        .map(([viewKey, aliases]) => {
+        const cfg = isRecord(s[viewKey]) ? s[viewKey] : undefined;
+        if (!cfg)
+            return undefined;
+        const legacyKeys = Object.keys(aliases).filter((legacy) => cfg[legacy] !== undefined);
+        return legacyKeys.length ? { viewKey, aliases, cfg, legacyKeys } : undefined;
+    })
+        .filter((entry) => entry !== undefined);
     if (!foldColumns && !foldRowHeight && !foldFilter && !legacyFlags.length &&
         !foldDescription && !foldAria && !foldSharing && !defaultViewKind &&
-        !foldColumnIdentity) {
+        !foldColumnIdentity && !perViewFolds.length) {
         return schema;
     }
     const next = { ...s };
@@ -271,6 +320,19 @@ export function normalizeListViewSchema(schema) {
         delete nextSharing.enabled;
         next.sharing = nextSharing;
     }
+    for (const { viewKey, aliases, cfg, legacyKeys } of perViewFolds) {
+        const nextCfg = { ...cfg };
+        for (const legacy of legacyKeys) {
+            const canonical = aliases[legacy];
+            // Same one-directional shape as every fold above: the canonical key wins
+            // when both are present, and the legacy key is REMOVED so a missed
+            // read-site fails loudly instead of quietly taking the legacy path.
+            if (nextCfg[canonical] === undefined)
+                nextCfg[canonical] = cfg[legacy];
+            delete nextCfg[legacy];
+        }
+        next[viewKey] = nextCfg;
+    }
     if (defaultViewKind)
         next.viewType = 'grid';
     return next;

package/dist/utils/number-display.d.ts

@@ -111,9 +111,13 @@ export interface DisplayNumberFormatOptions {
      * repo's runner, `80.175` percentage points formatted to 2 decimals renders
      * `80.18%` when formatted directly and `80.17%` after the divide-and-remultiply
      * — 27,581 of 1,200,013 ordinary-magnitude en-US forms move, plus every
-     * value at the top of the double range (`MAX_SAFE_INTEGER`, `1e23`). A caller
-     * holding percentage points must therefore NOT reach for `'percent'`; that is
-     * exactly the trap this option removes.
+     * value at the top of the double range (`MAX_SAFE_INTEGER`, `1e23`). That
+     * count is objectui#4576's tie-dense grid — 0.005 steps to 2,000, precisions
+     * 0/1/2 — measured on `formatDisplayNumber` / `formatMeasure`'s call shape.
+     * objectui#4590 re-measured the same route through `formatPercent` and
+     * reports 27,577 of 1,200,003: a different form set, not a correction of this
+     * one. A caller holding percentage points must therefore NOT reach for
+     * `'percent'`; that is exactly the trap this option removes.
      *
      * `'percentPoints'` is implemented with `Intl`'s `style: 'unit'` /
      * `unit: 'percent'`, which was measured to produce a BYTE-IDENTICAL percent