@object-ui/components 17.3.0 → 17.6.0

package/dist/lib/form-control-dom-props.d.ts

@@ -0,0 +1,77 @@
+import { DomProps as CoreDomProps } from '@object-ui/core';
+/**
+ * The DOM pass-through declaration for the `packages/components` renderers whose
+ * host element is a FORM CONTROL (objectui#5632).
+ *
+ * ## Why this exists at all, rather than a bare `toDomProps`
+ *
+ * `toDomProps` is the SDUI contract's executor and its key list is deliberately
+ * ELEMENT-AGNOSTIC — it cannot know what element the widget renders, so it
+ * carries only what is legal on every element. `name` and `disabled` are legal
+ * on form controls and nowhere else, which is exactly why `dom-props.ts` leaves
+ * them out: `name` on the `<div>` a container widget renders is one of the 14
+ * attributes objectui#4431 closed.
+ *
+ * The renderers in this group render the other case. Routing them through the
+ * bare SDUI list would strip `name` and `disabled` off real controls — and
+ * `packages/fields` already wrote down what that costs, in the same words, for
+ * the same two keys:
+ *
+ * > Withholding them would make this helper a silent styling- and
+ * > interactivity-dropper … That is a NEW silent failure of exactly the kind
+ * > the whitelist exists to prevent, so they are forwarded.
+ *
+ * It is worth being precise about how INVISIBLE that failure would be here.
+ * The gate that grades this change
+ * (`packages/app-shell/src/__tests__/widget-dom-leak-sweep.test.tsx`) reports
+ * attributes that ARRIVE illegitimately; it has no case for an attribute that
+ * stops arriving, and its canary node authors no `disabled` at all. So dropping
+ * `disabled` off every form control in the library would have moved not one
+ * number in this card's own acceptance evidence. The ledger predicted the same
+ * thing from the other side — its `BARE_SPREAD_MINUS_NAME` note says converging
+ * this group "will not change that attribute, only the thirteen around it" —
+ * and that prediction is only true if `name` is forwarded deliberately.
+ *
+ * ## One mechanism, three declarations
+ *
+ * This is the third declaration over the ONE mechanism in
+ * `@object-ui/core`'s `pickDomProps`, and it follows the pattern
+ * `@object-ui/fields` established rather than inventing one: the consuming
+ * package owns the key list its own contract implies, and calls the shared
+ * filter with it. The three, and what separates them:
+ *
+ *  - `toDomProps` (`@object-ui/core`) — the SDUI baseline, element-agnostic.
+ *  - `@object-ui/fields`' `toDomProps` — the baseline minus `role`, plus `name`
+ *    and `disabled`; `FieldWidgetComponentProps` declares the closed set.
+ *  - this one — the baseline PLUS `name` and `disabled`, nothing removed. It is
+ *    a strict superset of the SDUI list, which the compile-time assertion below
+ *    pins, so a key added to the shared set can never be quietly dropped here.
+ *
+ * Anything beyond this set is still the objectui#4435 route: DECLARE it and
+ * forward it by name. Do not reopen the spread (AGENTS.md #0.1 — fix the
+ * contract, never widen the consumer). `style` is the standing example, and it
+ * is forwarded by name at every call site for exactly that reason.
+ */
+declare const FORM_CONTROL_DOM_PASS_THROUGH_KEYS: readonly ["id", "className", "role", "tabIndex", "autoFocus", "onClick", "onBlur", "onFocus", "name", "disabled"];
+type FormControlDomPassThroughKey = (typeof FORM_CONTROL_DOM_PASS_THROUGH_KEYS)[number];
+/** The subset of `P` this declaration forwards, with each key's declared type. */
+export type FormControlDomProps<P> = CoreDomProps<P, FormControlDomPassThroughKey>;
+/**
+ * Keep only what may legitimately become an attribute on a FORM CONTROL, and
+ * drop everything else — the injected `schema`, the data-source adapter, the
+ * authored node's SDUI metadata, the flattened `props` container, and every
+ * declared prop the renderer already consumed off `schema`.
+ *
+ * Replaces the bare `{...rest}` spread in a form-control registration:
+ *
+ * ```tsx
+ * // before — forwards whatever `SchemaRenderer` handed it
+ * const { style, ...rest } = props;
+ * return <Input name={schema.name} {...rest} />;
+ *
+ * // after
+ * return <Input name={schema.name} {...toFormControlDomProps(rest)} style={style} />;
+ * ```
+ */
+export declare function toFormControlDomProps<P extends object>(props: P): FormControlDomProps<P>;
+export {};

