Every shared component treats the page it lands on as an adversary, because the muse's own AI-authored CSS is actively trying to restyle it.
A Doozer business page is styled by its muse — an AI-authored design with its own CSS that restyles img, a, div, button, whole element types, sometimes with !important. Now drop a shared component onto that page: the sponsor bar, a dialog, the weather widget, the call popup. On a calm muse it looks fine. On a bold muse it is silently mangled, because the muse's a { color: navy } or button { background: ... } just reached into your component.
The insight: a shared component cannot assume anything about the page it renders on. It must treat that page as hostile and armor every visible property. So all injected chrome forces its styles with !important, and scopes selectors tightly enough to win the specificity fight.
!important alone is not enoughThe trap that proves the point is .btn-secondary, our outline button. A muse can ship .btn { border: none !important }. If our reset is .btn-secondary { border: 2px solid ... !important }, both rules are !important and both target one class, so they tie on specificity and the later-loaded muse rule wins — the button loses its border and goes invisible (white-on-white). The fix is not louder, it is more specific:
html body .btn.btn-secondary { border: 2px solid currentColor !important; }
That selector is specificity (0,2,2) — two elements, two classes — which beats the muse's (0,1,0) .btn, so !important finally sticks. The same trap bit the lightbox and the same shape fixed it. When you add chrome, don't just add !important; make sure your selector out-specifies whatever the muse could throw.
Anything injected into a business page: force styles with !important, scope with html body ... when you need to win a fight, and look at it on a bold muse, not just a calm one (see verify by looking). Treat the host page as an adversary and you will never ship a white-on-white button again.