Adom Bridge

⋯ 1 unchanged line ⋯

@@ -1,6 +1,6 @@ {
   "slug": "adom-bridge",
-  "version": "2.1.174",
+  "version": "2.1.175",
   "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.174",+  "version": "2.1.175",   "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": [

@@ -12,6 +12,13 @@ description: Address and fan out to multiple Adom Bridges on one relay. Use when > HOW the feature works; the "Verified current architecture" file:line refs are from 2026-06-14
 > and have drifted, so re-verify them before coding against them.
 
+## Using the user's other machines (2.1.175, wiki #238/#240)
+
+- The user's boxes (laptop, office PC, test rigs, a cloud Linux box) are all addressable by name with `--target <name>`, over the cloud relay or the Adom Mesh.
+- `targets` reports **reachability**, not relay attachment: `reachable: true` has a live link now, `reachable: "mesh"` means the mesh dials it on demand (normal when idle), `route` says relay / mesh-direct / mesh-relay / mesh. `relayConnected` and `meshLinkLive` keep the raw facts. `connected:false` on its own never meant "offline".
+- Check a box with `adom-bridge --target <name> ping`: since 2.1.175 it answers FROM that box with its `route` (it used to answer from the local machine whatever you named).
+- Before taking over a box's screen, look first (`desktop_list_windows`, `desktop_get_foreground`, `desktop_screenshot_screen`): a person or another AI thread may be using it. Pick a free box rather than asking a human to wake one.
+
 ## Which machine is the user's own (`primary_machine`, 2.1.114)
 
 Naming machines solved addressing but not the question that actually comes up: when the user says

@@ -134,6 +134,8 @@ stops manually, treat the clip as complete and react accordingly. 
 ## Where files land, and retention
 
+**2.1.175 (wiki #238): keep a take.** The recordings folder is pruned oldest-first above 3 GB / 2 days, which on a multi-hour 4K shoot deletes take 1 while take 2 is still recording. Pass `keep:true` to `desktop_record_start` (or to `desktop_record_stop`) and the take is left alone: the reply says `kept:true`, and a `<file>.keep` marker beside it takes it out of every limit. To bring a big take back over the mesh, `pull_file` now waits up to `timeoutSeconds` (default 3600), and `read_file {path, offset, length}` copies it in pieces as a fallback.
+
 - Each finished clip is a single `.webm` (VP9). The exact on-disk path comes
   back in `filePath` on start/stop and in `desktop_record_list`.
 - Pull clips to your container with `pull_file`:

@@ -25,6 +25,7 @@ description: >-   "spawn": {
     "kind": "python",                       // python | node | exe | external-http  (NOT "process")
     "entrypoint": "server.py",              // the file/exe ab launches; ab AUTO-APPENDS `--port <port>` to argv
+    "entrypoints": {"windows": "my-bridge.exe", "linux": "my-bridge"}, // 2.1.175, optional: per-OS entrypoint, keyed by Rust's std::env::consts::OS; this OS's value replaces `entrypoint`
     "port": 0,                              // 0 = ab picks a STABLE port (recommended). Bind 127.0.0.1:<that port>.
     "persistent": true,                     // ab's supervisor respawns it if it dies
     "healthEndpoint": "/health",            // INSIDE spawn. ab probes it for the chip (default /health)
@@ -100,3 +101,12 @@ Your verb must be: ab calls it with `{"cascade": true, "name": "<your bridge>"}` so you can tell an app-uninstall
 sweep from a user running your verb by hand. Add it to your `describe` catalog and your skill
 like any other verb.
+
+## Linux: one bridge, two platforms (2.1.175)
+
+Adom Bridge now runs on Linux too (first target: Debian 13 x86_64 under X11). A bridge that wants to run there ships BOTH builds and says which file to start on which OS:
+
+- **bridge.json** `spawn.entrypoints: {"windows": "<x>.exe", "linux": "<x>"}`. The value for the running OS replaces `entrypoint`; a bridge without `entrypoints` keeps working exactly as before.
+- **Wiki manifest** (the file `updateManifestUrl` points at) may carry per-OS packages: `"platforms": {"linux": {"url": "...", "sha256": "...", "size": N}}`. When this OS has an entry, ab downloads that package instead of the top-level `url`. One zip that holds both binaries also works (then only `entrypoints` is needed); separate per-OS zips keep each download small.
+- **Linux rules of thumb:** bind `ADOM_BIND_HOST` (127.0.0.1) as on Windows; the display is `$DISPLAY` (X11); there is no `%LOCALAPPDATA%`, so use `ADOM_BRIDGE_DATA_DIR`; a host app usually lives on `PATH` or under `~/.local/bin`, so declare that in `detect.paths.linux`.
+