06-core-use-shared-website-components-for-visual-consistencylisted

# Shared Website Components & Visual Consistency 1. **COLORS**: Use central HSL CSS variables from `DESIGN_SYSTEM.md`; never hardcode hex/RGB. 2. **TYPOGRAPHY**: Use the `clamp()` font-scale tokens, not raw sizes. 3. **ICONS/LOGOS**: Pull vector SVGs from the central registry (`COMPONENTS_INVENTORY.md` / `icons.js`); no inline one-offs. 4. **REUSE FIRST**: Before building any UI component, check `DESIGN_SYSTEM.md` and `COMPONENTS_INVENTORY.md`; if it exists, use it — if not, build it from tokens and register it there. 5. **EDITORIAL LOOK**: Break symmetry, use subtle radial lights (not generic mesh gradients), and thin high-contrast borders. 6. **LOOK AT THE DESIGN — DON'T REFACTOR BLIND**: Any visual/design change requires SEEING it: render the live screen and screenshot it BEFORE (to judge the actual problem, not the CSS) and AFTER each iteration (to confirm the fix). Compare against a sibling screen for consistency. A design verdict or refactor reasoned only from source is invalid. → see [[04-core-verify-interactive-web-elements-before-claiming-complete]] 7. **ONE-SWAP RE-THEMABILITY (the user's standing goal for EVERY site)**: Build so the whole palette (and seasonal variants — Christmas/Halloween/rebrand) can be re-skinned by editing ONE token block, with near-zero component changes. Every color lives in a central token; components consume tokens only (never literal hues, even via `bg-[hsl(var())]` arbitrary values — promote those to named utilities so re-theming touche