Pup - Puppeteer Bridge

The toolbar extension becomes a launch arg (John repinned pup to Chrome for Testing after the branded-Chrome extension lockdown made every install path ugly). CfT still honors load-extension, so when the driving browser is CfT and the toolbarExtension setting is on, every profile launch simply carries the flag and every window is born with the toolbar: there is no install step at all. The transient pipe-install experiment is deleted (verified session-scoped, useless with detached launches), staging is a plain file copy, the flag rides only chrome-for-testing candidates since branded Chrome removed it, and pup_install_toolbar is now informational

The toolbar extension now simply auto-exists in pup (John: this is pup, you control the browser, there has to be a better way than a file dialog). The UIA dialog-driving experiment is deleted. Before a profile's Chrome ever launches, pup does an invisible two-second pipe-launch of the same profile and installs the extension via CDP Extensions.loadUnpacked (puppeteer enableExtensions plus installExtension, the sanctioned replacement for the load-extension flag branded Chrome removed in 137), so the extension persists in the profile and every window is born with the toolbar: no dialogs, no chrome-extensions driving, no user action, ever. Marker-gated per extension version so upgrades re-install once. pup_install_toolbar is now a thin status/trigger verb

Brand compliance plus the zero-click toolbar install. The annotate overlay, capture toast, popup, and caption bar now follow the Adom UI design system exactly: token colors (the real 00b8b1 accent family, 161b22 surfaces, 30363d borders, c9d1d9 body text), monochrome SVG line icons replacing every glyph character per the icon law, brand fonts bundled in the extension popup (Familjen Grotesk headers, Satoshi body, JetBrains Mono data), toast moved to bottom-center per the toast standard, drawing palette mapped to brand status colors. New pup_install_toolbar verb answers John's can-not-you-just-do-that-automatically: pup stages the extension, drives chrome://extensions itself through the shadow DOM (dev mode toggle, Load unpacked), and ab drives the one native folder dialog, so the one-time install is fully automated. /health now carries owner and view per session plus the toolbar prefs for the extension's badge feed, and annotation start clears any stale result flag

Interactive-surface phase 1+2 core (plan: docs/PLAN-interactive-surface.md). Annotation captures are now TIGHT-CROPPED to the drawn strokes plus a 48px margin instead of the whole browser view (John: if the user wants the whole view they'll draw a circle around it), Photoshop-style tool cursors with the pen carrying a live swatch of the selected color, a quick-capture Auto mode that fires the moment the mouse lifts, and the clipboard-first return path: every capture lands in the Windows clipboard as image plus text JSON sidecar together via a .NET DataObject helper so one paste into any AI chat carries both, with a caption bar baked under the crop and an iTXt metadata chunk inside the PNG so an image-only paste still carries context. An in-page toast shows a thumbnail of the exact crop grabbed. Also: USER_CALLERS set replaces the four exact-string user-taskbar-menu compares (the toolbar extension's user-toolbar caller joins it), and the toolbarExtension settings family lands ahead of the extension

Annotation and snipping land in pup (John: claude desktop can annotate in its browser, add it to pup, and build in a screenshot snippet like shift+win+s). New pup_annotate verb plus an Annotate this page task on every window's jump list: an in-page overlay with pen, arrow, box, text, color cycling, undo, and a Snip tool whose marquee captures just that region immediately, exactly the win+shift+s flow. Done captures a PNG and deliberately leaves the drawing in the DOM, because pup windows are thread-owned: the annotation is a message, and the owning AI thread's next screenshot shows exactly what the human circled. Captures store under screenshots/ and surface as session lastAnnotation; a caption confirms the handoff. jlAnnotate sub-setting, default on

Switch to public view on a shared-profile window no longer logs every thread out. John asked what should happen clicking the jump-list view toggle on a multi-tab window; the code answer was a browser-wide cookie wipe (CDP clearBrowserCookies) that silently signed out every window of every thread, then reloaded only the active tab, because the shared-profile guard tested the legacy adom-wiki-authed profile name and never matched today's shared adom-you. The guard now uses ground truth (any other live session on the same profile, plus the known shared names), so a shared-profile public switch takes the tab-preserving relaunch path: the whole window with all its tabs moves to a logged-out profile and no other window is touched. Also ships the quieted 60s overlay re-assert logging staged earlier

