You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bring file-type icons into the same visual DNA as chrome icons. packages/ui/src/components/file-icons/sprite.svg ships ~1075 colored, brand-faithful logos inherited from the upstream vscode-icons / material-icon-theme set (real Vue green, real Python yellow-blue, real Vercel triangle, etc.). Inside a PawWork file tree they collide hard with the brand v3 monochrome line-icon DNA used for chrome — every file row looks like it was pulled from a different design system.
What do you do today?
<FileIcon> renders the colored sprite anywhere the user sees a file: file-tree, dialog-select-file, dialog-select-directory, prompt-input/context-items, slash-popover, session-sortable-tab, message-timeline file references. Right next to those are PawWork chrome icons (line, mono, brand orange accent only). The two languages do not blend; the eye sees a file row as "stickered" while everything around it is restrained.
What would a good result look like?
All file representations follow the same line-icon DNA as chrome icons (1.5px stroke, square linecap, monochrome via currentColor, neutral resting / brand-orange-on-active mapping). File-type identity is still readable at small sizes (16-20px) through shape, not color. Sprite footprint shrinks dramatically — from ~1075 entries with light/dark variants down to ~20-30 generic line icons.
What would count as done?
A category set is defined (~20-30 line icons). Working starting list: Code / Markup / Image / Document / Spreadsheet / Presentation / Pdf / Archive / Config / Script / Lock / Data / Binary / Font / Audio / Video / Folder / FolderOpen / generic File (refine during work).
Every current extension and filename in packages/ui/src/components/file-icon.tsxICON_MAPS is remapped to one of these categories. No unmapped extension in production usage.
New sprite (or inline path strings) follows PawWork brand v3 stroke / weight / corner. No color logo survives in the output.
packages/ui/src/components/file-icons/types.ts regenerated to match the new shrunk set.
Visual review pass on every consumer surface: file-tree, dialog-select-file, dialog-select-directory, prompt-input/context-items, slash-popover, session-sortable-tab, message-timeline. No color flash, no remaining vscode-icons residue.
Local bun --cwd packages/ui run typecheck clean. Desktop dev launch shows no missing-icon warning on file rendering paths.
What should stay out of scope?
1:1 redrawing all 1075 SVGs — explicitly rejected. Cluster, do not duplicate.
Per-extension exception logos (no "we keep colored Vue but redraw the rest") — ship one consistent line-icon DNA, period.
App-icon vendored brand logos in packages/ui/src/assets/icons/app/ — those stay (these are other apps' logos used in "Open in…" pickers, not PawWork's own file representation).
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 file-type icons.
docs/DESIGN.md Iconography section already records this as a TODO (### File-type icons (sprite) block).
Suggested first concrete step before coding: brainstorm the cluster boundary set on a doc — list every distinct file category PawWork users actually meet (covering programming, office, archive, lock/key, font, audio/video/image, plus generic fallbacks), then sketch the ~20-30 line icons against the brand v3 reference. Only after the cluster set is signed off should the sprite work begin.
What task are you trying to do?
Bring file-type icons into the same visual DNA as chrome icons.
packages/ui/src/components/file-icons/sprite.svgships ~1075 colored, brand-faithful logos inherited from the upstream vscode-icons / material-icon-theme set (real Vue green, real Python yellow-blue, real Vercel triangle, etc.). Inside a PawWork file tree they collide hard with the brand v3 monochrome line-icon DNA used for chrome — every file row looks like it was pulled from a different design system.What do you do today?
<FileIcon>renders the colored sprite anywhere the user sees a file: file-tree, dialog-select-file, dialog-select-directory, prompt-input/context-items, slash-popover, session-sortable-tab, message-timeline file references. Right next to those are PawWork chrome icons (line, mono, brand orange accent only). The two languages do not blend; the eye sees a file row as "stickered" while everything around it is restrained.What would a good result look like?
All file representations follow the same line-icon DNA as chrome icons (1.5px stroke, square linecap, monochrome via
currentColor, neutral resting / brand-orange-on-active mapping). File-type identity is still readable at small sizes (16-20px) through shape, not color. Sprite footprint shrinks dramatically — from ~1075 entries with light/dark variants down to ~20-30 generic line icons.What would count as done?
Code/Markup/Image/Document/Spreadsheet/Presentation/Pdf/Archive/Config/Script/Lock/Data/Binary/Font/Audio/Video/Folder/FolderOpen/ genericFile(refine during work).packages/ui/src/components/file-icon.tsxICON_MAPSis remapped to one of these categories. No unmapped extension in production usage.packages/ui/src/components/file-icons/types.tsregenerated to match the new shrunk set.bun --cwd packages/ui run typecheckclean. Desktop dev launch shows no missing-icon warning on file rendering paths.What should stay out of scope?
packages/ui/src/assets/icons/app/— those stay (these are other apps' logos used in "Open in…" pickers, not PawWork's own file representation).Which audience does this matter to most?
Both.
Extra context
docs/SPEC.mddesign principle "全屏一份 icon DNA" applied to file-type icons.docs/DESIGN.mdIconography section already records this as a TODO (### File-type icons (sprite)block).