Repository navigation
record:highlights field icon is normalized by the renderer and then drawn by nothing at the pin — a possible #8691-class dead key #10054
Description
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:68normalizes the authored shape and carriesiconthrough:icon: f?.icon.- The normalized fields go to
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:tabs describe; the enumeration was in scope, a full liveness verdict was not. Specifically unverified:
- whether any consumer of
useRegisterHighlightFields(registered throughpackages/react/src/context/RecordContext.tsx) draws the icon outsideplugin-detail—app-shellwas 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
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 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.
Activity
os-zhuang commentedon Aug 20, 2026
Triage (half-state heal — the card had
domain:specbut no pm state):pm:queue, type Task. Measurement-first framing per the card's own honesty: the premise is "no read path found in plugin-detail at the pin", NOT "measured dead" — the dispatch's first job is closing the unswept surfaces (app-shell consumers ofuseRegisterHighlightFields, Studio block designer authorability, showcase visibility). Then exactly one of: (a) a read point exists ⇒ land the read-point describe à la #9881/#9972 and close; (b) measured dead ⇒ ADR-0049 enforce-or-remove via the ADR-0087 retirement flow, which touches the union's own describe that advertises the key — that arm narrows the authorable surface,Clause-②: yes, contract-review tier.premise_still_valid: falsewith the read point named is a good deliverable.Generated by Claude Code
os-zhuang commentedon Aug 21, 2026
Maintainer ruling (2026-08-21, live PM chat — recorded by the triage seat)
Verbatim (untranslated): 「其他接受」 — accepting the triage recommendation for this card: option A. The freshness gate confirms the premise is already closed: the 2026-08-20 measurement run closed all three previously-unmeasured surfaces and found
RecordHighlightsField.iconmeasured dead at the current pin (zero read points — structurally unable to traveluseRegisterHighlightFields; not designer-publishable —field-listinput typedstring[]; zero in-tree producers), while advertised in six author-facing surfaces. So the ruling executes directly as the retirement.State:
needs-user-decision→pm:queue(domain:spec), dispatchable.Dispatch notes: ADR-0087 retirement under the
spec-property-retirementplaybook. Clause-②: yes (narrows the authorable surface; an authorediconbecomes a namedunrecognized_keysrefusal at publish) — dispatch at the contract-review tier per the census ACCEPT's own note (claude-fable-5). Scope per the census: dropiconfrom the object arm + correct the six advertisements (union describecomponent.zod.ts:1013,RecordHighlightsProps.fieldsdescribe:1021, objectuiplugin-detail/src/index.tsxinput description,packages/lint/src/zod-issue-format.ts:25, regencontent/docs/references/ui/component.mdx:554/:589). The objectui-side advertisement edit follows the cross-repo rule (consuming-repo follow-up card if not deliverable in the same change). Recorded confidence gap stands: out-of-tree customer apps cannot be enumerated — the retirement's loud refusal is itself the mitigation.Generated by Claude Code
feat(spec): retire `record:highlights` highlight-field `icon` — adver…
docs(releases): name 17.2.0 as the current v17 series
docs(releases): name 17.2.0 as the current v17 series (objectstack-ai…
fix(spec): the protocol 16 → 17 conversion summaries and three descri…
fix(spec): the protocol 17 → 18 conversion summaries state each decis…