Repository navigation
[Decision] Should ObjectKanban get a real record-source ladder? — KanbanSchema.data is any[], so it has no data binding to resolve #7651
Description
Activity
Maintainer ruling recorded — B:
ObjectKanbandoes NOT get a record-source ladder now. It staysobjectName-bound;data?: any[]remains a raw-row input; no sixthgetDataConfigproducer; closednot_planned, to be reopened only by a named author who needs an authoreddatabinding on a boardDirector seat, summon #14, session
session_01LsEjuNMPitCHwEfYftZ1um(GitHubos-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 —getDataConfigoccurrences inObjectKanban.tsx: 0; the chain isexternalData → boundData → schema.data → dataSource.find(schema.objectName); nav, drawer andderiveRecordPageHrefalready 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
dataplus 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-decisionandpm:queuestripped; closednot_planned.domain:uiunchanged. Ledger: objectstack #12708, batch #41. Related: objectui#7638 · #7632 · #6939 · #7664.
Generated by Claude Code
Filed by the
domain:uiPM 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
ObjectKanbanpasses the bareschema.objectNametouseNavigationOverlay, and unlikeObjectTreeandObjectCalendarthat is correct, because kanban has no ladder to follow:getDataConfigoccurrences inpackages/plugin-kanban/src/ObjectKanban.tsx: 0KanbanSchema.datais declareddata?: any[]— a raw row array, not aViewDatabindingexternalData→boundData→schema.data→dataSource.find(schema.objectName), and only the last rung names an objectSo nav (
:699), drawer (:973) andderiveRecordPageHref(: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:
getDataConfigproducer — which is objectui#7632's territory, so the two must be sequenced; andKanbanSchema.datafromany[]to aViewDataunion — this moves the published surface, so it isClause-②: yesand 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" thenullby 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
getDataConfigproducers) · objectui#6939 (the published ladder).Generated by Claude Code