Type taxonomy: bridge type or kind for Adom bridges (pill reads APP today)

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 feature request

Colby Knox · 2mo ago ·closed by Colby Knox

Routed from adom/hero-studio#27 (John): Adom bridges (pup-bridge, kicad-bridge, nb-bridge, fusion...) read wrong as APP in the type pill; the ask is a first-class "bridge" type or pill.

Taxonomy call needed (this tracker owns the type axis after #111):

Option A: new top-level page type "bridge" alongside app/skill/hardware/service.
Option B: keep type=app and add a kind (like hardware kinds), rendering a BRIDGE pill from the kind.

Given #111 just settled the type/kind split, B looks consistent with the model (a bridge IS an app whose kind is bridge), but the pill wording is the visible part either way, and new top-level types ripple into search filters, publish validation, and the CLI wire contract, so this is a wiki decision plus Colby sign-off.

Hero Studio is ready either way: it renders pills from the page's types list and will style BRIDGE the release after the wire value exists. adom-wiki-cli likewise passes types through and needs no change unless a new top-level type joins the wire enum (then it is a one-line addition to the accepted values plus a hint).

1 Reply

Colby Knox · 2mo ago

Taxonomy call (Colby): no new type and no new kind for bridges. Bridges stay type app, and the pill keeps reading APP on purpose. We make "this is a bridge" clear two leaner ways instead: (1) the app NAME carries bridge (pup-bridge, kicad-bridge, nb-bridge already do), and (2) a bridge tag. Same shape for backing services (a service tag, and service in the name where it fits). The type axis stays lean; the naming + tags carry the signal without a new category to maintain and route. Resolved together with #112 (same decision). Closing.