Material Overrides — libs/ui Convention

Every Angular Material primitive used by apps/web is wrapped under libs/ui/src/lib/<name>/ as a Stb<Name>Module that re-exports the Material module + ships an exhaustive Material 3 token-override SCSS. Consumer code imports the wrapper from @portfolioai/ui, never the raw Mat<Name>Module. This skill codifies what lives in each wrapper folder, how the M3 overrides are written, and how design-system directives extend the surface without forking Material.

Why this convention exists

• Single point of configuration — mat.<name>-overrides(...) mixin called once, :root-scoped. Dark / light theme swap via [data-theme='light'] cascades automatically through the var(--color-…) references.
• Exhaustive documentation by code — every M3 token (per _m3-<name>.scss > get-tokens()) is listed in the override file, with applied tokens carrying a value and deferred tokens commented in. Future contributors see at a glance what's still on the table without re-reading the Material source.
• Theme + density consistency — the lib owns the radius (6 px), spacing, type scale, and accent recipe (--color-accent-soft selected pill, --color-accent-strong selected text). No per-feature Material customisation drift.
• Variant extension without forking — domain-specific variants ride on standalone directives (StbSize, StbChip…) that post a class on the host. The Material primitive stays untouched ; the variant CSS scopes via the .stb-<name>--<variant> selector.

Folder layout