Overlay badges can no longer silently vanish, the bare taskbar tile John caught that my log-trusting audit missed: the taskbar progress cycle (and other shell-side events) can clear a button's overlay, but pup's paint memory survived it, so the enforcer saw a painted window and never repainted, bare on screen while green in the logs. Windows offers no way to query overlay state, so the fix treats it as write-only: every progress change voids the paint memory (the 4s enforcer sweep repaints), and a 60s per-window ground-truth re-assert repaints unconditionally so memory can never drift from the screen for more than a minute. Also dedupes the sibling-favicon log line that spammed on every re-resolve

Close the whole window, not just the bound tabs, the last ghost-window wonk the mimic ralph surfaced: recovery binds one tab per session and the sibling-tab rescan runs later, so a pup_close_window issued soon after a bridge respawn closed 1 of N tabs, declared the session closed, and left the OS window alive as an orphan that pup later adopted as a strange auto-named adom-you session. pup_close_window now collects the CDP windowId of every bound tab and closes every page living in those windows, bound or not, with a shared-profile guard so a page tracked by any other session is never touched

Stop handle theft between same-page windows, the wonk the hardened mimic ralph caught red-handed: mimic windows and a second hd-publish window stole real windows' taskbar handles after a respawn. Three causes fixed. The natural-title resolver asked for the WRONG title (pup's activeTabId bookkeeping says first tab while Chrome's window title mirrors the last-opened visible tab), making a session uniquely match someone else's window; it now asks Chrome which tab is actually visible. A title shared by two pup windows is now refused outright, counted over all pup rows BEFORE ownership exclusions, because excluding the true owner's row is exactly how a theft looked unique. And a persisted-claims map now loads every session file's handle at recovery start, so a handle is protected before its owner's session even finishes recovering, closing the recovery-storm race. The mimic harness now also asserts the real windows and never resets its collision map so cross-session theft can never self-grade OK again

Recovered windows finally re-resolve their taskbar identity, read-only. The mimic ralph proved every window went bare after a respawn: the persisted-handle continuity check was silent, geometry cannot tell identical parked windows apart, and the off-screen re-capture failed silently on this box because Chrome clamps off-screen coordinates so the absolute-position match never hit (and its restore dumped windows at 0,0, itself visible wonk). Four changes: enum rows now carry the native window title; a new natural-title resolver matches each session's active-tab title against pup-owned windows only (pid-fenced so the user's own Chrome can never match, exactly-one or refuse, nothing written anywhere); the re-capture identifies the moved window by bounds change instead of absolute position (clamp-proof) and restores the exact original rect; and the continuity/recovery paths now log their outcomes so silent success or failure is visible

Fix the two wonks the mimic ralph reproduced from John's real 3-thread workload. One: after any bridge respawn every recovered window lost its taskbar identity (no handle, no overlay, unbrandable) because all four ownership proofs are dead for a recovered window, so the perfectly good persisted hwnd was discarded and the wiggle fallback could not disambiguate the shared profile. Recovery now records Chrome's persisted pid next to the restored hwnd, and hwndBelongsToPup accepts the pair (handle still owned by the exact process it was recorded under, and Chrome outlives pup respawns) as proof by continuity. Two: windows randomly ended up frozen with a 3-task jump list missing both view toggles, because a wiki window's categorized appId can commit before its login view resolves and the freeze locked that incomplete menu forever; wiki-category windows now freeze only once the view tasks are actually in the menu. Found by dev-skills/pup-taskbar-identity/ralph_mimic.sh, the new harness that replays John's observed workload including the respawn-recovery leg

