Observation-class finding, recorded while widening the DOM-leak sweep in #5574 (PR #5629). Not fixed there — that card's job was reaching the family at all, and this is a depth-of-fixture gap the widening created rather than one it inherited.
The gap
packages/app-shell/src/__tests__/widget-dom-leak-sweep.test.tsx now sweeps all 158 registry-reachable types from packages/components/src/renderers/**. Three of them reach their readiness selector through a placeholder branch that returns before the element the renderer spreads onto is ever constructed:
| target | source | what actually rendered |
|---|
element:definition-list | basic/data-list.tsx:56-57 | No details — items.length === 0, early return |
element:repeater | basic/data-list.tsx:157 | No records — the sweep's FAKE_ADAPTER answers with no rows by design |
element:metadata_viewer | basic/metadata-viewer.tsx:100 | the amber not-found placeholder — the canary node names no resolvable metadata |
All three currently read clean, and PR #5629 records that reading as covering the placeholder branch only (READY_OVERRIDE_REASONS in that file, pinned two-way so the list cannot grow quietly).
Why it matters, and why it is not urgent
This is the trap-1 shape from that file's own docblock — "a lazy boundary answers with a skeleton" — in a different dress. A clean reading taken off a branch that structurally cannot spread says nothing about the branch that can. It is a phantom clean in waiting: not currently misleading anyone, because it is written down, but it is exactly the reading that would be misread as "these three converged" once the surrounding rows start disappearing.
Of the 16 phantom cleans that widening surfaced, 12 were removed by authoring a schema and 4 by adding a SidebarProvider host. These three are the residue: they need data, not schema, and FAKE_ADAPTER returning empty is load-bearing elsewhere in the file (it is what keeps every data-bound target on its real render path rather than an error state).
Suggested shape
Author items for element:definition-list (pure schema — no adapter involved, so this one is cheap). For element:repeater and element:metadata_viewer, either a per-target adapter override on Target, or a data-bearing fixture adapter used only by the targets that declare it. Re-measure the three; if a leak appears, it is a new ledger row rather than a new gate.
Whoever picks this up should confirm the leak set from a real render before changing any row — the whole discipline of that file is that a row records a measurement, never a prediction.
References
Observation-class finding, recorded while widening the DOM-leak sweep in #5574 (PR #5629). Not fixed there — that card's job was reaching the family at all, and this is a depth-of-fixture gap the widening created rather than one it inherited.
The gap
packages/app-shell/src/__tests__/widget-dom-leak-sweep.test.tsxnow sweeps all 158 registry-reachable types frompackages/components/src/renderers/**. Three of them reach their readiness selector through a placeholder branch that returns before the element the renderer spreads onto is ever constructed:element:definition-listbasic/data-list.tsx:56-57No details—items.length === 0, early returnelement:repeaterbasic/data-list.tsx:157No records— the sweep'sFAKE_ADAPTERanswers with no rows by designelement:metadata_viewerbasic/metadata-viewer.tsx:100All three currently read clean, and PR #5629 records that reading as covering the placeholder branch only (
READY_OVERRIDE_REASONSin that file, pinned two-way so the list cannot grow quietly).Why it matters, and why it is not urgent
This is the trap-1 shape from that file's own docblock — "a lazy boundary answers with a skeleton" — in a different dress. A clean reading taken off a branch that structurally cannot spread says nothing about the branch that can. It is a phantom clean in waiting: not currently misleading anyone, because it is written down, but it is exactly the reading that would be misread as "these three converged" once the surrounding rows start disappearing.
Of the 16 phantom cleans that widening surfaced, 12 were removed by authoring a schema and 4 by adding a
SidebarProviderhost. These three are the residue: they need data, not schema, andFAKE_ADAPTERreturning empty is load-bearing elsewhere in the file (it is what keeps every data-bound target on its real render path rather than an error state).Suggested shape
Author
itemsforelement:definition-list(pure schema — no adapter involved, so this one is cheap). Forelement:repeaterandelement:metadata_viewer, either a per-target adapter override onTarget, or a data-bearing fixture adapter used only by the targets that declare it. Re-measure the three; if a leak appears, it is a new ledger row rather than a new gate.Whoever picks this up should confirm the leak set from a real render before changing any row — the whole discipline of that file is that a row records a measurement, never a prediction.
References
packages/components/src/renderers/**— four layout/basic renderers still carry the unfixed spread #5574 / PR test(app-shell): widen the DOM-leak sweep topackages/componentsrenderers, with the first run's ledger #5629 — the widening, and where the three are recordedtoDomPropswhitelist stops atpackages/fields— SDUI widgets elsewhere still close their DOM leak by hand, if at all #4425 — the tracking card for the whitelist migrationpackages/app-shell/src/__tests__/widget-dom-leak-sweep.test.tsx—READY_OVERRIDE_REASONSpackages/components/src/renderers/basic/data-list.tsx,basic/metadata-viewer.tsx