finding(types,plugin-kanban): `ObjectKanbanSchema` requires `groupField` (zero read sites) and declares neither `groupBy` nor `limit` — no working `object-kanban` node is assignable to any declared type

[yinlianghui]

Found while bringing content/docs/plugins/plugin-kanban.mdx under check:doc-snippets (objectui#5174 batch 7, PR to follow). Filed unassigned and NOT fixed there — packages/* source is outside that PR's surface. Measured on origin/main d717e8bc3 against the built dist.

What

An object-kanban node cannot be annotated with any type this repo ships. There are two declarations in play and each rejects the shape the renderer actually consumes.

1. ObjectKanbanSchema names a lane field the renderer never reads

packages/types/src/objectql.ts declares:

export interface ObjectKanbanSchema extends BaseSchema {
 type: 'object-kanban';
 objectName: string;
 groupField: string; // REQUIRED
 titleField?: string;
 cardFields?: string[];
 // … quickAdd, coverImageField, allowCollapse, conditionalFormatting
}

But packages/plugin-kanban/src/ObjectKanban.tsx — the component the object-kanban registration renders — reads schema.groupBy, at nine sites (lines 630, 631, 642, 654, 655, 660, 669, 670, 776, 894 …), and reads schema.limit for the row cap (line 293: $top: schema.limit ?? DEFAULT_KANBAN_LIMIT, and again in the effect deps at 320).

groupField has zero read sites anywhere in packages/plugin-kanban:

$ git grep -c "groupField" -- 'packages/plugin-kanban/**'
(no output — zero)

Neither groupBy nor limit is declared on ObjectKanbanSchema. They type-check today only because BaseSchema carries [key: string]: any, so both land on the index signature and are structurally invisible — the objectui#5155 / #6269 blind spot.

The package's own test suite writes the documented shape, not the declared one:

// packages/plugin-kanban/src/ObjectKanban.elementDataSource.test.tsx:192
{ type: 'object-kanban', objectName: 'account', groupBy: 'status', columns: LANES, limit: 20 }

2. ObjectKanbanComponentProps.schema is KanbanSchema, whose type is 'kanban'

// packages/plugin-kanban/src/ObjectKanban.tsx:141
export interface ObjectKanbanComponentProps {
 schema: KanbanSchema;
}

KanbanSchema.type is the literal 'kanban'. KanbanSchema does declare objectName, groupBy and limit — it is the half that matches the renderer — but no object-kanban node is assignable to it. ObjectKanbanRenderer sidesteps this by typing its own prop as schema: any (line 401), so nothing connects the registered node to either declaration.

Measured

Both annotations planted on the docs page's row-cap example, gate run, restored from HEAD under a trap (git diff HEAD empty after each):

annotated ObjectKanbanSchema
 TS2741: Property 'groupField' is missing in type
 '{ type: "object-kanban"; objectName: string; groupBy: string; limit: number; }'
 but required in type 'ObjectKanbanSchema'.

annotated KanbanSchema (what the component's prop actually declares)
 TS2322: Type '"object-kanban"' is not assignable to type '"kanban"'.

Note what the first diagnostic does not say: groupBy and limit produced no error at all. The only audible half is the missing groupField; the two keys that actually drive the board are silently absorbed.

Why this is filed rather than fixed

The renderer is the working half and the declaration is the stale half — the same shape as objectui#5903 (ObjectGantt read 11 keys ObjectGanttSchema did not declare) and objectui#7311 (ObjectCalendarComponentProps.schema cannot accept an object-calendar node). Which way to reconcile is a types decision with consumers beyond this docs page:

1. ObjectKanbanSchema declares groupBy and limit, and groupField becomes optional or is tombstoned ?: never the way TimelineSchema.timeScale was (objectui#6355). Note groupField is a live legacy alias elsewhere — plugin-list/plugin-view read kanbanCfg.groupByField || kanbanCfg.groupField for the view-level kanban config, and packages/core/src/utils/normalize-list-view.ts maps kanban.groupField to the spec's groupByField. So it is not dead in general; it is dead on this node.
2. ObjectKanbanComponentProps.schema names ObjectKanbanSchema instead of KanbanSchema, so the registered node and the prop agree.

Both need someone who owns the kanban authoring surface. Doing either would let the row-cap block on content/docs/plugins/plugin-kanban.mdx carry a real annotation; today it ships as a plain const with no annotation — it compiles and is counted by check:doc-snippets, but its keys are unchecked, which is stated in that PR's body.

Reachability

Nothing a user hits at runtime: the documented groupBy / limit shape is what the renderer reads and what its tests assert, so boards work. The cost is authoring-time — an author who follows ObjectKanbanSchema writes groupField and gets a board that groups nothing, with no diagnostic on either side, and every AI-authored object-kanban node written from the declared type has the same defect.

Related: objectui#7311, objectui#7313, objectui#5903, objectui#6973.