Nothing checks that an `icon:` literal reaching a record-reading lucide resolver is a live `icons` key — four hand-copied resolvers, four local pins, no gate over the population

[os-sales]

Split out of #5622 (suggestion 2), where triage fenced it out of the repair deliberately: "That is a new gate over a new population, not a repair, and folding it in would turn a five-name fix into a gate-design card carrying its own evidence burden." Filed unassigned so it can be triaged on its own terms.

The class

lucide retires a spelling by dropping it from the runtime icons record while keeping it as a deprecated named export. A retired name therefore still imports, still type-checks, and still renders wherever it is used as a component — and resolves to null wherever it is used as a string, because the string lookups read that record. Nothing goes red in either direction.

This has now been repaired twice, in two different packages, by two different cards:

• ViewSwitcher renders NO icon for chart and gantt views: both icon names were dropped from lucide's icons record #5586 — chart / gantt rendered no icon in plugin-view's ViewSwitcher.
• Two more retired lucide spellings reach the icons-record resolver — edit in DetailView's mobile Edit action, smile as the icon renderer's own default — and only one of the four resolver copies is pinned #5622 — edit on DetailView's mobile Edit action, smile as the ui:icon renderer's own declared default, plus three component aliases in plugin-list and two retired fixture spellings in app-shell.

Both cards added a local resolvability pin. Neither could add one over the population, because there is no population — just four hand-copied toPascalCase + one-entry iconNameMap ({ Home: 'House' }) implementations, each with its own set of call sites:

resolver	reads
packages/components/src/renderers/action/resolve-icon.ts	icons record
packages/components/src/renderers/basic/icon.tsx	icons record
packages/plugin-list/src/components/TabBar.tsx	icons record
packages/plugin-view/src/ViewSwitcher.tsx	icons record
packages/app-shell/src/utils/getIcon.ts, packages/layout/src/NavigationRenderer.tsx	lucide-react/dynamic.mjs's iconNames

The two surfaces disagree about aliases, so the same icon: 'edit' renders correctly in the sidebar and renders nothing in an action bar.

What the gate would have to decide

Recorded because they are the design questions, not implementation detail — this is not a "just add a check" card:

