Pup - the AI's own browser

@@ -1,6 +1,6 @@ {   "slug": "adom-desktop-puppeteer-bridge",-  "version": "1.9.199",+  "version": "1.9.200",   "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.199",+  "version": "1.9.200",   "tags": [     "skills",     "pup",

@@ -142,3 +142,26 @@ coordMap and the click silently no-ops (measured: interleaved ops failed 5x; the - The account-admin SPA jams CDP → hand off to the user or the API; do not fight it. - A fresh login is NOT persisted until Chrome flushes it → close+reopen+verify BEFORE claiming it   stuck; a portal crash before flush silently destroys the just-completed sign-in (happened once).++## ⛔ BEFORE any real-cursor step: WARN THE USER AND WAIT (John, 2026-07-29)++The `desktop_hover`-then-`desktop_click` recipe below is **native OS input**. It does NOT target a+window — it goes to **whatever window has OS focus at that instant**. This user runs several AI+threads and alt-tabs back to their own work almost immediately after any window is foregrounded.++An agent fired `desktop_type` here without warning; the user had already alt-tabbed away and the+text landed in THEIR document. The agent then blamed Windows for "failing to foreground the window"+instead of the obvious: the human took their focus back because nobody asked them not to.++**So for EVERY native step in this skill:**+1. `notify_user` toast + `desktop_caption` BEFORE asking for the screen.+2. Say it explicitly: **"please don't type or click until I say done."**+3. Wait until the window is genuinely the OS foreground; if they alt-tab away, HOLD, don't dispatch.+4. Re-verify foreground **immediately before each event** — focus can move between two keystrokes,+   and half a password typed into the wrong window is real harm.+5. Caption when DONE so they know they can use their keyboard again.++`browser_assisted_click` implements all five — prefer it over hand-rolling raise-then-click. And+remember the ordering rule: **CDP input (`browser_click`/`browser_type`/`browser_hover`) needs no+foreground and disturbs nobody** — native input is the LAST resort, only for what CDP genuinely+cannot drive (the FedCM chooser, native OS dialogs, sites that reject synthetic events).