finding(plugin-tree,plugin-gantt,plugin-calendar): a bare-array `data` renders EMPTY in three blocks while six siblings normalize it

[claude]

Measured while consolidating the five getDataConfig copies (#7632, PR #7660). Filed
unassigned, not claiming. Deliberately not fixed there — that PR's disposition is a
behaviour-neutral consolidation, and closing this divergence is a behaviour change in three
renderers, which is a separate decision.

What is true today (measured on origin/main 1ec291c0)

A bare array authored under data is normalized to { provider: 'value', items } by some
blocks in the family and silently ignored by others. The split is not documented anywhere as
a decision; it is just where each copy of the ladder ended up.

block	normalizes a bare-array data?	where
ObjectGrid	yes	inside its own getDataConfig
ObjectMap	yes	inside its own getDataConfig
ListView	yes	ListView.tsx:1655, "Also support schema.data as a plain array"
ObjectChart	yes	ChartRenderer.tsx:164, ObjectChart.tsx:287
ObjectDataTable	yes	ObjectDataTable.tsx:633
calendar-view-renderer	yes	calendar-view-renderer.tsx:273
ObjectTree	no	no Array.isArray on schema.data anywhere in plugin-tree
ObjectGantt	no	its ladder returns schema.data verbatim
ObjectCalendar	no	its ladder returns schema.data verbatim

For the bottom three the array is returned verbatim as the resolved data config, so
dataConfig.provider reads undefined downstream, the value branch is never taken, no
fetch is issued, and the block renders empty. No error, no warning.

Why it is worth a card

ObjectMap's own docblock argues the shorthand must be accepted family-wide, and names
ObjectTree as one of the blocks that accepts it:

ObjectGrid's own getDataConfig (...), ListView (...), ObjectTree, ObjectChart,
ObjectDataTable and calendar-view-renderer all accept it. An author (or a generator) that
learned the shorthand from object-grid writes it for object-map next; dropping it HERE
alone would leave the one block in the family that answers the shorthand with a silently
empty map.

That claim about ObjectTree is measurably wrong — plugin-tree has no Array.isArray on
schema.data at all — so the exact failure the comment describes is already happening, in
the tree, the gantt and the calendar. PR #7660 corrects the comment and leaves the behaviour
alone.

The shorthand itself is off-contract against one spec authority and on-contract against the
other, which is #6207: ViewDataSchema makes data a discriminated union over objects,
while ComponentPropsMap['object-grid'].data is z.array(z.unknown()). So "is the array
even legal" is genuinely unsettled, which is why this is filed rather than patched.

What a fix would have to decide

1. Accept it everywhere — add the head to tree, gantt and calendar. Smallest diff, makes
   the family consistent, but widens an off-contract shorthand to three more blocks while
   finding: object-grid.data — two spec authorities disagree on the KIND (ViewDataSchema object vs ComponentPropsMap['object-grid'].data array), so whichever the declaration matches, the other refuses it #6207 is open.
2. Reject it everywhere — drop the head from the six that have it. Consistent with
   ViewDataSchema, but breaks authored metadata that works today and turns
   ObjectMap.schemaDataShorthand.test.tsx and its siblings red by design.
3. Leave the split and document it — cheapest, but it is the state that produced the
   incorrect docblock in the first place.

Option 1 or 2 is likely blocked on #6207 settling which spec authority governs data's kind.

Related, not duplicate

• finding: object-grid.data — two spec authorities disagree on the KIND (ViewDataSchema object vs ComponentPropsMap['object-grid'].data array), so whichever the declaration matches, the other refuses it #6207 — the two spec authorities disagreeing on the KIND of object-grid.data. That is
  the upstream question; this card is about the renderers disagreeing with each other.
• [Decision] Should ObjectKanban get a real record-source ladder? — KanbanSchema.data is any[], so it has no data binding to resolve #7651 — whether ObjectKanban should gain a record-source ladder at all. Adjacent
  population, open maintainer decision.
• finding(plugins): getDataConfig — the three-rung record-source ladder — is hand-copied in five plugin components #7632 / PR refactor(core): one shared record-source ladder, five plugins delegate (objectui#7632) #7660 — where this was measured. That PR is a consolidation only and changes
  nothing here.

No severity claimed; triage's to set.

---

Generated by Claude Code