A brand-only component consuming core tokens

WHAT THIS TESTS Whether you understand the layered packaging that lets a single brand have unique components while still reusing core tokens and primitives and keeping the core clean.

A GOOD ANSWER COVERS Use a layered package structure. The core library exposes tokens and shared primitives and is brand-agnostic. Each brand has its own package that depends on core. The unique FeaturedArticle card lives in that brand's package, where it imports core primitives like Card, Text, and Image and consumes core semantic tokens, so it inherits the brand's theme automatically. It never enters the core, because no other brand needs it and adding it would bloat the core and couple it to one brand. The brand app depends on its brand package plus core; other brands' apps never see the component. Governance: an RFC decides core versus brand placement; if the component later generalizes, it can be promoted to core through review.

COMMON WRONG ANSWERS Adding the one-brand component to the shared core, bloating it and setting a precedent for brand leakage. Duplicating core tokens into the brand package, breaking the single source of truth. Forking the core for that brand. Hardcoding brand colors in the component instead of consuming tokens. No promotion path if it later becomes broadly useful.

LIKELY FOLLOW-UPS When would you promote a brand component into core? How does the brand package consume core tokens? How do you prevent core from accumulating one-off components? How do other brands stay unaffected?

ONE CONCRETE EXAMPLE Brand A's package defines FeaturedArticle, importing Card and Text from core and styling with core semantic tokens, which Brand A's theme repoints to its palette. Only Brand A's app installs that package, so the component looks on-brand and consistent yet is invisible to Brand B, and the core library remains free of any FeaturedArticle code.