Found while implementing objectui#7544 (the ListView capability gate never resolved chart). Recording only, no fix in that PR — it is a different package and outside that card's file surface.
What is measured
On origin/main 900f8d995, packages/app-shell/src/views/ObjectView.tsx reads the SAME authored chart: block two different ways, 337 lines apart:
:2098 — the dedicated chart-view branch, which renders ObjectChart directly and is ADR-0021 aware:
if (viewDef.type === 'chart') {
const chartConfig = viewDef.chart || {};
if (chartConfig.dataset) { ...dimensions, values... }
:2435 — the rung that relays the block into ListView (inside the fullSchema literal at :2170), a hand-listed projection of exactly six keys:
chart: {
chartType: viewDef.chart?.chartType,
xAxisField: viewDef.chart?.xAxisField,
yAxisFields: viewDef.chart?.yAxisFields,
aggregation: viewDef.chart?.aggregation,
series: viewDef.chart?.series,
config: viewDef.chart?.config,
},
dataset, dimensions and values — the whole ADR-0021 (#1890) authoring shape — are absent, as are categoryField / valueField. The list is the pre-ADR-0021 key set, frozen. The active view's block also does not reach ListView under its canonical chart: key: fullSchema spreads listSchema (the OBJECT's list schema), so schema.chart at the ListView end is the object-level list's block, never the active view's.
⇒ On the object-view route, a view that declares the ADR-0021 shape reaches ListView with its binding stripped, and ListView cannot tell that from a view that declared nothing.
Why this is load-bearing now
objectui#7544 gave ListView.availableViews a chart capability check: a grid view that declares a chart block and whitelists ['grid', 'chart'] is offered the Chart toggle, and one that declares nothing is not. That gate asks the block it is handed. Through this relay an ADR-0021 block arrives as six undefined keys, so the gate correctly answers "nothing declared" about a view whose author declared everything — the toggle stays hidden and the author gets no diagnostic. The legacy xAxisField / yAxisFields spelling survives the relay and does resolve, so the two authoring shapes behave differently on this route for reasons that live entirely in this projection.
Before objectui#7544 nothing downstream read those keys through this rung, which is why the gap was invisible.
What this is NOT
Not verified here
Whether InterfaceListPage (the other host that builds a ListView schema) has the same projection — it does not name chart at all in a grep of that file, which may mean it relays the block whole or does not relay it. Worth one reading before choosing the fix shape.
Generated by Claude Code
Found while implementing objectui#7544 (the ListView capability gate never resolved
chart). Recording only, no fix in that PR — it is a different package and outside that card's file surface.What is measured
On
origin/main900f8d995,packages/app-shell/src/views/ObjectView.tsxreads the SAME authoredchart:block two different ways, 337 lines apart::2098— the dedicated chart-view branch, which rendersObjectChartdirectly and is ADR-0021 aware::2435— the rung that relays the block intoListView(inside thefullSchemaliteral at:2170), a hand-listed projection of exactly six keys:dataset,dimensionsandvalues— the whole ADR-0021 (#1890) authoring shape — are absent, as arecategoryField/valueField. The list is the pre-ADR-0021 key set, frozen. The active view's block also does not reachListViewunder its canonicalchart:key:fullSchemaspreadslistSchema(the OBJECT's list schema), soschema.chartat the ListView end is the object-level list's block, never the active view's.⇒ On the object-view route, a view that declares the ADR-0021 shape reaches
ListViewwith its binding stripped, andListViewcannot tell that from a view that declared nothing.Why this is load-bearing now
objectui#7544 gave
ListView.availableViewsa chart capability check: agridview that declares a chart block and whitelists['grid', 'chart']is offered the Chart toggle, and one that declares nothing is not. That gate asks the block it is handed. Through this relay an ADR-0021 block arrives as six undefined keys, so the gate correctly answers "nothing declared" about a view whose author declared everything — the toggle stays hidden and the author gets no diagnostic. The legacyxAxisField/yAxisFieldsspelling survives the relay and does resolve, so the two authoring shapes behave differently on this route for reasons that live entirely in this projection.Before objectui#7544 nothing downstream read those keys through this rung, which is why the gap was invisible.
What this is NOT
viewDefisRecord<string, any>, so a MISSING rung is invisible to tsc) and it explicitly disclaims the census: "Not a claim that a rung is missing today." This is a rung that EXISTS and narrows — a different failure mode of the same relay, and one a rung census would not report because the key is present.startDateField: 'due_date'/titleField: 'name'for views with nocalendar:block — the guess short-circuits ObjectCalendar's own refusal screen and piles every record on today #7029 / finding(views): the gantt and timeline branches still fabricate date-axis field names on all three faces — and app-shell's own #3129 note certifies them as already fixed #7070. Those are invented binding names on the FORCED path (xAxisKeyfloored to'name', the value to'value'). This is authored names being dropped before they arrive; no floor is involved.packages/plugin-listand lands the gate that this relay now feeds.Not verified here
Whether
InterfaceListPage(the other host that builds aListViewschema) has the same projection — it does not namechartat all in a grep of that file, which may mean it relays the block whole or does not relay it. Worth one reading before choosing the fix shape.Generated by Claude Code