Bridge SDK change: every bridge now needs a <prefix>uninstall verb (for the uninstall cascade)

by adom

pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.

Overview Files Skills Discover Packages Releases Dependencies Issues17 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 3mo ago ·closed by John Lauer

Heads-up from the Adom Bridge (ab) thread: the Bridge SDK now requires every bridge to expose a <prefix>uninstall verb. Please add one. This shipped in the SDK skill with ab 2.0.28 (adom-wiki pkg install adom/adom-bridge, load adom-bridge-sdk), and this notice is the migration ask.

Why

An Adom employee reported that uninstalling left cruft on their machine. ab's uninstaller can remove ab's own files, but it has no way to clean up what a BRIDGE created — and bridges install state OUTSIDE ab's directory: a host-app add-in (the Fusion add-in lives in %APPDATA%, not ab's dir), per-bridge caches, downloaded runtimes/models, registry keys, temp dirs. Only the bridge knows where all of that is. So ab's uninstaller will CASCADE — enumerate the installed bridges and call each bridge's <prefix>uninstall before removing ab — and the whole ecosystem uninstalls cleanly.

What to add

A <prefix>uninstall verb (e.g. <yourprefix>_uninstall) that removes EVERYTHING your bridge created on the machine — your add-in/plugin files in host-app dirs, your caches, your registry entries, your temp files, anything outside ab's own bridges-cache (ab removes that). Requirements:

Idempotent and non-interactive — safe to call when already clean; NEVER prompt or block. It runs during a silent /S uninstall cascade, so a modal/prompt would hang the parent uninstaller. Route any message to your log, not a dialog.
Best-effort per item — one un-removable file must not abort the rest. Report what was and wasn't removed.
Scoped to YOUR OWN artifacts only — never touch the host app itself (do NOT uninstall KiCad/Fusion/Blender/the browser), other bridges, or user data/projects.

Wire-up

Declare it in your bridge.json: an uninstall field naming the verb (e.g. "uninstall": "fusion_uninstall"), so ab knows to call it during the cascade. If absent, ab logs that your bridge left cleanup to the user.
Add it to your describe catalog and your consumer skill like any other verb, with a rich _hint/_next in the OUTPUT.

Reference

Full contract: the adom-bridge-sdk skill (in the adom/adom-bridge pkg), section "REQUIRED: every bridge MUST expose a <prefix>uninstall verb." Reply here with a plan or any blockers. Thanks!

1 Reply

John Lauer · 3mo ago

Done as of pup 2.0.130 (the verb itself shipped in 2.0.126).

pup_uninstall removes pup's whole machine footprint: HKCU AppUserModelId Adom.Pup registry keys, all staged extensions, pup profiles + sessions, the OS-keychain credential vault, pup-settings.json, temp + jump-list launcher files. Idempotent, best-effort per item (one un-removable file never aborts the rest, the response reports removed vs skipped), never prompts or blocks, scoped strictly to pup's own artifacts (Chrome-for-Testing + firewall rules are shared and left alone unless explicitly flagged).
bridge.json now declares "uninstall": "pup_uninstall" so ab's cascade finds it.
Calling convention: the verb is confirm-gated for AI callers (confirm:"uninstall"), and accepts cascade:true as the equivalent non-interactive machine confirmation for ab's silent /S cascade. One ask back: have the cascade pass {"cascade":true} when it calls the declared verb. If ab's cascade instead calls with an empty body, say so here and I will honor the bare call from the declared-verb path.
In the pup_describe catalog with dryRun preview documented; dryRun verified live on a real machine.

John Lauer closed this · 3mo ago