package/dist/lib/sidebar-cookie.d.ts

@@ -0,0 +1,55 @@
+/**
+ * ObjectUI
+ * 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.
+ */
+/**
+ * Reads the persisted sidebar collapse state back out of `document.cookie` —
+ * objectui#4234.
+ *
+ * `SidebarProvider` has always WRITTEN `sidebar_state` on every toggle (7-day
+ * max-age) and never read it back, so a collapsed sidebar came back expanded
+ * on the next load: the cookie was present and correct, and nothing consulted
+ * it. Upstream Shadcn closes that loop in a **server component** — it reads the
+ * cookie there and hands the value down as `defaultOpen`. A pure SPA (the
+ * console) has no such step, so the read has to happen client-side, which is
+ * what this function is for.
+ *
+ * ## Why the implementation lives HERE and not in the primitive
+ *
+ * `packages/components/src/ui/**` is regenerated from the Shadcn registry
+ * (AGENTS.md Commandment #7) — anything written there is overwritten by the
+ * next `pnpm shadcn:update`. `src/lib/` is not part of that regeneration, so
+ * this file is permanent. `sidebar.tsx` gets only a one-line call, re-applied
+ * on every sync by the declared patch in `scripts/shadcn-local-patches.mjs`.
+ * Keeping the payload out of the regenerated zone is what makes the patch small
+ * enough to survive upstream churn — the same shape as `close-label.tsx`.
+ *
+ * ## Why the cookie NAME is a parameter
+ *
+ * The name is owned by the write side: `SIDEBAR_COOKIE_NAME` in `sidebar.tsx`,
+ * the same constant the `document.cookie =` assignment interpolates. Passing it
+ * in keeps that the single source of truth — a second spelling here could drift
+ * from the writer and would read a cookie nobody writes. (Importing the
+ * constant instead would make `sidebar.tsx` and this module circular.)
+ *
+ * ## Strict values, deliberately
+ *
+ * Only the two literals the write side produces are accepted. Anything else —
+ * absent, empty, `"1"`, `"collapsed"`, a truncated value — returns `undefined`
+ * so the caller falls through to its `defaultOpen`. That is contract-first
+ * (AGENTS.md #0.1): the writer is ours and emits exactly `true`/`false`, so a
+ * tolerant parse here would only serve values no part of this system writes,
+ * and would silently invent a preference the user never expressed.
+ *
+ * @param name Cookie name to look up, matched EXACTLY (not by prefix or
+ *   substring), so `sidebar_state_v2` / `my_sidebar_state` never answer for
+ *   `sidebar_state`.
+ * @returns `true` / `false` for a persisted preference, or `undefined` when
+ *   there is none to honour — including on the server, where there is no
+ *   `document` to read (Next.js SSRs `"use client"` components for the initial
+ *   HTML, so this guard is load-bearing for `apps/site`, not defensive noise).
+ */
+export declare function readSidebarStateCookie(name: string): boolean | undefined;

package/dist/lib/slider-thumb.d.ts

