Pup - the AI's own browser

@@ -1,6 +1,6 @@ --- name: pup-bot-walls-description: "DEV skill (source-only). What to do when a site serves pup a bot wall / CAPTCHA / 'Verification Required' instead of the page — identifying WHICH wall it is (DataDome vs Cloudflare vs Akamai vs Imperva), what pup already does about each, the sourcing ladder that avoids the fight entirely (official API → nb → pup), and how to hand a challenge to the human who is driving. Read this before touching the consumer-UA override, before adding retries to a crawl, and before anyone proposes fingerprint spoofing. Trigger words: bot wall, captcha, verification required, datadome, cloudflare challenge, just a moment, akamai, imperva, incapsula, blocked by mouser, blocked by digikey, chip-fetcher blocked, crawl blocked, are you spoofing the user agent, pup user agent, scraping blocked, access denied, 403 on a vendor site."+description: "DEV skill (source-only). What to do when a site serves pup a bot wall / CAPTCHA / 'Verification Required' instead of the page, identifying WHICH wall it is (DataDome vs Cloudflare vs Akamai vs Imperva), what pup already does about each, the sourcing ladder that avoids the fight entirely (official API → nb → pup), and how to hand a challenge to the human who is driving. Read this before touching the consumer-UA override, before adding retries to a crawl, and before anyone proposes fingerprint spoofing. Trigger words: bot wall, captcha, verification required, datadome, cloudflare challenge, just a moment, akamai, imperva, incapsula, blocked by mouser, blocked by digikey, chip-fetcher blocked, crawl blocked, are you spoofing the user agent, pup user agent, scraping blocked, access denied, 403 on a vendor site." ---  # Bot walls: identify it, avoid the fight, hand the hard ones to the human@@ -18,16 +18,14 @@ He is right about the substance, and the substance sets the ENGINEERING rule, no   direction**. There is a real human on the other end of every request. That is genuinely different   from a datacenter scraper farm, and it is why "we look like a bot" is usually a FALSE POSITIVE. - So the goal is **stop earning the false positive**, not **defeat the detector**. Those look similar-  from one angle and are completely different engineering. Behaving like a human-directed session —-  sane pacing, one page at a time, warm cookies, real input, using the front door where one exists —-  lowers your score honestly and holds up. Fingerprint spoofing is an arms race you re-lose on every+  from one angle and are completely different engineering. Behaving like a human-directed session, sane pacing, one page at a time, warm cookies, real input, using the front door where one exists, lowers your score honestly and holds up. Fingerprint spoofing is an arms race you re-lose on every   vendor update, and it makes every future false positive harder to diagnose because you can no   longer trust what you are presenting. - **We do not solve CAPTCHAs on the human's behalf.** A CAPTCHA is a site asking "is a person-  there?" and in Adom the honest answer is *yes, and here they are* — surface it, let them click it.+  there?" and in Adom the honest answer is *yes, and here they are*, surface it, let them click it.   That is not a limitation to engineer around; it is the correct answer to the question being asked. -## Step 1 — identify WHICH wall (never guess; they need different answers)+## Step 1: identify WHICH wall (never guess; they need different answers)  Read the challenge page's own markup. `pup_eval` on the stuck session: @@ -43,15 +41,15 @@ JSON.stringify({ | Wall | Tell | Notes | |---|---|---| | **DataDome** | `ct.captcha-delivery.com/c.js`, inline `var dd={'rt':'c','cid':…,'t':'fe'}` | Behavioural + fingerprint + IP velocity. Does NOT care what your UA claims. **Mouser runs this.** |-| **Cloudflare** | "Just a moment…", `/cdn-cgi/challenge-platform/` | Gates heavily on the **Sec-CH-UA brand list** — this is the one pup's consumer-UA override already solves. |+| **Cloudflare** | "Just a moment…", `/cdn-cgi/challenge-platform/` | Gates heavily on the **Sec-CH-UA brand list**, this is the one pup's consumer-UA override already solves. | | **Akamai** | `_abck` / `bm_sz` cookies, `/akam/` script paths | Also brand-list sensitive; same override helps. | | **Imperva/Incapsula** | `_Incapsula_Resource`, "Request unsuccessful" | Usually IP/ASN reputation. |  A blank body with a tiny `htmlLen` (~1.6 KB) and a title that is just the bare domain is the classic "challenge page, not your content" signature. `len: 0` with `title: "mouser.com"` is what a wall-looks like — do not mistake it for a slow load.+looks like, do not mistake it for a slow load. -## Step 2 — what pup ALREADY does, and what it does NOT cover+## Step 2: what pup ALREADY does, and what it does NOT cover  `computeConsumerUA()` / `applyConsumerUA()` in `server.js` override the UA header **and** `navigator.userAgentData` together, so every page sees consumer **Google Chrome** rather than@@ -70,7 +68,7 @@ declaring itself as Google Chrome instead of as a test build. It fixed Cloudflar **It does nothing for DataDome**, which ignores the claim and scores behaviour. So when someone asks "are you still not matching Chrome's user-agent?", the answer is measured, not assumed: read the three values above off the live window first. On 2026-08-20 they were already correct and the wall-was DataDome — a different vendor entirely.+was DataDome, a different vendor entirely.  **Same browser, same profile, same minute** (the contrast that proves it is site-specific, not a pup-wide identity problem):@@ -81,7 +79,81 @@ pup-wide identity problem): | DigiKey | 12,482 chars, loaded | no | | **Mouser** | **0 chars** | **yes** | -## Step 3 — the sourcing ladder (most walls are avoidable, not winnable)+## FIRST: most "bot walls" in pup are one of three self-inflicted conditions (2026-09-14)++Before you treat a page as walled, check these. Measured on AdomLapper 2026-09-14 across two runs:+the first scored 20 of 20, the second **19 of 20** with analog.com denied as the 7th of 20 sequential+loads. The clean score did NOT reproduce, so the honest figure is 19 of 20 with analog.com intermittent+under sequential load. None of them needed nb.++1. **Are you actually driving it through pup?** Sites in this class load on pup's own launch path. A+   hand-rolled Chrome started with a copied flag list is NOT equivalent and will mislead you (that+   mistake is what produced the withdrawn CfT-version claim below). Keep `CFT_BUILD_ID` near the+   installed Chrome as hygiene, but it is not an established cause.+2. **Did you ask too fast?** A burst of tabs trips velocity rules. One tab at a time, ~7 s settle.+3. **Is there a stale reject cookie?** A prior denial persists in `_abck`; clear the domain first.++Only when all three hold and the site STILL refuses do the vendor-specific sections below apply.++## Akamai + the browser VERSION and the egress IP (measured 2026-09-14, analog.com)++The consumer-UA/brands override above (now applied in the extension lane too, matched to the user's+INSTALLED Chrome version) is necessary but was NOT sufficient for the hardest Akamai sites. Two more+causes, each measured and each independent, found while chasing why analog.com denied pup but loaded+in the user's real Chrome on the same network:++**1. WITHDRAWN: "the Chrome-for-Testing VERSION is itself a detection surface".** This section used to+claim that pinning CfT 148 against a Chrome 152 desktop is what made analog.com answer HTTP 403, and+that bumping to CfT 152 fixed it. The comparison was not controlled: every denied trial was a raw+`shell_execute` Chrome launch carrying a hand-copied flag list, while every passing trial was pup.+Those differ in the infobar suppression, the feature-disable set and the identity shim, not just the+build number. Re-measured 2026-09-14 with screenshots: analog.com renders in pup on CfT 152 on the adom-you+profile. The arm intended as a fresh jar was not one, because `isolated:true` keeps the adom-you+profile (pup-bridge#112), so profile state is UNTESTED rather than excluded.+What IS established: these sites load when driven through pup's own launch path, and which element of+that path is decisive has NOT been isolated. Keep `CFT_BUILD_ID` within ~1 milestone of the installed+Chrome as cheap hygiene, and do not tell a user the version is why a site loads or fails. `typeof+bmak === "undefined"` on a denied page is a SYMPTOM (the deny page carries no sensor script), not the+cause. Diagnostic: `typeof bmak` on the denied page. `undefined` means the real page (with the sensor)+was never served, i.e. rejected upstream.++**2. Egress IP reputation is a separate, stacked cause.** Same CfT 152, same code, four boxes:++| Box | Egress | analog.com |+|---|---|--:|+| AdomLapper | corporate VPN | LOADS (`bmak:object`) |+| winvm | Azure | LOADS (`bmak:object`) |+| arav-rog | bare office LAN | DENIED (`bmak:undefined`) |+| ConfRoomROG | bare office LAN | DENIED (`bmak:undefined`) |++Identical browser; the only variable is the network path. The bare office NAT IP is Akamai-flagged+(one IP, lots of corporate/automated traffic); the VPN and the Azure IP are not. pup cannot fix this+from inside the browser, it is IP/ASN reputation (the Imperva row of the wall table applies to+Akamai too). A residential/VPN egress is the only lever. Confirming test: turn the VPN OFF on a box+that loads; it should start denying as it joins the flagged egress.++**Cookie hygiene for a poisoned verdict.** Once Akamai rejects you it sets `_abck` to a `~-1~` reject+state that persists; a later visit with the right config can still read denied until it is cleared.+`pup_clear_cookies {domain}` (HttpOnly included) and `pup_clear_site_data {origins}` exist for this, clear before re-testing a site that denied you earlier, or the stale verdict masks the fix.++## Current per-site matrix (extension lane, CfT 152, 2026-09-14)++16 of 20 vendor sites load on every box. The spread is entirely the Akamai-hardened four:++| | AdomLapper | arav-rog | CRR | winvm |+|---|:--:|:--:|:--:|:--:|+| ST, Mouser, TI, Microchip, Nordic, SnapEDA, UltraLib, CSE, Octopart, LCSC, JLCPCB, Newark, RS, Infineon, NXP | load | load | load | load |+| DigiKey | load | load | block | block |+| Arrow | load | block | block | block |+| Datasheets | load | load | load | block |+| **Analog** | load* | block | block | load |+| **Avnet** | block (interactive Akamai challenge, a human-click site, nb's job) | | | |++\*Analog tracks the version+IP findings above: loads on the VPN/Azure egresses, denied on the bare+office LAN even on CfT 152. The pattern (home/VPN/cloud better than bare office network) matches the+egress-reputation cause, not the browser.++## Step 3: the sourcing ladder (most walls are avoidable, not winnable)  **1. Official API first, always.** Mouser and DigiKey both have real APIs, and Adom already wraps them: the `adom-mouser`, `adom-digikey` and `adom-parts-search` skills talk to shared service@@ -92,41 +164,41 @@ an API is how you earn a velocity ban for data you could have had cleanly. **2. `nb` when the user's identity matters.** A site that wants a signed-in human should get the user's real signed-in browser. That is `nb`/`nbe`'s whole job. -**3. pup for what only pup can do.** chip-fetcher's actual need — downloading CAD bundles (STEP,+**3. pup for what only pup can do.** chip-fetcher's actual need, downloading CAD bundles (STEP, `.kicad_sym`, `.kicad_mod`, Altium `.IntLib`, Fusion `.lbr`, datasheet PDFs) behind click-through-flows — is not an API call, so pup is correct there. Keep pup scoped to that.+flows, is not an API call, so pup is correct there. Keep pup scoped to that.  **4. Hand the challenge to the human** when one still appears (below). -## Step 4 — the human handoff (the escape hatch that always works)+## Step 4: the human handoff (the escape hatch that always works)  pup is **headful and on-screen by design**, so the human can simply solve it. That is not a workaround; it is the payoff for every rule in `pup-bridge-dev` about windows being reachable.  1. Do NOT retry in a loop. A retry against a live challenge raises the score and can escalate a    soft challenge into a hard block.-2. Flash the taskbar button (`pup_alert_window`) — signal, never a focus steal.+2. Flash the taskbar button (`pup_alert_window`), signal, never a focus steal. 3. Tell the user plainly which site and what you need, and hand them the window. 4. Wait for the challenge to clear, then continue from where you were.-5. **The solve persists.** DataDome sets a clearance cookie, and pup's durable profile keeps it — so+5. **The solve persists.** DataDome sets a clearance cookie, and pup's durable profile keeps it, so    one human solve typically buys a long quiet period for that domain. This is the single strongest    argument for warm profiles over throwaway ones in a crawl. -## Step 5 — do not do this to yourself (how we tripped Mouser)+## Step 5: do not do this to yourself (how we tripped Mouser)  The 2026-08-20 trigger was self-inflicted and is the most common way a crawl gets walled: **mouser.com was opened twice in ~15 minutes while ti.com and digikey.com were opened simultaneously**, all from one IP. That is a textbook velocity signal. Before blaming fingerprints, check your own access-pattern — it is usually the answer, and it is the only input you fully control.+pattern, it is usually the answer, and it is the only input you fully control. -## TODO — the roadmap to feeling like the human we actually are+## TODO: the roadmap to feeling like the human we actually are  Ordered by value per unit of work. None of these are CAPTCHA-solving.  1. **Detect and REPORT a wall instead of returning a blank page.** Add a `botWall` field    (`{vendor, challenged:true, url}`) plus an `errorCode` and an `_hint` telling the caller to stop    retrying and hand off. Today a challenged page returns `ok:true` with an empty body, so every-   caller retries blindly — which is precisely the wrong reflex. **This is the highest-value item:+   caller retries blindly, which is precisely the wrong reflex. **This is the highest-value item:    it converts a silent failure into a correct one.** 2. **A first-class handoff verb** (`pup_request_human {sessionId, reason}`): raise-or-flash, tell the    user what is needed, poll until the page's real content appears, then return control with how@@ -145,12 +217,12 @@ Ordered by value per unit of work. None of these are CAPTCHA-solving.    pup+handoff), so the ladder is data, not folklore. 7. **Investigate CDP observability** honestly: establish whether DataDome-class walls detect CDP    attachment at all, and if so whether there is a SUPPORTED way to reduce the signal. If the only-   answer is spoofing, write that down and stop — an arms race we re-lose every vendor update is+   answer is spoofing, write that down and stop, an arms race we re-lose every vendor update is    worse than a clean handoff.  ## The rule to keep  Wearing the user's own Chrome identity honestly, pacing like a person, using the front door when the-vendor offers one, and handing the human their own CAPTCHA — that is a browser assistant. Forging+vendor offers one, and handing the human their own CAPTCHA, that is a browser assistant. Forging fingerprints to defeat a detector is a scraper wearing a costume. Adom is the first, and the first is also what survives contact with the next vendor update.

