Pup - the AI's own browser

@@ -1,7 +1,7 @@ --- name: pup user-invocable: true-description: "Drive a browser on the user's desktop from the cloud: the Puppeteer 'pup' bridge (pup_* verbs via the adom-bridge-cli CLI). pup drives Chrome for Testing (the automation build: no automation banner, deterministic version, toolbar extension rides the launch, see docs/WHY-CFT.md; installed Chrome/Edge are fallbacks) in a pup-managed DURABLE profile (logins/localStorage persist and are shared across pup windows; {isolated:true} for a throwaway), driven BY DEFAULT through pup's own extension channel with NO --remote-debugging-port (lane:'cdp' is the opt-in for CDP-only features), in the BACKGROUND so it never disturbs the user; NOT the user's real signed-in profile (that's the Adom extension's nbrowser_* verbs), NOT headless (a real rendered window, so screenshots/recording are true-to-life). Chrome for Testing only as a last resort. Open/close windows + tabs, navigate, screenshot, eval JS, record. This is the START-HERE skill: the mental model + when-to-use + the skill map; deeper topics route to the sub-skills. For 'is it ready' use pup_readiness (not pup_status). Trigger words: pup, puppeteer, browser window, open in pup, open my app in pup, browser screenshot, browser eval, browser reload, visual debug, headful chrome, pup_open_window, pup_screenshot, pup_readiness, pup_prewarm, chrome for testing, open in browser, open my web app, show my app in the browser, preview my app, open the app I just built, view my app, open localhost, show my dev server, pup_login, log into a site in pup, autofill password, saved login, durable profile, isolated window."+description: "Drive a browser on the user's desktop from the cloud: the Puppeteer 'pup' bridge (pup_* verbs via the adom-bridge-cli CLI). pup drives Chrome for Testing (the automation build: no automation banner, deterministic version, toolbar extension rides the launch, see docs/WHY-CFT.md; installed Chrome/Edge are fallbacks) in a pup-managed DURABLE profile (logins/localStorage persist and are shared across pup windows; {isolated:true} for a throwaway), driven through pup's own extension channel with NO --remote-debugging-port, which is the lane every vendor site loads on and the ONLY lane pup opens unless you pass lane:'cdp' for a CDP-only feature (see the pup-lanes skill), in the BACKGROUND so it never disturbs the user; NOT the user's real signed-in profile (that's the Adom extension's nbrowser_* verbs), NOT headless (a real rendered window, so screenshots/recording are true-to-life). Chrome for Testing only as a last resort. Open/close windows + tabs, navigate, screenshot, eval JS, record. This is the START-HERE skill: the mental model + when-to-use + the skill map; deeper topics route to the sub-skills. For 'is it ready' use pup_readiness (not pup_status). Trigger words: pup, puppeteer, browser window, open in pup, open my app in pup, browser screenshot, browser eval, browser reload, visual debug, headful chrome, pup_open_window, pup_screenshot, pup_readiness, pup_prewarm, chrome for testing, open in browser, open my web app, show my app in the browser, preview my app, open the app I just built, view my app, open localhost, show my dev server, pup_login, log into a site in pup, autofill password, saved login, durable profile, isolated window." ---  # Pup: browser control on the user's desktop (start here)

