fix(types): declare the three props-half slots on ListViewRuntimeProps

Corrects this branch's own first reading. I had concluded that nothing needed
adding to `ListViewRuntimeProps` because `onAddRecord` / `onBulkAction` /
`onPageSizeChange` are read off the PROPS bag and `ListViewProps`
(`@object-ui/plugin-list`) already declares all three as React props.

⛔ That measured only ONE of the two supply paths into that bag. `SchemaRenderer`
spreads every non-metadata top-level key of the node into the props it creates
the component with, so a host that builds the NODE in TypeScript reaches the
same read — and that path was typed only by `BaseSchema`'s passthrough index
signature. Declaring the refusal arms without declaring the slots would have
narrowed a live programmatic channel from `unknown` to `undefined`, which is
wider than this card asks for and is not what `'runtime-slot'` means. It is the
same repair objectui#9344's slice made on `ObjectGallerySchema` for the same
spread, and it means a published interface WIDENS here as well as narrowing —
the changeset says so.

`ObjectView.relayRungCensus-7559.test.ts` follows from that: the three entered
its derived population with this declaration, and its own failure text says the
answer is owed by the change that added them. Three `host-runtime` absences,
the existing kind whose validator requires exactly `ListViewRuntimeProps`
membership — no new absence kind, no new assertion.

⚠️ FILE SURFACE: that census file is outside this claim's declared surface
(`packages/types/src/`, `scripts/check-handler-key-read-sites.mjs`, one
changeset). It is reported rather than hidden; see the pull request body.

Co-authored-by: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KSd9P5u2Mf4p8g4n4SD4Fx

Author: claude

.changeset/7804-list-view-handler-slots-declared.md

@@ -45,11 +45,20 @@ precedence (`ListViewAuthored`), so:
   still the function types `ListViewRuntimeProps` declares, still supplied on
   the node by hosts such as `@object-ui/app-shell`'s `ObjectView`.
 - `ListViewSchema['onAddRecord']`, `['onBulkAction']` and `['onPageSizeChange']`
-  narrow from `unknown` (they were only ever reachable through the passthrough
-  index signature) to `undefined`. That is the intended narrowing: all three are
-  React props, declared by name on `ListViewProps` in `@object-ui/plugin-list`,
-  and a host passes them to `<ListView>` rather than authoring them on the node.
-- Nothing is ADDED to `ListViewRuntimeProps`, so no published interface widens.
+  are now DECLARED on `ListViewRuntimeProps` with the signatures `ListViewProps`
+  in `@object-ui/plugin-list` already carried, where before they were typed only
+  by `BaseSchema`'s passthrough index signature — `unknown`, a declaration
+  nobody wrote and nobody can read. `ListView` reads all three off its props
+  bag, and a host fills that bag either by passing the React prop or by putting
+  the key on the node, where `SchemaRenderer` spreads it in; this declaration is
+  the second path's contract. Same repair as the `ObjectGallerySchema` pair one
+  slice earlier, for the same spread.
+
+**A published interface therefore WIDENS as well as narrowing.** Three members
+are added to `ListViewRuntimeProps`. Nothing that compiled before stops
+compiling — `unknown` accepted any host handler and the declared signatures
+accept the ones `ListViewProps` already held hosts to — but the surface is
+larger, and it is stated here rather than left to be discovered.
 
 **Migration.** Nothing in the corpus has to change: no authored `'list-view'`
 document in this repository, its examples or its docs writes any of the five —

packages/app-shell/src/views/ObjectView.relayRungCensus-7559.test.ts

