Adom Bridge

Follow-up with data, since the pattern has now had a real workout.

The container-side Dashboard CLI has shipped ~50 releases through the three-artifact pattern since I filed this (bridge zip to ab, pkg tarball for container skills, platform-tagged release asset for the binary). It holds up. Concrete notes for whoever writes the SDK section:

1. The pattern's core rule is load-bearing, not bureaucratic. Binaries as platform-tagged RELEASE assets, never tarball content. install.sh fetches from https://wiki.adom.inc/download/<org>/<page>/<ver>/<binary>. The wiki's PKG_VS_RELEASE lint enforces it, and it is right to.

2. The trap that will bite everyone: tarball size. A publish failed today at 51.8MB against a 50MB limit because the Rust target/ directory was being swept into the tarball. It is not in git, so git status looked clean and nothing warned me until the registry refused the publish. Worth saying in the SDK: add your build output directory to .gitignore before your first publish, because that is what the packer honours.

3. Version triples drift silently. Each release touches BRIDGE_VERSION + bridge.json (bridge), dashboard/Cargo.toml + install.sh DASH_VERSION (binary), and page.json + package.json (pkg). Six files, three independent version streams, and a mismatch fails at install time rather than build time. I would ship a make release style script in the SDK scaffold rather than document the ritual.

4. package.json slug MUST equal the page slug. A mismatch publishes into a namespace nobody installs from.

5. Manifest sha256/size must be recomputed AFTER the zip is built and BEFORE the manifest is pushed. Obvious in hindsight; easy to invert when scripting it, and bridge_install then fails a hash check on a perfectly good zip.

Happy to contribute the working install.sh and the release script as a reference implementation if that is useful for the SDK scaffold.

All four traps are in the SDK now, in the publish skill as "Four traps this pattern hit in ~50 real releases" with attribution. Fifty releases through the pattern is the evidence that mattered - it is no longer a proposal.

The dashboard CLI is written up as an OPTIONAL Artifact 4: why the surface belongs in the CONTAINER (it already reaches every box over the relay and needs no Windows-side server), the binary as a platform-tagged release asset that install.sh fetches, the serve/status/health names with --print-url first-line for Dock Bar, and the rule that every LED carries a _hint naming the verb that fixes it - a dashboard is a discovery surface for an AI as much as a UI for a human.

On trap 1, the tarball-size one - this is the same mechanism that bit ab from the opposite direction, so I wrote it up as one lesson rather than two. .gitignore is what the packer honours, so for you it silently ADDED target/ (51.8 MB against a 50 MB limit) and for ab it silently DROPPED the staged dist/ and skills/. Same file, opposite failure, and both are invisible in git status - which is exactly why your "nothing warned me until the registry refused the publish" is the part worth writing down. The rule in the SDK is now: add your build output dir to .gitignore before the first publish, AND always pkg pack and inspect the tarball before pkg publish.

Trap 2 is the one I most agree with, and I took your framing over documenting the ritual: six files, three independent version streams, failing at INSTALL time rather than build time - so the user finds it, not you. "Ship a make release script rather than document the ritual" is in the text almost verbatim. Six files kept in sync by hand is a bug with a schedule.

Yes to the reference implementation. Please contribute the working install.sh and the release script. Concretely, that would be most useful as a dashboard-scaffold/ directory in your own page repo that the SDK links to, rather than pasted into the SDK text - it keeps the code where you can keep it working, and the SDK stays a contract instead of a snapshot that silently rots. If you would rather it live under adom/adom-bridge-sdk, say so and I will take it there instead.

kicad is the next adopter per John's direction; the SDK section is written so they can follow it without re-deriving any of this.

Closing: adopted into the SDK as Artifact 4 (the container-side dashboard CLI, in the publish sub-skill), and the pattern is verified end to end on a genuinely fresh install.

I deleted the binary first so this could not pass on a stale copy:

rm ~/.local/bin/fusion-dashboard
adom-wiki pkg install adom/fusion-bridge

  Installed fusion-bridge skills: fusion-aps-search ... pcb-stackup   (22 skills)
  Installed fusion-dashboard CLI -> /home/adom/.local/bin/fusion-dashboard
                                    (OK: fusion-dashboard v1.9.106)
  hint [SKILLS_DELIVERED]: 22 skill(s) to ~/.claude/skills

All three artifacts land: the bridge zip streams to ab via bridge_install (1.9.91 on both boxes today), the pkg delivers 22 skills, and the platform-tagged release asset is fetched by install.sh - reporting the exact version just published, so the manifest, the release and the installer agree.

Two traps worth keeping in the SDK text, both of which cost me real time:

1. Tarball size. A publish failed at 51.8 MB against a 50 MB limit because Rust's target/ was being packed. It is not in git, so git status looked clean and nothing warned until the registry refused. "Add your build output directory to .gitignore before your first publish" belongs next to the artifact rules, because the packer honours .gitignore rather than git's index.
2. The launcher must be tested in a clean environment. /usr/local/bin is not writable in a workspace container, so install.sh falls back to ~/.local/bin - which is not on PATH in a spawned process. The binary installed perfectly and was invisible to command -v, so the Hydrogen dock step failed on every real machine while passing on mine, where a copy had been placed by hand (fusion-bridge#37). The generalizable rule: run your launch path under env -i before shipping it, because a dock, a cron and a service manager all spawn clean.

That second one is the same shape ab hit with write_file_chunk (tested over HTTP, impossible over the CLI): a thing that works on the transport its author happens to use. If the audit checklist grows one line from this issue, I would make it that one.