Found while running the shipped-dashboard fixture pass for #14275 (measuring validate-widget-bindings's dashboard-filter branch before/after). Unrelated to that change: the finding is identical on the merge base and on the branch, and belongs to a different rule.
What was measured
validateWidgetBindings run over a stack assembled from @objectstack/platform-objects (its exported objects + SystemOverviewDatasets + SystemOverviewDashboard) reports exactly two findings, both pre-existing:
[chart-config-missing] dashboard "system_overview" > widget "widget_events_by_type"
chart-type widget ('pie') has no chartConfig - the renderer cannot determine which
measure to plot, so the series renders empty.
[chart-config-missing] dashboard "system_overview" > widget "widget_events_by_user"
chart-type widget ('bar') has no chartConfig - the renderer cannot determine which
measure to plot, so the series renders empty.
Source: packages/platform-objects/src/apps/dashboards/system_overview.dashboard.ts.
Why it is worth a card rather than a shrug
chart-config-missing is warning-tier, so the build stays green and nothing surfaces this. But the rule exists because of the consequence it names, and this is our OWN shipped metadata tripping it: the platform's Setup dashboard ships a pie and a bar whose renderer, by that rule's account, has no measure mapping to plot. That is the declared-vs-delivered shape Prime Directive #10 is about, one layer in from a customer app — and every customer who opens Setup sees it before they see any dashboard they wrote.
Two outcomes are both fine, and which one is right is exactly the question:
- The rule is right and the widgets are wrong - add
chartConfig with xAxis.field on the dimension and yAxis[].field on the measure name (post-ADR-0021 the result rows are keyed by measure NAME), and the tiles start plotting.
- The rule over-reaches for a single-measure widget - if the renderer has a defensible default when a widget selects exactly one measure and one dimension, then
chart-config-missing is producing a false finding on valid metadata, which is the ADR-0072 D1 cost the whole family is trying to avoid. In that case the fix is in the rule (exempt the unambiguous shape), not in the dashboard.
Deciding needs someone to look at what DatasetWidget actually does with a chartConfig-less pie, which is objectui's side and outside the card I was on.
Repro
Both widgets are visible in the source; to reproduce the diagnostic, run validateWidgetBindings over a stack carrying SystemOverviewDashboard and SystemOverviewDatasets plus the platform objects.
Filed unassigned and unlabeled for triage - not started, no branch.
Generated by Claude Code
Found while running the shipped-dashboard fixture pass for #14275 (measuring
validate-widget-bindings's dashboard-filter branch before/after). Unrelated to that change: the finding is identical on the merge base and on the branch, and belongs to a different rule.What was measured
validateWidgetBindingsrun over a stack assembled from@objectstack/platform-objects(its exported objects +SystemOverviewDatasets+SystemOverviewDashboard) reports exactly two findings, both pre-existing:Source:
packages/platform-objects/src/apps/dashboards/system_overview.dashboard.ts.Why it is worth a card rather than a shrug
chart-config-missingis warning-tier, so the build stays green and nothing surfaces this. But the rule exists because of the consequence it names, and this is our OWN shipped metadata tripping it: the platform's Setup dashboard ships a pie and a bar whose renderer, by that rule's account, has no measure mapping to plot. That is the declared-vs-delivered shape Prime Directive #10 is about, one layer in from a customer app — and every customer who opens Setup sees it before they see any dashboard they wrote.Two outcomes are both fine, and which one is right is exactly the question:
chartConfigwithxAxis.fieldon the dimension andyAxis[].fieldon the measure name (post-ADR-0021 the result rows are keyed by measure NAME), and the tiles start plotting.chart-config-missingis producing a false finding on valid metadata, which is the ADR-0072 D1 cost the whole family is trying to avoid. In that case the fix is in the rule (exempt the unambiguous shape), not in the dashboard.Deciding needs someone to look at what
DatasetWidgetactually does with achartConfig-less pie, which is objectui's side and outside the card I was on.Repro
Both widgets are visible in the source; to reproduce the diagnostic, run
validateWidgetBindingsover a stack carryingSystemOverviewDashboardandSystemOverviewDatasetsplus the platform objects.Filed unassigned and unlabeled for triage - not started, no branch.
Generated by Claude Code