Pup - the AI's own browser

@@ -418,3 +418,33 @@ live and called it out.   the user dismisses on their own terms), or write it into the verb response for the calling AI. - The one thing captions are *great* for: narrating a foreground/click the instant it happens, e.g.   the granted-foreground reason flash. Short, factual, gone.++## FOREGROUNDING: always caption the REASON, for 2 seconds (John, standing rule)++Foregrounding a window is a **rude operation**. It takes over the user's screen while they are working,+and this user runs many AI threads at once and alt-tabs straight back to their own work. That is why+pup FORCES the caller to supply a `foregroundReason` before it will grant a raise.++**The reason must be SHOWN, not just recorded.** An audit trail nobody sees is not accountability.++Every granted foreground MUST:++1. Flash an on-screen caption naming the session and quoting the caller's reason, so the user can see+   WHY their screen was taken over, as it happens.+2. Show it for **2 seconds maximum** (see the caption rule: a caption is a glance, not a dialog).+   `PUP_CAPTION_MAX_MS = 2000` enforces the ceiling at the choke point.+3. Never be skipped because a mode is quiet. This is a user-protection signal, NOT cosmetic+   machinery, so it is deliberately NOT gated behind `minimalTouch`.++Implemented by `captionForegroundReason(sessionId, reason, verb)`, called from the granted-raise path.++**If you add a NEW path that foregrounds a window, it must call that function.** A foreground that+appears with no explanation is the exact behaviour this rule exists to prevent, and it has happened:+an agent foregrounded a window silently, the user was mid-task, and the disruption read as pup+misbehaving rather than as an agent choosing to interrupt.++Related rules that travel with this one:+- Native OS input (`desktop_click` / `desktop_type`) needs the full warn-and-wait protocol, not just a+  caption, because it goes to whatever window has focus.+- `browser_assisted_click` already implements toast + caption + wait-for-ready + re-verify. Use it+  instead of hand-rolling raise-then-click.

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