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 over CDP, 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 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." ---  # Pup — browser control on the user's desktop (start here)@@ -176,7 +176,7 @@ does NOT attach to the user's running browser and does NOT run headless. It:    installed browser" — that was the mid-2026 policy and it was reversed. Check `pup_readiness`    for which browser a box actually runs. Either way pup uses a *browser binary*, never the user's    *profile*.-2. **…with a pup-managed `--user-data-dir` + a CDP debugging port** (`--remote-debugging-port`), driven over+2. **…with a pup-managed `--user-data-dir`.** By DEFAULT there is **no** `--remote-debugging-port` at all: pup drives the window through its own MV3 extension channel, because that port is the loudest automation signal a site can read. `pup_open_window {lane:"cdp"}` opts into a CDP port when you need a CDP-only feature (iframe targeting, trusted input, annotate, recording). The CDP lane is driven over    the Chrome DevTools Protocol. This is a profile **pup owns and persists**, never the user's own signed-in    OS Chrome/Edge profile. By default every window shares ONE durable profile (`adom-you`), so logins,    cookies and localStorage **accumulate and are shared across all pup windows** — sign into a site once and@@ -342,7 +342,31 @@ hover→click and narrates each step. This is the protocol so pup never foregrou user is not ready.  -## Walled by a vendor site? Extension-driven windows (no CDP debug port)+## Vendor sites: they load. The three conditions that make them load++Measured 2026-09-14 on AdomLapper: **all 20** of the electronics vendor sites we track (st, mouser,+digikey, arrow, analog, ti, microchip, nordic, snapeda, ultralibrarian, CSE, datasheets, octopart,+lcsc, jlcpcb, avnet, newark, rs-online, infineon, nxp) loaded in pup. Not one needed nb. Three+conditions, all required:++1. **Chrome for Testing must MATCH the user's installed Chrome.** A stale CfT gets refused AT THE EDGE, before any+   JavaScript runs: on CfT 148 against a Chrome 152 desktop, analog.com answered HTTP 403 (AkamaiGHost)+   with a static Access Denied page; on CfT 152 the same URL serves the real page. The decision is made+   on the CONNECTION fingerprint (the TLS ClientHello differs measurably between CfT builds), not on+   anything the page executes. Check `pup_readiness.chromeBuildId` against their Chrome before blaming+   a site. NOTE: `typeof bmak === "undefined"` on a denied page is a SYMPTOM (the deny page carries no+   sensor script), not the cause.+2. **Go at human pace: one tab at a time, ~7 s settle.** Bursting tabs trips velocity rules and is by+   far the most common SELF-INFLICTED block. avnet, arrow and datasheets all read as "blocked" purely+   because 20 tabs were opened at once.+3. **Clear that domain's cookies first** (`pup_clear_cookies {domain}`). A prior denial writes a reject+   verdict that persists and keeps denying you long after the real cause is fixed.++Per-site detail (which wall each runs, the failure signatures, the recipes) lives in the+**electronics-sites-skillpack**. Reach for nb only when all three conditions hold and a site still+refuses, or when the task genuinely needs the user's identity.++### Why the default lane has no debug port  Some vendor edges do not wall *you*, they wall the **DevTools debug port**. Measured on one box in one minute (pup-bridge#109): over CDP, st.com and mouser.com died with `ERR_HTTP2_PROTOCOL_ERROR` and