@@ -482,6 +482,14 @@ const ABSENCES: Record<string, Absence> = {
   // ── The runtime-only half of the intersection ─────────────────────────────
   onNavigate: { kind: 'host-runtime', reason: 'Host callback. This host wires record navigation through the `onRowClick` prop on the `<ListView>` element instead; a view record cannot carry a function.' },
   refreshTrigger: { kind: 'host-runtime', reason: 'Host refresh counter, supplied by the caller; not view metadata.' },
+  // ⭐ objectui#7804 declared these three on `ListViewRuntimeProps`, so they
+  // entered this census's population with that slice and owe an answer here.
+  // All three are host callbacks `ListView` reads off its PROPS bag; this host
+  // supplies none of them and a view RECORD cannot carry a function, so there is
+  // no rung to add — the absence is the whole of their contract on this path.
+  onAddRecord: { kind: 'host-runtime', reason: 'Host callback for the toolbar "+ New" affordance. This host routes record creation through its own action layer rather than through ListView, and a view record cannot carry a function.' },
+  onBulkAction: { kind: 'host-runtime', reason: 'Host callback for non-delete bulk actions. This host wires bulk delete through the `onBulkDelete` prop on the `<ListView>` element and offers no other bulk action here; a view record cannot carry a function.' },
+  onPageSizeChange: { kind: 'host-runtime', reason: 'Host callback for the pager\'s page-size select. This host lets ListView keep page size as session state rather than persisting it, the same posture as `onFilterChange` (objectui#4155); a view record cannot carry a function.' },
 };
 
 // ---------------------------------------------------------------------------

packages/types/src/__tests__/list-view-handler-slots-7804.test.ts

@@ -28,11 +28,12 @@
  * package, chained from the package's `type-check` script.
  *
  * ⛔ What this file does NOT assert: that the keys are unreachable. They are
- * RUNTIME SLOTS — `onNavigate` / `onDensityChange` reach `ListView` through the
- * node (`schema.onX`), the other three through React props declared on
- * `ListViewProps` in `@object-ui/plugin-list`. A host still supplies them; what
- * is refused is AUTHORING one as JSON, which could only ever hand a call site
- * a plain object where it expects a function.
+ * RUNTIME SLOTS. `onNavigate` / `onDensityChange` reach `ListView` off the node
+ * (`schema.onX`); the other three reach it off the PROPS bag, which a host fills
+ * either by passing the React prop `ListViewProps` declares or by putting the
+ * key on the NODE, where `SchemaRenderer` spreads it in. A host still supplies
+ * all five; what is refused is AUTHORING one as JSON, which could only ever hand
+ * a call site a plain object where it expects a function.
  */
 import { describe, it, expect } from 'vitest';
 import { ListViewSchema as ListViewMirror } from '../zod/objectql.zod.js';
@@ -143,11 +144,36 @@ const TYPE_PINS = {
   objectName: 'accounts' satisfies ListViewSchema['objectName'],
 } as const;
 
-/** The three PROPS-half keys are NOT authorable on the node type. */
-// @ts-expect-error `onAddRecord` is a React prop on `ListViewProps`, not a node key.
-const notOnTheNode: ListViewSchema['onAddRecord'] = () => undefined;
-void notOnTheNode;
+/**
+ * The three PROPS-half slots stay CALLABLE on the node type too — the second
+ * supply path (`SchemaRenderer` spreading a node key into the props bag) is what
+ * this declaration contracts, and it is exactly what the refusal arm would have
+ * killed without the precedence.
+ */
+const propsHalf = {
+  onAddRecord: (() => undefined) satisfies NonNullable<ListViewSchema['onAddRecord']>,
+  onBulkAction: ((action: string, records: unknown[]) => {
+    void action;
+    void records;
+  }) satisfies NonNullable<ListViewSchema['onBulkAction']>,
+  onPageSizeChange: ((size: number) => {
+    void size;
+  }) satisfies NonNullable<ListViewSchema['onPageSizeChange']>,
+} as const;
+void propsHalf;
 
-/** And the runtime half's own key list is what the precedence is keyed on. */
-const runtimeKeys: Array<keyof ListViewRuntimeProps> = ['onNavigate', 'onDensityChange', 'refreshTrigger'];
+/**
+ * ⛔ And the precedence is keyed on `ListViewRuntimeProps`' own member list, so
+ * a sixth refusal arm added to the mirror without a matching declaration here
+ * would go back to resolving as `undefined`. This is that list, stated where it
+ * fails if a member leaves it.
+ */
+const runtimeKeys: Array<keyof ListViewRuntimeProps> = [
+  'onNavigate',
+  'onDensityChange',
+  'refreshTrigger',
+  'onAddRecord',
+  'onBulkAction',
+  'onPageSizeChange',
+];
 void runtimeKeys;

