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 Issues40 Breadcrumbs Pull Requests Activity
Closed feature request

Bundle the adom-wiki CLI with Adom Desktop so wiki commit/push can run on the user's PC (avoid the pull-to-container round trip)

noah · 1mo ago ·closed by John Lauer

Problem

When an AI assistant (running in the cloud/Docker container) version-controls a users local project on the Adom Wiki, the files live on the USERS PC but the adom-wiki CLI only exists in the container. So every commit is a round trip:

  1. adom-desktop pull_file each changed file from the PC into the container,
  2. adom-wiki repo push <owner>/<slug> --files ... -m "..." from the container.

For a KiCad project that means copying the .kicad_pro/.kicad_sch (+ hierarchical sub-sheets) / .kicad_pcb / .step / .glb across on every single commit — slow, brittle (a missed sub-sheet = a broken commit), and it duplicates files that already sit on the PC. It also means the containers copy and the PCs copy can drift.

Request

Bundle the adom-wiki CLI with Adom Desktop (the AD installer already drops adom-desktop-cli.exe into %LOCALAPPDATA%\Adom Desktop\ and puts it on PATH — ship adom-wiki.exe the same way), and expose a verb so a cloud/relay AI can run wiki repo operations DIRECTLY on the PC where the files already are. Sketch:

  • adom-desktop wiki_push {repo, cwd, files[], message} → runs adom-wiki repo push locally in the project dir on the PC, no pull needed.
  • Or a generic adom-desktop wiki_exec {args[], cwd} passthrough to the bundled adom-wiki.
  • Auth: reuse the users existing adom-wiki` token/session on the PC (AD is already signed in to Adom Cloud), so the AI never handles credentials.

Benefit

commit my project becomes a single call that runs where the files live — no per-file pull_file, no missed sub-sheets, no container/PC drift. This is the #1 friction point in the "version-control my KiCad board on the wiki from a cloud AI" workflow today.

Environment

  • adom-desktop 1.9.102; adom-wiki CLI 1.0.22
  • Reproduced repeatedly 2026-07-09..10 committing a hierarchical KiCad project to a private wiki page

1 Reply

John Lauer · 26d ago

Shipped in AD 1.9.116. (1) adom-wiki.exe now ships in the installer next to adom-desktop-cli.exe in %LOCALAPPDATA%\Adom Desktop\ (verify_bundle gates it so it can never silently drop out). (2) New verb wiki_exec, the generic passthrough you sketched: adom-desktop wiki_exec '{"args":["repo","push","adom/my-board","--files","board.kicad_pcb","board.kicad_sch","-m","rev B"],"cwd":"C:\Users\me\boards\my-board"}' runs adom-wiki ON the PC in the project dir, so commits need zero per-file pull_file and there is no container/PC drift. Auth: AD injects the signed-in user's session token as ADOM_WIKI_TOKEN; the caller never handles credentials. Returns {exitCode, stdout, stderr, timedOut, durationMs}. It is Tier-2 gated for relay callers (same class as shell_execute) since it writes to the wiki as the user; on John-style boxes with Bypass granted it just runs. Update the laptop AD to 1.9.116 (auto-update banner or relay apply_update) and refresh the container CLI to see the verb in the help map.

Log in to reply.