Add an Open pup dashboard task to every pup taskbar jump list (John's ask): one right-click opens the live dashboard mapping every pup window and tab to its owning AI thread, reusing the one dashboard window on repeat clicks. Routed through the v2.0.41 direct-callback launcher like every other task. New jlDashboard sub-setting (default on) under Jump lists in the settings dialog, wired into the dedupe key and the settings refresh path so toggling it updates existing windows immediately

Jump-list tasks now call pup directly (John: be way smarter about how to call back into ab for the jump lists; should pup talk to itself when it is its own bridge). Answer: yes for pup verbs. Old tasks set no target so ab supplied the program (its bundled CLI), an exe path pup neither controls nor verifies and exactly what the CLI rename broke. Each task now carries target=powershell.exe plus a pup-owned launcher script that reads pup's own loopback port from a discovery file pup rewrites on every bind, POSTs the verb straight to pup (pup to pup, no ab hop, no CLI, no stale path), and only falls back to the resolved adom-bridge-cli.exe (which wakes pup via ab) if the direct hit fails because pup idled. JSON args ride as base64 so nothing mangles through the shell-link to powershell argv reparse. No ab change needed: the per-task target field already existed

Fix jump-list items doing nothing (John: Close ALL and other menu items don't work): the bundled CLI renamed from adom-desktop-cli.exe in the Adom Desktop folder to adom-bridge-cli.exe in the Adom Bridge folder, but pupRelaunchCommand hardcoded the OLD path, so every jump-list task, taskbar header click, and pinned launch invoked a missing exe and silently no-opped (verified live: old path gone, new path exists). The bridge runs on the desktop so it now resolves the real exe from disk, Bridge name first with a legacy fallback, cached

Remove the temporary birth-capture diagnostics now that the raw-Chrome-icon regression is root-caused and fixed (2.0.37 routes every window through the birth path, 2.0.38 makes capture position-independent and serialized). Verified live: four windows including three opened in parallel each got a distinct OS handle, a correct AUMID teal tile, and an overlay badge, with zero collisions and zero stamp failures

Position-independent, serialized birth-hwnd capture, the real fix: Chrome clamps our -32000 off-screen birth coordinate on-screen on some boxes, so identifying the new window by position fails (newOff was always 0). Now a global birth lock serializes window creation so the set-diff sees EXACTLY ONE new OS handle regardless of where Chrome placed it - that handle is the window, unambiguously, with no position or pid dependency. Combined with 2.0.37 routing the first window per profile through this same path, every pup window on Windows now gets a reliable unique handle, so AUMID and overlay paint and no window shows a raw Chrome button

THE root cause of the raw-Chrome taskbar icons: only the 2nd-plus window on a profile went through the birth-capture path that assigns an OS hwnd; the FIRST window on a profile used browser.newPage() which captures no handle, so after 2.0.24 removed the title-tag fallback that first window was permanently unresolvable and showed a raw Chrome button with no AUMID and no overlay. Now every pup window on Windows is created through createPageInNewWindow (off-screen birth + set-diff capture), so all of them get a reliable, unique handle. Keeps the 2.0.36 diagnostics one more build to confirm

Temporary diagnostic instrumentation on the birth-capture block to find why hwnd resolution stopped producing results (logs fresh/profile/beforeHwnds, per-iter rows/offscreen/newOff counts, and any thrown exception) - to be removed once the root cause is found

Make the 2.0.34 set-diff birth capture actually resolve under concurrency: widen the off-screen birth spacing from 40px to 220px so disambiguating concurrent births by nearest-birthLeft is unambiguous against Chrome placement jitter (the 18px tolerance was too tight and left every concurrent birth AMBIGUOUS with nothing stamped; 60px had been too loose and cross-wired). New windows are identified by set-diff, then the one nearest my unique birthLeft is mine

Fix cross-wired taskbar identity John caught (fusion and nb resolved to the SAME hwnd, so one thread stamped its AUMID onto the other's window and the loser stayed a grouped raw-Chrome button while a pup tile showed no overlay): the birth-time hwnd capture is now a SET-DIFF (snapshot window handles before createTarget, the NEW off-screen handle not present before and not already owned by any session is ours by construction) instead of a coordinate match whose 60px tolerance overlapped the 40px birth spacing; concurrent births disambiguate by the unique birthLeft with an 18px tolerance; and a hard guard rejects any handle already owned by another live session at every resolution path (birth, geometry, off-screen re-capture) so two windows can never share one handle