Adom Bridge

⋯ 1 unchanged line ⋯

@@ -1,6 +1,6 @@ {
   "slug": "adom-bridge",
-  "version": "2.1.188",
+  "version": "2.1.189",
   "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.",

@@ -1,6 +1,6 @@ {   "slug": "adom-bridge",-  "version": "2.1.188",+  "version": "2.1.189",   "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": [

@@ -86,6 +86,14 @@ Your two own cold-start verbs (above) still apply: `<prefix>_readiness` (read-on 
 Your `/health` (200) makes the chip green. Optionally return `led` (`green`/`yellow`/`red`), `summary` (short label), `tooltip` (full hover). ab owns the **offline** (gray) state when your endpoint is unreachable — you can never assert offline.
 
+**Keep `/health` cheap, and never call ab from it.** ab probes it every ~15 s with a 6 s limit (`status.bridgeHealth.probeTimeoutSecs`). A handler that calls an ab verb (`process_list`, `desktop_enum_windows`, ...) waits on ab for its own answer, and on a slow machine that is how a healthy bridge came to be replaced every ~94 s (adom/adom-bridge#260). Compute anything expensive on a background thread and have `/health` return the last value.
+
+**What ab does when `/health` is slow (2.1.189 on):**
+- **The port refuses connections:** the bridge is not running. A `persistent` bridge is respawned at once.
+- **The port takes the connection but the answer is slower than 6 s:** the bridge is alive, and it stays up. After 4 slow supervisor ticks in a row ab asks once more with a 30 s limit. A bridge that answers that probe is slow, not stuck, and stays up; only one that leaves it unanswered is replaced.
+- **A verb arrives while `/health` is slow:** ab sends the call through to a `persistent` bridge instead of replacing it first.
+- **Every stop is in `<name>.ad.log`** with who asked and why: the supervisor, an update, `restart_bridge`, the Restart and Kill buttons, `bridge_install`, `bridge_stop_all`, tray Quit and shutdown.
+
 ## Lifecycle verbs (ab gives these to USERS — know them to guide users)
 
 `bridge_install {manifestUrl}` · `bridge_list` · `bridge_info`/`bridge_detail {name}` · `bridge_log_read {name, sinceOffset?}` · `bridge_kill {name}` · `bridge_pause {name}` · `refresh_bridges {name?}` · `bridge_check_updates`. A bridge installed via `bridge_install` auto-updates with no further opt-in; `updateManifestUrl` in `bridge.json` makes it durable across republish.