@@ -1,6 +1,6 @@ {   "slug": "pup-bridge",-  "version": "2.0.562",+  "version": "2.0.563",   "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. The pkg version is kept in lockstep with the Release version so the page's max version row always carries BOTH a pkg tarball (skills) and a runtime zip (bridge) \u2014 a skills-only or runtime-only bump on the top row breaks constraint installs. TL;DR: pkg install = the skills for your AI; the bridge = the Release zip, which Adom Desktop manages for you.",   "keywords": [@@ -28,6 +28,7 @@     "skills/pup-browsers-and-chrome/SKILL.md",     "skills/pup-adom-wiki/SKILL.md",     "skills/pup-vendor-login/SKILL.md",+    "skills/pup-lanes/SKILL.md",     "skills/pup-settings/SKILL.md",     "skills/pup-credentials/SKILL.md",     "skills/pup-progress/SKILL.md",@@ -147,5 +148,5 @@       "prompt": "Download the puppeteer-bridge zip from the wiki and walk me through server.js"     }   ],-  "changelog": "Extension lane: no more orphan about:blank windows. A lane relaunch or a concurrent open went through the worker's open action and left Chrome's startup window on the desktop (John, 2026-09-14). pup now sweeps, after every ext open and on each health tick, every window no session owns whose tabs are all about:blank, the same rule the CDP lane applies in close_orphan_blank_targets. Carries 2.0.561 (a session is matched to its own window by title) and 2.0.560 (thread tile rendered in the binary; stamp at birth and on re-adoption)."+  "changelog": "The extension lane IS pup (John, 2026-09-14): it is the lane every vendor site loads on, so it is the default and the CDP lane opens ONLY on an explicit lane:\"cdp\". The silent fallback to CDP for profile/isolated/highFps/webSecurity requests is gone; such a request without lane:\"cdp\" is refused with cdp_lane_required and the fix. New user skill pup-lanes compares the two lanes with pros and cons, lists exactly which verbs need CDP, and states the cost of lane:\"cdp\" on adom-you. pup-taskbar-states no longer says the browser renders the name tile." }

@@ -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.562",+  "version": "2.0.563",   "tags": [     "skills",     "pup",@@ -117,6 +117,7 @@     "skills/pup-browsers-and-chrome/SKILL.md",     "skills/pup-adom-wiki/SKILL.md",     "skills/pup-vendor-login/SKILL.md",+    "skills/pup-lanes/SKILL.md",     "skills/pup-settings/SKILL.md",     "skills/pup-credentials/SKILL.md",     "skills/pup-progress/SKILL.md",@@ -167,5 +168,5 @@       "pup-bridge verbs are invoked through the adom-bridge CLI, not through a binary this package installs, so prefix rules cannot reach them."     ]   },-  "changelog": "Extension lane: no more orphan about:blank windows. A lane relaunch or a concurrent open went through the worker's open action and left Chrome's startup window on the desktop (John, 2026-09-14). pup now sweeps, after every ext open and on each health tick, every window no session owns whose tabs are all about:blank, the same rule the CDP lane applies in close_orphan_blank_targets. Carries 2.0.561 (a session is matched to its own window by title) and 2.0.560 (thread tile rendered in the binary; stamp at birth and on re-adoption)."+  "changelog": "The extension lane IS pup (John, 2026-09-14): it is the lane every vendor site loads on, so it is the default and the CDP lane opens ONLY on an explicit lane:\"cdp\". The silent fallback to CDP for profile/isolated/highFps/webSecurity requests is gone; such a request without lane:\"cdp\" is refused with cdp_lane_required and the fix. New user skill pup-lanes compares the two lanes with pros and cons, lists exactly which verbs need CDP, and states the cost of lane:\"cdp\" on adom-you. pup-taskbar-states no longer says the browser renders the name tile." }\ No newline at end of file

