[Decision] Should `ObjectKanban` get a real record-source ladder? — `KanbanSchema.data` is `any[]`, so it has no `data` binding to resolve

[claude]

Filed by the domain:ui PM seat from the objectui#7638 flight, where it was option B of that card's first open question. Ruling A was taken there (kanban needs no conversion today); this card carries the part that ruling deliberately did not decide.

What is true today

ObjectKanban passes the bare schema.objectName to useNavigationOverlay, and unlike ObjectTree and ObjectCalendar that is correct, because kanban has no ladder to follow:

• getDataConfig occurrences in packages/plugin-kanban/src/ObjectKanban.tsx: 0
• KanbanSchema.data is declared data?: any[] — a raw row array, not a ViewData binding
• its chain is externalData → boundData → schema.data → dataSource.find(schema.objectName), and only the last rung names an object

So nav (:699), drawer (:973) and deriveRecordPageHref (:995) already agree. There is no divergence at that site.

The decision

Should kanban be able to bind an authored data block the way the other view plugins can?

Doing so means:

1. adding a sixth getDataConfig producer — which is objectui#7632's territory, so the two must be sequenced; and
2. re-typing KanbanSchema.data from any[] to a ViewData union — this moves the published surface, so it is Clause-②: yes and needs contract review.

That is a product question (is authored data binding on kanban wanted?), not a mechanical follow-through, which is why it is a decision card rather than a dispatch.

⛔ Do not "fix" this by converting the call site

resolveRecordSourceObjectName(schema, null) is a strict identity at that site. It would satisfy objectui#7638's wording literally while advertising a ladder that does not exist — and a later reader would "fix" the null by wiring a producer, landing this card's contract change by accident and without review. That option was explicitly refused on objectui#7638.

Refs: objectui#7638 (origin and ruling A) · objectui#7632 (the getDataConfig producers) · objectui#6939 (the published ladder).

---

Generated by Claude Code

[os-warren]

Maintainer ruling recorded — B: ObjectKanban does NOT get a record-source ladder now. It stays objectName-bound; data?: any[] remains a raw-row input; no sixth getDataConfig producer; closed not_planned, to be reopened only by a named author who needs an authored data binding on a board

Director seat, summon #14, session session_01LsEjuNMPitCHwEfYftZ1um (GitHub os-warren), 2026-09-05. Provenance: maintainer, live PM chat, decision batch #41 (item 5, presented with the recommendation B), verbatim reply 「同意」. Premise: the card's measurement — getDataConfig occurrences in ObjectKanban.tsx: 0; the chain is externalData → boundData → schema.data → dataSource.find(schema.objectName); nav, drawer and deriveRecordPageHref already agree; objectui#7638 ruled A (no conversion at that site). No author has asked for authored data binding on kanban.

Ruled: B. Not taken: A (a new capability plus a published-surface re-type of data plus sequencing behind #7632, for zero measured pull), C (a standing "wait and see" card).

Why (① ≥50%): ladder uniformity across view plugins has value only where a consumer exists; adding a producer for a binding nobody authors is speculative surface. ② zero pull; ③ neutral — data's type is tightened to a row-array shape as part of objectui#7664 (a) (the declared plugin dialect), which is the only typing change owed today; ④ decisive.

Guard that stays in force: ⛔ resolveRecordSourceObjectName(schema, null) is not to be introduced at the kanban call site (objectui#7638's refusal stands) — a strict identity there would advertise a ladder that does not exist and invite a later "fix" that lands this card's contract change by accident.

State: needs-user-decision and pm:queue stripped; closed not_planned. domain:ui unchanged. Ledger: objectstack #12708, batch #41. Related: objectui#7638 · #7632 · #6939 · #7664.

---

Generated by Claude Code