← Commit history

Decision doc: flip pup to native-first (John, 2026-07-24). Record that the identity-dialog reason for CfT-first is dead (flags fix it on any Chromium), the freeze was the reap bug not CfT, native works with all taskbar branding, and CfT is now the last resort + the managed-box escape hatch via browser_use.

John Lauer ·b8d6a38598 · ·parent 8f85e8e
1 file changed +28−15
dev-skills/pup-bridge-dev/SKILL.md+28−15
@@ -818,9 +818,12 @@ This choice gets relitigated often (wiki issues #9, #15, #202, and the 2026-07-2 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 decision (v1.9.90, John, 2026-07-24 — FLIPPED to native-first):** the user's INSTALLED browser is+driven FIRST — Chrome, else Edge (ships on every Windows PC) — in a fresh isolated profile with the+identity-suppression flags. Chrome-for-Testing is fetched (~150 MB, once) ONLY as the last resort when+there is no installed Chromium at all (e.g. a Mac with no Chrome). Order lives in `launchCandidates()`;+`warmup()` no longer force-downloads CfT when a native browser exists. A local `browser_use {browser:"cft"}`+pin still selects CfT explicitly — for a managed/enterprise box whose policies interfere with automation.  **Frame the question correctly.** pup wants a GENERIC, anonymous, disposable window — a fresh empty profile, never the user's identity. Both a fresh `--user-data-dir` on the user's installed Chrome AND@@ -874,23 +877,33 @@ sign-in dialog" is NO LONGER a valid argument for CfT-first — the flags handle  ### 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).+- The no-download fast path on a fresh box (system browser used immediately). Native is now the+  DEFAULT, so this is simply the common path — CfT is no longer prewarmed to "converge" the box. - 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. -### Bottom line (the honest compression)+### Bottom line (the decision, FLIPPED 2026-07-24)  We did NOT actually pick CfT to avoid the profile/sign-in dialog — that reason collapsed the day we-saw CfT show the same dialog, and launch flags became the real fix. What genuinely justifies CfT is-**version determinism** (native Chrome auto-updates and can be enterprise-policy-managed under us; CfT-can't) and **running a clean binary we fully control** instead of the user's interactive browser. The-price is a build that can go stale and a fragile one-time download — which is exactly why the sane-posture is "keep CfT-first but keep its pinned build current," not "switch to native."+saw CfT show the same dialog, and launch flags became the real fix (they apply to native Chrome/Edge+too). What was left for CfT was **version determinism** and **a clean binary we fully control**. Weighed+against the costs — a build that goes stale (fleet was 6 majors behind on 146 while stable was 152), a+fragile ~150 MB download, and the fleet dep-bump needed to move it (blocked by AD `preserve_client_deps`,+adom/adom-desktop#28) — those advantages matter mainly for a MANAGED/enterprise fleet with policy-bound+Chrome. For the Adom individual user base (unmanaged Chrome, Edge always present), native-first wins: no+download, always the user's current battle-tested build, and every taskbar icon/identity override works+on it identically (OS-window level, browser-agnostic — verified: John's box drove native Chrome 150 fully+branded). The freeze that triggered this review was NOT a CfT bug — it was the close-reap leaving orphaned+renderers (fixed v1.9.89), so it was never a reason to keep or drop CfT either way.++**So the fleet default is native-first.** CfT stays a first-class option for the one case it earns its+weight (a policy-bound managed browser), reachable by `browser_use {browser:"cft"}`.  ### 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.+Native-first is the fleet default (installed Chrome → Edge → CfT-last-resort; `launchCandidates()` ++`warmup()`). Do NOT flip back to CfT-first without NEW evidence that native is genuinely failing for the+user base (e.g. a wave of policy-bound-Chrome breakage) — the identity-dialog argument is dead (flags fix+it on any binary) and the freeze was our own reap bug. If a specific box has a policy-bound or broken+Chrome, that is a per-machine `browser_use {browser:"cft"}` pin, not a fleet reversal. Keep the bundled+puppeteer's CfT build current regardless, so the last-resort binary isn't ancient.