Pup - the AI's own browser

Round-trip symmetry for the wiki view toggle plus the identity extension. John round-tripped the toggle and caught the asymmetry: the public direction relaunched into a throwaway jar but the logged-in direction signed in the throwaway itself instead of coming home, so authed from any toggle-created iso jar now takes the tab-preserving relaunch back to shared adom-you where logins enrich the shared store. The Chrome profile chip stops leaking internal names: anonymous jars read Adom anonymous. A second delayed raise fixes the toggle window returning in the background after a user click. The Chromium launches-when-Windows-starts promo infobar is suppressed in layers (candidate feature disables plus disable-field-trial-config, which is also the determinism WHY-CFT promises, plus promotional-tabs pref). And the new Adom Identity extension rides every adom-you launch: the toolbar icon is the user's avatar (staged from settings at launch, favicon fallback), click for the identity card explaining the shared adom-you profile; pinned via the computed unpacked id, algorithm validated against a live id

Annotate toolbar polish from John's live test, per the Adom UI design skills. The toolbar is draggable by a visible six-dot grip and clamps inside the viewport (floating-windows rules). Every control now has a real tooltip through a proper tooltip system: body-level fixed element, 600ms reveal, 0.18s fade and translate, measured after content is set, clamped to the viewport on both axes and flipping above rather than clipping (the tooltips skill contract), with carefully written copy per tool. Auto capture is on by default so the common single-circle flow needs zero extra clicks. And the view toggle is no longer out of sync: /health now carries the CHECKED wiki auth state per session, the extension popup labels the toggle from that ground truth instead of a cached belief, and hides the toggle entirely on non-wiki pages

The toolbar extension wears the real Adom favicon (John: your icon should be the adom favicon, not the hand-drawn dots), rendered from adom.inc favicon.svg at 16, 48, and 128. Also documents the CfT decision permanently: new sub-readme docs/WHY-CFT.md records the full technical case (the unsuppressable automation banner on branded Chrome that blipped over windows during cursor moves, logins and captcha assists; the Chrome 137 extension lockdown verified live including the session-scoped CDP install; version determinism with no auto-updater; no field trials or consumer nags; binary isolation from the user's own browser; and the honest trade-offs including the CfT download, the window title, and no Widevine). README and skill text updated off the stale system-browser-first policy

Pin the Adom Pup toolbar icon by default: MV3 action icons hide behind the puzzle menu unless pinned, so prepareCleanProfile now seeds extensions.pinned_extensions with the toolbar's id (stable because an unpacked extension id hashes from its staging path, which is fixed at .adom/pup-extension on every machine). Gated on the toolbarExtension setting

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