design-stack-pickerlisted

# design-stack-picker A selection layer, not a mandate to replace the project's design system. ## Decision order Audit first: framework and rendering model, existing icons/fonts/tokens/components/image pipeline/breakpoints, current dependencies, visual style. Then: 1. Reuse the existing project system if it works. 2. Extend it with the smallest compatible building block. 3. Add a library only when there is no good local solution. 4. Hand-craft only for brand assets, tiny static pieces, or where a dependency outweighs the implementation. ## Defaults Starting points, not requirements. | Axis | Default | |---|---| | Icons | Iconify + Solar; Simple Icons for brand marks | | Fonts | Unbounded display + Onest body via Fontsource | | Components | Project components first; HyperUI/Preline for static sections; shadcn/Radix for React primitives | | Color | Semantic CSS variables; one dominant brand color + one accent | | Motion | CSS-first restrained reveal; Motion for React; GSAP only for complex timelines | | Imagery | Real product/user/stock/CMS assets; AVIF/WebP where practical | ## Dependency budget No dependency for: a single icon when an icon system exists; one static section existing primitives can handle; a basic disclosure/dropdown in Astro or plain HTML where scoped JS is smaller and verifiable; a visual effect existing CSS covers; anything duplicating a current dependency. Add one when it removes real implementation risk: complex accessible widgets, broad consiste