Pup - the AI's own browser

@@ -10,8 +10,8 @@ Drive a browser on the user's desktop from a cloud container via the `adom-deskt **Bash command** (NOT an MCP tool):  ```bash-adom-desktop browser_open_window '{"sessionId":"mytask-web","owner":"mytask","url":"https://example.com"}'-adom-desktop browser_screenshot  '{"sessionId":"mytask-web"}'+adom-desktop --ai-thread "<your thread>" browser_open_window '{"sessionId":"mytask-web","owner":"mytask","url":"https://example.com"}'+adom-desktop --ai-thread "<your thread>" browser_screenshot  '{"sessionId":"mytask-web"}' ```  ## The mental model — what pup actually is (read this once)@@ -72,9 +72,9 @@ repo — not shipped here.)*  ```bash # Open in the BACKGROUND (automatic — never disturbs the user), then drive it invisibly.-adom-desktop browser_open_window '{"sessionId":"mytask-web","owner":"mytask","url":"http://localhost:3000"}'-adom-desktop browser_eval        '{"sessionId":"mytask-web","expr":"document.title"}'   # verify it really loaded-adom-desktop browser_screenshot  '{"sessionId":"mytask-web"}'                            # true-to-life PNG+adom-desktop --ai-thread "<your thread>" browser_open_window '{"sessionId":"mytask-web","owner":"mytask","url":"http://localhost:3000"}'+adom-desktop --ai-thread "<your thread>" browser_eval        '{"sessionId":"mytask-web","expr":"document.title"}'   # verify it really loaded+adom-desktop --ai-thread "<your thread>" browser_screenshot  '{"sessionId":"mytask-web"}'                            # true-to-life PNG ```  - **Task-prefix your `sessionId` and pass `owner`** — sessions are shared across every AI thread on the@@ -176,7 +176,7 @@ threads; pass `wikiView:"authed"|"public"` on browser_open_window instead. Detai   window/tab verb does), then poll `browser_list_windows` with backoff until it answers. **Do NOT spam   opens** while AD says `bridge_starting` — one is enough; it's already starting. (`bridge_list`   `status:"running"` is not liveness; the LED + `browser.bridgeRunning` + an actual verb reply are.)-- Full machine-readable catalog: `adom-desktop browser_describe '{}'`.+- Full machine-readable catalog: `adom-desktop --ai-thread "<your thread>" browser_describe '{}'`.  ## Verify what you rendered — pup checks it FOR you (v1.9.106) @@ -220,3 +220,22 @@ machines are the only way this bridge gets correct: `adom-wiki issue create adom/adom-desktop-puppeteer-bridge --title "<symptom>" --category bug-report --body "<what you ran, expected, got, the VERBATIM response JSON, bridge version, OS>"`. An AD-core problem (relay, bridge lifecycle, caller identity) goes to `adom/adom-desktop` instead.++## Every adom-desktop call needs `--ai-thread`++AD refuses any command that does not say which AI conversation is asking+(`errorCode: caller_identity_required`). It is a **global flag**, like `--target`, and it goes before+the verb:++```bash+adom-desktop --ai-thread "chip-fetcher tab 3" browser_open_window '{"sessionId":"cf-web","url":"..."}'+```++Pick a name the USER would recognise for this conversation, never a UUID. It is **attribution, not+permission** — self-reported, unverifiable, and nothing is gated on it. It exists so a user running ~20+threads can see which tab is driving their machine, and so a pup window can be labelled with the thread+that owns it.++**Do NOT `export ADOM_AI_THREAD`** — threads share one container and one `$HOME`, so it names the shell+rather than you: every thread reports the same name, which is worse than none because it is confident+and wrong. Pass it per call (or `{"caller":{"aiThread":"..."}}` in the args).

@@ -1,6 +1,6 @@ {   "slug": "adom-desktop-puppeteer-bridge",-  "version": "1.9.114",+  "version": "1.9.115",   "type": "app",   "description": "The pup SKILL PACK \u2014 the AI skills that teach a cloud/container AI how to drive the Adom Desktop Puppeteer (pup) bridge (browser_* verbs): the everyday `pup` skill plus focused sub-skills for windows/sessions/tabs, screenshots+recording, browsers+Chrome install, and driving the Adom wiki. Installs into ~/.claude/skills + ~/.codex/skills. DOCS ONLY \u2014 this is NOT the bridge runtime. The bridge itself (the Node program that drives the browser) runs on the DESKTOP: Adom Desktop bundles it and auto-installs/updates it, and it's published separately on the Releases tab as adom-bridge-puppeteer-v<ver>.zip. So the pkg version (skills, bumps often) and the Release version (runtime, bumps rarely) differ on purpose. TL;DR: pkg install = the skills for your AI; the bridge = the Release zip, which Adom Desktop manages for you.",   "keywords": [

@@ -4,7 +4,7 @@   "slug": "adom-desktop-puppeteer-bridge",   "title": "Adom Desktop - Puppeteer Bridge",   "brief": "The Adom Desktop Puppeteer (pup) bridge — drive a real headful browser on the user's desktop from the cloud: open/screenshot/eval/record. Cold-start drives the browser ALREADY on the machine (installed Chrome, else Microsoft Edge — every Windows PC ships with Edge) with a fresh isolated profile, so the common case needs NO download; Chrome for Testing is fetched only as a last resort. Two artifacts: the Releases zip is the bridge runtime (also bundled in Adom Desktop); the pkg installs the container-side Claude skills.",-  "version": "1.9.114",+  "version": "1.9.115",   "tags": [     "skills",     "pup",