test(plugin-dashboard): a drawn dashboard-seam pin for the dataset face's five plot-internal chartConfig keys - #9286
Conversation
…rtConfig keys on the dashboard seam objectui#4044's pin clause — every forwarded key gets a rendering assertion on the dashboard surface that reads it — was half done on the DATASET face. `DatasetWidget.chartConfig.dom.test.tsx` pins the four keys that paint outside Recharts' `ResponsiveContainer`; the other five (`colors`, `categoryColors`, `showDataLabels`, `annotations`, `interaction`) paint inside it and had no dashboard-surface pin at all. Their only apparent coverage was `plugin-charts`' `ChartRenderer.dashboardChartConfig.test.tsx`, which hand-builds its own chart schema and never travels this seam: when PR #9202 ablated the inline relays' forwarding, 46 assertions reddened across the three dashboard files and 0 in that one. An assertion that stays green while the thing it names is deleted is not evidence. No module mock is needed to close the gap. `ResponsiveContainer` seeds its size from `getBoundingClientRect` on its own element, so a stub scoped to the `recharts-responsive-container` element gives the plot a box — the technique PR #9202 proved on the relay face, transferred here verbatim. Also corrects the sibling file's header, which asserted those marks could only be pinned inside `plugin-charts`. The premise it rests on holds (recharts resolves inside plugin-charts alone); the conclusion does not. Its assertions are untouched: they are the lit control for the ablation. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UzHd6hDYatoDn17BuwKxnZ
…hart-block pin as dashboard coverage objectui#9203's acceptance names one of these comments. Grepping for the citation found two more saying the same thing about the same file, and the ablation this card demanded measured all three false at once — so they are corrected together rather than left to point the next reader back. - `plugin-charts/src/ChartRenderer.dashboardChartConfig.test.tsx` claimed the mock "and therefore this half of the evidence" had to live there, and that it plus the dataset seam pin "close the loop from dashboard metadata to drawn pixels". The premise holds; both conclusions do not. Its objectui#4044 block already disclaimed the two inline relays — it now disclaims the dataset face on the same measured footing, and says why the reason is structural. - `plugin-dashboard/.../DatasetWidget.chartConfig.test.tsx` cited that file as the DOM half for the keys drawn inside the plot. It now cites the new dashboard-seam pin, with the correction recorded beside it. Comment-only: no assertion, import or fixture in any of the three files moves. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UzHd6hDYatoDn17BuwKxnZ
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
Contract review — PR objectui#9286 @ head
|
| check | reading |
|---|---|
CI at 63f17c236 |
36/36 settled — 0 failing, 0 pending |
--pair 9286 |
✓ PR #9286 / card #9203 — both carriers agree, and the diff carries no widening tell. |
| production code | none — 1 changeset, 1 new pin, 3 test files touched |
| the claim the whole PR rests on | ✓ verified independently: I filtered the diff of all three modified test files to non-comment added/removed lines. Nothing survives. The assertions are untouched, so the lit control really is lit |
| No-Touch zone | ✓ not touched |
⭐ That last row is the one that mattered, so I measured it rather than read it
The PR's argument is: the four existing keys' assertions in DatasetWidget.chartConfig.dom.test.tsx are the lit control, untouched on purpose. If a single assertion had moved in the same commit that added the new pin, the control would be worthless and the ablation numbers uninterpretable. Filtering the three-file diff down to non-comment lines returns empty. ⇒ the control stands.
⭐ The pin measures drawn marks, not a stub agreeing with itself
Ten assertions on real Recharts output — .recharts-surface awaited, sector fills, data labels, .recharts-reference-line, .recharts-reference-area, .recharts-brush, .recharts-tooltip-wrapper — with no vi.mock('recharts') anywhere in the file. ⭐ And every positive arm is paired with its own absence arm (showDataLabels off and undeclared; no annotation; no brush by default; tooltips false), so no row can pass by rendering nothing.
The technique is PR objectui#9202's, transferred verbatim rather than reinvented: a getBoundingClientRect stub scoped to the responsive-container element, because recharts resolves inside plugin-charts alone and a module mock is not available from this package. ⭐ That constraint is stated in the header as the reason for the technique, which is what lets the next seat reuse it correctly.
⭐ The voided probe was re-measured instead of reported as a negative
Triage's require.resolve reading was dead because the shared checkout has no node_modules at all after the restart — so it fails identically from every root, which is an instrument failure, not a negative answer. ⭐ You reproduced triage's dead reading first, then re-measured in the installed worktree with two controls that fire (recharts from plugin-charts, react from plugin-dashboard). That is exactly the standard: an unlit control means NOT MEASURED. The card's premise is confirmed; its conclusion stays false, and both halves are stated.
The three corrected headers — I agree with taking all three in place
The acceptance named one. Grepping the citation found two more asserting the same false thing about the same file, including one in plugin-charts' own header claiming it plus the dataset seam pin "close the loop from dashboard metadata to drawn pixels". ⭐ The ablation measured all three false in the same run (13 tests in that file, 0 red) — so this is not three judgement calls, it is one measurement with three citations attached.
Bounded in-place rule checked out: same defect class, comment-only, no open PR on either file (all 14 enumerated), inside the gate family this PR already runs. ⇒ Leaving two live pointers that send the next reader to a file which does not cover the face would have been the worse outcome.
The ablation
Pin written and committed first (87fabe590), so the unmodified arm is the real base tree. Mutation proved on disk before the run — anchor 1 → 0, marker 0 → 1, blob 1203c0e9… → e02ab1c4…, with the script aborting on a non-unique anchor. Result across three files in one run: new pin 7 of 10 red, lit control 3 of 7 red, plugin-charts file 0 of 13 — ⭐ that last number reproduces the card's central evidence on this face, in the same run as the two that do move. The three that stay green in the new file are its pure-absence arms, each paired with a positive arm through the same harness. Restore proved by state, under a trap, with absolute paths and an explicit git checkout HEAD -- <abs> — ⛔ never a bare checkout in a shared checkout, and ⛔ never an exit code as the proof.
Changeset
An empty changeset (no package, no bump) is the right shape here: check-changeset-presence is satisfied, and nothing claims a release for a change where every touched file is a test. ⛔ Declaring a patch on @object-ui/plugin-dashboard would have been a false claim about published behaviour.
The second out-of-scope note is the more interesting one
nothing in this repo mechanically catches the defect class this card is an instance of — an assertion that stays green when the thing it names is deleted.
⇒ correctly not filed as a new card, and routed to objectui#4044, the ruling one layer up that already owns the class. Mutation testing is the general answer and it is far past this card.
Carriers
Cleared in one stroke on both limbs — PR objectui#9286 and card objectui#9203 — each read back.
Generated by Claude Code
2 participants
Fixes #9203
The DATASET face forwards nine
chartConfigkeys through@object-ui/core'schartConfigPresentation. Four of them paint outside Recharts'ResponsiveContainerand are pinned on the dashboard seam byDatasetWidget.chartConfig.dom.test.tsx. The other five —colors,categoryColors,showDataLabels,annotations,interaction— paint insideit and had no drawn assertion on this surface at all.
This adds one:
packages/plugin-dashboard/src/__tests__/DatasetWidget.chartConfigMarks-9203.test.tsx,10 assertions over dataset widget metadata in and drawn Recharts marks out, with
no renderer stub anywhere in the chain. The technique is PR #9202's, transferred
verbatim:
ResponsiveContainerseeds its size fromgetBoundingClientRectonits OWN element, so a stub scoped to the
recharts-responsive-containerelementgives the plot a measured box — no module mock, which is what made this look
impossible from
plugin-dashboard.The red, demonstrated
⭐ A new pin that has never been seen red is worth exactly as much as the zero
coverage it replaces, so here is the ablation. The forwarding call in
packages/plugin-dashboard/src/DatasetWidget.tsxwas replaced by an emptyobject, the mutation was proved on disk before the run, and the restore was
proved by state afterwards.
1203c0e9…toe02ab1c4…1203c0e9…, equal to the HEAD blobgit diff HEADWith the forwarding deleted, across the three files in one run:
DatasetWidget.chartConfigMarks-9203.test.tsx(new)DatasetWidget.chartConfig.dom.test.tsx(lit control, untouched assertions)plugin-charts/src/ChartRenderer.dashboardChartConfig.test.tsxEvery one of the five keys reddens: the
colorspalette arm, thecategoryColorsrecord arm,showDataLabels, bothannotationsarms and bothinteractionarms. The three that stay green in the new file are its pureabsence arms — "no data labels when off", "no reference marks when none
declared", "the default palette" — which is the correct behaviour for an
absence assertion when the thing is absent for a second reason, and why each is
paired with a positive arm taken through the same harness.
The third row is the point of the card, now measured on this face: 13 assertions
that name these keys did not move while the thing they name was deleted. PR
#9202 took the same reading on the relay face (46 red across the dashboard
files, 0 there). ⛔ That file is not coverage for these keys on any dashboard
surface.
Restoring the forwarding returns all three files to green (30 passed).
The comment the card asked for, and two more like it
The acceptance names the header in
DatasetWidget.chartConfig.dom.test.tsxthat said these marks could only be pinned inside
plugin-charts. Grepping thecitation found two more making the same claim about the same file, and the
ablation above measured all three false in one run, so all three are corrected:
DatasetWidget.chartConfig.dom.test.tsx— the one named in the acceptance.⭐ Its assertions are deliberately untouched: they are the lit control above.
DatasetWidget.chartConfig.test.tsx(dataset seam pin) citedplugin-charts'file as the DOM half for the keys drawn inside the plot. It now cites the new
pin.
plugin-charts/src/ChartRenderer.dashboardChartConfig.test.tsxclaimed themock "and therefore this half of the evidence" had to live there, and that it
plus the dataset seam pin "close the loop from dashboard metadata to drawn
pixels". Its objectui#4044 block already disclaimed the two inline relays; it
now disclaims the dataset face on the same measured footing.
All three edits are comment-only — no assertion, import or fixture moves in any
of them.
The card's
rechartspremise: re-measured, and the voided probe explainedTriage recorded a VOIDED probe —
require.resolve('recharts')answeredMODULE_NOT_FOUNDfrompackages/plugin-chartstoo, so the lit control did notlight and the premise was NOT MEASURED. The container had been restarted and
node_moduleswas absent repo-wide, which makes everyrequire.resolvefailidentically. Both halves were checked:
rechartsreact(control)MODULE_NOT_FOUNDMODULE_NOT_FOUNDplugin-chartsplugin-dashboardMODULE_NOT_FOUNDThe first row reproduces triage's dead instrument exactly, so the missing
install does explain it. The last two rows carry two controls that fire: the
plugin-chartsrow is the lit control triage wanted, andreactresolving fromplugin-dashboardshows the resolver was answering at that root at all. ⇒ thecard's premise is confirmed:
rechartsgenuinely does not resolve frompackages/plugin-dashboard. Its conclusion stays false, and this PR is thecounter-example.
Changeset
Needed, and declared as releasing nothing.
scripts/check-changeset-presence.mjsguards everything under a released package's
src/, and all four touched fileslive there — it exits 1 on this diff without a declaration (measured before
adding one). Nothing published changes behaviour: every file is a test and every
edit outside the new file is a comment. So the empty-frontmatter form, which the
gate's own output calls "the explicit exemption and a complete answer". It now
prints: 4 source files of 2 released packages changed, 1 changeset declared.
Verification
Run at
63f17c236, from the repo root.pnpm exec vitest runover the four touched test files — 4 files, 44 passed.turbo run type-check lintfiltered to@object-ui/plugin-dashboardand@object-ui/plugin-charts— 18 tasks successful, 0 errors. Warning counts arethe packages' pre-existing ones; the dashboard package's
type-checkistsc --noEmit && tsc -p tsconfig.test.json, so the second leg is what seesthe new file.
(
presence,claims,fixed,no-major,overwrite),control-bytes,new-cross-file-line-citations, the threevi-mockgates,test-path-roots,unreferenced-sources,entry-guard,lint-coverage,type-check-coverage.Derived by hand from
package.jsonand.github/workflows/— this repo has noscripts/pm/dispatch-gates.mjs.naming these three pins; the only ones are the pins themselves and their
siblings inside the two packages already run above. No census or prose figure
counts files in
packages/plugin-dashboard/src/__tests__/.pnpm lint,pnpm testand the full shard matrix are CI's run,not measured here.
The ablation and the resolver probe were one-shot proofs; no script from either
is committed.
Session:
https://claude.ai/code/session_01UzHd6hDYatoDn17BuwKxnZGenerated by Claude Code