@@ -0,0 +1,48 @@+---+name: pup-lanes+user-invocable: false+description: "Parent skill: pup. The two ways pup drives a Chrome for Testing window, the extension lane (DEFAULT, every vendor site loads, no debug port) and the CDP lane (opt-in ONLY via lane:'cdp', full DevTools control but detectable and walled by vendor edges). Pros and cons of each, exactly which verbs need CDP, what lane:'cdp' costs (it takes adom-you away from the extension lane and closes its windows), and the rule: never open a CDP window unless the task specifically needs a CDP-only feature. Read before passing lane, isolated, profile, highFps or webSecurity to pup_open_window, and whenever a verb answers lane_needs_cdp or cdp_lane_required. Trigger words: pup lane, extension lane, cdp lane, lane:cdp, lane_needs_cdp, cdp_lane_required, which lane, remote-debugging-port, debug port detected, site blocks pup, pup_open_window lane, isolated:true refused, highFps refused, three icons vs four icons."+---++# pup lanes: the extension lane is pup. CDP is the exception.++The point of the September 2026 work (John, 2026-09-13 and 14) was one thing: pup windows that load+EVERY website without the site blocking us. That turned out to be the extension lane. So it is the+default, and the CDP lane opens only when an AI writes `lane:"cdp"` because the task needs something+only CDP can do. pup no longer falls back to CDP on its own for any reason.++## What each lane is++| | Extension lane (DEFAULT) | CDP lane (`lane:"cdp"`, opt-in) |+|---|---|---|+| How pup drives the window | pup's own MV3 extension polls the bridge and runs the commands inside Chrome | Chrome DevTools Protocol over `--remote-debugging-port` |+| Debug port | none | yes, and vendor edges detect it (measured: st.com and mouser RST the HTTP/2 stream, arrow denies) |+| Profile | the shared adom-you browser, one process, every thread's windows in it | any profile; on adom-you it TAKES the profile from the extension lane and closes those windows |+| Toolbar | four icons: pup dots, pen, identity tile, nbe | three icons (nbe rides the extension lane only) |+| Taskbar identity, tiles, overlays, jump lists | yes | yes |+| Vendor sites (st, mouser, digikey, arrow, analog, ti, avnet, nxp, infineon, and the rest of the 20) | load | walled by several of them |++## Pros and cons++**Extension lane**+- Pro: sites load. This is the reason it exists and the reason it is the default.+- Pro: one shared adom-you browser, so logins and cookies accumulate for every thread, and every window carries the full toolbar including nbe.+- Con: `pup_eval` runs in the page's MAIN world, so a page with a strict Content-Security-Policy (wiki.adom.inc, claude.ai) refuses it with "Evaluating a string as JavaScript violates the following Content Security Policy". Use `pup_screenshot`, `pup_list_tabs`, `pup_navigate` and the other DOM-free verbs there, or `lane:"cdp"` if you truly must run script on such a page and accept that vendor sites will not load in that window.+- Con: no trusted input events, no iframe targeting, no element or full-resolution screenshots, no annotate, no recording, no selector-driven downloads, no `realKeystrokes`, no separate profile, no `highFps`, no `webSecurity:false`. Each of those verbs answers `lane_needs_cdp` with the fix.++**CDP lane**+- Pro: everything DevTools can do: trusted mouse and keyboard events, cross-origin iframes, `Runtime.evaluate` that ignores page CSP, element and full-res screenshots, annotate, recording, emulation, separate profiles, anti-throttle for a live view.+- Con: the debug port is a detection surface. A CDP window is what gets you "Access Denied" on the hard vendor sites.+- Con: `lane:"cdp"` on adom-you evicts the extension lane: pup closes every extension-lane window to hand the profile over, because Chrome runs one process per profile. Other threads lose their windows. That is why it is opt-in.+- Con: three toolbar icons, no nbe.++## The rule++1. Open windows with no `lane`. You get the extension lane.+2. Do not pass `profile`, `isolated`, `highFps` or `webSecurity:false` unless you also pass `lane:"cdp"`. Without it pup refuses with `cdp_lane_required` and says why. Since 2.0.563 nothing silently opens on CDP.+3. Pass `lane:"cdp"` only when the task needs a CDP-only feature, say which one in `reason`, and expect vendor sites to wall that window.+4. If a verb answers `lane_needs_cdp`, first ask whether the task can be done without it (a screenshot instead of an eval on a CSP page, a URL download instead of a click). Only then reopen with `lane:"cdp"`.++## How you tell them apart++The toolbar: four icons is the extension lane, three is CDP (John's own spec for the fourth icon). `pup_list_windows` reports `transport: "ext"` or `"cdp"` per window. `pup_status.extensionLane` shows the lane's health.

@@ -34,7 +34,7 @@ preview is DERIVED from the same sources listed here, so preview and reality can  ## Where every pixel comes from (and how the preview stays honest) -- **Name tiles**: composed by `renderThreadTileIco` into `%TEMP%\pup-thread-tiles\<gen>\<slug>.ico`,+- **Name tiles**: rendered IN THE BINARY (`pup_identity::tile`, 2.0.559: no page, no lane, no CSP; until then a script evaluated inside the open page, which strict-CSP sites blocked) into `%TEMP%\pup-thread-tiles\<gen>\<slug>.ico`,   registered in HKCU and stamped per-window. The Settings preview draws with the same algorithm. - **Category icons**: shipped `pup-cat-*.ico` set; the preview shows the REAL registered icon via   `/dashboard/stampicon?session=<sid>`.