@@ -0,0 +1,86 @@
+/**
+ * ObjectUI
+ * 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.
+ */
+import type * as React from 'react';
+/**
+ * The payload of the `slider-thumb-pass-through` local patch
+ * (`scripts/shadcn-local-patches.mjs`, objectui#3318).
+ *
+ * ## The defect this exists for
+ *
+ * A Radix slider's focusable control is the THUMB — `span[role="slider"]`,
+ * `tabindex="0"`, the element that carries `aria-valuenow` and the one a
+ * keyboard user and their screen reader actually land on. `Slider.Root` renders
+ * a role-less wrapper `span` and forwards every unrecognised prop to it, so a
+ * host's control-channel facts (`id`, `aria-invalid`, `aria-describedby`,
+ * `aria-labelledby`, `aria-required`) landed on a wrapper assistive technology
+ * never visits. Measured on `origin/main`, a real form + a required slider that
+ * had just failed validation:
+ *
+ * ```
+ * slider  ariaInvalidTrue=[]  labelFor=…-form-item -> DANGLING
+ *         descConsumers=0     focusable=[span[slider],input]
+ *         ids=[]              <- no element of the row carried an id at all
+ * ```
+ *
+ * This is the same shape objectui#3306 fixed for `select`, one step harder:
+ * there the focusable control is `SelectTrigger`, a component the primitive
+ * EXPORTS, so the widget could address it directly. `ui/slider.tsx` renders its
+ * thumb internally and exports only `Slider`, so the widget has no handle on
+ * the one element that must carry the state — hence a pass-through.
+ *
+ * ## Why a declared prop and not an implicit bridge
+ *
+ * The primitive could instead have COPIED a fixed list of `aria-*` keys from
+ * its own props down to the thumb. Rejected: the copy would leave the same keys
+ * on Root as well, and for `id` that is not a duplicate attribute but a
+ * duplicate DOM ID — `document.getElementById` answers with the wrapper, so a
+ * host `<label for>` would resolve to the non-focusable span and the bug would
+ * survive its own fix wearing a green test. Splitting is therefore mandatory,
+ * and once the caller must say which keys go where, saying it explicitly is
+ * strictly better than a list the caller cannot see (AGENTS.md #0.1: one strict
+ * contract, no consumer-side guessing).
+ *
+ * ## Where the split is decided
+ *
+ * Not here — this only routes. The widget decides, and `SliderField` mirrors
+ * `SelectField`'s #3306 split exactly: `name` and `disabled` stay on Root (Root
+ * owns the hidden form input and is the single disabled authority), everything
+ * else in the DOM pass-through whitelist goes to the thumb.
+ */
+/** Props the `Slider` wrapper hands to its internal `SliderPrimitive.Thumb`. */
+export interface SliderThumbPassThrough {
+    /**
+     * Forwarded verbatim onto the focusable `span[role="slider"]`.
+     *
+     * Deliberately typed as the DOM attribute surface rather than
+     * `ComponentPropsWithoutRef<typeof SliderPrimitive.Thumb>`: this module must
+     * not import the primitive (it is consumed BY the no-touch file, and a cycle
+     * through it would be a fragile thing to hang a sync patch on), and the thumb
+     * is a plain `span` as far as every key a host delivers is concerned.
+     */
+    thumbProps?: React.HTMLAttributes<HTMLSpanElement> & {
+        id?: string;
+        tabIndex?: number;
+        'aria-label'?: string;
+    };
+}
+/**
+ * Route a `Slider`'s props to the two elements that need them.
+ *
+ * `thumbProps` is REMOVED from the root half — leaving it there would put
+ * `thumbprops="[object Object]"` on the wrapper span, which is exactly the leak
+ * objectui#3291's sweep exists to catch.
+ *
+ * The pre-existing `aria-label` bridge is preserved and applied FIRST, so a
+ * caller that passes both keeps the explicit `thumbProps` value; nothing about
+ * the attribute's previous behaviour changes for callers that pass neither.
+ */
+export declare function splitSliderThumbProps<P extends Record<string, unknown>>(props: P): {
+    root: Omit<P, 'thumbProps'>;
+    thumb: Record<string, unknown>;
+};

package/dist/notifications/index.d.ts

