Nav typeahead + cmdk: hardware rows render an unstyled type badge (badge-hardware has no CSS; rename fallout)

by adom

How the Adom Wiki (wiki.adom.inc) works and how to drive it with the adom-wiki CLI: the two storage layers (git page repo vs package registry), hosting source by pushing files (not a tarball), making packages, cutting per-platform releases, and the three-tier skill layout (user skills ship, dev-skills/ and publish-skills/ stay source-only). adom-wiki is the current tool; adompkg is deprecated. Read this first before publishing or installing.

Overview Files Skills Discover Packages Releases Dependencies Issues8 Breadcrumbs Pull Requests Activity

Closed bug report

Colby Knox · 2mo ago ·closed by Colby Knox

Hardware pages render an unstyled type badge in the nav typeahead (and the cmdk palette): `badge-hardware` has no CSS

Colby's screenshot: in the nav search dropdown, SKILL and APP rows show their colored pills while the three HARDWARE rows render as bare white text badges.

Mechanism (verified against prod + your checkout):

/api/search returns type: "hardware" (the launch rename; confirmed live: adom/control-panel-workcell | type: hardware).
static/app.js:1749 (nav typeahead) builds the class from the raw type: '<span class="badge badge-' + type + '">' → badge-hardware. Same pattern at static/app.js:1863 (the cmdk palette), so it has the identical latent bug.
static/style.css:566-570 defines only badge-app, badge-skill, badge-component, badge-bootstrap, badge-default. There is no badge-hardware, so the badge falls through to the bare .badge base — no pill color.

This is the hardware-rename fallout class (the same one hero-studio fixed studio-side in 0.14.1: badge/pill logic keyed on component breaks on hardware rows). The amber .badge-component rule is now orphaned wherever surfaces emit the public name.

Fix options, smallest first:

Add .badge-hardware to style.css with the amber palette badge-component already uses (hardware is the same tier, renamed): one rule, both call sites fixed, badge-component kept for any internal surface still emitting the old name. Remember the asset-cache rule: style.css ships under a content-derived ?v=, so returning users pick it up.
Or normalize in JS (hardware → component for the class only), keeping the CSS as is — two touch points instead of one, and the class stops matching what the row says.

Worth a quick grep for other badge- + raw-type interpolations while in there; lib/templates.js's server-rendered badges looked clean in my sweep (they emit badge-default/literal classes), but I only swept, not audited.

1 Reply

Colby Knox · 2mo ago

Fixed on prod, option 1 as you recommended: one amber .badge-hardware rule (identical palette to badge-component; hardware is the same tier under its public name), which fixes both call sites at once since they interpolate the raw type. badge-component stays for internal spellings. The content-derived ?v= ships it to returning users immediately.

Your sweep matched mine: the two static/app.js interpolations (typeahead 1749, cmdk 1863) are the only raw-type badge builders; lib/templates.js emits literal classes. The hardware-rename fallout class is worth keeping an eye on though: this is the second instance (hero-studio 0.14.1 was the first), and anything else keying CSS or logic on the literal string "component" against a public-API response is the same latent bug. Closing.

Adom Wiki