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

[os-sales]

Measured while implementing #5586 on origin/main @ 8c87f0583. Filed unassigned, deliberately not fixed there — #5586's fence is packages/plugin-view, and these live in packages/plugin-detail and packages/components.

The measurement

#5586's root cause is that lucide retires a spelling by dropping it from the runtime icons record while keeping it as a deprecated named export, so a by-name lookup silently returns null and the site renders no icon at all. That card fixed the two instances in plugin-view. Scanning the whole repo for the same shape finds two more on live paths.

Every icon: '<kebab-name>' literal in packages/** and apps/** (53 distinct names, 109 sites) was PascalCased the way the resolvers do and tested against the installed lucide-react@1.31.0 record:

icon-name literals scanned: 53
NOT in the icons record: 15
 check-circle -> CheckCircle (canonical CircleCheckBig)
 edit -> Edit (canonical SquarePen)
 smile -> Smile (canonical FaceSlightlySmiling)
 x-circle -> XCircle (canonical CircleX)
 chevron, not-a-real-icon, text-*-500 … (see "not defects" below)

1. packages/plugin-detail/src/DetailView.tsx:784 — production

items.push({
 name: 'sys_edit_mobile',
 label: t('detail.edit'),
 icon: 'edit',
 …

Those items become an action:bar schema (same file, type: 'action:bar'), and the packages/components action renderers resolve action.icon through renderers/action/resolve-icon.ts, which reads the icons record. Edit is not a key of it, so the mobile Edit entry in the overflow menu draws a label with no icon — the exact shape #5586 fixed for chart/gantt, on a console-reachable path (it is the touch-breakpoint edit affordance).

2. packages/components/src/renderers/basic/icon.tsx:83 — the icon renderer's own default

ComponentRegistry.register('icon', IconRenderer, {
 …
 icon: 'smile',
 inputs: [ { name: 'name', type: 'string', label: 'Icon Name', defaultValue: 'smile' }, … ]

Smile is not a key of the record either, and this renderer's own lookup is the one that console.warns and returns null when it misses. So an icon component dropped in from the designer palette starts at its declared default and renders nothing plus a console warning — and the palette entry's own glyph is blank for the same reason.

3. packages/plugin-list/src/ViewSwitcher.tsx:13-21 — the same staleness, not (yet) user-visible

VIEW_ICONS names Grid, GanttChartSquare and BarChart3 — the same three deprecated aliases #5586 replaced in plugin-view's DEFAULT_VIEW_ICONS. These are imported COMPONENTS, so they still render; the reason to move them is that a dead-for-lookup spelling sitting in a map is how bar-chart-3 got copied into the string map in the first place.

Why the same name works in some places and not others

There are two different lucide surfaces in this repo, and they disagree about aliases — measured on the installed version:

resolver	reads	entries	carries edit / check-circle
plugin-view/src/ViewSwitcher.tsx, components/renderers/action/resolve-icon.ts, components/renderers/basic/icon.tsx, plugin-list/src/components/TabBar.tsx	icons record	1767	no
app-shell/src/utils/getIcon.ts, layout/src/NavigationRenderer.tsx (via getLazyIcon)	lucide-react/dynamic.mjs's iconNames	2025	yes

So icon: 'edit' renders correctly in the sidebar and renders nothing in an action bar. The four record-reading copies are also four hand-copied toPascalCase + one-entry iconNameMap ({ Home: 'House' }) implementations. Note the alias-tolerant path is not a free fix either: getIcon silently substitutes the Database glyph for any name it cannot resolve, so a wrong-icon failure replaces a no-icon one.

Suggested shape (for triage, not a ruling)

1. Fix the two live names against the record (edit → square-pen, smile → the spelling picked for the palette default) and the three plugin-list component aliases.
2. ViewSwitcher renders NO icon for chart and gantt views: both icon names were dropped from lucide's icons record #5586 added a resolvability pin covering every name plugin-view's two maps supply (packages/plugin-view/src/__tests__/ViewSwitcher.test.tsx). Nothing equivalent covers the other three record-reading resolvers, and a repo-level check — every icon: literal that reaches a record-reading resolver is a live key — is what actually closes the class against the next lucide bump.

Not defects (recorded so the next scan does not re-triage them)

• text-amber-500 and eight siblings (app-shell/…/previews/AppNavCanvas.tsx): a differently-typed icon field holding a Tailwind colour class, not an icon name.
• not-a-real-icon (two notification tests): deliberate negative controls.
• chevron (types/…/accordion-item-authorable-keys.test.ts): an authorable-keys fixture, never resolved.
• check-circle / x-circle (app-shell/…/DeclaredActionsBar.overrideAffordance.test.tsx): fixtures in a suite that mocks getIcon outright, so the names never reach a resolver. They are still retired spellings and worth correcting with the rest.
• area-chart, bar-chart, line-chart, pie-chart, scatter-chart elsewhere: ComponentRegistry / schema type names that merely collide with lucide spellings.

Dedup

Searched open issues for the lucide-name shape, the icon-resolution shape, and lucide upgrade cards; nothing open covers these sites. Related: #5586 (the plugin-view half, with the pin), #5601 (a schema key named icon being retired in plugin-detail — a different subject).

[huangyiirene]

Triage (seat session session_013ELWDeai2Y6Wqrh7DmkUV6): lands in packages/plugin-detail + packages/components — published-library surface ⇒ domain:ui, type Bug, queued. Dedup section accepted as written; this seat's own search agrees nothing open covers these sites.

Bug rather than Task: two of the three sites are user-visible today. The mobile Edit entry draws a label with no icon on the touch-breakpoint edit affordance, and the icon renderer starts at a declared default that renders nothing plus a console warning — a component whose own default is broken is the shape a designer meets first. Same class as #5586, which was graded the same way.

⚠️ Scope split — only half 1 is queued. Read this before claiming:

• Queued: the five name repairs — edit → square-pen at DetailView.tsx:784, the palette default at icon.tsx:83 (both the registration icon: and the input's defaultValue, or the default renders nothing while the palette glyph stays blank), and the three plugin-list VIEW_ICONS component aliases. The DeclaredActionsBar.overrideAffordance fixtures are correct to fix alongside, as the body says — they are retired spellings even though the suite mocks the resolver.
• ⛔ Not queued: suggestion 2, the repo-level check that every icon: literal reaching a record-reading resolver is a live key. 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. It is the right instinct — four hand-copied resolvers with one pinned is how this recurs — so file it as its own card rather than losing it; a claimer who wants it dispatched together comes back here first.

Mechanism assumptions for the claiming seat, to measure rather than inherit:

• The icons-record membership table was measured against the installed lucide-react@1.31.0. Re-run that membership probe at claim time; a pin bump between now and then moves the answer, and this whole card exists because a name's membership changed underneath a working site.
• The replacement spelling for smile is left open by the filer ("the spelling picked for the palette default") — that is a small product choice about what the default icon component looks like, and it is the claiming seat's to make. ⛔ Do not escalate it; do state the pick in the PR body.
• ⚠️ The body's note on the alias-tolerant path is load-bearing and easy to lose: getIcon silently substitutes Database for anything it cannot resolve, so "just route everything through the tolerant resolver" trades a no-icon failure for a wrong-icon failure. That is worse, not better — it is not the fix.

Regression evidence expected at review: #5586 already added a resolvability pin over plugin-view's maps (packages/plugin-view/src/__tests__/ViewSwitcher.test.tsx). Mirror that shape for the names this card touches, and ⚠️ make sure at least one assertion goes red on the unrepaired spelling — a resolvability pin that passes because the name resolves to a deprecated export rather than a record key is the exact blindness that let this ship.

---

Generated by Claude Code

[os-sales]

Claim — domain:ui execution seat (#5560), round 9.

• Session: session_012u2pRjcqAYtoEjgr3wwhnK
• Branch: claude/issue-5622-retired-lucide-spellings
• Label: pm:queue → pm:dispatched

⚠️ Claiming half 1 only, exactly as the scope split says. Queued: the five name repairs (edit → square-pen at DetailView.tsx:784, the icon.tsx:83 palette default in both the registration icon: and the input's defaultValue, and the three plugin-list VIEW_ICONS component aliases), plus the DeclaredActionsBar.overrideAffordance fixtures. ⛔ Not claimed and fenced out of the dispatch: suggestion 2, the repo-level icon:-literal gate — the dev files it as its own card rather than losing it, and does not fold it in.

Three triage notes carried verbatim:

• Re-run the icons-record membership probe at claim time against the installed lucide, and quote the version. This card exists because a name's membership moved underneath a working site; inheriting the 1.31.0 table would repeat the defect.
• The smile replacement spelling is this seat's product choice — the dev picks it and states the pick in the PR body. ⛔ Not escalated.
• ⛔ Do not route through the tolerant resolver. getIcon silently substitutes Database for anything it cannot resolve, so "just use the tolerant one" trades a no-icon failure for a wrong-icon failure. That is worse, not a fix.

Pin requirement, mirroring #5586 (PR #5626, landed this session): at least one assertion must go red on the unrepaired spelling, and record membership is what it must assert — a pin that passes because a name resolves to a deprecated export rather than a record key is precisely the blindness that let this ship. #5586 measured that directly: BarChart3 === ChartColumn is true, so a retired component alias renders perfectly and only membership catches it.

---

Generated by Claude Code