packages/types/src/objectql.ts

@@ -2644,6 +2644,42 @@ export interface ListViewRuntimeProps {
    * Used by parent components (e.g. ObjectView) to signal that a mutation occurred.
    */
   refreshTrigger?: number;
+
+  /**
+   * ⭐ The three slots below are declared here by objectui#7804, and the reason is
+   * the one objectui#9344's slice already measured on `ObjectGallerySchema`: a key
+   * that reaches the renderer through `SchemaRenderer`'s props spread is on the
+   * TypeScript face whether or not anyone declared it — `BaseSchema`'s index
+   * signature was typing all three `unknown`, which is a declaration nobody wrote
+   * and nobody can read.
+   *
+   * `ListView` reads them off its PROPS bag (`props.onAddRecord`, not
+   * `schema.onAddRecord`), and there are two supply paths into that bag, both
+   * live: a React host renders the component and passes the prop directly — the
+   * `ListViewProps` interface in `@object-ui/plugin-list` declares all three by
+   * name for exactly that — or a host builds the NODE in TypeScript and
+   * `SchemaRenderer` spreads every non-metadata top-level key into the props it
+   * creates the component with. This declaration is the second path's contract.
+   * Declaring it is what keeps the `'runtime-slot'` disposition on the matching
+   * zod arms true: JSON cannot author a function, so the mirror refuses the key
+   * by name, while a programmatic host goes on supplying one HERE.
+   *
+   * ⚠️ Signatures match `ListViewProps` deliberately, `any` included. A host that
+   * discovered the payload from the implementation annotated its own handler
+   * against that interface, and a narrower declaration here refuses such a host
+   * CONTRAVARIANTLY — the reading objectui#9341 took on
+   * `ObjectKanbanSchema.onCardClick` and the reason `ListViewProps.onRowClick`
+   * carries the same spelling.
+   */
+
+  /** Called when the user asks for a new record (toolbar "+ New" and the empty-state CTA). */
+  onAddRecord?: () => void;
+
+  /** Called with a non-delete bulk action key and the currently selected rows. */
+  onBulkAction?: (action: string, records: any[]) => void;
+
+  /** Called when the user picks a different page size in the pager. */
+  onPageSizeChange?: (pageSize: number) => void;
 }
 
 /**

packages/types/src/zod/objectql.zod.ts

@@ -1142,15 +1142,16 @@ export const ListViewSchema = BaseSchema
     //     `onNavigate` has no in-repo supplier on a `list-view` node, yet the
     //     channel is wired end to end and the read still fires.
     //   `onAddRecord` · `onBulkAction` · `onPageSizeChange`  read off the PROPS
-    //     bag (`props.onX`) and declared as React props on `ListViewProps`
-    //     (`@object-ui/plugin-list`), the interface objectui#4528 wrote out by
-    //     name. `StudioDesignSurface` supplies `onAddRecord` as a React prop;
-    //     the other two have no in-repo supplier and are still read and still
-    //     invoked.
-    //
-    // ⇒ nothing is ADDED to `ListViewRuntimeProps` by this slice: every one of
-    // the five already has a declared TypeScript home, and the three props-half
-    // keys never belonged on the node type at all.
+    //     bag (`props.onX`). TWO supply paths reach that bag and both are live:
+    //     a React host passes the prop to the component — `ListViewProps`
+    //     (`@object-ui/plugin-list`) declares all three by name, and
+    //     `StudioDesignSurface` supplies `onAddRecord` that way — or a host
+    //     builds the NODE and `SchemaRenderer` spreads it in. The second path
+    //     was typed only by `BaseSchema`'s index signature, so this slice
+    //     declares the three on `ListViewRuntimeProps` as well, which is the
+    //     same repair objectui#9344's slice made on `ObjectGallerySchema` for
+    //     the same spread. `onBulkAction` / `onPageSizeChange` have no in-repo
+    //     supplier and are still read and still invoked.
     //
     // ⚠️ Unlike the plain `interface X extends BaseSchema` arms this card
     // drained before it, THIS arm feeds its own TypeScript face: