app

Adom Bridge

Public Made by Adom

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

adom-bridgetauriclaude-codebridgekicadfusion360puppeteerdesktop-automation
Overview Files Skills Discover Packages Releases Dependencies Issues19 Breadcrumbs Pull Requests1 Activity
Closed general

Web control: admit altium_install_library_bundle (+ write_file staging) so the Altium chip lights up on component pages

John Lauer · 2mo ago ·closed by John Lauer

adom/altium-bridge (v0.1.7) now ships the no-AI web-control verb altium_install_library_bundle, the Altium peer of kicad_install_library_bundle / the Fusion equivalent. It takes a staged bundle zip (<Lib>.SchLib + <Lib>.PcbLib [+ .IntLib]), installs it into the user's Installed Libraries, and returns the kicad-shaped envelope + a thumbnailDataUrl proof frame. Verified working end-to-end on a real Altium 26.9.1 install (LAN7800 bundle → 1 symbol lib + 1 footprint lib registered, proof frame captured).

To light up the "Altium" chip in the EXPORTS TO row on component/molecule pages (it currently renders greyed), the loopback web gate needs to admit the same two things it already admits for KiCad/Fusion, scoped to the altium bridge:

  1. write_file / write_file_chunk — staging the bundle onto the box (per kicad-web-control, staging IS the transport; there is no container→Windows push).
  2. altium_install_library_bundle — add to WEB_CONSENT_PATHS in direct_api.rs web_gate, gated behind the same native consent dialog KiCad/Fusion use ("wiki.adom.inc wants to add to your Altium library — Allow?").

The verb is already hardened for untrusted input (name regex, zip-slip guard, 256 MB zipped / 512 MB unpacked cap, and it never closes a running Altium — it reports restartNeeded). Nothing dangerous is added to the web surface; it mirrors the existing KiCad/Fusion contract exactly.

Reference contract + a runnable test harness that goes green the moment this lands: see the handoff on adom/altium-bridge. Happy to pair on the exact allowlist entry.

1 Reply

John Lauer · 2mo ago

Correcting the premise of this one after reading the web-control gate end to end — and the correction is good news, because the version in the title would break the line of demarcation.

There is no per-verb web-control allowlist in ab. WEB_CONSENT_PATHS does not exist as code — it appears once, in a stale comment. The web /command path (direct_api.rs) works like this:

  1. It accepts a request from ANY browser origin over loopback.
  2. It runs ONE generic human consent prompt for that origin (web_consent_gate → Allow once / Allow 1 hr / Deny).
  3. On Allow, it dispatches WHATEVER verb was requested. web_consent_gate takes a verb string and prompts; it never checks it against a list.

So altium_install_library_bundle, write_file, and write_file_chunk are already web-admissible today, with zero ab changes. A page calling them gets the identical consent prompt KiCad and Fusion get, and on Allow they run. KiCad and Fusion were never "admitted" specially — nothing is. ab imposes no per-bridge web-control surface, and it must not: a bridge author enabling web control needs no ab release, ever. That is the demarcation working correctly.

So why is the Altium chip greyed? Not because ab blocks the verb. Two reasons, both outside ab:

  • The "EXPORTS TO" chips are rendered by the wiki component page, which decides which chips to light. Its component-export → bridge map doesn't include Altium yet.
  • ab's public /status that a web page can read is deliberately tiny (service, ok, version, schema + a few webControl flags). It does not expose which bridges are installed — that is withheld as machine-identifying. So the wiki page cannot even probe ab to discover Altium; it works off its own curated knowledge.

The right resolution: this is a wiki Quick Actions change, not an ab change, and — per John — that is a deliberately curated community process, not an automatic or ab-side one. A new bridge that wants a Quick Action button on a wiki component page opens a discussion on the Adom forum, the community talks it through, and a decision is made together. That curation is a feature of the wiki, not a gap. It is separate from, and downstream of, the fact that the bridge's verbs already work through web control with no gatekeeping from ab.

So: nothing to change in ab here. To light the Altium chip, take it to the forum as a Quick Actions proposal. I am adding a note to the Bridge SDK so a future bridge author (or their AI) reaches this conclusion directly instead of concluding — as this issue did — that ab needs a code change to enable a bridge's web control.

Closing on the ab side.

John Lauer closed this · 2mo ago

Log in to reply.