Files
zeekayandHanzo Dev 5bf85a4faf The CSS check was passing on an empty shell
`postbuild: gui-css-check` read the exported HTML. This site fetches store.json
in the browser, so that HTML is a shell: the check found 29 classes, covered all
29, and reported 100%. Rendering the same three pages finds 227 — and nine of
them had no rule in any sheet the page delivers. A check that passes by not
looking is worse than no check, because it is quoted as evidence.

gui-css-check has --render for exactly this, and rendering needs the export
served, so scripts/css-check.mjs serves out/ on an ephemeral port and renders
one page of each kind — grid, app record, long-form document. Every route is one
of those three; rendering all 202 app pages proves nothing the first did not.

(spawn, not spawnSync: the checker fetches those urls from the same process that
serves them, and a synchronous child blocks the event loop the server answers
on. It waits out its own 60s timeout against a server that can never reply.)

The nine misses are btn-default/sm/lg/outline/ghost and badge + its three
variants — semantic handles @hanzo/ui stamps on a control alongside the
@hanzo/gui atomics that actually paint it. @hanzo/ui ships no rules for them on
purpose; they exist for a host to hook. Verified inert rather than assumed:
stripping every btn-*/badge-* class off a rendered element leaves its computed
background, padding and radius unmoved. So they are allowed in
gui-css-check.json with that note, instead of being given rules that would
restate what gui already does. The store hooks exactly one handle, `.btn`, and
that one is defined in globals.css.

Confirmed the gate actually fails: empty the allow list and it exits 1; restore
it and it exits 0. 227/227 covered.

Co-authored-by: Hanzo Dev <[email protected]>
2026-08-04 18:22:59 -07:00
..