Converge the empty-state defaults onto `DataEmptyState` — four packages now answer "is it broken or is it young" four different ways, and two rulings just fixed two of them locally

[os-warren]

Filed by the domain:ui seat (session session_012wwHa4aaFybxXrfmfHioDM) as the deliberately deferred convergence half of two maintainer rulings that landed within ten minutes of each other:

• Flip the empty-section DEFAULT: sparse records keep the section skeleton — stop forcing hideEmpty ?? true over DetailSection's own stated heuristic #7064 / PR fix(plugin-detail): let DetailSection's heuristic own the empty-section default #7123 — eeb6c2f2b, record-detail empty sections (hotcrm#1247 ruling)
• Dashboard/analytics widgets render a bare 「暂无数据行」 that is indistinguishable from a load failure — make the DEFAULT empty state self-explaining, platform-wide #7063 / PR fix(plugin-dashboard,i18n): a self-explaining default empty state for dashboard widgets #7124 — 220c18d05, dashboard widget empty state (hotcrm#1212 ruling)

Both rest on the same principle — objectstack#13848: apps are simplified business implementations; uniform behaviour belongs to the platform, and per-widget/per-section authored copy is the per-app tax being ruled against.

⭐ Why this card exists rather than having been done inside one of those PRs

DataEmptyState (packages/components/src/custom/view-states.tsx) is already consumed by four packages: plugin-list, plugin-kanban, plugin-dashboard and plugin-detail. Its title default is literally 'No data'.

⇒ Changing its defaults would have been a smaller diff that repaired both rulings at once, and #7124's implementer identified exactly that and declined it on purpose, consuming the primitive unchanged and recording the reason in the new component's file header.

That was the correct call, and it is the reason this card is filed rather than lost: the two rulings were dispatched in parallel to two agents who could not see each other's reasoning, and both dispatch orders explicitly forbade designing a cross-surface abstraction, requiring stop-and-report instead. ⚠️ A shared abstraction designed simultaneously by two agents is worse than two honest local fixes — and it would have been invisible as a problem, because the diff would have looked elegant.

Both local fixes have now landed. The precondition for doing it properly, once, is satisfied.

The measured spread — four packages, four answers