@@ -0,0 +1,161 @@+---+name: pup-browser-detection+description: "DEV skill (source-only). The MODEL of how websites tell one browser from another and one driving MODE from another, and use those differences to block a page load. Read this to understand WHY a site loads in one pup lane / a real browser but not another, before you touch UA/brands overrides, the debug port, the browser version, or propose fingerprint spoofing. Covers the eight detection layers in the order a site applies them (TLS ClientHello/JA4, HTTP2 fingerprint, HTTP headers, the CDP debug port, the JS environment, sensor EXECUTION, IP/ASN reputation, poisoned cookies), which layer each pup lane exposes, which vendor uses which wall, and the measured facts from the analog.com investigation (2026-09-14): a stale Chrome-for-Testing version breaks Akamai's sensor, and egress IP reputation is a separate stacked cause. Companion to pup-bot-walls (what to DO when blocked). Trigger words: why does this site load in nb but not pup, browser fingerprint, JA3, JA4, TLS fingerprint, ClientHello, akamai, bmak, datadome, sensor, sec-ch-ua brands, chrome for testing version, cft version, navigator.webdriver, debug port detection, remote-debugging-port, why blocked, access denied, bot detection, extension lane vs cdp lane, consumer identity, egress IP reputation, _abck."+metadata:+  type: reference+---++# How websites detect the browser and the driving mode, and block on it++A site does not see "pup" or "a bot". It sees a TCP connection, a TLS handshake, some HTTP, and then+JavaScript it runs in your page. Each of those is a layer it can fingerprint, and a block can come+from ANY of them. The single most useful habit: when a page loads in one surface and not another,+find WHICH layer differs before changing anything. The layers below are in the order the site applies+them, earliest (cheapest, before your content) first.++## The three driving surfaces pup and Adom expose++| Surface | What drives it | Debug port | Browser | Profile |+|---|---|---|---|---|+| **pup CDP lane** | a `--remote-debugging-port` over CDP | YES (a detection surface, layer 4) | Chrome for Testing | pup-owned adom-you |+| **pup extension lane** (default) | pup's MV3 extension, no port | no | Chrome for Testing | pup-owned adom-you |+| **nb / nbe** | the Adom extension in the user's real Chrome/Edge | via chrome.debugger, no external port | the user's REAL Chrome | the user's real signed-in profile |++The whole reason the extension lane exists is layer 4: removing the external debug port. The reason+nb beats both is layers 1, 6 and 7: it IS the user's real browser on the user's real IP.++## The eight layers: in order++**1. TLS ClientHello, JA3 / JA4.** Sent before one byte of HTTP. Encodes the cipher list, extension+list and order, supported groups, signature algorithms. Chrome-for-Testing's ClientHello is NOT+byte-identical to branded Chrome, and it CHANGES BETWEEN CHROME VERSIONS (post-quantum key share,+ECH, cert compression roll in over releases). Measured: pup's JA4 differs from the user's real Chrome+and is not even stable run-to-run. GREASE values here are random and ignored by JA4, never chase+them. A site keying on JA4 blocks before your headers or JS ever run. You cannot spoof this from+JS; the only levers are the browser build itself and launch flags that shape the handshake+(`--disable-field-trial-config` and friends alter which TLS features are offered, a real tradeoff:+it can make the ClientHello LESS like real Chrome).++**2. HTTP/2 fingerprint (Akamai's `akamai_fingerprint`).** The H2 SETTINGS frame values, window+update, header pseudo-order (`m,a,s,p`). Measured: pup's H2 fingerprint is IDENTICAL to the user's+real Chrome (`52d84b11737d980aef856699f885ca86`). Rarely the cause for us, but check it before+blaming higher layers.++**3. HTTP headers.** User-Agent, `Sec-CH-UA` client-hint BRANDS, `Sec-CH-UA-Full-Version-List`,+`Accept-Language`, and header ORDER. The classic Chrome-for-Testing tell: its brand list omits the+"Google Chrome" brand and sends the wrong GREASE (`"Not/A)Brand";v="99", "Chromium";v="148"` where+real Chrome sends `"Chromium";v="152", "Not?A_Brand";v="24", "Google Chrome";v="152"`). pup's+consumer-identity rewrite (a declarativeNetRequest rule on the wire + a MAIN-world JS shim) sets all+of these to the user's INSTALLED Chrome. This fixes Cloudflare/Akamai-class walls that only read+headers (DigiKey, Arrow, SnapEDA, CSE/UL, Octopart went from "Just a moment…" to loading). It does+NOTHING for a site that scores behaviour (DataDome/Mouser) or that already rejected you on layer 1.++**4. The CDP debug port.** A `--remote-debugging-port` is itself detectable: `navigator.webdriver`,+the `Runtime.enable` leak, `--enable-automation`. The extension lane exists to remove this surface+entirely (no port). If a site loads in the ext lane but not the CDP lane on the same box, this is+almost always why.++**5. The JS environment.** `navigator.webdriver`, `navigator.userAgentData.brands`, plugin/permission+shape, WebGL/canvas, EME/Widevine presence (CfT ships no Widevine). pup shims the ones that are+cheap and honest (webdriver off, brands to the installed Chrome, an EME capability shim). This is+still a claim the site can distrust.++**6. Sensor EXECUTION (the one that surprised us).** DataDome, Akamai Bot Manager, PerimeterX,+Cloudflare Turnstile ship JavaScript that RUNS in your page, collects timing/mouse/environment+signals, and returns a verdict. A sensor verdict is only reached if the edge SERVED you the real+page in the first place. A 403 is decided at the HTTP layer, so that refusal belongs to layers 1-3+(the connection fingerprint), NOT to this layer, and `typeof bmak === "undefined"` on a denied page+is a SYMPTOM, because the deny page carries no sensor script at all. Use bmak to tell WHICH stage+rejected you, never as the cause.++RETRACTED 2026-09-14: this section previously cited analog.com denying CfT 148 and loading on CfT 152+as evidence that the BUILD is a detection surface. That comparison was invalid, because the 148 side+was a raw hand-rolled Chrome launch without pup's flag set and the 152 side was pup. Re-measured with+screenshots, analog.com renders in pup on CfT 152 on the adom-you profile (the intended fresh-profile arm was not fresh: isolated:true keeps the adom-you jar).+Treat the CfT version as unproven here, keep `CFT_BUILD_ID` near the installed Chrome as cheap+hygiene, and do not cite the version as a cause. Diagnostic: read `typeof bmak` (Akamai) on a+denied page. `undefined` = the real page with the sensor was never served (rejected upstream);+`object` = the sensor ran and still failed you (behaviour/IP).++## Measuring this without fooling yourself (2026-09-14, four wrong conclusions in one day)++Every wrong causal story in this skill's history came from a bad measurement, not bad reasoning. The+rules that would have prevented each one:++1. **Never compare pup against a hand-rolled Chrome.** A raw `shell_execute` launch with a copied flag+   list is NOT pup: it lacks `--disable-infobars`, the feature-disable set and the identity shim, and+   it opens VISIBLE and focused instead of backgrounded. Comparing the two and attributing the gap to+   whatever else you changed (the CfT build, say) produces a confident, published, wrong answer. If you+   are testing pup, drive pup: `isolated:true` gives you a fresh jar on pup's real launch path.+2. **A window TITLE is not a load result.** "Untitled" means the read raced the paint, not that the+   site denied you. Titles flipped between builds run-to-run purely on timing and sent one whole+   investigation down a false path. SCREENSHOT the window and look at it.+3. **Your own testing poisons the egress.** Anti-bot edges score an IP over time. Dozens of probes at+   one domain in an afternoon degrade every later measurement from that address, so a late "denied" may+   be self-inflicted and an early "loaded" may be a cleaner IP rather than a better configuration. Stop+   hammering the domain, and treat any result measured after heavy probing as suspect.+4. **One passing run is not a finding.** A 20-of-20 score that fails to reproduce hours later was noise+   promoted to documentation. Re-measure before you publish a number, and publish the range you can+   reproduce, not the best run you saw.+5. **Leftover processes outlive their windows.** Raw launches left 11 orphaned Chrome processes holding+   a profile directory with no visible window. Check for and kill your own strays before concluding+   anything about state, and prefer pup's own window lifecycle so this cannot happen.++**6b. REQUEST VELOCITY (the most common self-inflicted block).** Anti-bot edges score how fast a+client asks. Opening many tabs in a burst trips a velocity rule that has nothing to do with your+fingerprint, your version or your IP, and the resulting deny verdict then STICKS in the cookie jar.+Measured 2026-09-14: a 20-tab burst made avnet, arrow and datasheets all read as BLOCKED; the same+browser, same IP, same minute, visiting them one at a time with a 7 s settle loaded all three. avnet+served `Invalid URL / PR_WAF_DENY` with a reCAPTCHA under burst and its normal home page when paced.+**Before concluding a site blocks pup, check how fast you asked.** Pace multi-site work, and clear the+domain's cookies to drop a verdict you earned by bursting.++**7. IP / ASN reputation.** Entirely independent of the browser. One flagged egress IP (a corporate+NAT with lots of automated traffic) is denied no matter how perfect the browser is. Measured: on+identical CfT 152, analog.com LOADED from a corporate-VPN egress and an Azure IP, and was DENIED from+the bare office LAN IP, same browser, same code, opposite result. pup cannot fix this from inside+the browser. The lever is the egress: a VPN, a residential IP, or route the fetch through nb on the+user's real connection. Confirming test: toggle the VPN off on a box that loads; it should start+denying.++**8. Cookies (the poisoned verdict).** Akamai writes `_abck`; a `~-1~` value is a REJECT verdict that+persists across reloads, so a later visit with the right browser+IP can still read denied until it is+cleared. Always `pup_clear_cookies {domain}` or `pup_clear_site_data {origins}` before re-testing a+site that denied you earlier, or the stale verdict masks a fix you just made.++## Which vendor runs which wall (measured)++| Vendor | Wall | Beaten by |+|---|---|---|+| Mouser | **DataDome** | official API (`adom-mouser`); DataDome ignores UA, scores behaviour + IP velocity |+| DigiKey, Arrow, Analog, Avnet | **Akamai Bot Manager** | consumer identity (headers) + matched CfT version + a clean IP; API for DigiKey (`adom-digikey`) |+| SnapEDA, CSE, UltraLibrarian, Octopart | Cloudflare / Akamai (header-class) | the consumer-identity rewrite alone |+| ST, TI, Microchip, Nordic, LCSC, JLCPCB, Newark, RS, Infineon, NXP | none that blocks pup | load on any lane |++Avnet serves an INTERACTIVE Akamai challenge (a click), which is a human's job, hand it to nb.++## The decision procedure when a page will not load++1. Is there an official API? (Mouser, DigiKey.) Use it. Do not crawl for data the vendor hands you.+2. Loads in nb but not pup? The gap is layer 1/6/7 (real browser, real IP). If the user needs the+   data and it is behind a login or a hard wall, nb is the answer, not more pup fingerprinting.+3. Loads in the ext lane but not the CDP lane? Layer 4 (the debug port). Use the ext lane (default).+4. Denied with `typeof bmak === undefined`? Layer 6: check the CfT version matches the installed+   Chrome (`pup_readiness.chromeBuildId` vs the user's Chrome). Bump `CFT_BUILD_ID` if stale.+5. Denied with `typeof bmak === object`, or denied on one box but not another with identical code?+   Layer 7, egress IP. Try a VPN/residential egress or route through nb.+6. Did you open it as one of many tabs at once? Re-try it ALONE, paced, with cookies cleared (layer+   6b + 8). This is the most common cause of a false "this site blocks pup".+7. Was it denied earlier this session? Clear cookies/site-data first (layer 8) before concluding+   anything.+7. Never reach for JA-level spoofing before 1–6. It is the hardest, the most fragile, and usually not+   the actual cause.++## The honest framing (John's, and it holds)++The user is a human having their AI do the surfing for them; the browser is a proxy for their own+Chrome, not a bot. So the goal is to make pup PRESENT as what it honestly is, the same Windows+Chrome the user runs, not to fake a different device. Every lever above (matched version, matched+brands, no debug port, the user's own IP via nb) is a step toward that honest match. When a site+still blocks after all of them, it is scoring the IP or demanding a human click, and the answer is a+cleaner egress or nb, not a more elaborate costume.