Pup - Puppeteer Bridge - Commits

Composite taskbar badge: favicon + Adom mark, overlay-only branding (John's design). Overlays are the GENTLE branding path and are now ALLOWED in minimal-touch: SetOverlayIcon paints onto the EXISTING taskbar button, unlike an AppUserModelID change which makes Windows destroy and recreate that button (the invasive behaviour that fired repeatedly on SPAs). So minimal mode now stamps NO identity and builds NO jump list, but each window wears ONE composed badge: the page's own favicon as the dominant image (23x23 at 1,1 on a 32x32 rounded dark plate) with the Adom mark tucked into the lower-right on a dark disc for legibility at taskbar size. The .ico fast-path no longer bypasses compositing, so every badge carries the Adom mark.

John Lauer · c650d79 · 13d ago

Publish 1.9.190

John Lauer · 201ebcf · 13d ago

Seal minimal-touch so the experiment measures what it claims. A systematic sweep of every desktop_taskbar / set_window_identity / flash_window call site found three AUTOMATIC paths still firing in minimal mode: updateThumbnailTooltip, badgePupTaskbar (legacy overlay fallback) and registerPupAumid. All three now no-op. The only remaining ungated taskbar calls are on USER-INITIATED raise paths (browser_raise_os_window and its flash-clear), which are explicit user actions, not the continuous background machinery under investigation.

John Lauer · b339e46 · 13d ago

Publish 1.9.189

John Lauer · c106407 · 13d ago

Taskbar-state audit fixes (John: 'you still seem to be inconsistent with how you handle them'). (1) applyAppOverlay leaked past minimal-touch, so windows opened in minimal mode wore a HALF-BRANDED taskbar button: plain Chrome icon (no AUMID stamp) with a pup-painted favicon overlay on it. In minimal mode pup now paints nothing on the taskbar at all. (2) AUMID keys leaked two ways: a closed window's key survived until the next bridge boot (audit found Adom.Pup.mt3.web.i3 long after mt3 closed), and a LIVE window accumulated one key per category change with nothing removing the superseded ones (audit found 3 keys for one window). Now: close prunes, and the pruner drops a live session's superseded keys while keeping its current one.

John Lauer · a42ee55 · 13d ago

Publish 1.9.188

John Lauer · 62dead9 · 13d ago

Gate the AUMID stamp at its choke point so minimal-touch is actually silent. Live measurement showed mt3 still getting [identity] stamps from callers that bypassed the launch-path gate; stampPupIdentity and brandPupWindow now no-op in minimal mode, so nothing can leak a taskbar-identity change (which makes Windows destroy and recreate the window's taskbar button).

John Lauer · ef00104 · 13d ago

Publish 1.9.187

John Lauer · 8f38524 · 13d ago

Close the last two minimal-touch leaks found by live measurement: per-verb auto-flash (scheduleAutoFlash) and the post-navigation category re-check (scheduleCategoryRecheck), which re-registered an AppUserModelID and re-stamped the taskbar button on every category change — meaning Windows destroyed and rebuilt that button repeatedly on SPAs that route-change constantly. Both are now off in minimal mode.

John Lauer · 0356405 · 13d ago

Publish 1.9.186

John Lauer · 27df633 · 13d ago

Close the minimal-touch leaks the first live check caught: the launch path still fired a taskbar flash, stamped a per-session AUMID (which makes Windows DESTROY and RECREATE the window's taskbar button — the most invasive thing pup did to a window it does not own, and it also pulled in the jump-list rebuild), and ran a second park pass 2.5s after the first. All three are now off in minimal mode: no flash, the window keeps Chrome's own taskbar identity, and the window is positioned exactly once per open.

John Lauer · 6669e61 · 13d ago

Publish 1.9.185

John Lauer · f8cf45f · 13d ago

Stop doing the extra things to Chrome, instead of monitoring harder (John: 'you crash chrome with the way you control it ... what are you doing that's so different trying to control chrome that you cause crashes and freezes in the first place? that's where you should be looking'). TWO changes. (1) REAL LEAK FIXED, unconditional: the v1.9.78 crash detector opened a SECOND CDP session per tab and never detached it, so every tab held an extra attached debugger session for its entire life, accumulating in the browser process; puppeteer's page 'error' event already covers renderer crashes, so it is removed. (2) New minimalTouch setting (browser_configure {minimalTouch:'on'}) strips pup to open-a-window + drive-it-over-CDP and disables EVERY cosmetic/janitor action pup performs ON Chrome: taskbar identity re-stamps (which destroy+recreate the taskbar button), tab-count badges, favicon overlays, jump-list rebuilds, progress bars, auto-flash, foreground toasts, the in-page title MutationObserver (which re-fired on every SPA title write, a pup-created in-page write loop on exactly the Slides/Sheets windows that froze), and the periodic reclaim/placement/reconcile/unstick sweeps that eval into parked pages and force wakes. In minimal mode pup also NEVER kills or relaunches Chrome behind the user's back. This makes the cause measurable: if freezes persist with it on, pup's window machinery is not the cause and I look elsewhere; if they stop, it was.

John Lauer · cbaee45 · 13d ago

Publish 1.9.184

John Lauer · 9ffd4e3 · 13d ago

Stop the unstick misfire that kept clicking the user's screen (John: 'why does the mouse keep jumping to the upper right corner of the pup window'). The v1.9.183 stuck-occlusion check probed only pup's notion of the active tab; when the user was viewing a DIFFERENT tab of that window, the probed background tab reported hidden (normal), so a healthy window was diagnosed frozen every 30s and the cure ladder fired a real desktop click each time. Now: a window is stuck only if NO tab reports visible (a healthy frontmost window always has one); a visible tab also re-syncs pup's stale activeTabId to what the user is actually viewing; detection must repeat on two consecutive sweeps before any cure runs; and the real-click last resort is hard-capped at once per session per 10 minutes. No evidence, no action.

John Lauer · efc87af · 13d ago

Publish 1.9.183

John Lauer · b74fdb5 · 13d ago

Unstick last-resort upgraded to a REAL input click (proven cure). The stuck-occlusion state (window frontmost, page reports hidden, Chrome paints nothing) hit John TWICE today including on a freshly opened window, and both soft cures (CDP lifecycle active, ALT-nudge SetForegroundWindow) failed live while a genuine mouse click fixed it instantly both times. The auto-unstick now escalates: lifecycle, forced activation, then a real desktop_click on the window's empty tab-strip area via AD (pure activation, cannot hit page content; only runs when the user is already looking at the frozen window).

John Lauer · e0cbfeb · 13d ago

Publish 1.9.182

John Lauer · 48226bc · 13d ago

EMERGENCY: revert+harden the v1.9.181 tab reconciler that destroyed live windows (John's smu-deck-pup2 and wiki-review were stripped to 0 tabs mid-use and taken down). Root cause: liveness judged from browser.targets() via puppeteer-internal target-id fields whose id set did not match page.target()'s, so every live tab looked absent and was dropped. Now: a tab is dropped only on DIRECT evidence (isClosed, or a probe failing with the crashed/detached-frame signature; timeout=busy=keep), never on target-set inference; a new safety rail refuses any reconcile that would empty a session outright (wholesale-death is more likely a probe failure); patrol slowed 45s to 5min (rescans still reconcile inline).

John Lauer · f7f2abc · 13d ago

Publish 1.9.181

John Lauer · 9f4d011 · 13d ago

THE FIGHT-THE-USER FIX (John: 'pup windows still don't behave well and seem to freeze a lot' — he was right, pup was doing something deeply wrong). Root cause: pup could not tell 'the user is using this window' from 'this window drifted on-screen', so recovery re-parked every window to the bottom after every bridge restart (the foreground flag was never persisted to the session file), and reclaim-adoption parked windows the user was actively reading after every crash. Fixes: (1) session files persist the foreground choice and recovery restores it BEFORE the rewrite; (2) new user-activity watcher: the 15s sweep observes when the OS-foreground window IS a pup window and stamps it foreground (persisted) — taskbar clicks now count exactly like a granted raise, implementing PLACEMENT-INVARIANT item 1; (3) reclaim-adoption skips the park when the window is the user's foreground; (4) recovery park guarded by userIsUsingWindow (10-min recency). Load reduction so pup stops pounding the machine: tab reconciler judges liveness from browser.targets() instead of waking every throttled renderer with page.evaluate every 45s; the unstick sweep probes only the one foreground-matched window (was: every session every 15s); the 20s progress reconciler only fires for bars actually lit (was: an AD PowerShell call per session per tick forever); session hwnds cached 10 min.

John Lauer · c44227f · 13d ago

Publish 1.9.180

John Lauer · 4bff490 · 13d ago

STUCK-OCCLUSION auto-unstick (root-caused live on John's Slides window): after a browser-process hang, Chrome's occlusion state for a window can come back corrupted — the window is FRONTMOST yet the page reports visibilityState hidden, so Chrome withholds every frame; the user sees DWM's last composited frame (looks perfect in screenshots) but wheel/typing repaint nothing, i.e. 'pup is frozen' on a healthy page. Raise and even minimize/restore do not recompute it; only a real activation does. New unstickIfHiddenWhileFront detects the impossible state (OS-foreground window + page-hidden), fixes it via CDP Page.setWebLifecycleState active then a real forced activation (AttachThreadInput ALT-nudge + SetForegroundWindow), reports via the cleanup queue, 30s per-session cooldown. Wired into the 15s health sweep and 2s after every granted raise.

John Lauer · adbc542 · 13d ago

Publish 1.9.179

John Lauer · 713f73e · 13d ago

Fix inflated tab counts + vanished overlay icons (John caught count:4 on 1-tab windows). Root cause: rescanProfile keyed its already-attached map on the puppeteer Page OBJECT, which is recreated on every reconnect, so each rapid bridge restart re-attached the same Chrome tab as a duplicate — a 1-tab window grew 4 identical entries, the count badge read 4, and the favicon read hit a detached phantom so the overlay fell back to that wrong count. Now: rescan dedupes by CDP TARGET ID (stable across reconnects); new reconcileSessionTabs prunes dead/detached + duplicate tab entries (probe timeout = busy, kept — never drops a merely-slow tab) and re-stamps the overlay; runs at boot, every 45s, and at the end of every rescan.

John Lauer · 1f17149 · 13d ago

Publish 1.9.178

John Lauer · 7e81ac1 · 14d ago

Crashed-renderer recovery: require STABLY-alive (two consecutive readyState reads ~700ms apart) before declaring a respawn successful — a fresh renderer flickers a transient execution context mid-navigation, so the old single-probe check falsely reported success then the page was still crashing. browser_navigate now also reports tab_renderer_crashed_unrecovered (close+reopen hint) when respawn does not take, symmetric with browser_reload. So recovery either genuinely brings the tab back or cleanly tells the caller to close+reopen — never a false success.

John Lauer · 25f1860 · 14d ago

Harden crashed-renderer recovery: respawnCrashedRenderer is now race-safe (one respawn per page; the auto-heal and a manual reload/navigate can no longer collide into a hang) and every CDP call is hard-timeout-bounded, so a crashed target can never wedge the verb. browser_reload now reports tab_renderer_crashed_unrecovered with a close+reopen hint when the in-place respawn cannot recover (e.g. Chrome too memory-pressured), instead of falsely claiming success. Follows the 1.9.176 fix where the recovery could hang under a concurrent auto+manual respawn.

John Lauer · 6bd05bb · 14d ago

Recover crashed renderers ('Aw, Snap! Out of Memory'). A crashed renderer detaches the page's main frame, so browser_reload/browser_navigate threw 'detached Frame' — the recovery the crash hint promised could not actually run, leaving the window stuck on the Aw-Snap page. New respawnCrashedRenderer() drives the raw target with Page.navigate to spawn a fresh renderer in the same tab/window/session; browser_reload and browser_navigate now use it (both when the tab is flagged crashed and as a fallback when they hit a detached frame). Plus the renderer crash detector AUTO-heals the tab once (an Aw-Snap tab is already dead, so respawn loses nothing), reporting via the cleanup queue, capped at one attempt to avoid a reload-crash loop. Surfaced by John hitting an Aw-Snap on a shared-profile wiki window after back-to-back heavy tests piled memory into the one shared Chrome.

John Lauer · e56f49d · 14d ago

Publish 1.9.175

John Lauer · 5849fc3 · 14d ago

Fix stale wikiView docs that misreported the shared logged-in view as the anonymous public view. Since the wiki login now lives on the one shared adom-you profile, OMITTING wikiView shows the LOGGED-IN view, not the logged-out world view — only an explicit wikiView:public forces an isolated anonymous jar. The browser_open_window describe and the per-open wikiViewHint now distinguish three cases (omit=shared/logged-in, public=isolated/logged-out, authed=explicit vault) so an agent verifying 'did private source leak to the public?' no longer inspects the user's logged-in view by mistake. Surfaced live while opening 10 random wiki windows as a logged-in/logged-out mix.

John Lauer · 1320c90 · 14d ago

Publish 1.9.174

John Lauer · 12eefa5 · 14d ago

Docs: teach the calling AI pup's resilience behavior so the new signals are DISCOVERABLE — _degraded on list/status means a window is busy (Chrome under load), NOT crashed or frozen; a vanished window is auto-relaunched by the health loop and reported via _cleanupReport (do not panic-kill/reopen by hand); one window timing out never means the bridge is dead. Adds the 'Under heavy load or a crash, pup self-heals' section to the pup skill and the jam/crash/torture scenarios to the maintainer test skill.

John Lauer · 6f1853d · 14d ago

pup-bridge-test: add jam-resilience, crash self-heal + reclaim-race, and TORTURE scenarios; record the jam-vs-crash root cause (frozen = CDP jam not crash; Chrome stays alive ~45 procs) proven live 2026-07-28

John Lauer · 0615e77 · 14d ago

Publish 1.9.173

John Lauer · 3b10e86 · 14d ago

Crash self-heal race fix: when Chrome crashes under load, reclaimUnmanagedWindows could reap the crashed session (and delete its file) before the health/heal loop relaunched it, so the relaunch failed 'session not found' and the window was lost (seen live under stress). Now: handleBrowserDisconnect stamps the last-known URL on the session at disconnect; reclaim gives the heal a protected 2-minute window before reaping a _lostBrowser session; and recovery falls back to the cached URL when the session file is gone. So a crash under load actually recovers the windows instead of stranding them.

John Lauer · 9cee43d · 14d ago

Publish 1.9.172

John Lauer · 5a1c471 · 14d ago

Jam-proof status verbs: browser_list_windows and browser_status now gather sessions in PARALLEL with a hard 2.5s per-session timeout and an in-memory fallback, so one busy window (Chrome under heavy load on a heavy SPA) can no longer hang the whole handler into a null response (the 'pup looks frozen' symptom). getSessionInfo caps its per-window CDP reads (title + focus eval) and caches last-known url/title; busy windows return marked degraded with last-known state instead of being dropped. Reproduced live: 6 heavy windows + memory pressure drove list_windows to null before; this returns the full list every time.

John Lauer · af38094 · 14d ago

Publish 1.9.171

John Lauer · 23442ed · 14d ago

Crash self-heal: proactively relaunch _lostBrowser sessions after a Chrome crash (signed-in, background, at last URL) with a 2-attempt backoff so a crash-on-load page cannot loop; keep the hung-CDP probe as a second path into the same relaunch. Fixes the frozen-pup-after-crash the v1.9.170 browsers-probe could not catch (entry is already deleted on crash).

John Lauer · 0f536c0 · 14d ago

Publish 1.9.170

John Lauer · cad61fd · 14d ago

Browser-health watchdog so pup SELF-HEALS from a shared-Chrome crash instead of sitting frozen (John: 'pup seems frozen again' — the Autodesk sign-in flow has crashed the shared adom-you Chrome four times this session). Root cause of the frozen FEELING: when the shared Chrome crashes, the browsers-map entry becomes a dead connection; getOrLaunchBrowser has a real health check but only runs REACTIVELY on the next open, and the dead handle lingers so verbs fail 'Connection closed' and passive verbs return null — pup looks frozen until the user notices. New watchdog probes every browser every 15s with a real CDP call (pages() + 3.5s timeout, catching both crash and hang); a browser that fails TWO consecutive probes (~30s, so a transient slow beat never triggers it) is discarded, its zombie Chromes reaped, its sessions marked _lostBrowser for relaunch, and the recovery is reported through the cleanup queue. So a shared-Chrome crash becomes a ~30s self-heal the user is told about, not an indefinite freeze. Does NOT prevent the crash (root cause still unreproduced deterministically) — makes it a non-event. Two-strike guard prevents killing a briefly-slow-but-alive Chrome.

John Lauer · 525b9ba · 14d ago

Publish 1.9.169

John Lauer · 41b26c6 · 14d ago

Update 1 file(s)

John Lauer · 8782a94 · 14d ago

Make the assisted-click protocol DISCOVERABLE (John: 'did you build in ai hints to make sure the ai acts the way i told you?' — audit found NO). browser_assisted_click was built (1.9.167) but had zero describe-catalog entry (undiscoverable), browser_raise_os_window did not steer to it, and it lived only in pup-vendor-login. Now: full V() catalog entry for browser_assisted_click (so browser_describe surfaces it with args + example); browser_raise_os_window's hint explicitly redirects native-dialog/FedCM click-foregrounds to browser_assisted_click; and the main pup SKILL.md foreground rule points click-foregrounds at it. So any AI doing a foreground-to-click discovers and uses the respectful (toast, caption, alt-tab-aware wait, tight cursor) protocol instead of raise-then-click.

John Lauer · fd9699b · 14d ago

Publish 1.9.168

John Lauer · 8f6d22a · 14d ago

pup SKILL.md: document the Power & rendering balance that was in code but never in the user skill — background windows are throttled by default (saves CPU/battery, James's issue #14), so a healthy backgrounded window can LOOK frozen (throttling, not a hang, wakes on focus); highFps is the LEASED override (20min default, 120 max, auto-downgrades) for a window that must keep rendering while unfocused. Do not use highFps to fix a merely-throttled window — just focus it.

John Lauer · 5a7eb3b · 14d ago

Update 1 file(s)

John Lauer · 4008e56 · 14d ago

Publish 1.9.167

John Lauer · e69917b · 14d ago

Assisted-foreground-click protocol — John's respect requirements after I disrupted his work by foregrounding while he was mid-task and not ready. New browser_assisted_click verb for the rare surface pup's CDP click can't drive (native dialog, cross-origin FedCM chooser): (1) captions the AI's reasoning via desktop_caption BEFORE touching the screen, (2) toasts, (3) foregrounds, (4) THE RESPECT LOOP — waitForUserReady polls osGetForegroundWindow vs the session's HWND and BLOCKS until the user's foreground actually IS this window and stays stable ~1.2s, captioning 'Adom is waiting — click back when ready, nothing happens until you do' if they alt-tabbed away; times out gracefully with user_not_ready and clicks NOTHING, (5) only then a TIGHT real-cursor hover->click (fresh capture, hover, 900ms for genuine motion, click — the exact sequence FedCM accepts and that failed when ops were interleaved), (6) captions each step through completion. Also generalized pupCaption + sessionHwnd helpers. This is the protocol so pup never again foregrounds and acts while the user isn't ready.

John Lauer · 0d80c04 · 14d ago

Pup - Puppeteer Bridge

Commit History