@@ -19,8 +19,8 @@
  * Every one of these used to be handed to `onToast` regardless of type, so all
  * five looked identical (#3014).
  */
-export { NotificationBanners, type NotificationBannersProps } from './NotificationBanners';
-export { NotificationSnackbar, type NotificationSnackbarProps } from './NotificationSnackbar';
-export { NotificationAlerts, type NotificationAlertsProps } from './NotificationAlerts';
-export { NotificationInline, type NotificationInlineProps } from './NotificationInline';
-export { NOTIFICATION_ACTION_BUTTON_VARIANTS, NOTIFICATION_POSITION_CLASSES, NOTIFICATION_SEVERITY_STYLES, notificationActionVariant, notificationIcon, notificationSeverityStyle, type NotificationSeverityStyle, } from './severity';
+export { NotificationBanners, type NotificationBannersProps } from './NotificationBanners.js';
+export { NotificationSnackbar, type NotificationSnackbarProps } from './NotificationSnackbar.js';
+export { NotificationAlerts, type NotificationAlertsProps } from './NotificationAlerts.js';
+export { NotificationInline, type NotificationInlineProps } from './NotificationInline.js';
+export { NOTIFICATION_ACTION_BUTTON_VARIANTS, NOTIFICATION_POSITION_CLASSES, NOTIFICATION_SEVERITY_STYLES, notificationActionVariant, notificationIcon, notificationSeverityStyle, type NotificationSeverityStyle, } from './severity.js';

package/dist/renderers/action/action-bar.d.ts

@@ -1,8 +1,8 @@
-import { ActionSchema, ActionLocation } from '@object-ui/types';
+import { UIActionSchema, ActionLocation } from '@object-ui/types';
 export interface ActionBarSchema {
     type: 'action:bar';
     /** Business actions to render — subject to inline/overflow split via {@link maxVisible} */
-    actions?: ActionSchema[];
+    actions?: UIActionSchema[];
     /**
      * System/chrome actions (Duplicate, Export, View History, Delete, etc.) that
      * are *always* placed in the overflow menu — never inline — regardless of
@@ -13,7 +13,7 @@ export interface ActionBarSchema {
      * The first system action is automatically separated from business-overflow
      * entries by a menu separator.
      */
-    systemActions?: ActionSchema[];
+    systemActions?: UIActionSchema[];
     /** Filter actions by this location */
     location?: ActionLocation;
     /** Maximum visible inline actions before overflow into "More" menu (default: 3) */

package/dist/renderers/action/action-button.d.ts

@@ -1,6 +1,16 @@
-import { ActionSchema } from '@object-ui/types';
+import { UIActionSchema } from '@object-ui/types';
+/**
+ * The declared props. `schema` is `UIActionSchema` (objectui#4418): every key
+ * this renderer forwards below — `target`, `endpoint`, `bodyExtra`,
+ * `bodyShape`, `locations`, `enabled`, `size` — is declared by the modern type
+ * and by no other, and the legacy `crud.ts` `ActionSchema` it used to name is
+ * `@deprecated` and requires `type: 'action'` (this renderer serves
+ * `'script' | 'url' | 'modal' | 'flow' | 'api'`). `actionType` stays on the
+ * intersection: it is the legacy-shaped override this renderer reads FIRST
+ * (`schema.actionType || schema.type`), and it is not a `UIActionSchema` key.
+ */
 export interface ActionButtonProps {
-    schema: ActionSchema & {
+    schema: UIActionSchema & {
         type: string;
         className?: string;
         actionType?: string;

package/dist/renderers/action/action-group.d.ts

@@ -1,5 +1,5 @@
 import { default as React } from 'react';
-import { ActionSchema, ActionLocation } from '@object-ui/types';
+import { UIActionSchema, ActionLocation } from '@object-ui/types';
 export interface ActionGroupSchema {
     type: 'action:group';
     /** Group name */
@@ -9,7 +9,7 @@ export interface ActionGroupSchema {
     /** Group icon */
     icon?: string;
     /** Actions in this group */
-    actions?: ActionSchema[];
+    actions?: UIActionSchema[];
     /** Display mode: inline button row or dropdown */
     display?: 'dropdown' | 'inline';
     /** Filter actions by location */
@@ -35,7 +35,13 @@ export interface ActionGroupSchema {
  * showed even when its predicate was false.
  */
 export declare const DropdownActionItem: React.FC<{
-    action: ActionSchema;
+    action: UIActionSchema;
     index: number;
-    onSelect: (action: ActionSchema) => void | Promise<void>;
+    onSelect: (action: UIActionSchema) => void | Promise<void>;
+    /**
+     * The row this group is mounted over, forwarded by the host. Optional: an
+     * object-level group genuinely has no row, and a predicate over an empty
+     * record is still evaluable (objectui#4075).
+     */
+    record?: unknown;
 }>;

package/dist/renderers/action/action-icon.d.ts

@@ -1,6 +1,14 @@
-import { ActionSchema } from '@object-ui/types';
+import { UIActionSchema } from '@object-ui/types';
+/**
+ * The declared props. `schema` is `UIActionSchema` (objectui#4418) for the same
+ * reason as `action:button`'s: `target`, `endpoint`, `bodyExtra`, `bodyShape`,
+ * `locations`, `enabled` and `size` are all modern-only keys this renderer
+ * forwards, and the legacy `crud.ts` `ActionSchema` is `@deprecated` and pins
+ * `type: 'action'` where this renderer's own registry `inputs` declare
+ * `'script' | 'url' | 'modal' | 'flow' | 'api'`.
+ */
 export interface ActionIconProps {
-    schema: ActionSchema & {
+    schema: UIActionSchema & {
         type: string;
         className?: string;
     };

package/dist/renderers/action/action-menu.d.ts

@@ -1,4 +1,5 @@
-import { ActionSchema } from '@object-ui/types';
+import { default as React } from 'react';
+import { UIActionSchema } from '@object-ui/types';
 export interface ActionMenuSchema {
     type: 'action:menu';
     /** Menu trigger label (defaults to icon-only) */
@@ -6,7 +7,7 @@ export interface ActionMenuSchema {
     /** Menu trigger icon (defaults to more-horizontal) */
     icon?: string;
     /** Actions to render as menu items */
-    actions?: ActionSchema[];
+    actions?: UIActionSchema[];
     /** Trigger variant */
     variant?: string;
     /** Trigger size */
@@ -17,3 +18,20 @@ export interface ActionMenuSchema {
     className?: string;
     [key: string]: any;
 }
+/**
+ * One action inside an `action:menu`. Exported for its pin tests only (it is
+ * not re-exported from the package index) — mirrors `DropdownActionItem` in
+ * `action-group.tsx`, whose gate is the same one.
+ */
+export declare const ActionMenuItem: React.FC<{
+    action: UIActionSchema;
+    onExecute: (action: UIActionSchema) => Promise<void>;
+    /**
+     * The row this menu is mounted over, forwarded by the host. Optional: an
+     * object-level menu genuinely has no row, and a predicate over an empty
+     * record is still evaluable (objectui#4075 — the failure being fixed is a
+     * predicate that FAULTS on an unbound root, not one that reads a missing
+     * field).
+     */
+    record?: unknown;
+}>;

package/dist/renderers/action/auto-trigger.d.ts

@@ -0,0 +1,20 @@
+/**
+ * ObjectUI
+ * 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.
+ */
+/**
+ * Is this action asking to be auto-triggered? One spelling of the test, so the
+ * flag cannot be read as `!== undefined` in one renderer and `=== true` in
+ * another. Deliberately strict: only the literal `true` arms it.
+ */
+export declare function hasAutoTrigger(action: unknown): boolean;
+/**
+ * Run `run` at most once, as soon as `armed` is true.
+ *
+ * `run` may change identity freely (it is rebuilt from `schema` on most
+ * renders); the ref is what makes this once-only, so depending on it is safe.
+ */
+export declare function useAutoTriggerOnce(armed: boolean, run: () => void | Promise<void>): void;

package/dist/renderers/action/visibility-gate.d.ts

@@ -0,0 +1,81 @@
+/**
+ * ObjectUI
+ * 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.
+ */
+/**
+ * Did this action DECLARE a visibility gate at all? The renderer-side name for
+ * the repo's one definition of that question, which now lives one layer down in
+ * `@object-ui/core` as `hasDeclaredPredicate`
+ * (`packages/core/src/evaluator/declaredPredicate.ts`) — read the reasoning
+ * there; only what is specific to this file is repeated below.
+ *
+ * ## Why this module is now a re-export (objectui#3850 / objectui#3862)
+ *
+ * The question was answered three times with three different scopes, and the
+ * widest-scoped answer was on the key where the mistake is not benign:
+ *
+ *   - HERE, `!= null && !== ''` — so every OBJECT counted as a declared gate,
+ *     including `{ dialect: 'cel', source: '' }`. That envelope is not an exotic
+ *     spelling: `@objectstack/spec`'s `ExpressionInputSchema` normalizes every
+ *     authored predicate into one, so "the author left the predicate empty"
+ *     compiles to exactly it. The verdict path then normalized the same value to
+ *     `undefined` and `evaluateCondition(undefined)` answered `true` = "no
+ *     condition, so visible/enabled" — which on `disabled` means GREYED OUT.
+ *     A button disabled forever, indistinguishable from the metadata's intent
+ *     (objectui#3850).
+ *   - `SchemaRenderer`'s inline `!== undefined`, one notch wider again, so
+ *     `disabled: null` greyed out any node on the generic rendering path
+ *     (objectui#3862).
+ *   - `ActionRunner`'s module-private helper, which asked "does this normalize
+ *     to something evaluable?" — the scope objectui#3850 then ruled to be THE
+ *     scope (objectui#3848).
+ *
+ * The ruling: a gate is declared when normalization still leaves a condition to
+ * evaluate. `''`, a whitespace-only string, an empty-`source` envelope and any
+ * non-predicate value are therefore NOT declared, and one definition in core
+ * says so for the renderers, `SchemaRenderer` and the execution entry alike.
+ *
+ * The NAME is kept (`hasDeclaredVisibilityGate`) and this module keeps
+ * re-exporting it: the five member-action call sites — `action:button`,
+ * `action:icon`, `action:group`'s inline button and dropdown item, and
+ * `action:menu`'s item, plus `DeclaredActionsBar` and `record-quick-actions`
+ * through the `@object-ui/components` barrel — are unchanged by this move. The
+ * name is historic (objectui#3492 arrived through `visible`) and the predicate is
+ * key-neutral, which the call-site comments already say.
+ *
+ * ## What did NOT change: truthiness still cannot answer this
+ *
+ * `if (action.visible && !isVisible)` was the objectui#3812 defect: it
+ * classified `visible: false` — the most explicit way an author can say "never
+ * show this" — as *ungated*, so the gate never consulted the verdict and the
+ * action rendered for everyone. A declared boolean is still a declared gate
+ * here; only the empty and non-predicate shapes moved.
+ *
+ * ## The scope change is not verdict-neutral on every key — measured
+ *
+ * On `visible` the empty shapes were mostly benign already, because the two
+ * mistakes cancelled: over-broad "declared" plus `evaluateCondition` answering
+ * `true` for an empty predicate = SHOWN, the same result as "no gate". Measured
+ * on this tree (`action:button`, before → after):
+ *
+ *   | value                        | `visible`         | `disabled`        | `enabled`         |
+ *   |------------------------------|-------------------|-------------------|-------------------|
+ *   | `''`                         | shown → shown     | on → on           | on → on           |
+ *   | `{ dialect:'cel', source:'' }`| shown → shown    | GREY → on         | on → on           |
+ *   | `{ source: '' }`             | shown → shown     | GREY → on         | on → on           |
+ *   | `'   '` (whitespace)         | HIDDEN → shown    | on → on           | GREY → on         |
+ *   | `0` / `{}` (not a predicate) | shown → shown     | GREY → on         | on → on           |
+ *   | `true` / `false` / CEL / `${…}`| unchanged        | unchanged         | unchanged         |
+ *
+ * The whitespace row is the one that moves on `visible`, and it moves toward the
+ * invariant rather than away from it: `'   '` used to be normalized to `'${   }'`
+ * (the normalizer wraps it rather than folding it), which evaluates falsy, so a
+ * predicate that says nothing HID the action from everyone. "An empty predicate
+ * must not hide the action from everyone" is what this gate has always claimed —
+ * the whitespace spelling simply never obeyed it. Same story on the negated
+ * `enabled` leg, where it greyed the control out instead.
+ */
+export { hasDeclaredPredicate as hasDeclaredVisibilityGate } from '@object-ui/core';

package/dist/renderers/basic/elements.d.ts

@@ -15,9 +15,9 @@
  *   - element:divider                            (no-props separator)
  *   - ElementButtonProps  -> element:button
  *
- * Heavier interactive elements (element:filter, element:form) live in their
- * owning plugins and are left to those packages. element:record_picker — which
- * writes its selection into a page variable — ships alongside in `./record-picker`.
+ * Heavier interactive elements (element:form) live in their owning plugins and
+ * are left to those packages. element:record_picker — which writes its
+ * selection into a page variable — ships alongside in `./record-picker`.
  *
  * All props are read off `schema.properties` per the spec's
  * `UIComponent.properties` convention; `schema.props` is also accepted

package/dist/renderers/basic/html-elements.d.ts

@@ -7,7 +7,7 @@
  *
  * Safe native HTML element passthrough renderers (ADR: kind:'html').
  *
- * A `kind:'html'` page is authored as a constrained JSX/Tailwind string that is
+ * A `kind:'html'` page is authored as a constrained JSX string that is
  * PARSED (never executed) into the SDUI tree. For that tier to live up to its
  * name, the everyday HTML tags an author reaches for — headings, paragraphs,
  * lists, links, images, emphasis — must each resolve to a renderer (otherwise

package/dist/renderers/basic/record-picker.d.ts

@@ -9,7 +9,7 @@
  * record of an object and writes the selection into a page variable.
  *
  * Data binding follows the spec's ElementDataSource (`schema.dataSource`):
- *   { object, filter?, sort?, limit? }
+ *   { object, view?, filter?, sort?, limit? }
  * with `properties.object` accepted as a fallback. Display config is read off
  * `schema.properties`:
  *   { labelField='name', valueField='id', label?, placeholder?, emptyText? }
@@ -20,6 +20,15 @@
  * picker is uncontrolled (still usable, just inert) so it never throws outside
  * a Page. The written value drives any predicate referencing `page.<var>`
  * (e.g. another component's `visible` / `visibility`).
+ *
+ * `view` is resolved through {@link useElementDataSource} rather than read off
+ * the binding directly (objectstack#6953). This block used to take `object` /
+ * `filter` / `sort` / `limit` off `schema.dataSource` and DROP `view`, so
+ * `dataSource: { object: 'account', view: 'hot' }` — the spec's own example —
+ * built an unfiltered picker over every account instead of the rows the saved
+ * view selects. That symptom is quieter than the one objectstack#5576 fixed on
+ * `list-view`: nothing errors, the list is simply WIDER than what was authored,
+ * which is exactly the failure an AI-authored page hides best.
  */
 import * as React from 'react';
 declare function ElementRecordPickerRenderer({ schema }: {

package/dist/renderers/complex/data-table.d.ts

@@ -7,6 +7,101 @@ import { DataTableSchema } from '@object-ui/types';
  * only reachable structurally through `DataTableSchema`.
  */
 type RowActionDef = NonNullable<DataTableSchema['rowActionDefs']>[number];
+/**
+ * The authoring shape of the built-in row Edit/Delete predicates — derived from
+ * `DataTableSchema`, never restated by hand (objectui#4354). Everything below
+ * reads what the production caller hands it (`schema.rowEditPredicates` /
+ * `rowDeletePredicates`), so a hand-written `{ visibleWhen?: unknown; … }` here
+ * would be a second definition of one authoring shape, free to drift from the
+ * type it is supposed to mirror without a single test going red.
+ *
+ * The union of the two twins is deliberate: every consumer below serves BOTH
+ * built-ins (`name: 'edit' | 'delete'`), so it may only read keys that BOTH
+ * schema keys declare — if either twin dropped one, the read stops compiling
+ * instead of silently reading `undefined`.
+ */
+type BuiltinRowPredicates = NonNullable<DataTableSchema['rowEditPredicates'] | DataTableSchema['rowDeletePredicates']>;
+/**
+ * Does the built-in Edit/Delete item render for THIS row? The single
+ * definition, read both by the item itself and by the row-level guard that
+ * decides whether the "⋮" trigger exists at all. The two disagreeing is
+ * objectui#3562: the guard counted handlers, the items were then filtered by
+ * these predicates, and a row with every item suppressed still got a trigger
+ * that opened an empty 128×10 box.
+ *
+ * `visibleWhen` counts as a declared gate by `!= null`, not by truthiness —
+ * `visibleWhen: false` hides the item rather than reading as "ungated".
+ *
+ * The parameter is consumption-shaped — visibility is all this decides, so
+ * `disabledWhen` is deliberately absent — but `Pick`ed from the authoring type
+ * rather than hand-written, so it is a SUBSET of that type by construction
+ * (objectui#4354).
+ */
+export declare function isBuiltinRowActionVisible(predicates: Pick<BuiltinRowPredicates, 'visibleWhen'> | undefined, name: 'edit' | 'delete', row: any, scope: Record<string, unknown>): boolean;
+/**
+ * Does this schema-driven custom row action render for THIS row? Same
+ * single-definition rule as the built-ins above.
+ *
+ * A gate counts as DECLARED by `!= null && !== ''`, never by truthiness
+ * (objectui#3758). Truthiness cannot answer the question: `visible: false` is a
+ * declared gate that excludes every row, and testing `!action.visible`
+ * classified it as *ungated* — so the most explicit way to say "never show this"
+ * rendered the item for everyone, and counted toward the "⋮" guard. This is the
+ * invariant objectui#3492 established for the selection bar (plugin-grid's
+ * `hasVisibilityGate`), and the same `!= null` posture the built-in `visibleWhen`
+ * gate above has always had. The boolean then decides in
+ * {@link evalRowActionVisibility}, which short-circuits it instead of handing it
+ * to the engine.
+ *
+ * `''` is grouped with `null` deliberately: an empty predicate is nothing to
+ * evaluate, so it must not hide the item from everyone either.
+ */
+export declare function isCustomRowActionVisible(action: {
+    name?: string;
+    visible?: unknown;
+} | undefined, row: any, scope: Record<string, unknown>): boolean;
+/** What the row overflow menu will actually render for ONE row. */
+export interface DataTableRowMenuPlan {
+    /** The built-in Edit item renders for this row. */
+    edit: boolean;
+    /** The built-in Delete item renders for this row. */
+    remove: boolean;
+    /** Custom actions surviving their own `visible` predicate, in declared order. */
+    custom: RowActionDef[];
+    /** Items that will render. `0` means: render no trigger at all (#3562). */
+    count: number;
+}
+/**
+ * Resolve the row overflow menu for ONE row — which items survive their
+ * per-record predicates, and how many that leaves.
+ *
+ * Per ROW, not per table: `visibleWhen` / `visible` are per-record predicates,
+ * so two rows of the same table legitimately differ (one keeps Edit, the next
+ * has nothing left). A table-level guard cannot express that, which is why the
+ * trigger decision lives here and is recomputed for every row.
+ *
+ * Only visibility is decided here — a `disabled` item still renders (greyed
+ * out) and still counts, exactly as before. That counting is pinned where it
+ * can be OBSERVED, on the rendered menu, by
+ * `data-table-row-menu-empty-guard.test.tsx`'s "keeps the trigger for a row
+ * whose only item renders merely DISABLED".
+ *
+ * The predicate parameters are consumption-shaped — this function reads
+ * `visibleWhen` and nothing else, and the signature keeps saying so — but each
+ * is `Pick`ed from the authoring key its production caller passes, rather than
+ * hand-restated (objectui#4354). Same subset, minus the drift: a rename in
+ * `@object-ui/types` fails here at compile time instead of leaving a stale
+ * hand-copy that still type-checks against nothing.
+ */
+export declare function planDataTableRowMenu(input: {
+    onRowEdit?: unknown;
+    onRowDelete?: unknown;
+    editPredicates?: Pick<NonNullable<DataTableSchema['rowEditPredicates']>, 'visibleWhen'>;
+    deletePredicates?: Pick<NonNullable<DataTableSchema['rowDeletePredicates']>, 'visibleWhen'>;
+    customActions: readonly RowActionDef[];
+    row: any;
+    scope: Record<string, unknown>;
+}): DataTableRowMenuPlan;
 /**
  * One schema-driven custom row action in the data-table's inline row overflow
  * menu. Extracted into its own component so the action's `visible` (and
@@ -50,10 +145,11 @@ export declare const DataTableRowActionItem: React.FC<{
  */
 export declare const DataTableBuiltinRowActionItem: React.FC<{
     name: 'edit' | 'delete';
-    predicates?: {
-        visibleWhen?: unknown;
-        disabledWhen?: unknown;
-    };
+    /**
+     * The whole authoring pair, because this component reads both keys — derived
+     * from `DataTableSchema` rather than hand-copied (objectui#4354).
+     */
+    predicates?: BuiltinRowPredicates;
     row: any;
     icon: React.ReactNode;
     label: string;