@@ -1,6 +1,6 @@ {   "slug": "pup-bridge",-  "version": "2.0.549",+  "version": "2.0.551",   "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": [@@ -147,5 +147,5 @@       "prompt": "Download the puppeteer-bridge zip from the wiki and walk me through server.js"     }   ],-  "changelog": "A Chrome-for-Testing version bump now actually fetches the new build. detect_cft falls back to any cached CfT so an offline box still drives, but ensure_background short-circuited on that fallback, so 148 stayed cached and the pinned 152 was never downloaded. ensure_background now gates on the PINNED build: present = ready; missing = download it in the background while a cached fallback drives meanwhile, so a box upgrades on its own after a bump."+  "changelog": "Correct the causal story for vendor walls in the skills: a stale Chrome-for-Testing did NOT break Akamai's bmak sensor. analog.com answered HTTP 403 from AkamaiGHost on CfT 148, which is a refusal at the HTTP layer before any page JavaScript runs; CfT 148 executes JavaScript fine. typeof bmak === undefined on a deny page is a symptom (the Access Denied page carries no sensor script), not the cause. The discriminator is the connection fingerprint (the TLS ClientHello differs between CfT builds); which element flips the verdict is not isolated. Corrected in the root pup skill, pup-why-cft, pup-browser-detection and pup-bot-walls." }

@@ -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.549",+  "version": "2.0.551",   "tags": [     "skills",     "pup",@@ -167,5 +167,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": "A Chrome-for-Testing version bump now actually fetches the new build. detect_cft falls back to any cached CfT so an offline box still drives, but ensure_background short-circuited on that fallback, so 148 stayed cached and the pinned 152 was never downloaded. ensure_background now gates on the PINNED build: present = ready; missing = download it in the background while a cached fallback drives meanwhile, so a box upgrades on its own after a bump."+  "changelog": "Correct the causal story for vendor walls in the skills: a stale Chrome-for-Testing did NOT break Akamai's bmak sensor. analog.com answered HTTP 403 from AkamaiGHost on CfT 148, which is a refusal at the HTTP layer before any page JavaScript runs; CfT 148 executes JavaScript fine. typeof bmak === undefined on a deny page is a symptom (the Access Denied page carries no sensor script), not the cause. The discriminator is the connection fingerprint (the TLS ClientHello differs between CfT builds); which element flips the verdict is not isolated. Corrected in the root pup skill, pup-why-cft, pup-browser-detection and pup-bot-walls." }\ No newline at end of file

@@ -41,9 +41,28 @@ toolbar failed or was vetoed: CfT still honors `--load-extension`, so the toolbar is just a **launch argument**: every window is born with it pinned, no install step exists. This gap alone justifies the policy. +## 3. Version determinism (with a HARD limit: the pin must track the user's Chrome)++**Updated 2026-09-14, and this is the important half.** Determinism is still what makes pup's tests+reproducible, but pinning to an OLD build is a liability in the real world, not a neutral choice: a+stale CfT reads as a bot. Measured: pup pinned CfT **148** on a desktop running Chrome **152**, and+analog.com answered **HTTP 403 from AkamaiGHost** with a static Access Denied page. Bumping the pin to+CfT **152**, matched to the installed Chrome, made the same URL serve the real page.++Be precise about WHERE that is decided: the 403 arrives at the HTTP layer, so the edge refused the+request itself and no page JavaScript ever ran. CfT 148 executes JavaScript fine; that was never the+issue. What differs between the builds is the CONNECTION fingerprint (the TLS ClientHello measurably+differs between CfT versions). Which exact element flipped the verdict has NOT been isolated. And+`typeof bmak === "undefined"` on a denied page is a SYMPTOM, not the cause: the Access Denied page+simply carries no sensor script.++**The rule:** keep `CFT_BUILD_ID` within about one milestone of the user's installed Chrome, and treat+a version gap as a first-class suspect whenever a site that works in nb fails in pup. pup now fetches+the pinned build in the background when it is missing, so a bump actually lands on the fleet.+ ## 3. Version determinism -CfT is pinned to the exact build puppeteer expects and **has no auto-updater**. Branded Chrome+CfT is pinned to an exact build and **has no auto-updater**. Branded Chrome updates itself under running profiles on Google's schedule, so CDP behavior can drift mid-session and two windows opened an hour apart can be driving different browser versions. Deterministic versions are what make pup's ralph tests reproducible and a CDP bug a fixable fact instead of a