surface	what an empty result renders	state
plugin-detail record sections	heading + labels + em-dash placeholders, heuristic-owned	✅ just ruled and fixed (#7064)
plugin-dashboard dataset/table/pivot widgets	WidgetEmptyState — role="status", title + explanation, names the data source	✅ just ruled and fixed (#7063)
plugin-list, plugin-kanban	DataEmptyState defaults — terse, unexamined against either ruling	⚠️ unmeasured
plugin-charts ObjectChart	⛔ no empty branch at all — a bare chart frame	🟡 filed as #7130

⇒ The two rulings did not establish a platform-wide answer; they established it on two surfaces. This card is about whether the other two should follow, and whether the shared primitive should carry the answer.

⛔ What this card must NOT do

• ⛔ Do not re-litigate Dashboard/analytics widgets render a bare 「暂无数据行」 that is indistinguishable from a load failure — make the DEFAULT empty state self-explaining, platform-wide #7063 or Flip the empty-section DEFAULT: sparse records keep the section skeleton — stop forcing hideEmpty ?? true over DetailSection's own stated heuristic #7064. Both are ruled and landed. If convergence would change either surface's behaviour, that is a new question for the maintainer, not a refactor.
• ⛔ Do not assume the answer is "hoist it into DataEmptyState". That is the hypothesis, not the ruling. A list and a record-detail section and a chart may legitimately want different empty states — finding(plugin-charts): ObjectChart has NO empty branch at all — an empty result draws a bare chart frame, the fourth distinct answer on this surface to "is it broken or is it young" #7130 makes exactly that argument for charts (axes may already be self-describing).
• ⛔ Do not widen any authoring surface. Both rulings closed the per-app-compensation route; a convergence that adds an emptyState key to a new surface would reopen it one card later. ⚠️ It would also be clause ②, needing a contract review the exhausted Fable 5 quota currently blocks — built-but-unlandable, the state finding(types/plugin-charts): the static ChartSchema node's two data keys are declared-but-unread — ChartDataSeries.data is required and never read, and categories is read as a SERIES list, not axis labels #6896 / PR feat(types)!: retire ChartDataSeries.data, correct categories' prose (#6896) #7111 is in.

Suggested first step — measurement, not refactor

Render all four surfaces' empty states side by side and judge them against the two rulings' own stated properties:

1. distinguishable from a load failure at a glance (role="status" vs role="alert" is the structural test fix(plugin-dashboard,i18n): a self-explaining default empty state for dashboard widgets #7124 used);
2. self-describing without authored copy.

Then answer: does the shared primitive carry those properties, or does each surface legitimately differ? ⭐ "They legitimately differ, here is the evidence" is a fully valid outcome — close it measured-and-declined.

Sequencing

⚠️ packages/components is consumed by all four packages, so a defaults change there is broad-blast. Check the packages/app-shell PR backlog before starting.

Refs: #7063 · #7064 · PR #7123 · PR #7124 · #7130 (ObjectChart) · #7125 (dead keys from #7124) · objectstack#13848 · hotcrm#1212 · hotcrm#1247.

[os-warren]

🔒 Claimed — domain:ui execution seat (objectui)

• Session: session_012wwHa4aaFybxXrfmfHioDM · Branch: claude/issue-7132-empty-state-convergence
• Build tier: opus (⚠️ Fable 5 quota exhausted; the exemption lowers the build tier only)

✅ Unblocked — and by the mechanism this card was written to protect

This card exists because #7124's implementer identified changing DataEmptyState's defaults as a smaller fix spanning both rulings, and declined it, because two agents designing one cross-surface abstraction in parallel is worse than two honest local fixes. Both local fixes have since landed (eeb6c2f2b, 220c18d05).

⭐ The fence held a second time, unprompted. #7130 (ObjectChart) was dispatched with the same instruction — if the answer is "promote the seam to a shared package", stop and report here. Its implementer measured four package-boundary options and reported promoted_to_7132: false, taking the one that changes nothing structural: consume DataEmptyState, which was already shared and already a declared dependency. ⇒ Nothing has been pre-decided for this card by either sibling.

⚠️ It is now FIVE call sites, not four

PR #7139 (#7130) is in flight and adds ObjectChart as a fifth consumer of DataEmptyState, deliberately so that it "collapses with the other four when #7132 converges the defaults." ⛔ Do not treat that as a decision already taken — it is a call site placed to be convergeable, not an argument that convergence is right.

Measure on main, and account for #7139 landing during the work. ⛔ Do not edit packages/plugin-charts — that is its surface.

The fences from the card, restated as binding

• ⛔ Do not re-litigate Dashboard/analytics widgets render a bare 「暂无数据行」 that is indistinguishable from a load failure — make the DEFAULT empty state self-explaining, platform-wide #7063 or Flip the empty-section DEFAULT: sparse records keep the section skeleton — stop forcing hideEmpty ?? true over DetailSection's own stated heuristic #7064. Both ruled and landed. If convergence would change either surface's behaviour, that is a new question for the maintainer, not a refactor.
• ⛔ Do not assume the answer is "hoist it into DataEmptyState". That is the hypothesis this card tests, not its conclusion.
• ⛔ Do not widen any authoring surface. Both rulings closed the per-app-compensation route; adding an emptyState key to a new surface would reopen it one card later — and it is clause ②, needing a review the exhausted quota blocks. Built-but-unlandable, the state finding(types/plugin-charts): the static ChartSchema node's two data keys are declared-but-unread — ChartDataSeries.data is required and never read, and categories is read as a SERIES list, not axis labels #6896 / PR feat(types)!: retire ChartDataSeries.data, correct categories' prose (#6896) #7111 has been in all session.
• ⭐ "They legitimately differ, here is the evidence" is a FULL PASS. Close it measured-and-declined and I will accept it as one. finding(plugin-charts): ObjectChart has NO empty branch at all — an empty result draws a bare chart frame, the fourth distinct answer on this surface to "is it broken or is it young" #7130 was dispatched on exactly those terms and its measurement is what turned a plausible decline into a warranted fix — the reverse outcome is equally valid.

⚠️ One datum that already argues against naive hoisting: #7124 measured that metric/KPI widgets deliberately render 0 over an empty dataset rather than an empty state, because a KPI reading "no data" reads as broken. DatasetWidget.tsx:726-728 says so in the code. At least one consumer family legitimately wants different behaviour. Whether that generalises is what you are measuring.

---

Generated by Claude Code