DEPRECATED: Bridge SDK (moved into Adom Bridge)

The fusion bridge just shipped (v1.9.42, live and end-to-end verified today) a THIRD installable artifact beyond the bridge zip and the skills pkg: a container-side binary CLI that serves the bridge's Dashboard - its Launch Page web app. John's direction is that this becomes a standard Bridge SDK facet, with fusion blazing the trail and kicad-bridge mimicking next. Here is the whole proven pattern so the SDK can adopt it.

Why a container binary at all. The user's AI lives in the container; the container already reaches every ab box via the relay and the adom-bridge CLI. So a bridge's user-facing web surface (status LEDs, setup, settings, demos) belongs IN the container: it aggregates any number of machines through the CLI the user already has, needs no new protocol, no Windows-side web server, and it proxies to any browser surface via the container's port proxy. The bridge on the box stays the single source of truth; the dashboard CLI is a thin, honest aggregator that SHELLS bridge verbs.

The three-artifact pattern (per bridge wiki page):

1. Release zip + manifest -> installed into ab on Windows (bridge_install), unchanged.
2. pkg tarball -> the Linux container: skills AND NOW the dashboard CLI. Per the wiki's PKG_VS_RELEASE lint, the binary itself is NOT tarball content - it is a platform-tagged release asset (adom-wiki release upload <page> <ver> <bin> --platform linux --arch x64), and install.sh downloads it from https://wiki.adom.inc/download/<owner>/<slug>/<ver>/<bin> to /usr/local/bin (fallback ~/.local/bin). One version everywhere.
3. Page media/docs, unchanged.

The dashboard CLI contract (suggest the SDK standardize these exact verbs):

• <bridge>-dashboard serve [--port <p>] [--target <box>] [--print-url] - serves the web app; --print-url first line = the Dock Bar's await:"url" step.
• <bridge>-dashboard status [--target] - one-shot JSON of the LED payload.
• <bridge>-dashboard health - liveness. All output OK:/ERROR:/Hint:.
• HTTP: GET /api/status (LEDs; EVERY LED carries a _hint naming the exact verb that fixes a red one - the dashboard is a discovery surface for AIs as much as a UI for humans), POST /api/action {action,args}, GET /state, /console, /health.

Dock Bar integration: a dock.json (dock_manifest 1.1.0) at the page repo root: step 1 adom-wiki pkg install <page> with skip_if: command -v <bridge>-dashboard, step 2 serve --print-url with await:"url". Works today against the shipped Dock SDK.

What the fusion dashboard shows (the facet checklist for any EDA bridge): app running, add-in/bridge serving, signed in, cloud search (APS) configured AND working, MCP server, Data Hub, pending-update-waiting; plus a first-run Setup walker, a Settings panel (sticky auto-update toggle etc.), copy-paste AI prompts, the demo tour with live progress, and a wiki part import demo.

Traps we hit so kicad does not: (a) the pkg publisher keys off package.json slug - it must equal the PAGE slug or the publish is treated as a brand-new page (and demands a Hero Studio hero); (b) zip is not in every container - build tarballs/zips with python; (c) keep the dashboard out of the bridge zip entirely; (d) a ~640KB static Rust binary (tiny_http + serde_json, opt-level=z + lto + strip, UI include_str!d) is plenty - no framework needed.

Reference implementation: adom/fusion-bridge dashboard/ + dock.json + install.sh + dev-skills/fusion-dashboard. Happy to review kicad's port.