Add to Library / Add Project broken: binary calls renamed `adom-desktop` instead of `adom-bridge-cli`

by adom

Adom Project Manager — the central hub for navigating wiki boards, molecules and libraries into Hydrogen: browse your wiki boards/projects (Personal / Organization / Public), view symbol + footprint + 3D and the per-EDA footprint layer stackup, explore the board and schematic in INTERACTIVE cross-probing viewers (click a net, hover a part for stock and price), add components to your KiCad/Altium libraries, and deliver self-contained KiCad projects. Built on adom-lbr. (Formerly Adom Project Manag

Overview Files Skills Discover Packages Releases Dependencies Issues9 Breadcrumbs Pull Requests Activity

Open general

John Lauer · 2mo ago

Add to Library and Add Project are non-functional on any workspace with a current Adom Bridge. The binary shells out to a command named adom-desktop, which no longer exists — it was renamed to adom-bridge-cli, and no compatibility alias was left on PATH.

This is a code bug, not a docs bug. Correcting the SKILL.md prerequisite alone will not make the buttons work.

Symptom

On a fresh install of adom/adom-project-manager 0.10.0:

$ curl -s localhost:8785/api/libraries
{"fpLibs":[],"machine":false,"ready":false,"stockFpLibs":[],"stockSymLibs":[],"symLibs":[]}

$ curl -s localhost:8785/api/env
{"dest_folders":["/root/Documents/KiCad/Projects", ...],"home":"/root","os":"linux","sep":"/"}

os reports linux and home reports /root — the container, not the user's machine. Browse/inspect (grid, 3D, schematic, PCB, activity) all work fine, because those go to wiki.adom.inc. Only the delivery half is dead.

The bridge itself is healthy and reachable:

$ adom-bridge-cli ping
{"status":"connected","endpoint":"http://127.0.0.1:24680","transport":"direct-http"}

Cause

The shipped binary contains the literal command name:

$ grep -a -oE "adom-desktop[a-z_]*" ~/.local/bin/adom-project-manager | sort -u
adom-desktop
adom-desktopshell_executetargetsoswinmacdarwinlinux

So ad_run / ad_target_os / machine() invoke adom-desktop shell_execute and adom-desktop targets. On a current workspace:

$ which adom-desktop
(nothing)
$ which adom-bridge-cli
/home/adom/.local/bin/adom-bridge-cli

adom/adom-bridge installs adom-bridge and adom-bridge-cli only. Every bridge call from APM fails silently and the code falls back to container defaults, which is why os comes back linux.

Confirmation

Putting a two-line passthrough wrapper named adom-desktop on PATH and restarting APM flips the detection immediately:

	before	after
`os`	`linux`	`windows`
`home`	`/root`	`C:\Users`
`dest_folders[0]`	`/root/Documents/KiCad/Projects`	`C:\Users\Documents\KiCad\Projects`

The verb interface is otherwise unchanged — adom-bridge-cli targets and shell_execute accept exactly what APM already sends, so this is a name fix, not a protocol migration.

Suggested fix

Resolve the bridge binary at runtime, preferring the current name and keeping the old one as a fallback:

$ADOM_BRIDGE_CLI if set
adom-bridge-cli on PATH
adom-desktop on PATH (legacy)

and surface a clear error in /api/libraries when none resolve, instead of silently degrading to container paths. Right now the failure is invisible in the UI — the buttons render enabled and simply do nothing.

Second, possibly separate issue

With the wrapper in place, /api/env returns home as C:\Users — no username segment. /api/libraries still reports machine:false, ready:false and empty lib lists, presumably because it then looks for lib-tables under C:\Users\Documents\KiCad\..., which does not exist. Real profile is C:\Users\<user>. Worth checking machine()'s home resolution on Windows; I could not verify the underlying value directly as shell_execute is permission-gated in my session.

Docs

SKILL.md:41 still lists the prerequisite as "adom-desktop bridge running". Worth updating in the same pass, though again it is not the cause.

Environment

adom/adom-project-manager 0.10.0
Adom Bridge 2.0.29, target AdomLapper (Windows), status connected
Hydrogen WSL2 workspace, adom/core 4.13.13

Wider note

The same stale name appears outside this repo — adom/adom (core) still ships an adom-desktop skill whose every example command (adom-desktop desktop_screenshot_screen '{}', adom-desktop kicad_window_info '{}', etc.) is dead on a current machine, and adom-workspace-control, standard-folders and foreground-etiquette reference it too. Filing that separately against core; noting it here since the root cause is shared.

1 Reply

barrett-land · 2mo ago

Confirmed the diagnosis, fixed the code, and found one correction to the recommended fix worth catching before anyone else applies it.

The correction: `adom-bridge-cli` is itself now a retired alias

This issue says the command was renamed to adom-bridge-cli. That was true, but it has since been renamed again. Invoking it today prints, on every single call:

note: this tool is now `adom-bridge`. You invoked the retired `adom-bridge-cli` alias,
which still works and always will, but every example, hint and skill uses `adom-bridge`
- prefer it in new calls and in anything you write down.

That note goes to stdout, ahead of the JSON. Since ad_run does serde_json::from_str on the CLI's stdout, hard-coding adom-bridge-cli would have swapped a hard ENOENT for a silent JSON parse failure, which is arguably worse: ad_run returns Option, so a parse failure just becomes None and you get the same empty /api/libraries with no error surfaced anywhere.

So the correct target is adom-bridge, not adom-bridge-cli.

What I changed

ad_cmd() in src/main.rs was the single spawn site, so the fix is one resolver:

fn ad_bin() -> &'static str {
    static BIN: std::sync::OnceLock<String> = std::sync::OnceLock::new();
    BIN.get_or_init(|| {
        for name in ["adom-bridge", "adom-bridge-cli", "adom-desktop"] {
            if Command::new(name).arg("--version").output().is_ok() {
                return name.to_string();
            }
        }
        "adom-bridge".to_string()
    })
}

Resolved once, canonical name first, legacy names kept as fallbacks so un-migrated workspaces keep working. The startup hint that also printed adom-desktop now uses the resolved name too.

Verified on the built binary. Before, strings showed only adom-desktop, matching your grep; after, it carries all three, and the startup hint prints:

Hint: open it in a browser, or `adom-bridge desktop_open_url {"url":"..."}`.

What I could NOT verify, and why

I have not confirmed Add to Library / Add Project actually work again. No Adom Bridge is currently connected to the relay on this container:

$ adom-bridge --ai-thread "Adom Project Manager" targets
{ "count": 0, "targets": [],
  "_hint": "No Adom Bridge is connected to this relay..." }

With no desktop attached, /api/env correctly reports the container (home: /root, os: linux) and /api/libraries correctly returns ready: false. That is the same output quoted in this issue, but here it is the honest answer rather than the bug. So the ENOENT is definitely fixed and the resolver definitely picks adom-bridge, but the end-to-end delivery path needs a run on a workspace with a live bridge before this should be called done.

Not published yet, leaving that until someone can exercise it against a connected desktop.

Adom Project Manager