← Commit history

Document the CfT-over-native design decision: the original profile-poisoning reason is now handled by launch flags (CfT showed the same dialog), the reasons that still hold, the costs (staleness/limits/download), and when native is right

John Lauer ·3c00e978e6 ·3mo ago ·parent fc5fa00
1 file changed +61
dev-skills/pup-bridge-dev/SKILL.md+61
@@ -773,3 +773,64 @@ adom-desktop --target <name> browser_readiness '{}'   # proves the new code is l   from the adom-desktop repo — that clobbers this cloud-owned page. - Don't ship the bridge runtime in the pkg tarball or the skills in the release zip. Two artifacts, two homes. - Don't install 'stable' Chrome — pin to puppeteer's expected buildId (`chrome.js` does this).++## DESIGN DECISION: why Chrome for Testing (CfT) over the user's native Chrome/Edge++This choice gets relitigated often (wiki issues #9, #15, #202, and the 2026-07-24 native-Chrome-150+diagnostic). Read this before touching the browser pick order (`launchCandidates` in chrome.js) so you+argue from the real, current rationale — not the original one, which has partly changed.++**The decision:** cached CfT is preferred FIRST; installed system Chrome/Edge is the no-download+fallback; CfT is fetched (~150 MB, once) only when there is no Chromium at all. Order lives in+`launchCandidates()`. A local `browser_use` pin overrides it per-machine.++### The original reason — and why it's now only HALF the story++CfT-first was introduced (v1.8.71) after the "Aditya/Google-auth incident": driving branded Chrome/Edge+with an isolated `--user-data-dir` still popped the "Sign in to Chromium? / Set up a work profile"+dialog, which poisoned pup's anonymous windows (duplicate profiles, consolidation prompts, lost user).+CfT is automation-first with no sign-in/sync/profile machinery, so it dodged that.++**BUT** (measured live 2026-07-19): **CfT shows the SAME dialog.** Switching to CfT did NOT actually+fix the poisoning. The real fix was launch flags applied to EVERY browser pup drives+(`noBrowserIdentityFlags` in server.js: `--allow-browser-signin=false`, `--disable-features=+SigninIntercept,...,ProfilePicker`, `--disable-signin-promo`, `--disable-sync`). So "CfT avoids the+sign-in dialog" is NO LONGER a valid argument for CfT-first — the flags handle it regardless of binary.++### The reasons that DO still hold for CfT-first++- **Version determinism.** CfT is pinned to an exact build (via bundled puppeteer's `expectedBuildId`).+  The user's Chrome auto-updates underneath pup — uncontrolled version drift, and recent Chrome+  releases keep tightening remote-debugging/profile behavior. CfT can't shift under us mid-session.+- **Automation-first binary.** No branded UI surfaces (update nags, promo bars, first-run flows) that+  can intrude on a screenshot or a recording.+- **Fully bridge-controlled.** We own its lifecycle and cache; we don't share a binary with the user's+  interactive browsing.++### The COSTS of CfT-first (be honest about these)++- **Staleness.** The pinned build is only as fresh as the bundled puppeteer. Measured 2026-07-24: the+  fleet was on CfT **146**.0.7680.76 while current stable CfT was **152** — six majors behind, and an+  old patch of 146 at that. Bumping means bumping puppeteer (see the version-bump note) and+  re-publishing; the fleet then converges on next open. Native Chrome is always current with zero work.+- **Tighter resource limits (issue #16).** CfT appears to run leaner than desktop Chrome; a heavy SPA+  tab (measured a 438 MB renderer) plus an in-page eval can tip a CfT renderer over more readily. This+  is a live suspect for the "tab freezes under load" reports, hence the native-Chrome-150 diagnostic.+- **The ~150 MB download is the fragile part (issue #15).** A half-populated cache made pup unusable;+  the download failing behind an npm allow-scripts gate is a real fleet failure mode. Native browsers+  need no download. This is exactly why we must NEVER block an open on the CfT download when a system+  browser exists (the v1.9.77 gate fix).++### When native IS the right call++- The no-download fast path on a fresh box (system browser used immediately; CfT prewarms in the+  background to converge later).+- A CfT build regression — pin native with `browser_use {browser:"chrome"|"edge"}` as an escape hatch.+- Diagnostics like ruling CfT out as the cause of a freeze.++### The rule++Do NOT flip the fleet pick order to native-first without NEW evidence — that reverses issue #9's+determinism argument, not just a bug fix. The defensible fleet change is keeping CfT-first but keeping+its pinned build CURRENT (bump puppeteer), so the fleet isn't running a stale Chromium. Per-machine,+`browser_use` is always available as the override.