What task are you trying to do?

Cut chrome icon registry noise and polish the few entries that still look less refined than the brand v3 redraw. The chrome icon registry in packages/ui/src/components/icon.tsx has 105 keys; cross-referencing every consumer surface (<Icon name> direct + ternary, icon= prop, icon: object literals, homeIcon and friends) shows 26 keys with zero real references. They linger in icon.stories.tsx and pollute the catalog that design agents pick from, which is one reason agents occasionally drop a stale icon into a new layout.

What do you do today?

Two distinct shapes of pain. First, when an agent (human or AI) opens icon.stories.tsx to pick an icon, the catalog mixes brand v3 entries with old chrome leftovers and never-wired forward-looking entries; agents land on unused old chrome icons (archive, layout-*, discord, github, file-tree, etc.) by accident. Second, a small set of in-use icons (e.g. new-session) read less crisp than the rest of brand v3 — they were redrawn but feel under-polished next to the rest of the set.

What would a good result look like?

The chrome icon registry contains only icons that are actually used in the app, or that are staged for upcoming features. Polish targets pass visual review against the brand v3 DNA (line-stroke, square linecap, monochrome via currentColor). icon.stories.tsx and icon-registry-rename.test.ts stay in sync with the registry, so the catalog the agent sees matches reality.

What would count as done?

• 26 unused keys removed from icon.tsx. Confirmed unused list: align-right, archive, arrow-down-to-line, chevron-double-right, chevron-left, collapse, discord, edit-small-2, expand, eye, file-tree, file-tree-active, fork, github, layout-bottom, layout-bottom-full, layout-bottom-partial, layout-left, layout-left-full, layout-left-partial, layout-right, layout-right-full, layout-right-partial, share, shield, speech-bubble.
• icon.stories.tsx names array trimmed to match.
• packages/ui/test/components/icon-registry-rename.test.ts guard updated for the post-cleanup registry.
• Polish target list confirmed during work (starting set: new-session + new-session-active; more to be picked from local Pawwork-chrome-icon-imagegen-v3 batches as we review).
• Each polish target gets a vector-edited SVG path replacement in icon.tsx (raw potrace output via icon-trace.mjs → manual cleanup in vector editor → path string).
• Local bun --cwd packages/ui run typecheck and a desktop dev launch show no missing-icon runtime warning on any active page (titlebar, sidebar, composer, session view, settings).

What should stay out of scope?

• File-type sprite (packages/ui/src/components/file-icons/sprite.svg) — separate issue.
• App-icon vendored brand logos in packages/ui/src/assets/icons/app/ — those keep the brand-faithful original (PawWork shows other apps' logos in "Open in…" pickers; not subject to PawWork DNA).
• Adding new icon keys for upcoming features — leave for the feature PRs that need them. Brand v3 forward-looking entries already in registry (automation, plugin, remote-control, schedule, chevron-up, key) are kept as placeholders for now.

Which audience does this matter to most?

Both.

Extra context

• This issue is the action item behind docs/SPEC.md design principle "全屏一份 icon DNA" applied to the chrome icon set specifically.
• Local source for polish material: ~/Downloads/Pawwork-chrome-icon-imagegen-v3/ — 8 batch PNGs + skills/skills-2/worktree extras + icon-trace.mjs (crops a cell, runs potrace).
• Brand v3 was landed in commit 2abc3697d (feat(ui): replace chrome icon set with PawWork brand v2); this issue is the follow-up cleanup + polish pass.
• Registry → consumer mapping was done by grepping every <Icon name> form (literal, ternary, dynamic), icon= prop, icon: object literal, homeIcon/fallbackIcon/leadingIcon/trailingIcon patterns, then filtering false positives (slash command names, theme ids, state keys). The 26 unused list is the residual.