1. What is the population? Every icon: string literal in packages/** / apps/** is 53 distinct names across 109 sites, and Two more retired lucide spellings reach the icons-record resolver — edit in DetailView's mobile Edit action, smile as the icon renderer's own default — and only one of the four resolver copies is pinned #5622's scan found 15 that are not record keys of which only 4 were defects. The other 11 are false positives of three distinct kinds — a differently-typed icon field holding a Tailwind class (text-amber-500 and eight siblings in app-shell/…/previews/AppNavCanvas.tsx), deliberate negative controls (not-a-real-icon), an authorable-keys fixture that is never resolved (chevron), and ComponentRegistry/schema type names that merely collide with lucide spellings (area-chart, bar-chart, line-chart, pie-chart, scatter-chart). A gate that cannot separate "reaches a record-reading resolver" from "is a string that looks like an icon name" is a gate that gets suppressed.
2. Which record does a given site read? The answer differs per resolver (table above), and a gate that checks the wrong one is worse than none: it would bless edit because the dynamic surface carries it.
3. Does it also cover imported COMPONENTS, not just strings? Two more retired lucide spellings reach the icons-record resolver — edit in DetailView's mobile Edit action, smile as the icon renderer's own default — and only one of the four resolver copies is pinned #5622 measured that Grid === Grid3x3, BarChart3 === ChartColumn, Edit === SquarePen, Smile === FaceSlightlySmiling, CheckCircle === CircleCheckBig and XCircle === CircleX are all true — a retired component alias is the very same object under a dead name, renders perfectly, and only record membership can see it. Both prior cards had to pin identifiers as well as strings.
4. Or is the real fix upstream of the gate — collapsing the four hand-copied resolvers into one shared helper, so there is a single place a check can attach and a single iconNameMap to maintain? That would make the gate small; it is also a bigger change than the gate.

⛔ Not the fix

Routing everything through the alias-tolerant getIcon is not the answer and should be ruled out up front: it silently substitutes the Database glyph for anything it cannot resolve, so it trades a no-icon failure for a wrong-icon failure. Recorded in #5622's body and re-stated by triage there.

Prior art to reuse

The membership-assertion shape is settled — four pins now use it (packages/plugin-view/src/__tests__/ViewSwitcher.test.tsx from #5586; plugin-detail, plugin-list and components pins from #5622). Each reads the map or registry entry, applies the consumer's own toPascalCase + iconNameMap, and asserts Object.prototype.hasOwnProperty.call(icons, key) — with a control that a name lucide keeps only as a deprecated export is rejected. A repo-level gate would generalise exactly that predicate.

Related: #5586, #5622, #5631 (ui:icon reading the SDUI identity key name as an icon name — a different defect on the same renderer).

[os-sales]

Measured input for design question 1 (what is the population?), taken while implementing #5622 so it does not have to be re-derived. Installed lucide-react@1.31.0, 1767 icons-record entries; 347 files import named lucide exports.

54 distinct identifiers are imported by name and are NOT keys of the runtime icons record, across roughly 350 sites. All of them render — they are component imports — so none is a defect today. They are the reservoir the two repaired cards drew from: #5586 and #5622 both found a dead string spelling sitting next to a dead component spelling in the same package.

The heaviest, with the live record spelling of the same object:

retired identifier	sites	live spelling
Loader2	84	LoaderCircle
AlertTriangle	39	TriangleAlert
AlertCircle	35	CircleAlert
CheckCircle2	30	CircleCheck
BarChart3	16	ChartColumn
XCircle	11	CircleX
Edit	9	SquarePen
MoreHorizontal	9	Ellipsis
CheckSquare	9	SquareCheckBig
Code2, History	8 each	CodeXml, RotateCcwClock
Home	7	House — the one already special-cased in all four iconNameMaps

The tail is 43 more at 1–5 sites each, including AreaChart, BarChart, BarChart2, LineChart, PieChart, ScatterChart, GanttChart, GanttChartSquare, KanbanSquare, Filter → Funnel, Globe2 → Earth, Layout → PanelsTopLeft, FileJson → FileBraces.

Three things this measurement settles:

1. The population is much larger than the defect count, and almost entirely benign. A gate that flags all 54 would be suppressed on day one. Whatever it checks has to be "this name reaches a record-reading resolver as a STRING", not "this name is retired".
2. Grid3X3 vs Grid3x3 is in the list (1 site) — a capitalisation miss, not a rename. Any gate has to survive that being spelled two ways, and toPascalCase will not produce either from a kebab string without care.
3. examples/** was never in the original scan. Two more retired lucide spellings reach the icons-record resolver — edit in DetailView's mobile Edit action, smile as the icon renderer's own default — and only one of the four resolver copies is pinned #5622's body scanned packages/** and apps/**; extending to examples/** finds examples/schema-catalog/src/schemas/components-form-command/command-menu.json carrying "icon": "smile" — the same retired name Two more retired lucide spellings reach the icons-record resolver — edit in DetailView's mobile Edit action, smile as the icon renderer's own default — and only one of the four resolver copies is pinned #5622 repaired in the ui:icon registration. It is inert: packages/components/src/renderers/form/command.tsx never reads icon at all, so that key resolves nowhere. Recorded here rather than as its own card precisely because "which globs, and which keys are actually read" is this card's question, not a separate repair.

One false positive to discount when re-running any sweep like this: LucideIcon (13 sites) is the exported type, not an icon.

The sweep is ~30 lines over import { … } from 'lucide-react' plus an icons-record membership test; it is worth rebuilding rather than trusting this table, since the whole class exists because membership moves under a pinned version range.

---

Generated by Claude Code

[huangyiirene]

Concentration-round first-touch (triage seat): promoted finding → pm:queue, Task M.

Route ruled at triage from the card's own question 4: consolidate first, gate second. The four hand-copied toPascalCase + iconNameMap resolvers collapse into one shared helper (that answers "the producer is where?" — one map to maintain, one place aliases live, ends the sidebar-vs-action-bar disagreement), and the membership gate then attaches at that single seam — which dissolves the card's design questions 1–2 (the population becomes "call sites of the shared resolver", and there is one record to check). Question 3 (retired component aliases) stays covered by the existing four local pins' shape, generalised at the same seam. ⛔ The getIcon alias-tolerant fallback stays ruled out (wrong-icon beats no-icon in the wrong direction), as both prior cards recorded. Sequencing: after the #5631 ruling (which key ui:icon consults changes what the consolidated resolver reads on that one renderer); the two dynamic-surface consumers (getIcon/NavigationRenderer) are a declared second surface — unify or document the split, don't silently keep both.

---

Generated by Claude Code

[claude]

Claimed by os-dev session 01EuPCi56cnGyykygi3z9w4m (dispatched by the domain:ui PM seat).

Branch: claude/issue-5633-icon-literal-gate

Claim-precedence check before assigning (all agents share one GitHub identity, so the assignee field alone proves nothing):

• git ls-remote --heads origin 'claude/issue-5633*' → no refs. No live branch from an earlier round.
• Comments read in full before writing code: two, neither a claim — the measured-population input (2026-08-21) and the triage first-touch that promoted finding → pm:queue (2026-08-22). No prior session id appears on this card.
• Issue was unassigned at claim time.

Scope this round, per the dispatch fence: one repo-level gate whose judgement is the runtime icons record itself (no hand-kept list of retired spellings), its tests, retirement of the local pins the gate subsumes, and a changeset. Resolver behaviour is not touched this round — the triage note sequenced a four-resolver consolidation ahead of the gate; that divergence is recorded and returned to the PM in the report rather than decided here.

---

Generated by Claude Code

---

Generated by Claude Code