Pup - the AI's own browser

@@ -235,7 +235,7 @@ So it is **opt-in and leased**: | Verb pair | Captures | How it works under the hood | |---|---|---| | **`pup_record_start` / `pup_record_stop`** | ONE pup **tab/window**, the page content | **CDP `Page.startScreencast`** (JPEG frames, up to ~50 fps) piped to **ffmpeg**, encoded to **VP9** in real time → one `.webm`. Tab-scoped at the protocol level, so it captures the exact tab even in the **background**, no `getDisplayMedia`, no picker, no foreground. |-| **`desktop_record_start` / `desktop_record_stop`** | the WHOLE **desktop** (multiple apps, dialogs) | Screen capture via **MediaRecorder** → one `.webm`; ffmpeg remuxes it to stamp a proper Duration. |+| **`desktop_record_start` / `desktop_record_stop`** (ab-core's capability, served by pup on its behalf until adom-bridge#143 lands) | the WHOLE **desktop** (multiple apps, dialogs) | Screen capture via **MediaRecorder** → one `.webm`; ffmpeg remuxes it to stamp a proper Duration. |  ```bash adom-bridge-cli pup_record_start '{"sessionId":"demo-web"}'          # → { recordingId }@@ -246,7 +246,7 @@ adom-bridge-cli pup_record_stop  '{"sessionId":"demo-web","recordingId":"<id>"}' **ffmpeg** is required for recording. The bridge auto-detects it (a WinGet `Gyan.FFmpeg` install, PATH, or common dirs) and re-checks **lazily on `record_start`**, so if it's missing you can `winget install Gyan.FFmpeg` and just retry, no bridge restart. `pup_record_status` /-`pup_record_list` (and the `desktop_record_*` equivalents) report in-flight and finished captures.+`pup_record_list` (and the `desktop_record_*` equivalents, which are ab's verbs pup only answers for now) report in-flight and finished captures.  ### Formats, one native format, easy conversion 

@@ -4,7 +4,7 @@   "slug": "pup-bridge",   "title": "Pup - Puppeteer Bridge",   "brief": "pup is the AI's own browser: a real, full Chrome on the user's desktop that the AI fully controls (a sandbox, not the user's signed-in browser). Rides Bridge; pup_* verbs open windows and tabs, navigate, screenshot, and eval JS.",-  "version": "2.0.396",+  "version": "2.0.397",   "tags": [     "skills",     "pup",

@@ -115,7 +115,7 @@ install Node. On a truly fresh box it may be `installing` for a few seconds afte  ## The shell-approval gate (rarely relevant to pup) -Core AD verbs and pup's own `pup_*` / `desktop_record_*` verbs run with **NO desktop prompt**. Only+Core AD verbs and pup's own `pup_*` verbs (plus the `desktop_record_*` verbs pup answers for ab-core) run with **NO desktop prompt**. Only open-ended `shell_execute` / `run_script` pop AD's "Shell command needs approval" dialog — which you almost never need (prefer typed verbs). If one returns `needs_approval` / `human_only` on **AD ≥ 1.9.86**: run `adom-bridge-cli --target <box> request_shell_approval` (re-surfaces the dialog), ask the user to click

@@ -77,6 +77,14 @@ pup reports its own slow work in the SDK's measured-progress shape, so a bar can   one row per in-flight phase: opens in flight, the Chrome-for-Testing download (percent + ETA from   the real byte rate), a consent toast waiting on the user (`blockedBy`), or a browser dialog   (`blockedBy`). Empty `active[]` means idle. Poll it once a second while a slow verb runs.+- **Blocked on a human is a RESPONSE, never a timeout** (v2.0.397, ab BRIDGE_SDK 2.1.30 hard rule):+  any pup verb parked on a human answers `{success:false, errorCode:"blocked_on_user", stillRunning,+  blockedBy, _hint}` inside every ab budget. `stillRunning:true` = pup keeps collecting the decision+  in the background (consent toasts: 45s in-verb, 120s toast lifetime): re-call the SAME verb with the+  SAME args to re-attach (no second prompt) or watch `active[]` (rows carry `blockedOnUser:true`,+  then `phase:"consent_decided"` once the user clicked and nobody has collected it). `stillRunning:false`+  = the human must act first (`pup_assisted_click` needs the window focused; a `pup_login` submit hit a+  2FA / captcha wall), then you re-issue the verb. `progressContract.blockedOnUser` restates this. - **Window etiquette** (SDK #63): every open/raise/lower response carries   `windowEtiquette: "background" | "foreground"` (the key to branch on; `placement` stays as the   legacy alias), and a bare `foreground:true` is refused with `errorCode: foreground_reason_required`.

@@ -44,7 +44,7 @@ adom-bridge-cli pup_screenshot '{"sessionId":"mytask-web","tabId":"tab-2"}' # a | Recorder | Captures | Use for | |---|---|---| | **`pup_record_start` / `pup_record_stop`** | ONE pup tab/window — the page content | "record my app", a feature walkthrough, a focused UI flow |-| **`desktop_record_start` / `desktop_record_stop`** | the WHOLE desktop (multiple apps, KiCad/Fusion, OS dialogs) | anything spanning more than the pup window |+| **`desktop_record_start` / `desktop_record_stop`** (an **ab-core** capability; pup only serves it on ab's behalf until ab-core's native recorder lands, adom-bridge#143) | the WHOLE desktop (multiple apps, KiCad/Fusion, OS dialogs) | anything spanning more than the pup window; needs ffmpeg on the box today |  ```bash # Recording a pup window the user will watch → DO bring it forward first@@ -56,8 +56,10 @@ adom-bridge-cli pup_lower_os_window '{"sessionId":"demo-web"}'   # tuck it away ```  - `pup_record_stop` returns the saved video **path**. Recording status/list verbs:-  `pup_record_status` / `pup_record_list` (window recorder) and `desktop_record_status` /-  `desktop_record_list` / `desktop_recorder_open` / `desktop_recorder_close` (desktop recorder).+  `pup_record_status` / `pup_record_list` (pup's tab/window recorder) and `desktop_record_status` /+  `desktop_record_list` / `desktop_recorder_open` / `desktop_recorder_close` (the desktop recorder:+  ab's feature, answered by pup's Chrome-based HUD only until ab-core's native one ships, see+  the `adom-bridge-recording` skill; do not present desktop recording as pup's). - Closing a tab/window mid-recording auto-stops that recording. - For a **narrated** walkthrough, drive the scene here and hand the video to the `video-post` / `adom-tts`   flow for voiceover — pup just produces the raw capture.

@@ -152,8 +152,8 @@ pup_assisted_click {sessionId, x:<account px>, y:<account px>, ``` It: captions the reasoning + toasts BEFORE touching the screen; foregrounds; then **waits, detecting if you alt-tabbed away** and captioning "Adom is waiting — click back when ready" until your-foreground actually IS the window (nothing clicks until then; times out as `user_not_ready` clicking-nothing); then runs the TIGHT hover→click that FedCM accepts and captions each step. THE TIGHT+foreground actually IS the window (nothing clicks until then; after 45s it answers `blocked_on_user`+with `reason: user_not_ready`, clicking nothing, and you re-issue it when the user is back); then runs the TIGHT hover→click that FedCM accepts and captions each step. THE TIGHT SEQUENCE MATTERS: any screenshot/eval BETWEEN the raise and the click steals focus / invalidates the coordMap and the click silently no-ops (measured: interleaved ops failed 5x; the tight raise→capture →hover→click worked). pup_assisted_click encapsulates that — use it, don't reinvent it.