Found while implementing objectui#6576 (transcribing ObjectDataTableProps.schema into the new ObjectDataTableSchema). Filed unassigned for triage; #6576 transcribed the member as declared and did not touch it — removing a declared member was outside that ruling.
The fact
Two widget schema types declare the same member:
ObjectDataTableSchema.dataProvider?: { provider: string; object?: string } (packages/types/src/objectql.ts, carried over from the inline literal that used to sit in packages/plugin-dashboard/src/ObjectDataTable.tsx).ObjectPivotTableProps.schema.dataProvider (packages/plugin-dashboard/src/ObjectPivotTable.tsx:44), same shape.
Two producers write it onto the node: DashboardRenderer.tsx:737 and DashboardGridLayout.tsx:308 and :347, all as dataProvider: widgetData.
Zero read sites. Measured on origin/main at 2956d7af8 with one query over packages/*/src excluding __tests__ — every spelling of a read (.dataProvider, dataProvider?., a destructure) — returns nothing but the two declarations and the three writes. ObjectDataTable reads objectName, bind, filter, data, columns, drillDown, onRowClick off its schema and nothing else (the read census in widget-schema-anchors-6576.test.ts).
Why it matters
This is the objectui#5018 class — a declared-but-unread key re-creates the drift defect pointing the other way: an author (or an AI writing metadata) reads the declaration as an authorable input, writes it, and nothing happens. It also travels: ObjectDataTable spreads its node into the data-table it renders, so the object rides along into a renderer that has no use for it either.
Unmeasured, stated as such: whether the spread value reaches a DOM element as an attribute (the objectui#4357 class). Not checked here.
What needs deciding
Enforce or remove (ADR-0049): either some renderer should consume dataProvider (then declare where and what for), or the two declarations and the three writes go. The producers already write objectName: widgetData.object beside it, which is the key the widgets actually read.
Refs: objectui#6576, objectui#5018, objectui#4357.
Filed by the os-dev seat working objectui#6576; session https://claude.ai/code/session_01NRRumy89BYdW9ogbcdHTho
Found while implementing objectui#6576 (transcribing
ObjectDataTableProps.schemainto the newObjectDataTableSchema). Filed unassigned for triage; #6576 transcribed the member as declared and did not touch it — removing a declared member was outside that ruling.The fact
Two widget schema types declare the same member:
ObjectDataTableSchema.dataProvider?: { provider: string; object?: string }(packages/types/src/objectql.ts, carried over from the inline literal that used to sit inpackages/plugin-dashboard/src/ObjectDataTable.tsx).ObjectPivotTableProps.schema.dataProvider(packages/plugin-dashboard/src/ObjectPivotTable.tsx:44), same shape.Two producers write it onto the node:
DashboardRenderer.tsx:737andDashboardGridLayout.tsx:308and:347, all asdataProvider: widgetData.Zero read sites. Measured on
origin/mainat2956d7af8with one query overpackages/*/srcexcluding__tests__— every spelling of a read (.dataProvider,dataProvider?., a destructure) — returns nothing but the two declarations and the three writes.ObjectDataTablereadsobjectName,bind,filter,data,columns,drillDown,onRowClickoff its schema and nothing else (the read census inwidget-schema-anchors-6576.test.ts).Why it matters
This is the objectui#5018 class — a declared-but-unread key re-creates the drift defect pointing the other way: an author (or an AI writing metadata) reads the declaration as an authorable input, writes it, and nothing happens. It also travels:
ObjectDataTablespreads its node into thedata-tableit renders, so the object rides along into a renderer that has no use for it either.Unmeasured, stated as such: whether the spread value reaches a DOM element as an attribute (the objectui#4357 class). Not checked here.
What needs deciding
Enforce or remove (ADR-0049): either some renderer should consume
dataProvider(then declare where and what for), or the two declarations and the three writes go. The producers already writeobjectName: widgetData.objectbeside it, which is the key the widgets actually read.Refs: objectui#6576, objectui#5018, objectui#4357.
Filed by the os-dev seat working objectui#6576; session https://claude.ai/code/session_01NRRumy89BYdW9ogbcdHTho