app
Adom Bridge
Public Made by Adomby 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
← Commit history
Publish 2.1.147
6 files changed
+96−97
README.md+1−1@@ -127,7 +127,7 @@ A dedicated Chrome-for-Testing (or Edge) that Adom Bridge downloads and manages:  -Your *real*, signed-in Chrome or Edge profile, for the logins and forms a throwaway automation profile cannot do. The desktop bridge is bundled and works extension-free out of the box: it discovers your browser profiles, opens URLs in the right signed-in profile (OAuth consent flows), and inventories browser windows. Installing the companion browser extension unlocks full in-page drive: tabs, clicks, JS eval, and background screenshots. +Your *real*, signed-in Chrome or Edge profile, for the logins and forms a throwaway automation profile cannot do. The desktop bridge is fetched from its wiki page on first launch and works extension-free out of the box: it discovers your browser profiles, opens URLs in the right signed-in profile (OAuth consent flows), and inventories browser windows. Installing the companion browser extension unlocks full in-page drive: tabs, clicks, JS eval, and background screenshots. ### KiCad (`kicad_*`)
dist/linux/adom-bridge⋯ 1 unchanged line ⋯
package.json+1−1@@ -1,6 +1,6 @@ { "slug": "adom-bridge", - "version": "2.1.146", + "version": "2.1.147", "type": "app", "brief": "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-only permission system keeps you in charge of every side-effecting command.", "description": "Install this package in a cloud or Hydrogen Desktop container, not on the PC. It delivers two things: the Linux adom-bridge-cli (linked onto PATH) and the Claude skill set that teaches an AI every desktop verb (shell, files, screenshots, windows, notifications, KiCad, Fusion 360, browser automation). The CLI drives the Adom Bridge app running on your Windows PC over the relay; the Windows app itself is the separate installer in the Download box, not part of this package. Run adom-wiki pkg update to keep the CLI and skills current.",
page.json+1−1@@ -1,6 +1,6 @@ { "slug": "adom-bridge",- "version": "2.1.146",+ "version": "2.1.147", "type": "app", "description": "Install this package in a cloud or Hydrogen Desktop container, not on the PC. It delivers two things: the Linux adom-bridge-cli (linked onto PATH) and the Claude skill set that teaches an AI every desktop verb (shell, files, screenshots, windows, notifications, KiCad, Fusion 360, browser automation). The CLI drives the Adom Bridge app running on your Windows PC over the relay; the Windows app itself is the separate installer in the Download box, not part of this package. Run adom-wiki pkg update to keep the CLI and skills current.", "keywords": [
skills/adom-bridge-bridges-guide/SKILL.md+7−9@@ -81,17 +81,16 @@ The AI always does the install; the level only sets timing and consent: | Level | Bridge(s) | Behavior | |---|---|---| | 0 built-in | Hydrogen (`hd`) | The platform itself; a manifest stub only, never installed by ab. | -| 1 fundamental, pre-emptive | Puppeteer (`pup`) | Bundled seed; ab pre-installs its runtime (Node + Chrome-for-Testing) in the background on first boot. | -| 2 recommended, proactive offer | native-browser | The desktop bridge half is bundled (works extension-free day one); the in-browser extension is proactively offered and installs on a yes. | +| 1 seeded | Puppeteer (`pup`), native-browser, KiCad, Fusion 360 | Named in ab's `seeds.json` (name + manifest URL, nothing else): a fresh install fetches each from its own wiki page on first launch (2.1.147, wiki #212; before, copies of them shipped inside the installer). ab prewarms the Node/Python runtimes; a bridge downloads its own assets (pup fetches Chrome for Testing itself). | | 3 on-request host app | KiCad, Fusion, Altium, ... | ab detects the host app; it never pre-installs a multi-GB app unasked, and never tells the user to install it manually — the AI installs it the moment the user wants it. | | 4 explicit third-party | any `bridge_install`'d bridge | The user opts in by installing it from its wiki manifest URL. | ## Updates — each bridge from its OWN wiki page -Bundled seeds auto-update from their own wiki pages: on launch + every 4 hours, ab checks -each registered bridge's `updateManifestUrl`; a strictly-newer version downloads -(sha256-verified) into `~/.adom/bridges-cache/` and cache-over-bundled supersedes the -seed. On demand: +Every bridge updates from its own wiki page: on launch + every 4 hours, ab checks +each registered bridge's `updateManifestUrl` (a seed not installed yet uses the URL in +`seeds.json`); a strictly-newer version downloads (sha256-verified) into +`~/.adom/bridges-cache/`. On demand: ```bash adom-bridge bridge_check_updates # READ-ONLY: current vs wiki latest per bridge @@ -100,8 +99,7 @@ adom-bridge refresh_bridges # apply updates for ALL bridges that adom-bridge refresh_bridges '{"name":"kicad"}' # or just one ``` -Version semantics: `current` = what ab actually runs = the newer of cache and bundled -(numeric semver). After an update, the running server process still holds old code until +Version semantics: `current` = what ab actually runs = the cache copy (numeric semver). After an update, the running server process still holds old code until it respawns; the version-aware liveness check forces a respawn on the next verb call, so you normally do not need to kill anything. @@ -160,7 +158,7 @@ adom-bridge bridge_readiness # read `error`; confirm with bridge_list. Never treat a parsed manifest as an install. adom-bridge bridge_install '{"manifestUrl":"https://wiki.adom.inc/api/v1/pages/<bridge-page>/files/<bridge>-bridge-manifest.json"}' -# Remove one. Bundled bridges revert to the bundled copy; third-party are fully removed. +# Remove one. A seed comes back from the wiki on the next launch/sync; a third-party bridge stays removed. adom-bridge bridge_uninstall '{"name":"my-bridge"}' ```
skills/adom-bridge-ownership/SKILL.md+86−85@@ -1,85 +1,86 @@-name: adom-bridge-bridge-ownership-description: The boundary between Adom Bridge core and a bridge author — what ab owns vs what you (the bridge) own. Read before filing an ab bug about a bridge (kicad, fusion360, native-browser, puppeteer, blender, rdp, or any third-party bridge) or before editing bridge code, so you fix and report in the right place.--# Who owns what: ab core vs bridge author--**Read this FIRST if you're working on, debugging, or filing a bug about a bridge-(kicad, fusion360, native-browser, puppeteer, blender, rdp, or any third-party-bridge).** It exists because an AI drove the Fusion bridge end-to-end, hit a dozen-issues, and filed almost all of them against **adom-bridge** — when nearly every-one was **bridge code**. The platform never stated the boundary, so the AI guessed-"ab," posted to the wrong place, and hand-edited the wrong copy. Don't repeat that.--## The split--### Adom Bridge (ab) core owns-- The `adom-bridge` CLI + the **relay / `/command` passthrough** (ab relays a- bridge's response **verbatim** — incl. `_hint`/`_next`/`related` and every other- top-level field the bridge sets; v1.9.30 made this a denylist, never an allowlist).-- **Bridge lifecycle**: discover/register/spawn/reap, stable ports, the- `bridge_*` verbs, and **streaming a bridge from its wiki page into the local- cache** (`bridge_install` / `refresh_bridges` / the 4-h auto-sync).-- The core `desktop_*` verbs (input, screenshot, UIA, tunnels, wsl, …).-- Generic, app-agnostic behavior. **ab returns good DATA so the calling AI decides- — it does NOT bake in app-specific verbs** (see CLAUDE.md "ab stays GENERIC").--### The bridge author owns (NOT ab)-- **Every bridge-specific verb and its behavior** — args, outputs, and the per-call- `_hint`/`_next`/`related`/`pitfalls` (the rich-hint contract). A wrong/missing- hint is a **bridge** fix.-- **Any integration the bridge ships** — e.g. Fusion's **APS** cloud search: its- OAuth/auth, its config, its `*_aps_*` verbs, its never-charge caps. ab does NOT- manage it. Divergent results from the bridge's own status verb = a **bridge** bug.-- **The bridge's add-in / plugin code AND getting it deployed into the host app.**- Editing the streamed cache source is not enough if the host app loads the add-in- from elsewhere (e.g. Fusion loads from `%APPDATA%\…\API\AddIns\`, not the- bridges-cache) — wiring cache→host-app is the **bridge's** concern.-- The bridge's `SKILL.md`, `describe` verb, hero/wiki page, and version.-- The **edit-source → publish → bump version → reinstall** loop.--## The cardinal rules--1. **NEVER hand-edit the streamed cache** (`%LOCALAPPDATA%\Adom Bridge\bridges-cache\<bridge>\`).- It's a download. Edit the **source** (the bridge's own repo/wiki), `publish`,- bump the version, then `bridge_install`/`refresh_bridges` to pull it. A- hand-edit is overwritten on the next sync and may not even be what the host app- runs (cache-vs-deployed-copy gotcha).-2. **Before filing a bridge bug against adom-bridge, ask "who owns this?"** If it's- verb behavior, a hint, an integration, an add-in, or the bridge's docs → it's the- **bridge author's** repo/wiki, not ab. Cloud-owned bridges (kicad, fusion, puppeteer)- live in their OWN wiki repos (see CLAUDE.md "Cloud-owned bridge repos").-3. **ab's job is to relay + host, generically.** If ab is *dropping* or *mangling*- a bridge's data, or missing a lifecycle/verb capability — THAT is an ab bug.- Fix the ab VERB; don't re-absorb the bridge.--When in doubt: data-shape/relay/lifecycle/ports → **ab**; what a verb does, its-hints, its integration, its add-in, its docs → **the bridge**.--## Skill ownership — a bridge ships its OWN skill pkg (not bundled in ab-core)--The same boundary applies to the **consumer skill** (the SKILL.md that teaches a cloud-container how to drive a bridge's verbs):--- **The ab-core pkg** (`adom-wiki pkg install adom/adom-bridge`) ships ONLY core skills —- desktop verbs, discovery, direct-api, installer, notify, multi-ad, bridge-sdk,- bridge-ownership, windows-host. It must NOT bundle a cloud/3rd-party bridge's skill (it- would go stale and isn't ab's to own). (2026-06-28: `eagle-commands.md` — Fusion-Electronics,- `fusion_electron_run` — was dropped for this reason; 2026-06-29: `pup-SKILL.md` was dropped- too when Puppeteer became cloud-owned. Both belong in their bridge's own pkg.)-- **Each cloud/3rd-party bridge publishes its OWN skill pkg** carrying its SKILL.md, e.g.- `adom/kicad-bridge`, `adom/fusion-bridge`,- `adom/pup-bridge`. The cloud thread that owns the bridge owns + bumps it.- (Puppeteer's runtime still ships as an NSIS-bundled SEED for fresh-PC/offline spawn — but its- *skill* now ships from its own page, like the other cloud bridges.)-- **How a container gets dynamic bridge skills:** it does NOT get them from the ab-core install.- It (a) installs ab-core (CLI + core skills), then (b) `adom-bridge bridge_list` against the- live laptop ab to see which bridges are present, then (c) `adom-wiki pkg install- adom/adom-bridge-<bridge>-bridge` for each one it needs (and `adom-wiki pkg update` keeps them- fresh, version-matched to the bridge the cloud thread published). The bridge's runtime PAYLOAD- (what ab spawns on the laptop) is a SEPARATE artifact — the `/files` manifest+zip that- `bridge_install`/`refresh_bridges` pull — don't conflate it with the skill pkg.-- **Discoverability gap / enhancement:** `bridge_list` should surface the exact- `adom-wiki pkg install adom/adom-bridge-<name>-bridge` line per live bridge so a container- knows precisely which skill pkg to pull (today it infers the slug from the bridge's `docs`).+--- +name: adom-bridge-bridge-ownership +description: The boundary between Adom Bridge core and a bridge author — what ab owns vs what you (the bridge) own. Read before filing an ab bug about a bridge (kicad, fusion360, native-browser, puppeteer, blender, rdp, or any third-party bridge) or before editing bridge code, so you fix and report in the right place. +--- + +# Who owns what: ab core vs bridge author + +**Read this FIRST if you're working on, debugging, or filing a bug about a bridge +(kicad, fusion360, native-browser, puppeteer, blender, rdp, or any third-party +bridge).** It exists because an AI drove the Fusion bridge end-to-end, hit a dozen +issues, and filed almost all of them against **adom-bridge** — when nearly every +one was **bridge code**. The platform never stated the boundary, so the AI guessed +"ab," posted to the wrong place, and hand-edited the wrong copy. Don't repeat that. + +## The split + +### Adom Bridge (ab) core owns +- The `adom-bridge` CLI + the **relay / `/command` passthrough** (ab relays a + bridge's response **verbatim** — incl. `_hint`/`_next`/`related` and every other + top-level field the bridge sets; v1.9.30 made this a denylist, never an allowlist). +- **Bridge lifecycle**: discover/register/spawn/reap, stable ports, the + `bridge_*` verbs, and **streaming a bridge from its wiki page into the local + cache** (`bridge_install` / `refresh_bridges` / the 4-h auto-sync). +- The core `desktop_*` verbs (input, screenshot, UIA, tunnels, wsl, …). +- Generic, app-agnostic behavior. **ab returns good DATA so the calling AI decides + — it does NOT bake in app-specific verbs** (see CLAUDE.md "ab stays GENERIC"). + +### The bridge author owns (NOT ab) +- **Every bridge-specific verb and its behavior** — args, outputs, and the per-call + `_hint`/`_next`/`related`/`pitfalls` (the rich-hint contract). A wrong/missing + hint is a **bridge** fix. +- **Any integration the bridge ships** — e.g. Fusion's **APS** cloud search: its + OAuth/auth, its config, its `*_aps_*` verbs, its never-charge caps. ab does NOT + manage it. Divergent results from the bridge's own status verb = a **bridge** bug. +- **The bridge's add-in / plugin code AND getting it deployed into the host app.** + Editing the streamed cache source is not enough if the host app loads the add-in + from elsewhere (e.g. Fusion loads from `%APPDATA%\…\API\AddIns\`, not the + bridges-cache) — wiring cache→host-app is the **bridge's** concern. +- The bridge's `SKILL.md`, `describe` verb, hero/wiki page, and version. +- The **edit-source → publish → bump version → reinstall** loop. + +## The cardinal rules + +1. **NEVER hand-edit the streamed cache** (`%LOCALAPPDATA%\Adom Bridge\bridges-cache\<bridge>\`). + It's a download. Edit the **source** (the bridge's own repo/wiki), `publish`, + bump the version, then `bridge_install`/`refresh_bridges` to pull it. A + hand-edit is overwritten on the next sync and may not even be what the host app + runs (cache-vs-deployed-copy gotcha). +2. **Before filing a bridge bug against adom-bridge, ask "who owns this?"** If it's + verb behavior, a hint, an integration, an add-in, or the bridge's docs → it's the + **bridge author's** repo/wiki, not ab. Cloud-owned bridges (kicad, fusion, puppeteer) + live in their OWN wiki repos (see CLAUDE.md "Cloud-owned bridge repos"). +3. **ab's job is to relay + host, generically.** If ab is *dropping* or *mangling* + a bridge's data, or missing a lifecycle/verb capability — THAT is an ab bug. + Fix the ab VERB; don't re-absorb the bridge. + +When in doubt: data-shape/relay/lifecycle/ports → **ab**; what a verb does, its +hints, its integration, its add-in, its docs → **the bridge**. + +## Skill ownership — a bridge ships its OWN skill pkg (not bundled in ab-core) + +The same boundary applies to the **consumer skill** (the SKILL.md that teaches a cloud +container how to drive a bridge's verbs): + +- **The ab-core pkg** (`adom-wiki pkg install adom/adom-bridge`) ships ONLY core skills — + desktop verbs, discovery, direct-api, installer, notify, multi-ad, bridge-sdk, + bridge-ownership, windows-host. It must NOT bundle a cloud/3rd-party bridge's skill (it + would go stale and isn't ab's to own). (2026-06-28: `eagle-commands.md` — Fusion-Electronics, + `fusion_electron_run` — was dropped for this reason; 2026-06-29: `pup-SKILL.md` was dropped + too when Puppeteer became cloud-owned. Both belong in their bridge's own pkg.) +- **Each cloud/3rd-party bridge publishes its OWN skill pkg** carrying its SKILL.md, e.g. + `adom/kicad-bridge`, `adom/fusion-bridge`, + `adom/pup-bridge`. The cloud thread that owns the bridge owns + bumps it. + (Since ab 2.1.147 no bridge ships inside ab's installer at all: `bridges/seeds.json` names + the default bridges and their manifest URLs, and a fresh install fetches them from their + own pages on first launch, wiki #212.) +- **How a container gets dynamic bridge skills:** it does NOT get them from the ab-core install. + It (a) installs ab-core (CLI + core skills), then (b) `adom-bridge bridge_list` against the + live laptop ab to see which bridges are present, then (c) `adom-wiki pkg install + adom/adom-bridge-<bridge>-bridge` for each one it needs (and `adom-wiki pkg update` keeps them + fresh, version-matched to the bridge the cloud thread published). The bridge's runtime PAYLOAD + (what ab spawns on the laptop) is a SEPARATE artifact — the `/files` manifest+zip that + `bridge_install`/`refresh_bridges` pull — don't conflate it with the skill pkg. +- **Discoverability gap / enhancement:** `bridge_list` should surface the exact + `adom-wiki pkg install adom/adom-bridge-<name>-bridge` line per live bridge so a container + knows precisely which skill pkg to pull (today it infers the slug from the bridge's `docs`).