Filed unassigned by the #9972 dev seat (session session_01URCaKuNTuK3BKJvwqM74QU) as an out-of-scope finding hit while enumerating the remaining icon slots in packages/spec/src/ui/component.zod.ts. Unlabeled for PM triage: unlike its sibling finding, this one is a candidate defect, not a prose gap — but the measurement below is deliberately partial, so the premise needs confirming before anything is done about it.
Observation
RecordHighlightsField.icon (packages/spec/src/ui/component.zod.ts, inside the object arm of the union) is declared describe('Icon name (lucide icon key)'), and the union's own describe advertises it: Highlight field: bare name, or {name,label?,icon?,type?,readonly?}.
At .objectui-sha = 82a94170c (read via git show 82a94170c:, not at the checkout's HEAD):
packages/plugin-detail/src/renderers/record-highlights.tsx:68 normalizes the authored shape and carries icon through: icon: f?.icon.- The normalized fields go to
HeaderHighlight (imported at :17) and to useRegisterHighlightFields. Grepping packages/plugin-detail/src at that pin for a per-field icon read finds none: HeaderHighlight.tsx's only icon occurrence is size="icon" on a button. The chip has no icon slot.
That is the exact shape #8691 recorded for the reference-rail entry icon, which was refused on the strength of it: "the renderer declares it in its TS interface and the page synthesizer emits it, but no render path reads it — the card has no icon slot, so a declared icon draws nothing."
What was NOT measured — read this before acting
This seat's card was the page:tabs describe; the enumeration was in scope, a full liveness verdict was not. Specifically unverified:
- whether any consumer of
useRegisterHighlightFields (registered through packages/react/src/context/RecordContext.tsx) draws the icon outside plugin-detail — app-shell was not swept; - whether the Studio block designer publishes the key as an authorable input, which would make it an author-facing promise regardless of the render path;
- whether an authored
icon is visible anywhere in the running showcase.
So the premise here is "no read path found in the obvious package", not "measured dead". A first-touch grading that closes this premise-overtaken with the missing read point named would be a good outcome.
If it holds
ADR-0049 enforce-or-remove, the same route the rail's icon took: either the key is retired via ADR-0087 (with the union's own describe corrected, since it advertises the key to authors), or a read path exists and the key gets the read-point describe #9881/#9972 landed for the container icons. The intermediate state — declared, normalized, drawn by nothing, described as if live — is the one that costs an author silently.
Dedup checked: searched open and closed issues for record:highlights icon, for highlight-field liveness, and for the #8691 dead-key phrasing — nothing matches this key.
Backlink: #9972. Sibling finding on the same enumeration: #10053.
Filed unassigned by the #9972 dev seat (session
session_01URCaKuNTuK3BKJvwqM74QU) as an out-of-scope finding hit while enumerating the remainingiconslots inpackages/spec/src/ui/component.zod.ts. Unlabeled for PM triage: unlike its sibling finding, this one is a candidate defect, not a prose gap — but the measurement below is deliberately partial, so the premise needs confirming before anything is done about it.Observation
RecordHighlightsField.icon(packages/spec/src/ui/component.zod.ts, inside the object arm of the union) is declareddescribe('Icon name (lucide icon key)'), and the union's own describe advertises it:Highlight field: bare name, or {name,label?,icon?,type?,readonly?}.At
.objectui-sha=82a94170c(read viagit show 82a94170c:, not at the checkout's HEAD):packages/plugin-detail/src/renderers/record-highlights.tsx:68normalizes the authored shape and carriesiconthrough:icon: f?.icon.HeaderHighlight(imported at:17) and touseRegisterHighlightFields. Greppingpackages/plugin-detail/srcat that pin for a per-field icon read finds none:HeaderHighlight.tsx's onlyiconoccurrence issize="icon"on a button. The chip has no icon slot.That is the exact shape #8691 recorded for the reference-rail entry
icon, which was refused on the strength of it: "the renderer declares it in its TS interface and the page synthesizer emits it, but no render path reads it — the card has no icon slot, so a declared icon draws nothing."What was NOT measured — read this before acting
This seat's card was the
page:tabsdescribe; the enumeration was in scope, a full liveness verdict was not. Specifically unverified:useRegisterHighlightFields(registered throughpackages/react/src/context/RecordContext.tsx) draws the icon outsideplugin-detail—app-shellwas not swept;iconis visible anywhere in the running showcase.So the premise here is "no read path found in the obvious package", not "measured dead". A first-touch grading that closes this premise-overtaken with the missing read point named would be a good outcome.
If it holds
ADR-0049 enforce-or-remove, the same route the rail's
icontook: either the key is retired via ADR-0087 (with the union's own describe corrected, since it advertises the key to authors), or a read path exists and the key gets the read-point describe #9881/#9972 landed for the container icons. The intermediate state — declared, normalized, drawn by nothing, described as if live — is the one that costs an author silently.Dedup checked: searched open and closed issues for
record:highlightsicon, for highlight-field liveness, and for the #8691 dead-key phrasing — nothing matches this key.Backlink: #9972. Sibling finding on the same enumeration: #10053.