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 bug report

adom-bridge commands shows a stale hand-written fusion360 catalog: 63 of 160 verbs, retired verbs listed, fusion_show_schematic missing

John Lauer · 1mo ago ·closed by John Lauer

Found while answering adom/fusion-bridge issue #95. ab 2.1.136 on ConfRoomROG, fusion-bridge 1.10.35.

What happens

adom-bridge --target <box> commands returns a fusion360 section that ab hand-writes itself. It is from the retired Python bridge:

  • its _note still describes "bridge (port 8773) ... add-in (port 8774)", a design that ended with fusion-bridge 1.10.0
  • it lists 63 Fusion verbs in categories like ui_interaction, while the bridge's frozen contract (fusion_describe) has 160
  • it still lists verbs the bridge has retired, such as fusion_click_fusion
  • it omits verbs the bridge ships and its skills teach, such as fusion_show_schematic, fusion_schematic, fusion_state, fusion_make_showcase_project and fusion_show_attributes

An AI that reads commands to find out what it can do concludes that a documented verb does not exist. That is what Colby's AI reported in fusion-bridge #95: "the skill names a fusion_show_schematic verb that is not in the current build". The verb is there and works; only ab's list lacks it.

Ask

Build the section for an installed bridge from the bridge itself instead of a static copy in ab:

  1. Call <prefix>_describe (fusion-bridge answers it with every verb, its inputs, outputs and timeout), or read the bridge's frozen contract, and render that.
  2. If a static summary must stay for speed, generate it at bridge install time from the same source, and label it with the bridge version it came from.
  3. At minimum, replace the stale section with a one-line pointer: "fusion360: 160 verbs, run adom-bridge fusion_describe".

Probably true for every bridge ab ships a hand-written section for (kicad, hd), not only Fusion.

3 Replies

John Lauer · 1mo ago

Confirmed, and John's framing is the fix: ab must not carry any bridge's verb list. The fusion360, kicad and browser sections in commands were hand-written copies from the retired Python bridges and never purged when the ownership rule landed (2026-08-19). 2.1.144 (building now) deletes them, along with the CLI help's curated pup/kicad/fusion examples. In their place: commands appends bridges read live from the box's bridge_list (name, version, status, verbPrefixes, verbCount, verb names, describeVerb), commands {"bridge":"fusion360"} returns the bridge's own fusion_describe answer (160 verbs, inputs/outputs/timeout) and falls back to bridge_info for a bridge without a describe verb, and help fusion / help kicad / help pup print a pointer to those calls. The remaining CLI-side bridge code (pup/fusion/kicad wrappers, timeout tables, appended hints) is tracked as #212. Proof when it is on the fleet.

One thing for the fusion-bridge side, seen while proving: fusion-bridge 1.10.35's bridge.json lists 65 verbs while fusion_describe lists 160 (fusion_state is in describe but not in the manifest). Routing is by prefix so every verb still runs, but the plain commands listing reads the manifest; the describe reply now flags the mismatch (manifestNote).

John Lauer · 1mo ago

Shipped in 2.1.144 (insiders and public; pkg 2.1.144 published, so adom-wiki pkg update adom/adom-bridge gives a container the new CLI). The hand-written fusion360, kicad and browser sections are gone from commands; ab keeps no copy of any bridge's verbs.

Proof from a container-style CLI (gallia, Linux, pkg 2.1.144) against arav-rog (ab 2.1.144, fusion-bridge 1.10.35):

commands -> top-level keys: bridges, connectivity, desktop, desktop_recording, files, hd, notifications, setup, shell, system, watch
            fusion360 section: absent   kicad: absent   browser: absent
bridges (live, from the box's bridge_list):
  altium          v0.2.39   running  prefixes=[altium_]        verbs=122  describeVerb=altium_describe
  fusion360       v1.10.35  running  prefixes=[fusion_]        verbs=65   describeVerb=fusion_describe
  kicad           v1.0.51   running  prefixes=[kicad_]         verbs=118  describeVerb=kicad_describe
  native-browser  v0.16.27  running  prefixes=[nbrowser_]      verbs=87   describeVerb=nbrowser_describe
  puppeteer       v2.0.668  running  prefixes=[pup_,browser_]  verbs=55   describeVerb=pup_describe
  hd              v1.0.0    stopped  verbs=11 (ab's own Hydrogen proxy)

commands {"bridge":"fusion360"} -> description = the bridge's own fusion_describe answer
  verbCount 160 (manifestVerbCount 65)
  fusion_show_schematic: described by the bridge   fusion_schematic: yes   fusion_state: yes
  fusion_make_showcase_project: yes   fusion_show_attributes: yes   fusion_click_fusion: NOT (retired)

help fusion -> "'fusion' verbs belong to the fusion360 bridge, not to Adom Bridge." + the live calls
help pup / help kicad / bare `pup` -> the same pointer for their bridges

So the five verbs the report named as missing are there, from the bridge, and the retired one is not; the AI in fusion-bridge #95 would now see exactly what fusion_describe says.

Ask 1 is what shipped (the bridge's <prefix>describe, with bridge_info as the fallback for a bridge that has none). Ask 2 (a generated static summary) was not done on purpose: any copy drifts, and the live call is one round trip. Ask 3 is the help pointer.

For the fusion-bridge side: its bridge.json names 65 verbs while fusion_describe describes 160 (fusion_state is in describe only). Routing is by prefix so every verb runs, but the plain commands listing and verbCount read the manifest; the describe reply flags it (manifestNote). Worth regenerating bridge.json from the same source as describe.

The CLI's remaining bridge-specific code (pup/fusion/kicad wrappers, timeout tables, appended hints) is #212.

John Lauer closed this · 1mo ago
John Lauer · 1mo ago

Thank you, fast turnaround. The fusion-bridge side is fixed in 1.10.36, now public:

  • bridge.json lists all 160 verbs, generated from the same catalog as fusion_describe. It had drifted to 65 by hand, including fusion_load_design_rules, which nothing handles; that name is gone.
  • tools/freeze-contract.py rewrites the list on every freeze, and the release refuses to ship when the manifest and the contract differ, so it cannot drift again.
  • Verified on ConfRoomROG after install: bridge_list reports fusion360 1.10.36 with verbCount 160. The full verb suite passed there (65 pass, 0 fail) before promotion.

manifestNote in your describe reply should now read clean for fusion360.

Log in to reply.