Pup - the AI's own browser

@@ -349,13 +349,16 @@ digikey, arrow, analog, ti, microchip, nordic, snapeda, ultralibrarian, CSE, dat 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.+1. **Drive the site through pup, not a hand-rolled Chrome.** Re-measured 2026-09-14 with screenshots:+   analog.com rendered fully in pup on CfT 152 on the warm adom-you profile AND on a brand-new isolated+   jar, so neither the cookie jar nor accumulated profile state is what gets you in. An earlier version+   of this skill claimed the CfT 148 to 152 bump was the fix. That claim came from comparing pup against+   raw `shell_execute` Chrome launches that lacked pup's flag set (no `--disable-infobars`, different+   feature disables, no identity shim), which is not a valid comparison. What makes these sites load is+   pup's launch configuration as a whole; WHICH part has NOT been isolated. Keeping `CFT_BUILD_ID` near+   the user's installed Chrome is still good hygiene, but do not report it as the reason a site loads.+   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.

@@ -1,6 +1,6 @@ {   "slug": "pup-bridge",-  "version": "2.0.551",+  "version": "2.0.552",   "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": "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."+  "changelog": "Two corrections. (1) adom/pup-bridge#108: pup_list_sessions now resolves to the same caller-scoped implementation as pup_my_windows (registered passive, so it never launches a browser) and carries a catalog entry that survives regeneration, instead of erroring not_in_rust_yet while naming no supported equivalent. (2) WITHDRAWN across the root skill, pup-why-cft, pup-browser-detection and pup-bot-walls: the claim that matching CfT to the installed Chrome is what makes vendor sites load. That comparison was uncontrolled, every denied trial was a raw hand-rolled Chrome launch without pup's flag set while every passing trial was pup. Re-measured with screenshots on 2026-09-14, analog.com renders in pup on CfT 152 on both a warm profile and a brand-new isolated jar, so neither the build nor the cookie jar is the established discriminator. Keep the pin near the installed Chrome as hygiene, not as an explanation." }

@@ -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.551",+  "version": "2.0.552",   "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": "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."+  "changelog": "Two corrections. (1) adom/pup-bridge#108: pup_list_sessions now resolves to the same caller-scoped implementation as pup_my_windows (registered passive, so it never launches a browser) and carries a catalog entry that survives regeneration, instead of erroring not_in_rust_yet while naming no supported equivalent. (2) WITHDRAWN across the root skill, pup-why-cft, pup-browser-detection and pup-bot-walls: the claim that matching CfT to the installed Chrome is what makes vendor sites load. That comparison was uncontrolled, every denied trial was a raw hand-rolled Chrome launch without pup's flag set while every passing trial was pup. Re-measured with screenshots on 2026-09-14, analog.com renders in pup on CfT 152 on both a warm profile and a brand-new isolated jar, so neither the build nor the cookie jar is the established discriminator. Keep the pin near the installed Chrome as hygiene, not as an explanation." }\ No newline at end of file

@@ -43,22 +43,27 @@ 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.+**Updated 2026-09-14, twice, and the second update retracts the first.** Determinism is still what+makes pup's tests reproducible. An earlier version of this section claimed that a stale CfT "reads as+a bot", citing analog.com answering HTTP 403 from AkamaiGHost on CfT 148 and serving the real page on+CfT 152. -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.+**That claim is withdrawn. It was not a controlled comparison.** The CfT 148 trials were raw+`shell_execute` Chrome launches carrying a hand-copied flag list; the CfT 152 result came from pup+itself. Those two differ in far more than the build number (pup passes `--disable-infobars`, a+different feature-disable set and the identity shim; the raw launches visibly showed the automation+infobar). Re-measured with screenshots on 2026-09-14, analog.com rendered fine in pup on CfT 152 on+BOTH the warm adom-you profile and a brand-new isolated jar. -**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.+**What is actually established:** sites in this class load when driven through pup's own launch path.+Which element of that launch is decisive has NOT been isolated, and it has NOT been shown to be the+CfT version. `typeof bmak === "undefined"` on a denied page is a SYMPTOM, not a cause: the Access+Denied page carries no sensor script.++**The rule:** keep `CFT_BUILD_ID` within about one milestone of the user's installed Chrome as+hygiene, because a large version gap is a plausible signal and costs nothing to avoid. Do NOT present+it to a user as the reason a vendor site loads or fails. pup fetches the pinned build in the+background when it is missing, so a bump does land on the fleet.  ## 3. Version determinism