A vet booking app's workshop shows components only under the default theme, and a partner clinic's theme shipped an unreadable booking-status chip. How should the workshop change, and how do you measure its coverage?

## What went wrong A veterinary clinic booking app's library serves the main product and several partner clinics, each with its own theme. The workshop rendered every example under the **default theme only**. The booking-status chip's *waitlisted* variant looked fine there. Under one partner's theme, the role it used for text and the role it used for its fill resolved to two pale values, and the chip became unreadable. Nothing in the workshop could have shown it: the combination was never rendered. The gap is not in the chip. It is that the workshop presented one theme as if it were all of them. This pattern is common for a simple reason: the default theme is where designers and engineers spend their days, so it is the most polished and the most looked at. Secondary themes are applied by values alone and rarely viewed component by component, so their defects collect quietly until a partner's users find them. ## Theme switching done properly 1. **A global switcher.** One control changes the theme for every example, and the choice is part of the link, so *waitlisted chip, partner theme* can be shared. 2. **The real mechanism.** The workshop applies a theme exactly the way consuming apps do. A workshop-only approximation — hand-picked colors, a separate copy of the values — shows something users never get, which is worse than showing nothing. 3. **Every shipped theme.** The list comes from the system's own list of themes, so a new theme appears in the workshop automatically. 4. **A side-by-side view.** For review, each example rendered under every theme at once, so a reviewer scans one grid instead of switching back and forth. 5. **Other context axes.** The same switcher approach covers any other context the system supports — density, text size, reading direction — each owned and specified elsewhere, all rendered here. ## Measuring coverage | Measure | How it is counted | What a gap means | |---|---|---| | Component coverage | exported components with at least one example | a component nobody can see in isolation | | State coverage | specified variants and states with an example | an unseen state, likely untested | | Theme coverage | examples that render under every shipped theme | a theme where problems cannot be seen | | Fixture use | examples also rendered by tests | a state that is shown but never exercised | | Health | examples that render without error | a catalog that has started to rot | **State coverage** is the most revealing: it compares the spec's list of variants and states with the example list, so it finds exactly the kind of gap that let the chip ship. A raw count of examples per component says little; ten examples of the default state cover less than three well-chosen ones. ## Enforcing it - A **build check** fails when an exported component has no example, or when a variant the component declares has none. - Every example is **rendered under every shipped theme** in the build; one that throws or renders nothing fails. This proves that it renders, not that it looks right. - Changes to shared theme values trigger a review of the side-by-side view for the components they touch. - Examples have **owners**, the same as the components. ## What coverage cannot tell you - **Presence is not correctness.** A rendered, unreadable chip counts as covered. Judging it takes a person reviewing the grid or the library's test layers — visual comparisons across themes and automated contrast checks — which belong to the test strategy, not to the workshop. - **Specs can be incomplete.** State coverage is only as good as the state list it compares against. - **Real pages still differ.** The workshop shows components under each theme, not whole pages. ## On native mobile Native preview catalogs can render the same component under several themes side by side, and the same measures apply: specified states with a preview, previews under every shipped theme, and a build that fails when a declared variant has no preview.