Filed unassigned by the #10053 dev seat (session session_016gcKVsiywU9CcS96S5t9qD) as an out-of-scope finding hit while implementing that card. Observation class — recorded, not queued. Not fixed in #10270: the correct prose is not pinned by existing evidence (it needs a fresh cross-repo read-point measurement), so it fails the bounded-in-place test and gets its own card instead.
Observation
#10053 states that ElementButtonPropsSchema.icon and ObjectMetricPropsSchema.icon are "the LAST two icon slots indistinguishable-by-describe from the refused reference-rail key", and #10270 records read points for both. There is a third in the same file, in the same state:
packages/spec/src/ui/component.zod.ts:1003 (on origin/main at 68f65ff60), inside the strictObject arm of RecordHighlightsField:
icon: z.string().optional().describe('Icon name (lucide icon key)'),Same defect class as the two #10053 covers: the describe states only the vocabulary. "Icon name (lucide icon key)" is equally true of the page:headericon retired in #6946, which is refused precisely because no render path reads it. Nothing on the spec side separates the two verdicts.
Why the enumeration missed it
The #10053 enumeration appears to have walked the top-level *PropsSchema props bags. This one is nested a level deeper — it sits on a field entry inside a z.union arm of RecordHighlightsField, not on RecordHighlightsProps itself. Any repeat of the sweep that walks only component props bags will miss it the same way, which is the part worth recording: the enumeration method, not just the key.
Not measured here
Deliberately. Whether this key is live is exactly the question, and answering it means measuring objectui's RecordDetailsRenderer / HeaderHighlight path at the current pin — the work this finding exists to schedule, not to pre-empt. Note the surrounding docblock at :1005-1010 already records that the renderer's HeaderHighlight gate reads a sibling key on the same entry, so a read point for icon is plausible but unconfirmed.
⚠️ Whoever picks this up: measure at .objectui-sha as it reads that day. It is 9a3daf8d37ad973a621e5edd276fe32467f90684 as of this filing (#10137 moved it), not the 82a94170c the #9881/#9972 records cite — see the sibling finding on those stale citations.
Dedup checked: searched open and closed issues for this key, for record:highlights icon, and for the component.zod.ts icon-describe phrasing — #9881 (closed), #9972 (closed) and #10053 (open) match the class, and none covers this key.
Backlink: #10053.
Filed unassigned by the #10053 dev seat (session
session_016gcKVsiywU9CcS96S5t9qD) as an out-of-scope finding hit while implementing that card. Observation class — recorded, not queued. Not fixed in #10270: the correct prose is not pinned by existing evidence (it needs a fresh cross-repo read-point measurement), so it fails the bounded-in-place test and gets its own card instead.Observation
#10053 states that
ElementButtonPropsSchema.iconandObjectMetricPropsSchema.iconare "the LAST two icon slots indistinguishable-by-describe from the refused reference-rail key", and #10270 records read points for both. There is a third in the same file, in the same state:packages/spec/src/ui/component.zod.ts:1003(onorigin/mainat68f65ff60), inside thestrictObjectarm ofRecordHighlightsField:Same defect class as the two #10053 covers: the describe states only the vocabulary. "Icon name (lucide icon key)" is equally true of the
page:headericonretired in #6946, which is refused precisely because no render path reads it. Nothing on the spec side separates the two verdicts.Why the enumeration missed it
The #10053 enumeration appears to have walked the top-level
*PropsSchemaprops bags. This one is nested a level deeper — it sits on a field entry inside az.unionarm ofRecordHighlightsField, not onRecordHighlightsPropsitself. Any repeat of the sweep that walks only component props bags will miss it the same way, which is the part worth recording: the enumeration method, not just the key.Not measured here
Deliberately. Whether this key is live is exactly the question, and answering it means measuring objectui's
RecordDetailsRenderer/HeaderHighlightpath at the current pin — the work this finding exists to schedule, not to pre-empt. Note the surrounding docblock at:1005-1010already records that the renderer'sHeaderHighlightgate reads a sibling key on the same entry, so a read point foriconis plausible but unconfirmed..objectui-shaas it reads that day. It is9a3daf8d37ad973a621e5edd276fe32467f90684as of this filing (#10137 moved it), not the82a94170cthe #9881/#9972 records cite — see the sibling finding on those stale citations.Dedup checked: searched open and closed issues for this key, for
record:highlightsicon, and for thecomponent.zod.tsicon-describe phrasing — #9881 (closed), #9972 (closed) and #10053 (open) match the class, and none covers this key.Backlink: #10053.