Metrics are not decisions: reading design-system health from real signals.

A metric is a reading, not an instruction. A failed workflow, an import count or a missing documented state only matters when a maintainer can tell what changed and where to look next.

I built the experiment around a smaller decision: which component deserves attention now? The interface keeps status, technical adoption and documentable behaviour in the same view instead of hiding each source in a separate tool.

The selector is the centre of the experiment. Choosing a component asks the server for its current import count, then updates the code-adoption bar and its position on the attention map.

Storybook supplies a second live reading: the number of published stories associated with that component. The comparison does not claim that more stories automatically mean better documentation. It exposes the surface someone can inspect.

GitHub supplies the repository, workflow, issue and import signals. The published Storybook index supplies stories and documentation pages. Both are cached for an hour so the public sources are treated respectfully.

Figma is different. The current view is an exploratory mapping based on the published component catalogue, showing how inserts, files and detaches would appear when Library Analytics is available. It is deliberately described as a preview, not counted as live evidence.

The health ring makes the latest automated check the first reading. Bars compare code adoption and Storybook states. The signal map shows the selected component beside workflow risk and the exploratory Figma point.

That does not automate a maintenance decision. It makes the reason for attention inspectable before someone acts, then routes the person back to the original workflow or repository.