Every gate this skill has shipped answers one question: is this designed. Anti-slop rules, token discipline, the fold draw, the acceptance bar. Nothing answered the other one — does this screen have the parts screens of its kind need — and only three surfaces had a parts list at all, because only three have an outcome recipe. Settings, data tables, search, detail views, first-run states, billing, pricing, docs pages, checkout, onboarding, destructive confirms and invite flows had none.
ux_coverage is that second question, and this release is what points the skill at it. The routing table and Tier 4 name it, /harden pulls the archetype's parts after its own nine-item matrix, and references/coverage.md carries all twelve archetypes for installs without the MCP server. Twelve archetypes, 85 parts, authored from forms.md, state-design.md, components.md and dashboard.md rather than invented beside them.
Each part carries four fields and none of them is useful alone: what should exist, what present concretely looks like, the rule for building it with the reference that states it, and what the user loses when it is missing. Presence on its own is a checklist anyone could write. The rule on its own repeats what the references already say. The cost is what makes a finding arguable instead of a preference — "no export" is a status; "the user expects the 24 rows on screen and receives 10,000" is a reason.
It reports markers, never a number: present, partial, missing, not-needed, unknown. That refusal comes from measurement, not taste. Coverage is a hygiene axis, and the score audit found 30 of 49 files tied at exactly 100 with every finding hygiene — so a coverage percentage would read near-100 for most surfaces and bury the distinction signal underneath it. A number also converts not-needed into a failure, which is the one reading the marker set exists to prevent: a read-only table is not failing two thirds of a table checklist for having no bulk actions. Run against a real staging table, the split came out one present, two partial, one missing and four not-needed — "1 of 8, 12%" would have described a mostly-correct surface as broken. So it never gates, never exits non-zero, and is never folded into score_ui. The two axes are reported side by side.
coverage.md is generated from the same data the tool serves, byte-stable, with a drift gate ordered ahead of the mirror check — mirroring a stale fallback only propagates it. The fallback is what the least-tooled installs get, so a hand-maintained second copy would fail exactly where nobody reports it.
Installers and generated launchers now write ui-craft-mcp@0.9.0, which is the half that answers. The tool has been callable since that publish; until this release nothing told an agent to call it.
Honest limits, two of them. The planned eval could not run: the quality fixtures are eleven components of 1–2 KB and not one contains a table, a checkout or a settings screen. Validation ran instead against a documentation site that predates the work — 0 present, 2 partial, 5 missing, so the items discriminate rather than tying at the top, which was the predicted failure mode for a hygiene axis. But the same author wrote the items and ran the check, so that shows they discriminate, not that these are the right twelve archetypes or the right 85 parts. And the parts are a floor, not a ceiling: a screen can hold every one of them and still look generated, which is what the other axis is for.