Component promises

Why the split matters

“Unread” is one word for three different defects with three different fixes, and only one of them is a wiring job. The kind is derived, not authored: missing-part falls out of “are ALL of this part’s tokens unread”, which is the same evidence a human uses. A part of one token can never be called missing — there are no siblings to compare against, so it stays unwired and a person decides.

no component 24

The namespace names no component. Either it is staged ahead of code that has not landed (legitimate, if documented in SPEC.md) or it is a ported surface superseded by a component under a different name.

missing part 0

Every token naming this part is unread, so the part has no markup behind it. Closing this is a FEATURE — build the part or delete the tokens. Wiring is not available as an option.

unwired 0

Sibling tokens naming the same part are read, so the markup exists and the component simply does not consult this hook. A CSS edit, and the only kind here that is purely a wiring fix.

exempt 0

Unread by DECISION, not by accident — the component exists and these map onto real elements in it. Held exempt from the wire-or-delete rule; see the exemptions table for the owner and for what a spoke gives up. Not counted as a gap, still listed by name.

Over-promise — declared, not read

Tokens naming another component

A tier-3 token is for a part the component draws itself. When the “part” is really another component, it should be composed and themed through its tokens. --sidenav-user-avatar-bg was the first of these found — esa-avatar already owns --avatar-bg, so the token was a second avatar implementation living in the token file. The tell is in the name: two nested part words means you have stopped naming a part and started naming a component tree.

Reported apart from the gap tally, and deliberately so — this is a different defect class, and folding classes into one bucket is what let --topbar-* hide. A group appears only when at least one of its tokens has a direct counterpart in the child’s namespace; that filter is what removes the noise. The 13 tokens naming icon are suppressed because esa-icon has no tier-3 surface at all, so a parent sizing a glyph inside its own layout is correct. --pagination-button-color is suppressed because esa-button declares only --button-on-warning — there is no --button-color to duplicate.

Read by more than one component

A tier-3 token themes one component, so several readers is worth a look — but it is not one defect, it is three different facts, and only two of them are problems. Sorted by reader count, so the widest blast radius is first.

The component doc pages read the same data: each one splits its theming surface into the hooks wired to it and the shared tokens it merely consumes, so a spoke author can tell “mine to turn” from “turning this moves the family”. This table is the system-wide view of the second half. Everything here is derived — a new component that reads --dialog-bg appears on the next build.

Under-promise — read, declared nowhere

The inverse failure. These hooks work — the component reads them with an inline fallback — but no token file declares them, so nothing outside the component’s own source records that they exist. They show on the component’s Theming surface table as tier ad-hoc; they do not show in component-tokens.css, which is where a spoke author looks first.

This panel used to add “and SPEC.md permits the pattern”. It does not. Its only mention of ad-hoc gives two dispositions and no third — promote into component-tokens.css, or fold away — and reading a permission into that turned a missing declaration into a fourth tier. There are three. An undeclared read is a tier-3 token that never got its line written.

Empty is the expected state. The 30 that stood here were resolved on 2026-08-16 (9 declared, 24 folded). A row below means someone has added an undeclared read since — it wants one of the same two answers, not a third.