Pup - Puppeteer Bridge

The dashboard err chip stops counting its own plumbing (John saw a red 10 err chip on a healthy dashboard after the window reopen). Both sources were self-inflicted 404s on the dashboard page: the badge preview endpoint now answers a transparent pixel while a freshly opened window has no composed overlay yet, and the bridge answers Chromes automatic favicon.ico probe with a redirect to the dashboard icon instead of a 404. The chip now only fires on real page errors

The corner pencil no longer appears stuck-visible in a freshly opened window (John hit this on the three-tile demo window). Chromium fires one synthetic hover event at page load under a parked cursor; when that landed in the corner reveal zone the pencil revealed and nothing ever tucked it because tuck only runs on real mouse movement. A reveal that sees almost no movement within 3.5 seconds is now recognized as that synthetic case and auto-tucks; genuine hovers produce a stream of moves and keep it up

A dedicated pen button joins the browser toolbar (John: show the pen inline with the extension icons). Chrome permits exactly one action button per extension and no inline toolbars, so the pen is its own tiny third extension, Adom Annotate: one family tile (teal rounded tile, dark-teal pencil mark), pinned first so pen, pup, and identity read as one inline Adom toolbar. The click fires annotate via an instantly self-closing popup on the popup rail, the one extension surface proven reliable under load-extension here, resolving the window by tab URL like every other user path

The dashboard has been silently broken since 2.0.50 and this is the one-character reason: the tbFloatyPencil settings row description contained an escaped apostrophe that serializes into the dashboard page as a raw quote, killing the entire inline script at parse, which is why the page froze at connecting with zero counts while the SSE stream itself was healthy (traced tonight: curl streamed fine, a fresh EventSource from the page worked, the page console showed Unexpected identifier s, and node --check on the served inline script pointed at the exact row). Description rewritten apostrophe-free

The pencil hit area becomes a user-tunable slider (John: 8px too small, 160 too big, let me pick): new floatyHitPx setting, 6 to 120 px slider under the toolbar family in the pup dashboard Settings, default 24. It live-applies: the versioned injection guard now includes the px value, so moving the slider re-injects the floaty on every open page instantly, tear-down and rebuild, no reloads. Built so John can feel each size and report the best default

The stale-injection accumulation bug: evaluateOnNewDocument scripts from every prior bridge process persist on long-lived pages and run oldest-first, so the plain boolean guard let the oldest floaty win forever, which is why John kept seeing the big hover zone after reloads that faithfully re-ran ancient code. The floaty guard is now versioned with the bridge version: the newest module tears down any elder host and rebuilds, so a reload always lands the current behavior

The pencil reveal target shrinks to a tiny 8 pixel literal corner (John: dashboards have buttons in the upper right and a 160 pixel zone summons the pencil over them; he wants roughly 6 pixels, truly out of the way). Jamming the cursor into the exact corner reveals the pencil; the generous proximity zone still keeps it open once revealed

The pup toolbar icon's mark renders in the Adom logo's own dark teal 003d40 on the corrected 00b8b1 tile (John's call): the white glyph elements of the favicon render are flipped to the dark accent the brand mark already uses, so the icon family reads as tile plus dark mark for pup and tile plus avatar for identity

The real teal, everywhere in the icon family (John: is that our real brand color?): the pup toolbar icon was rendered from adom.inc favicon.svg which still carries #00b8b0, the documented wrong-digit teal the design system warns about, while the identity tile used the true #00b8b1, so the matching pair differed by one invisible digit. Both extension icon sets are regenerated from the favicon with the teal corrected to #00b8b1, matching the identity tile recipe exactly

One icon family across every pup surface (John: the two toolbar extension icons felt like brothers from another mother): the Adom Identity icon becomes the same teal rounded tile as the pup toolbar icon and the Windows taskbar tiles, with the user's avatar circle-cropped and inset inside the tile frame, same silhouette, same corner radius, same brand teal, composed with sharp at stage time from the profile avatar with the favicon tile as fallback

The floaty pencil tucks away (John: it will interfere with page UI): hidden by default, revealed by a corner hover zone tracked via passive mousemove so nothing ever intercepts a page click, the taskbar-tuck pattern, auto-hiding 1.2s after the mouse leaves. When revealed it carries the floating-windows-skill drag grip (six-dot glyph); dragging pins it visible wherever the user places it, viewport-clamped. Also the floaty ralph harness is fixed: pup_eval wraps expressions as return(expr), so the harness's statement-chain emits were silent syntax errors that never set the result, which was the entire phantom failure while the real path worked

Annotate captures go flicker-free: CDP captureScreenshot compositor-swaps the surface and visibly blips on a foreground hardware-accelerated window, which pup never noticed because its usual screenshots target background windows; annotate is the first feature shooting the window the user is watching. Captures now grab a single screencast frame on the recorder's rail, which has no visual artifact, DPR-scale-cropped server-side with sharp, with captureScreenshot as the logged fallback

The last blip: Chrome's native screenshot flicker, a viewport re-layout that fires when captureBeyondViewport is left on (the default) for clipped captures. John's blip-then-outline sequence proved captures process on the real path and located the flicker exactly; captureBeyondViewport false removes the re-layout so the capture is visually silent until the dashed teal outline confirms it

The capture indicator becomes a dashed teal outline of exactly the copied region (John: cooler than the white wash), holding half a second then fading. And the post-draw blip: the ten-second sweep re-arm called show on an overlay the user's mouse-up had just hidden, flashing the dismissed toolbar back across the screen; re-arms after an emit-hide are now invisible

Correct the region-only flash guard: the early return in 2.0.79 sat inside the capture-done function and would have suppressed the toast and fade for regionless captures too; the guard now skips only the flash block while the toast and drawing fade always run

The capture camera-flash covers only the shot region, never the whole window (John's rule): the full-viewport fallback for regionless captures is removed, so a full-view capture gets the toast alone and only cropped captures flash their exact rectangle

The capture watcher survives navigations: the wiki auto-login navigation destroys the execution context moments after a window opens, the waitForFunction rejects, and the watcher silently died, which was the final layer of the no-toast bug. Context-destroyed and detached rejections now re-arm the wait instead of abandoning it; only a genuinely closed page ends the watch

The final capture bug: arming the watcher cleared __pupAnnotateResult, destroying any capture the user emitted moments earlier, which is why the toast never came. Arming no longer clears, and pup_floaty_click arms the watcher immediately on the verb path so popup, ralph, and hotkey-via-worker captures have zero arm latency; the in-page pencil path arms via the 10-second sweep with the overlay already visible instantly

Quick capture works again: the 2.0.72 fast-harvest loop never dispatched in production (instrumented and proven silent), so the capture pickup returns to the 2.0.49-proven per-annotation watcher, now feeding the new fast pipeline: screenshot, immediate camera flash and preview toast, then caption bar, iTXt, clipboard and disk in the background, with quick mode re-arming per stroke. The pencil and hotkey keep their instant client-side open and additionally set the click flag so the 10-second sweep arms the watcher (restored, proven), with an arming guard against double-starts. The dead fast loop is deleted

Instrument the silent capture pipeline: log the harvested result, the screenshot entry and completion, and bound the screenshot with a 10 second timeout so a hang becomes a logged error instead of a silently eaten capture

The no-toast bug in the fast capture loop: the harvest evaluated a destructive read-and-clear under a 600ms race, so whenever the CDP round-trip lost the race the capture was consumed in the page and dropped server-side with no trace. The loop now peeks read-only under the race (a lost peek loses nothing) and only performs the destructive read after a confirmed hit, with no racing timeout

The annotate lag John felt is gone by architecture: the whole overlay module is PRECACHED into every page at load, so the pencil click and Alt+Shift+A open the toolbar instantly client-side with zero bridge round-trip, and a new 700ms fast-harvest loop replaces the 10-second identity sweep for capture pickup. The capture pipeline is reordered for perceived speed: screenshot, then immediately the client-side camera flash (a deliberate white 20 percent pulse over exactly the captured region plus margin, replacing the unexplained blip) and the toast with the preview, while the caption bar, iTXt, clipboard, and disk writes run in the background. After the shot the drawings fade out so the user is back to normal surfing. And the pencil tooltip is restyled to the canonical tooltips-skill surface: teal-tinted border, blur, structured title, body, and a monospace shortcut chip

The annotate hotkey moves onto pup's injection rail: chrome.commands never fires under this load-extension combo (verified with real focused keystrokes after the Alt rebind), completing the pattern where only the extension's action surface works while content scripts, chrome.scripting, and commands are all dead. The floaty injection now carries a page-level Alt+Shift+A listener that sets the same click flag the pencil sets, so the hotkey works whenever a pup page is focused, which is exactly when a user would press it, and it is ralphable with real OS keystrokes

The annotate hotkey moves to Alt+Shift+A: John caught Ctrl+Shift+A colliding with Chrome's built-in Search Tabs, a conflict that ships silently because Chrome just declines the extension binding. Every mention updates (manifest suggested key, floaty tooltip, popup chip, settings row, skill), and the floaty ralph gains a registration assertion reading chrome://extensions/shortcuts so an unassigned or conflicted chord fails the weekly ralph instead of reaching a user

pup_floaty_click, the test seam John asked for: a first-class verb that simulates a user click on the floaty pencil by firing the same host click handler a real mouse does, so the flag, sweep harvest, and annotate start are all exercised as the production chain. Built specifically so the floaty can be ralph-tested weekly forever without CDP input-simulation flakiness, with honest errors when the floaty is absent

Floaty pencil click handlers move from the button inside the closed shadow root to the host element in the light DOM: trusted CDP clicks at the host's coordinates were not reaching the shadow button's handler (verified by the sweep heartbeat harvesting a null flag after a real click), and host-level handlers work regardless of shadow hit-testing while remaining synthetically testable

Floaty-click harvest hoisted above the identity-support gate with a sweep heartbeat: the pencil must work even when identity stamping is unsupported, and a silent sweep is now visible in the log. Diagnosing the click flag being consumed with no action

The floaty pencil for real this time: 2.0.65 shipped no code because the edit script hit an anchor mismatch and the ship ran anyway. pup now injects the pencil per page on the owner-chip rail (shadow root, brand tokens, the tooltip teaching the feature and shortcut), the click sets an in-page flag, and the 4-second enforcer sweep harvests it and starts red-pen annotate on that exact tab, no extension dependency. Gated by tbFloatyPencil

The floaty pencil moves to pup's own injection rail: both extension content-script paths (declarative and chrome.scripting) are verifiably dead under the load-extension flag on this CfT build even though the popup works, so discoverability must not depend on the extension. pup now injects the pencil per page exactly like the owner chip (shadow root, brand tokens, the great tooltip teaching the feature and the Ctrl+Shift+A shortcut), the click sets an in-page flag, and the 4-second enforcer sweep harvests it and starts red-pen annotate on that exact tab. Gated by the same tbFloatyPencil setting

The floaty pencil injects programmatically: declarative content_scripts never fire under the load-extension path on this CfT build (verified live, zero injection anywhere while the worker and popup run fine), so the worker now injects content.js via chrome.scripting on every completed http tab, idempotent per page. Manifest gains the scripting permission and broad host permissions and drops the dead declarative block

Annotate becomes discoverable (John: people won't find it). The extension now renders a tiny monochrome pencil floaty in each page's upper-right corner; one click starts annotate in red-pen mode, with a great tooltip (600ms, clamped) teaching the feature, the Ctrl+Shift+A shortcut, and the lift-the-mouse-and-it-is-on-your-clipboard flow. The hotkey itself is re-aimed from snip to the red pen since a circle tells the AI what the user means better than a bare crop. The floaty is a content script routing through the worker to pup's loopback (pages cannot reach it themselves), and a new tbFloatyPencil sub-setting (default on) under the toolbar family lets users who find it annoying turn it off

pup_annotate joins SESSION_TARGETING_VERBS, the one-word fix the menu ralph was holding the line for: the 2.0.58 tab-URL resolution only runs for verbs in that set, and pup_annotate had been inserted into PASSIVE_VERBS instead by a sloppy heuristic edit, so every toolbar-popup and hotkey annotate resolved no session and failed with Session undefined not found. The PASSIVE_VERBS membership stays deliberately since human annotation should not light the agent-driving progress bar. Found by probing the verbatim response after the menu ralph refused to go green

Two fixes from the full-menu ralph and John's approval. One: annotate and snip injected their overlay into pup's bookkeeping of the active tab while the user was looking at a different tab, an invisible overlay and the true reason the snippet menu never worked for John; the resolved clicking tab now wins, then Chrome's actually-visible tab, then the old chain. Two: URL-based category prediction at open, wiki being John's 60 percent case: while pages still load, the intended URL classifies the window and an unchecked wiki page predicts signed-in, so the very first AUMID stamp is already the categorized id and the visible double-stamp collapses to one for the common case, with the rare wrong guess re-stamping once

The snip hotkey resolves its window the fixed way: Ctrl+Shift+A passed the tab URL through to the server-side any-tab resolution instead of the old main-page-only match that silently failed from most tabs, the same 2.0.58 bug class the popup had. Part of the full-menu ralph pass John requested

Annotate mode exits the way John expects: Esc closes the toolbar and removes the drawings from anywhere in the flow, and Auto mode is one-shot, circle the area, lift the mouse, it is captured and copied, and the toolbar closes immediately so the page is usable again (the drawing stays visible for the owning thread's next screenshot). Turning Auto off keeps the compose-then-Done flow for multi-step annotations, and the Auto tooltip teaches all of it

Toolbar popup actions actually fire from any tab (John clicked Annotate and nothing happened): the popup could only match a window by its main-page URL, so clicks from any other tab resolved no session and the error was swallowed. User-caller commands now resolve the window server-side by matching ANY tab of any session against the clicking tab's URL, the popup passes its tab URL through, and failures render in the popup instead of vanishing (every action answers back). Also the Adom Identity card becomes the real medium identity card per the identity-card skill: new pup /identity endpoint reads ab's Carbon session on the desktop and serves display name, handle, email, avatar and orgs, and the card renders name bold, handle-dot-email muted, and org pills with org avatars, showing only fields the identity API returns

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

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

Let the off-screen re-capture run even while a window is in the geometry-resolution backoff (the backoff only suppresses the geometry hammering, not the definitive re-capture that actually fixes the bare window), with a 30s per-window cooldown so it moves the window at most once per half-minute

Self-heal bare BACKGROUND pup windows that have no birth handle (opened before the 2.0.31 fix, or re-attached by recovery/drag-out) on a crowded shared profile where geometry cannot disambiguate: as a last resort the resolver briefly moves the window's own CDP target to a unique far-off-screen slot, enumerates to grab the window now at that exact coordinate (unambiguous identity by construction), then restores it on-screen at z-bottom and re-parks. Invisible because the window is already background z-bottom, and never done to a window the user is using. Gives an on-screen window the same reliable handle a birth-time window gets, so its AUMID and overlay finally paint

Fix raw-Chrome taskbar icons on pup windows, the regression from removing the title tag: killing the title tag in 2.0.24 silently removed the shared-profile fallback that BOTH the identity stamp (titleContains) and hwndBelongsToPup (v1.9.350 title-ownership proof) relied on, so any window whose hwnd did not resolve got no AUMID and no overlay and showed a raw flashing Chrome button. Fixes: (1) birth-time hwnd capture now matches the window by its UNIQUE off-screen birth position instead of by pid membership, which was empty for the shared adom-you Chrome process whose real pid is untracked; (2) hwndBelongsToPup now trusts a birth-captured handle as proof of ownership by construction, no title and no pid tracking needed, and learns the pid so sibling windows on the shared process pass instantly. Identity and overlay no longer depend on the title tag at all

Fix the jump-list tasks broken by the 2.0.28 ownership gate: a click on a pup window's own taskbar jump-list is the USER operating their own window (caller aiThread user-taskbar-menu) and is always sanctioned, so it bypasses the ownership gate, the omitted-sessionId active-window resolution, and the dead-session hard error; and pup_close with no sessionId is the global close-all by design and is never gated or resolved to the active window. The Close ALL task, the Owned-by info card, and both wiki view-switch tasks all work again

Close issue 42, the wiki sign-in race across shared-profile pup windows: auto-sign from the desktop wiki token now runs for the shared adom-you profile on ANY adom URL that is not the deliberately-anonymous public or isolated view, not only when wikiView:authed is explicitly requested, so a fresh window whose shared cookie has not landed yet no longer paints signed-out while its siblings show signed-in; it fires only on a definite 401 (never a probe timeout) so an already-signed-in window is never re-navigated, and it schedules an overlay repaint so the taskbar hover thumbnail drops any cached signed-out frame

Close issue 41, the isolation hole the nb thread caught that masqueraded as a cross-thread takeover: a verb naming a DEAD sessionId now hard-errors with session_not_found and the live-session list instead of silently falling back to another thread's active window, and per John's ai-thread model the activeSessionId implication is deleted from every session-targeting verb: omitted sessionId resolves to the CALLER THREAD's own window (the shared ai-thread-slug keying pup_open_window uses, or the single window the thread owns by explicit name), with a teaching error when the thread has none or several; the ownership gate also now covers resolved targets, not just explicitly named ones

The PowerShell deletion on ab 2.0.16 native verbs, closing the ab64 commitment: z-order, foreground reads, user-idle, window enumeration by pid and class, hwnd owner validation, parent-pid checks, send-to-back, lower-by-pid, and the taskbar attention clear are all precompiled-Rust ab calls now (roughly 20ms each versus 300ms runtime-compiled PowerShell spawns), the EnumWindows resolver and its temp-file EBUSY class are gone, the zero-caller osMinimizeToBackground and osBackgroundWatchdog are deleted, the synchronous PowerShell runner itself is deleted with zero callers remaining, internal identifiers adCommand and adPayload renamed to abCommand and abPayload, and the user-foreground doctrine got the fix John's question exposed: an ever-user-raised window stays hands-off for as long as it remains OS-foreground with no ten-minute clock, the recency window only applies once the user has left. Five scripts remain by design: the focus-raise dance x3 (works today, wishlisted for a native raise verb), base-icon extraction, and the credential import scan, all async-only

Stop fighting the user for the window: the post-open re-assert timers called the z-bottom primitive with force (needed for Chrome PDF self-activation pops) which also demoted a window the USER had just raised from the taskbar, because the session-flag guards lag the click by seconds. The primitive now checks GetLastInputInfo in the same PowerShell pass: OS-foreground plus user input within 5s means a human raised it, so it returns user-foreground instead of bottoming even under force; a PDF self-pop with idle hands still gets demoted. All re-assert and park callers stop retrying on that signal and mark the session userActive so every later demotion timer skips it for 10 minutes

One visible taskbar mutation per window open instead of three, from John watching the button live: the create-time identity stamp fired before session registration so its result was never recorded and the post-park re-brand recreated the button again with the identical appId (pre-registration stamps are now remembered and adopted at registration so the second stamp truly no-ops), and the favicon overlay no longer races onto the still-Chrome button just to be wiped by the stamp (young windows defer overlay until identity lands, stamp-once then overlay-once, with a 30s grace so an unstampable window is never left bare)

Title mangling fully dead, completing what John asked when the jump-list owner task shipped: the three legacy always-on title-suffix injectors (launch path, adopted-tab retag, post-navigate) predated the titleTag setting and kept appending the ai-thread/profile suffix with their own observers; they now stamp only the invisible window.name carrier and strip legacy tags, installing nothing and observing nothing. Ownership is conveyed solely by the jump-list Owned-by task and the pup_window_info native card

Zero synchronous PowerShell: all 7 remaining execFileSync window-management helpers (idle probe, foreground reads, force-activate, the three backgrounding paths, z-bottom, flash-clear) are now async with every call site awaited, so pup's event loop can never again stall on a powershell spawn and starve ab's health probe (the ab61 reap trigger); the sync runner carries a do-not-add-callers tombstone until ab ships native window verbs and PowerShell is deleted outright

Caption card copy polish: replace em-dashes with middots in the pup_window_info native card per the house style for user-facing copy

Ownership conveyed the way John designed it instead of title mangling: every pup window's jump-list now leads with an 'Owned by: ' task, and clicking it runs the new pup_window_info verb, which paints a native always-on-top click-through caption card just above the taskbar (ab desktop_caption, 12s auto-dismiss) showing the owning thread, container, profile, tabs, window age, last agent action, and any takeover history; the verb also returns the same info as JSON for AI callers and is read-only and never owner-gated

Hotfix for the frozen-window regression John hit within the hour: revert the titleTag default to off (the v2.0.19 flip re-armed the documented title-observer ping-pong that pegs renderers and froze hd-publish-1.0.0), harden the opt-in observer to only ever watch a real title node instead of the whole document subtree on titleless pages, and make takeover:true on one-shot verbs act without stealing ownership so a sanctioned repair reload does not lock the original thread out of its own window

Hard window ownership keyed on caller identity: every window-mutating verb naming an explicit sessionId is refused with session_owned_by_another_thread when that session belongs to a different AI thread (the old gate compared only the optional args.owner field and covered just navigate and close, so undeclared callers could take over other threads' windows, the kicad-vs-nb incident John caught); takeover:true is logged with both thread names and reassigns ownership. Ownership is now user-visible too: the ai-thread title tag defaults on so taskbar hover and Alt-Tab name the owner, and the jump-list header carries the owning thread

Negative-result backoff on window-handle resolution: a shared-profile window that cannot be disambiguated was re-probed with PowerShell EnumWindows passes on every overlay, park, and flash touch, forever; three straight misses now put that session on a 5-minute resolution cooldown (any real handle landing clears it). Ends the hot loop that burned laptop CPU and blocked the event loop so often that ab's 1500ms health marker probe timed out against a live bridge, judged it unhealthy, and reap-looped it, the other half of the 557 flap

EADDRINUSE self-heal for the 557 permanent-outage loop: when a replacement pup spawn finds its port held, it probes the holder's /health and, only if the holder identifies as a sibling pup bridge (by definition an orphan ab lost track of), kills that one pid and retries the bind with a 3-attempt cap; a non-pup holder is never touched and the process exits with a clear log. Turns the reaper-lost-my-pid outage from a manual taskkill into automatic recovery on the next verb

Close out wiki discussion 557 (startup hang after an ab cycle with orphaned Chrome windows): timeout-cap every hangable await in session recovery (CDP version probe 5s, puppeteer.connect 15s, browser.pages 10s, window.name evaluate 3s) so one wedged or orphaned Chrome window costs seconds instead of wedging the whole recovery pass, and sweep the remaining Adom Desktop and AD naming out of user-facing errors, hints, tooltips, dashboard copy, welcome and recorder pages to the canonical ab, Bridge, adom-bridge-cli names, leaving frozen code identifiers untouched

Guidance shim for the browser_* to pup_* clean break: pup re-claims the browser_ prefix and answers every old-verb call with a verb_renamed error naming the exact pup_* replacement (nothing executes, no aliasing), so broken callers self-migrate instead of following the misleading not-installed hint into a reinstall; nbrowser_* unaffected

Overlay/HWND fix: resolve a window's OS handle by its unique (ai-thread: sid) title tag whenever it returns exactly one match, regardless of the titleTag setting. Fixes shared-profile windows (e.g. a 13-tab bridge-pages) that the geometry wiggle left ambiguous, so their taskbar overlay finally paints.

Freeze the jump-list on the first commit to the real category appId (not a beat later), collapsing the settle rebuilds too. Completes option B: one taskbar commit per window, then frozen.

Freeze the jump-list too (option B): once a window's menu is committed to its frozen identity, never rebuild it on later view/active-tab changes. Completes the stamp-once-then-freeze so multi-tab windows produce ZERO taskbar rebuilds after settle.

Stamp-once-then-freeze taskbar identity (option B): after a per-session window is branded with its first real category, freeze the appId so later category changes (e.g. adding a web tab -> mixed) never recreate the taskbar button, jump-list, or overlay again. Zero multi-tab churn; tile may be slightly stale by design.

Jump-list multi-tab churn: reset the debounce timer on every request so a multi-tab open (auth flip + tab-add) commits the menu ONCE after it settles, instead of rebuilding 2-3x.

v1.9.350: fix missing taskbar favicon overlay on the shared adom-you profile. The ownership guard (hwndBelongsToPup) refused every badge because the shared Chrome process pid was absent from the tracked pid set; now a pup window's unique ai-thread title tag confirms ownership and learns the owner pid onto the browser entry so sibling windows self-heal, while Edge and non-pup buttons stay protected.

Overlay badge refinement (John): drop the teal border (it wasted space and shrank the favicon). The favicon now sits on a full-bleed dark card the tone of the Windows taskbar (#202124), inset only 2px so it stays as large as possible (44/48) with a thin visible dark margin. Transparent favicons still get a clean backdrop; no border eating pixels.

Taskbar icons (John): remove the notch from the base tile — it is a FULL solid icon again — and move the 'background' onto the OVERLAY badge where it belongs. The overlay favicon now sits on a solid dark, teal-edged rounded card (composited behind it at 48px), so transparent site favicons no longer look bad painted onto the tile; every badge reads as one clean unit. PUP_ICON_GEN i6->i7 so Windows recreates the buttons with the un-notched tile.

Fix bridge instability on heavy pages (John: a heavy page should never crash the bridge; CDP mishandling). neutralizeDebugger kept Debugger.enable on for every tab's whole life, which streams a Debugger.scriptParsed event for every script the page parses — thousands on a heavy Babylon.js bundle — flooding the bridge's single event loop and de-opting V8; under concurrent heavy-page opens the loop starved and AD couldn't reach the bridge (error sending request). Now it disables Debugger right after clearing any inherited pause and detaches the session: freeze immunity kept (a page debugger; is a no-op with no client holding the domain), flood + de-opt + per-tab session leak gone.

Steer all pup windows to the shared adom-you profile (John): a thread passing its own named profile (nameplates, np-verify, nsf-draft) fragmented the doppelganger identity — separate login jar, no shared adom-you logins, no adom-you frame color. Now, outside genuine throwaway isolation (isolated:true / webSecurity:false / wikiView:public), any custom profile name is overridden to adom-you and the override is surfaced as _profileSteered in the response. A named {profile} no longer creates a separate durable jar; use isolated:true for a private throwaway.

Pup window frame color changed from bright teal (20,184,184) to the Adom near-black ground #0d1117 (13,17,23) per John: the teal was 'a bit ugly', wanted something closer to black but on-brand that still color-codes pup/adom-you windows as distinct from the user's real Chrome profiles. Applied via --install-autogenerated-theme on the adom-you (DEFAULT_PROFILE) launch.

Fix owner-chip toggle timeout: applyOwnerChipSetting awaited page.evaluate on every tab with no bound, so one slow/wedged page (a heavy 3D-viewer tab) hung the whole sweep and browser_set_identity/ownerChip toggles timed out. Each per-page evaluate is now raced against a 1.5s timeout, and browser_set_identity fires the repaint non-blocking, so toggling the chip on/off never hangs on a busy window.

Show the user's Adom identity in the floating owner chip: since Chrome's own profile chip cannot take a custom local image (Google sign-in only), the owner chip now leads with the user's Adom avatar + name. New verb browser_set_identity {avatarB64,name,enabled,clear} stores the identity in pup-settings and repaints live windows. Owner-chip injection (attachTab) and the live-apply path both render the round avatar; falls back to the hexagon glyph when no identity is set.

Fix multi-monitor park overflow: a freshly opened pup window is launched off-screen then parked by reading screen.availWidth/Height, which reflects whichever monitor the window momentarily sits on. On a multi-monitor setup that could size the window for a LARGER monitor while it lands on the smaller primary, overflowing off the bottom-right so page content past the fold was unreachable until the slow 120s placement sweep re-parked it. placeOnScreen now settles then re-reads the destination monitor's work area and re-clamps immediately if it differs, so a window is never left bigger than the screen it is actually on.

Fix debugger-pause freeze: every pup tab now skips ALL debugger pauses (Debugger.setSkipAllPauses+resume) so a page's 'debugger;' statement or a stray breakpoint can never freeze the window and its 3D viewer (John's wiki viewer locked up behind a 'Debugger paused in another tab' banner). Fix overlay-paint spam: dedup desktop_taskbar — only paint when the composed icon+tooltip+target actually changed since the last paint, instead of re-sending identical overlays every few seconds and flooding AD's activity log. Enforcer now treats a genuinely no-favicon page's generic glyph as final after 3 upgrade attempts (retried on navigation) rather than re-composing it every 10s forever.

adom-you visual identity: name the shared profile 'Adom' and tint every adom-you window frame+toolbar Adom-teal via --install-autogenerated-theme (always-visible, no sign-in, no nag). Removed the gaia-picture avatar spoof, which rendered a generic gray chip AND a permanent 'Action required' nag on local profiles.

No more generic-globe flash: applyAppOverlay caches the last REAL favicon per session (keyed by URL) and reuses it instead of downgrading to the generic globe when a same-page repaint can't re-fetch the favicon (the post-re-stamp case). Gated on unchanged URL so a real navigation to a truly faviconless page still falls through to the generic glyph. Runtime-only, no icon-gen bump / no re-stamp.

Generic-overlay recovery cooldown 90s->10s: after an icon-gen re-stamp recreates buttons, overlays fall to the generic globe momentarily; the enforcer now re-fetches the real favicon within ~10s instead of leaving every window on the ugly generic globe for 90s+. No icon-gen bump (no re-stamp).

Remove the baked Adom-mark from the notch (John: it sabotages the clean-background purpose and bleeds through the transparent overlay favicon). The notch is now a clean EMPTY transparent cutout so the taskbar shows through behind the overlay; overlay presence is guaranteed by the 4s enforcer + event triggers, so no fallback mark is needed. Bumped icon gen i5->i6 to regenerate mark-free tiles + re-stamp.

Force ai-thread name as the session owner (John: 'sick of seeing sessionid, force ai-thread now'). browser_open_window now resolves the owner from the calling ai-thread (X-Adom-Caller-Thread header / args.caller.aiThread / args.aiThread); the sessionId is NEVER an identity fallback anymore (removed the auto- stopgap). An open with neither an ai-thread nor an explicit owner is REFUSED with caller_identity_required + the --ai-thread remedy. owner=ai-thread, and ownerSource now correctly reports caller-identity. SKILL.md updated: ai-thread is the owner, owner: arg is a legacy alias, sessionId is just the window key.

Batch-fix 8 open wiki issues. #434: shared-Chrome kill now checks live sessions+in-flight verbs on the profile (not the drift-prone refCount) so it can't kill Chrome out from under a live session. #437: wait-for-focus caption backs off (max 3 shows then silent), gated on fgCaption + honors fgCaptionMs (no more permanent nag). #435: add --disable-session-crashed-bubble/--hide-crash-restore-bubble so a crashed shared Chrome never restores dead-session tabs into the wrong window. #425: findTabForTarget resolves iframe/OOPIF-originated target=_blank popups by opener-frame URL (unique match) so they adopt as tabs. #338: sessions are never unowned (synthesize a stable auto- owner) closing the no-caller-identity ownership hole. #293: raceCrash trims the last 20s hang when an in-flight screenshot/eval races a renderer crash (detection+fast-fail already existed). #350: adCommand caller shorthand + sessionCaller forwards reason (chokepoint already forwards X-Adom-Caller-* + Delegate:pup). #280: self-install now sets PUPPETEER_SKIP_DOWNLOAD so it never hangs on the failing CfT fetch (self-heal already existed).

Fix wiki #468 (Drew: pup 100% unusable, 'never bound its port'). ROOT CAUSE: the heavy native requires (puppeteer, keytar via credential_vault, sharp, and chrome.js which itself requires puppeteer) ran synchronously at module load, blocking the event loop ~8s before the HTTP port could bind — long after AD's recover_not_listening reaps a not-yet-bound bridge (~2-3.6s). FIX: defer all four out of the sync module-load path into ensureHeavyInit(), which runs in the listen callback AFTER the port binds (recover_not_listening is a TCP listen check, so the post-bind load is safe) plus lazily on the first non-/health request. /health needs no heavy module (chrome.readiness guarded). Port now binds in <1s.

Notch margin symmetry (John: 2px cutout on the left of the overlay but only 1px below - unprofessional). The inner (bottom-left) corner radius curved the notch inward where the favicon's bottom-left sits, eating the bottom margin while the straight left edge kept its full margin. Dropped the inner-corner radius to near-sharp (rx 11% -> 2%) so both the left and bottom cutouts are uniform straight edges = even margin around the overlay. Bumped PUP_ICON_GEN i4->i5 so live buttons re-stamp with the new geometry.

Fix: the 'Switch to logged-in view' jump-list task did nothing. browser_wiki_set_view short-circuited with unchanged:true (only bringToFront) whenever pup BELIEVED the window was already in the requested view — but the task promises a harmless reload and pup's view belief is unreliable (default-authed may not have actually signed in; cookies expire). Now a real USER click (caller aiThread user-taskbar-menu) ALWAYS re-asserts the view via the mint/navigate path (a genuine reload that guarantees signed-in), instead of skipping. Programmatic same-view calls still short-circuit.

No redundant Adom mark on the overlay when AUMID is ON (John: the teal category tile is already the 'Adom controlled' indicator). The favicon overlay now carries the Adom mark ONLY when aumidIcons is off (plain Chrome base needs the branding); when AUMID is on the overlay is the clean site favicon alone. Cache key now includes AUMID state so the badge recomposes on toggle.

Fix: notch never appeared on the LIVE taskbar button. The icon FILES changed (added the notch) but PUP_ICON_GEN was not bumped, so the AUMID appId stayed the same and Windows kept the un-notched button it baked at creation (it never re-reads an icon for an unchanged appId; only a new appId forces a fresh button). Bumped i3->i4 so every window re-stamps with the notched tile. Also: notchedIconPath now serves the cached notched icon as soon as it exists on disk (not only after this run's build), so a respawn re-stamps notched immediately instead of flashing the un-notched tile.

Overlay GUARANTEE hardening + graceful notch (John: bare window = broken-looking empty notch; overlays must always be present). ROOT CAUSE of missing overlays: applyAppOverlay REFUSES to paint when it can't confirm the window's hwnd (the Edge-protection guard), and your AD rebuilds constantly respawn+re-adopt windows, forcing hwnd re-resolution and transient bareness. Fixes: (1) baked a small Adom-mark fallback into the notch so a bare window shows a tidy branded corner, not a hole; (2) enforcer sweeps every 4s (was 10s) with a 4s bare cooldown (was 20s) so a bare window heals in seconds; (3) enforcer no longer SKIPS the overlay paint when a base-tile re-stamp is pending (they're independent now).

Notch shape fix (John: overlay favicons are SQUARE, not circles). The notch was a rounded-rect with a 30%-of-side radius, which rounds all four corners into a circular blob. Overlays are square (favicon fills 48x48 + Adom mark corner), so the notch is now a SQUARE: the mask rect extends past the top and right edges so those corners fall off-canvas and only the inner corner is rounded, giving a clean square opening flush to the tile edges. Cache path bumped (-sq) to regenerate.

Notched category tiles (John's idea): punch a transparent rounded notch into the UPPER-RIGHT of each pup category .ico so the favicon overlay AD paints there sits on the clean taskbar background instead of the busy teal art. Generated at bridge runtime (sharp, desktop-only) into a cache dir via a minimal PNG-frame ICO encoder (format validated); baked into the static tile so there's NO per-window/per-favicon churn, only a one-time re-stamp. pupIconPath serves the notched copy once built. Notch geometry (50% upper-right) tuned live.

Taskbar favicon overlay fix (John: icons still wrong). ROOT CAUSE: the badge compositor decided ICO-vs-image by the favicon URL ending in .ico, but analyzeIconBytes had already re-encoded it to PNG, so icoLargestPng ran on PNG bytes, returned null, and dropped the favicon -> bare Adom mark (hit Google Docs and any .ico-suffixed favicon). Now sniffs the real magic bytes. SECOND bug: the generic-glyph fallback set src but never populated iconPng (which is the only thing the composite draws), so undecodable favicons also went mark-only; now it renders the glyph into iconPng and marks src.href generic so the LED shows amber, not a lying green.

Credential import goes LIVE against AD 1.9.220's desktop_decrypt_browser_credentials. Vault (credential_vault.js) now identity-tagged: keep BOTH on a (host,username) conflict from different source accounts, newest-wins within an identity, getCredentialForUrl picks by preferred identity then most-recently-used; passwords in keytar under per-entry composite accounts, index never holds a password (offline-tested). Dashboard Import button calls the decrypt helper LOCALLY (bridge->AD direct API, never relay), handles consent_declined/elevation_declined/relay_forbidden/helper_missing, merges rows, drops plaintext, returns counts only.

Overlay drift fix: the favicon taskbar badge now recomputes on the NAVIGATION EVENT (framenavigated), not just on explicit mutating verbs. Any nav pup didn't initiate — JS redirect, meta refresh, form submit, SPA route change, OAuth bounce, in-tab link click, browser_login submit — previously left a STALE badge; now every navigation from any source re-triggers the recalc (debounced, honors overlayBadges pref, active/visible tab).

Dashboard Settings: 'Import logins from Chrome/Edge' picker (adom-you seed). Reads browser_import_scan, lists every discovered profile with source-account identity tags + saved-login count + ABE lock, checkbox each (default all). Import button reports honest-pending until the AD-core elevated decrypt helper (adom/adom-desktop #51) lands.

browser_import_scan: read-only discovery verb for the comprehensive credential import — enumerates every Chromium profile (Chrome/Edge/Brave) with source-account identity tag, saved-password count, and ABE status; foundation for the Settings import picker. Actual decryption is AD-core (adom/adom-desktop #51).

Make GROUPED mode actually group by category (John: 'i like that you just group to each category icon'): with icon-style category, windows of the same category share one AUMID (Adom.Pup.) so you get up to 5 category buttons each wearing its category icon; standard style still collapses to one Adom Pup button. Previously grouped lumped every window under one button regardless. Updated the setting copy

Fix jump lists not clearing when toggled OFF (John: 'i turned off jump lists but still see them'): turning jumpLists off now commits an EMPTY task list to every window (removing the menu tasks); toggling jumpLists on or the sub-prefs forces a re-commit so changes show live. Wired jumpLists/jlViewTasks/jlCloseAll to refreshAllJumplists()

Correct the jump-list setting copy: remove the stale 'Windows 11 bug keeps tasks off the menu' claim (tasks appear now); note it requires AUMID on and the honest first-click-blip / right-click-again quirk

Replace the fake jump-list settings screenshots with REAL ones: captured the actual Windows jump-list flyout (double right-click for the blip) showing the live tasks, and cropped it into jumplist.png (full menu), jlviewtasks.png (the two Switch-to-view rows), jlcloseall.png (the Close ALL task). The AUMID/grouping/icon-style screenshots are untouched

Reduce the jump-list first-right-click blip: stop forcing a redundant CommitList ~1.6s after every stamp (jump lists live on the AUMID and were already committed at stamp time; the re-commit only gave the shell another chance to dismiss a just-opened flyout). Dedup-respecting now. Residual ~200-300ms blip is a shell/AD race (documented in dev-skills/pup-jumplist)

Dashboard shows wiki login state per wiki window (John: 'why doesn't the dashboard say if i'm logged in to the wiki'): each pup window on an Adom wiki URL now gets a 'wiki: signed in' (green) or 'wiki: public' (warn) badge, from the _wikiAuthed state pup already tracks

Wiki pages open LOGGED IN by default (John's request): for an Adom wiki URL with no wikiView, default to authed (auto-signs from the desktop token, no prompt); pass noAutoLogin:true (or wikiView:public) for the anonymous/public view. Hint tells the AI it was logged in by default and how to opt out

Fix jump lists never committing: the registration guard required the appId in _registeredPupAumids, which is only filled by desktop_register_app_identity (a silent no-op on this AD build), so updateWikiJumplist returned before every commit and then dedup-skipped forever. Register best-effort, never block the commit; the window stamp already binds the AUMID and the commit works with hwnd

diag: log jump-list gate conditions to find why updateWikiJumplist returns before committing

Fix jump lists not working: updateWikiJumplist resolved its hwnd by title (desktop_find_window titleContains) which is null when the title tag is off, so payload.hwnd was never set and the jump list never committed to the window. Use the reliable birth-time/persisted handle instead. The 'known Windows 11 bug' was this title lookup

Stop the dashboard refresh blip: badge image URL was cache-busted with SNAP.ts (new every SSE tick) and served no-store, so every icon refetched a couple times a second. Version the badge URL by its actual paint time and make badge + tab-favicon endpoints cacheable, so icons only reload when they truly change

Recovered windows restore their persisted OS handle on the rescan adoption path too (not just recoverSessions), so a multi-window-profile window that lost its handle to a respawn goes green from the saved handle instead of red now that the wiggle is gone

PERMANENT fix for title-based window lookup (John: stop duct-taping it): add windowTarget() helper that returns the validated HWND, and route every AD window OPERATION (park z-bottom, taskbar overlay/progress/badge, thumbnail, screenshot, focus) through it so hwnd is primary everywhere; titleContains survives only as a cold fallback. Also delete the destructive width-wiggle

Delete the destructive width-wiggle: it shrank windows to a marker width to identify them and left one stuck narrow when the restore failed (deformed John's window). Handle resolution now uses only read-only signals (birth-time capture, persisted handle, sole-window-of-profile); a window none resolve is left bare rather than resized

Fix AUMID stamp failing on windows without a title tag: stamp by resolved HWND (same handle the overlay paint + flash use) instead of only titleContains, which could not find the dashboard window (no ai-thread tag) so it never stamped when AUMID was turned on

Fix dashboard-vs-taskbar mismatch (revert the wrong 1.9.298 assumption): with aumidIcons off, live pup windows wear the Chrome-for-Testing exe icon + pup overlay, NOT a teal tile (proven by flashing the live windows). The teal tiles on the taskbar are GHOST buttons from dead AUMID-stamped windows. Dashboard now draws the real Chrome-for-Testing base icon for un-stamped windows, teal only when actually stamped, so it matches the glass

Fix sleep/wake window loss: the 8s reaper was racing sleep-recovery and killing recovered windows. On wake, rescan reattaches a page then prunes it as the dead pre-sleep tab, leaving the session at 0 tabs with _lostBrowser already cleared, so the reaper deleted it before the healer relaunched. Now: re-mark any post-prune empty session as lost + refresh its heal window; the reaper never reaps a session the healer is still trying to recover (until it explicitly gives up)

Birth-time handle resolution: each new window is born at a unique off-screen position and its OS handle captured while off-screen and small (before park maximizes it), the only unambiguous moment for a same-profile window; the resolver trusts this birth handle ahead of all geometry heuristics. Finally resolves multi-window profiles the width-wiggle never could

Reliable wiggle-free handle resolution: a profile process with exactly one window resolves to that window directly (works on maximized windows, which the width-wiggle never could); multi-window profiles still leave bare rather than guess until birth-time resolution lands

Make window-handle resolution conservative (correct-or-bare, never wrong): raise the wiggle serialization timeout above the enumeration time so concurrent wiggles cannot collapse multiple windows onto one handle; use a distinctive narrow marker width real windows never sit at; verify the width actually applied; require EXACTLY ONE match or leave the window bare rather than paint a guessed/shared handle

Kill overlay drift at the source: one centralized debounced overlay re-sync now fires for every mutating verb (navigate/reload/back/forward/switch_tab/click/type/eval) plus close_tab/close_window, clearing the favicon cache and repainting via the ungated applyAppOverlay (refreshWindowChrome was a no-op under minimalTouch), without touching the cached handle so no routine verb triggers the wiggle

Fix window-handle desync + stuck regenerate: time-box the width-wiggle lock so a hung holder cannot deadlock the whole chain (was leaving every window hwnd=None); persist the resolved OS handle to the session file and restore+validate it on respawn so windows stop re-wiggling after every ship; regenerate button preempts a wedged busy flag, per-window timeouts, and always clears the flag

Regenerate-overlays button now runs the sweep in the background and answers instantly (dashboard icons update live via SSE); header shows regenerating/last-sweep status; per-window drift report logged

Dashboard taskbar strip now shows the teal pup tile for every pup window (matching the real taskbar) instead of Chrome's exe logo for un-stamped windows; add a Regenerate All Overlay Icons header button that re-runs the from-scratch overlay algorithm on every window and reports which windows drifted

Fix missing taskbar overlay: hwndBelongsToPup now requires a real top-level visible Chrome_WidgetWin_1 frame, not just any window owned by the profile process. A stale same-process utility handle (18) was passing the pid-only check forever, so overlays painted onto a non-taskbar window and never appeared

Fix duplicate tab on burst opens: the popup-tracker was double-attaching pup's own in-window window.open blanks (which addTabToSession already adopts); it now skips any tab tagged with the pupclaim_ window.name marker

Fix in-window tab adoption: identify the window.open tab by a unique per-call window.name marker instead of set-difference, which under a burst of adds could adopt the wrong new target and duplicate tabs

Fix orphaned about:blank tabs: adopt the window.open tab by target set-difference instead of a racy opener match, which used to leave a stray blank tab beside the real one whenever the anchor page was mid-navigation

Serialize the width-wiggle resolution so it is actually unique (1.9.290 collapsed everything onto one hwnd because the enforcer fires resolves CONCURRENTLY - their width changes and window enumerations overlapped, so every session matched whichever window was momentarily at a marker width). A global lock now guarantees exactly one wiggle (set unique width -> enumerate -> restore) runs at a time, with the lock released on every path including the error path (hoisted release handle so the outer catch frees it - no deadlock).

Robust observer-proof window resolution via UNIQUE-WIDTH WIGGLE (finally kills the dup-hwnd bug for all windows, clean titles kept). With titleTag off, the transient-title approach was fought by each page's own title observer (un-disconnectable on pre-1.9.288 pages), so same-profile windows parked at the identical rect collapsed onto one hwnd. New approach: when the tag is off, pup gives the window being resolved a UNIQUE width via CDP Browser.setWindowBounds (pup controls this directly, no page script can fight it), matches the one OS window at that exact width, then restores - deterministic and unambiguous even for many same-profile windows. Guarded to never resize a foreground window the user is looking at (falls back to plain bounds there); the window is off-screen during most resolves so the width change is invisible. Title-tag-ON path still uses the exact persistent-tag find. Together with the reconciler's duplicate-hwnd self-heal (clears any shared cache to force re-resolve), every window binds to its own unique handle.

Duplicate-hwnd self-heal: the reconciler now detects any OS handle claimed by more than one live session and clears the cached hwnd on all of them, forcing each to re-resolve to its own unique window (reliable now that 1.9.288 stopped the tag-strip observer from fighting the transient resolution). This corrects stale wrong-hwnd caches that per-profile validation cannot catch (two windows of the same Chrome process), so John's wildlife-compare/haircut-review shared-handle case self-heals within a sweep instead of persisting. Verified: two fresh same-profile windows resolve to distinct handles.

Issue #22 (AdityaAngajala) — session ownership is no longer opt-in. His Finding 1: owner was an optional self-asserted string, so the one real session on his machine, driven actively for 43 minutes by another agent, reported owner:null and had no protection at all; the guard that protects a busy window was opt-in and the real session had opted out by omission. The issue named the blocker as 'relayed commands carry no caller identity, so owner can only ever be a self-asserted string' — that blocker is gone: AD 1.9.180+ sends X-Adom-Caller-* and pup already binds _ownerThread from it. Now the advisory owner field is backed by that AUTHENTICATED identity whenever the caller did not declare one, both at session creation and on any later verb, so a session is owned from birth instead of when someone remembers to ask. Adds ownerSource ('declared' vs 'caller-identity') to browser_status and browser_list_windows so an agent can tell a self-asserted owner from an authenticated one. The cold-start double-claim race in his Finding 2 is NOT addressed here and the issue stays open for it.

Diagnostic: dump the exact composed badge PNG to disk plus the target (hwnd vs titleContains) before handing it to AD, so the composite can be INSPECTED rather than inferred from a screenshot. Four successive theories about the unpainted first taskbar button were wrong (SVG rasterisation, code-not-running, duplicate sessions, the composite cache); this measurement splits the problem cleanly — if the PNG contains the generic icon then the compositor is exonerated and the fault is delivery to that specific window.

Revert the invented badge placeholder (John: the teal tile was 'hideous', and a full-size Adom logo — 'no it shouldn't'). The badge design is the TAB'S OWN FAVICON with the mini Adom mark inset, full stop. When there is no usable favicon pup now paints NO overlay and logs why, instead of substituting a tile or a blown-up logo. Recorded in the code where it matters: the window that keeps hitting this branch DOES have tabs with real favicons (registration.hanover.com) — it reports 'no favicon anywhere in this window' only because duplicate sessions have split one window's tabs across several session objects, so the session painting that taskbar button can only see the PDF tabs. Fixing identity resolution (HWND instead of the title tag Chrome's PDF viewer cannot carry) removes the cause; inventing placeholder art was papering over it.

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.

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.

Audit columns for the standard test table (John: 'put a column for how many times you triggered an orange flash, and another for if you triggered a progress bar in windows taskbar' + 'and how long that prog bar ran'). Every browser_list_windows entry now carries flashCount (both flash paths counted), progressBarCount (times the agent-activity taskbar progress bar engaged), and progressBarMs (total time it ran, live-inclusive if currently running) — so the post-open table proves the window's full attention footprint (flash, progress, overlay, geometry) from one call, no log scraping.

Background windows are BORN off-screen again (John: 'you keep opening pup windows on top of the one i'm working in ... it just happened for all those windows you opened'). Regression chain, owned: 1.9.135 removed the process-wide --window-position=-32000 launch default because it poisoned every window's RESTORE rect (the taskbar-click-shows-nothing bug) — but that default was also what made the birth moment invisible, so new windows started appearing at a visible position ON TOP of whatever the user had up (including the pup window they were working in) for the beat before the park pushed them to bottom-z. Fix: Target.createTarget now passes explicit per-window left/top -32000 for the one creation moment; the per-window unconditional park (1.9.138) immediately rewrites the normal rect on-screen with the inset frame at bottom z-order, so the restore-rect poisoning cannot recur (the park always lands, re-asserts at 2.5s, logs both attempts, and healOffscreenWindow sweeps any stragglers). Birth invisible, life on-screen at the bottom, reveal only on the user's click — the full contract.

10px inset on every side of the work-area placement (John: 'reduce it by 10px on all sides so i can tell you literally did this purposely') — position = work area X+10,Y+10, size = work area minus 20 in each dimension. A pup window now sits visibly, deliberately framed inside the work area: taskbar never covered, a uniform 10px margin proving the geometry is computed, not accidental.

Park and window-sizing now use the primary monitor's WORK AREA instead of raw resolution (John: 'use the work area'). All four GetSystemMetrics(0)/(1) sites swapped for Screen.PrimaryScreen.WorkingArea, with position taken from the work area's X/Y — so a taskbar on ANY edge (bottom, left, top) is respected and no strip of a pup window ever hides behind it. Same behavior as a genuinely maximized window.

Drop --window-position=-32000 and --window-size from background launches (John: 'if --no-startup-window then stop fighting it'). With no-startup-window Chrome starts with NO window, so the off-screen position arg protected nothing on the main path — while silently poisoning every window Chrome itself creates (popups, target=_blank, restores) with an off-screen DEFAULT position, which is the likely mechanism behind windows found stranded at -32768 even after being foregrounded. Geometry now has exactly one owner: the park (on-screen, bottom z, full size, no-activate).

Emergency follow-up to 1.9.133, which shipped with a JS SYNTAX ERROR (a python-style # comment inside the PS-lines array — my parse check ran AFTER the ship gate instead of before, the documented patch/ship desync repeated). Also fixes the size John hit immediately: the CDP park kept 1280x800, so on-screen-parked windows appeared small; now near-fullscreen fallback at the CDP site and the SetWindowPos park corrects to the true screen work area right after. Park contract: on-screen, bottom z-order, no-activate, full size.

Background windows now park ON-SCREEN at the BOTTOM of the z-order instead of at -32000,-32000 (John's design, implemented immediately after the trap bit him twice in one hour: agenda-monday, then the gmail window whose taskbar click showed nothing). Both park sites changed — the CDP Browser.setWindowBounds park and the SetWindowPos park, which already used HWND_BOTTOM + SWP_NOACTIVATE so only the coordinates were wrong. Background still means: no focus steal, covers nothing the user works on (it is BEHIND everything). But the window is now always at real screen coordinates, so a user's plain taskbar click is pure native Windows foregrounding of a correctly-placed window — no pup code in that path, nothing to catch, the failure is structurally impossible. Known accepted tradeoff: bottom-z windows show in desktop peek. The -32000 launch-instant args remain as belt-and-suspenders for the pre-park moment only.

Clean up zombie sessions automatically and REPORT the cleanup to the next caller (John's design). Two parts. (1) Zombie detection was gated on _lostBrowser, a flag only set when a DISCONNECT EVENT fires — a Chrome killed outright (the bridge-restart tree kill) never emits one, so those sessions sat with 0 tabs, no flag, and were never dropped. That is exactly the four zombies John found cluttering browser_list_windows for every thread. Zero tabs plus a dead CDP port is now sufficient, with a _launchInFlight guard so a session mid-launch is never mistaken for one. (2) A cleanup REPORT QUEUE: each janitorial action (zombie session dropped, orphaned browser processes reaped) is recorded and attached to the NEXT verb response as _cleanupReport, then dropped — report-once. Per John, the receiving thread is usually NOT the one whose window was cleaned; that is accepted, it can ignore the note, and the information still reaches the user eventually instead of never. Verb-scoped so AD's health poll cannot swallow it, capped at 12 entries, and added to the output-merge list because anything left on the outer envelope is silently dropped on a SUCCESSFUL call.

Lint a malformed wiki URL and name the real cause, instead of letting the caller invent one. The HD build thread opened https://wiki.adom.inc/adom-wiki-skillpack, got 'Page not found', and reported to John that 'org pages are invisible to logged-out readers'. That conclusion was WRONG and cost trust: the window was signed in as John the entire time (pup's auto-login had worked), the page exists and is public, and the URL was simply missing its OWNER segment — wiki.adom.inc pages are owner-qualified as // (and ///blob/ for a file). pup already knew the URL 404'd and knew the host, so it could have named the cause. It now does: on a render failure, a new wikiUrlLint() detects a wiki URL with no owner segment (including the /blob/ form), suggests the corrected URL, tells the caller to confirm the real owner with 'adom-wiki page get ' rather than trust the guess, and explicitly says NOT to conclude anything about permissions or login until the URL is right and re-checked. Known non-page routes (apps, skills, components, discover, login, api, ...) are excluded. Unit-tested 6/6 against the thread's three real URLs plus valid controls.

Make a bridge upgrade REPAIR the jump-list task commands on windows that already exist. This is why John's 'Switch to public view' still failed after 1.9.115 fixed the command format: a jump-list task embeds a full CLI command line, and stampPupIdentity only re-commits the list when the appId CHANGES, so any window whose category was unchanged across the upgrade kept its OLD identity-less command and the click was refused silently — while the very same verb worked perfectly when I called it from the CLI, which is exactly why my verification passed and his click did not. On every bridge start pup now clears the jump-list dedupe key for all recovered sessions before the startup brand sweep, so the re-attach is real instead of a no-op and every surviving window gets task commands matching the running version. One AD call per live window, once per boot.

Correct the record on the jump-list blip. The v1.9.112 post-stamp jump-list re-commit did NOT fix it: three fresh windows each got exactly 1 AUMID registration plus 1 re-commit and all still showed the flyout for ~200-300ms before it vanished. The re-commit stays (attaching the destination list to the live button is correct hygiene) but its comment no longer claims to be the cure. The blip is UNRESOLVED and now tracked on adom/adom-desktop#40 with all four eliminated hypotheses and the measurements behind each, plus a decisive diagnostic AD can run on its own window (AD flips its own AUMID for the mode signal, so if AD's own flyout blips the behaviour is inherent to runtime AUMID retagging and reproduces without a bridge).

Jump-list first-right-click dismissal: re-commit the destination list once the taskbar button actually exists. Reached by ELIMINATION, with measurements: nothing fires while windows are idle (0 log lines across 40s), windows that registered exactly ONE AUMID blip too (so it is not category churn), and a registry-only vs Start-Menu-shortcut A/B showed no difference (so it is not the missing shortcut). What every FRESH window shares is that the identity stamp RECREATES the taskbar button (Win11 bakes a button's identity at creation) while the jump list was committed BEFORE the stamp — deliberately, so the header art bakes. So the button is born pointing at a destination list committed against a button that did not yet exist, and the first right-click is the shell reconciling that, which is exactly why the second click works. pup now re-commits the list ~1.6s after a successful stamp, guarded so a superseded stamp does not clobber a newer one. Still a hypothesis until John re-tests a freshly opened window.

A detected render failure must LEAD the response, not hide behind cosmetics (John, reading a real launcher-mockup response). The 1.9.106 verdict was correct and the calling AI did act on it ('Dev server crashed. Let me restart it'), but _hint opened with a FAVICON nag, then a power lecture, then a browser inventory, so the single most important fact — that the page was a 404 — sat screens down past 32 permission strings and an availableBrowsers list. Rich hints are the right instinct; burying the critical one behind cosmetic ones is not. When renderCheck.ok is false, _hint now opens with the failure, the signals, the HTTP status, what the page actually says, an explicit do-NOT-report-success, and the screenshot command, then appends the cosmetic hints marked as secondary.

Stop reporting ok:true for a page that plainly did not render (John's catch). The launcher-mockup thread opened a .adom.cloud app that served '404 page not found'; pup answered ok:true, said nothing, and the AI reported success. Telling the caller to screenshot was too weak, so pup now LOOKS: a new probeRender() checks the loaded document (main-frame HTTP status captured from goto, plus 404 / 'Cannot GET' / server-error / visible-stack-trace text, effectively-blank body, zero stylesheets loaded, broken images) and the open response carries a machine-readable renderCheck{ok,httpStatus,signals,excerpt}. When it detects a failure, _verifyRender no longer offers advice — it LEADS with 'THIS PAGE DID NOT RENDER CORRECTLY, pup checked it, do NOT report success', names the signals, quotes the page, and says do not tell the user it works while this warning is present. Fixed my own silent bug along the way: the HTTP status was being assigned to a 'session' variable that does not exist in launchSession, so it was throwing into a catch and capturing nothing; it is now stashed on the page object.

Put the owning AI thread ABOVE the taskbar hover-preview, where John was actually looking. The header Windows draws above the preview IS the window title (Chrome derives it from document.title), so the tooltip work in 1.9.101 was real but invisible there. The thread tag now LEADS the title — 'adom-tsci · Example Domain (session: x)' — so it survives the ~25-30 char truncation in that header and answers 'which of my 20 threads made this window' at a glance. Implemented WITHOUT adding a third title mutator: the code already documents that two observers writing the same region ping-pong forever, peg the renderer and flood CDP (which hung browser_open_tab on Edge), so the wiki glyph and the new thread tag are now ONE composed prefix slot under ONE observer, applied in a fixed order, and stripping only ever removes decorations we know we wrote (never a page title that merely contains a middot). Tag capped at 18 chars; re-asserted after navigation.

Fix the owning-thread stamp missing on the window that matters most. The v1.9.101 stamp ran at dispatch and could only find a session that ALREADY existed — but on browser_open_window the session is created inside the handler, so the window a thread had just created got no identity and its hover tooltip read '(no AI-thread identity yet)'. The owner is now stamped as soon as the session is real, so a freshly opened pup window immediately shows 'adom-tsci · galliaApril' on its taskbar preview.

Surface the owning AI thread on the taskbar hover preview (John's ask). pup was DISCARDING the caller identity AD stamps on every relayed bridge request (X-Adom-Caller-Thread / X-Adom-Caller-Container); it now captures both, stamps the FIRST thread to touch a session as that window's owner, tracks lastDrivenBy so a handoff stays visible, and LEADS the thumbnail tooltip with 'thread · container'. With ~20 threads running at once a pup window is effectively an AI thread, so this turns an anonymous Chrome preview into 'that's my adom-tsci thread'. The tooltip is the only UNCAPPED text surface on the preview (the header above the thumbnail is the window title and truncates ~25-30 chars). Also fixes a line that has been wrong since native-first: the tooltip claimed 'Chrome for Testing' unconditionally and now reports the browser actually driving the window, plus the sessionId.

Make pup insist the AI LOOKS at what it just rendered (John's ask). browser_open_window / browser_open_tab / browser_navigate / browser_reload now return a _verifyRender instruction: the exact browser_screenshot command, a concrete checklist of what to look for (blank/white page, unstyled flash of plain HTML meaning CSS never loaded, a stack trace or framework error overlay, missing images, broken or overlapping layout, content cut off, a dev-server 'Cannot GET /', or the wrong build), and the ralph-test loop — fix the source, reload, screenshot AGAIN until the render is genuinely correct. The framing that matters: ok:true means the NAVIGATION worked and says NOTHING about whether the page painted. Wording escalates when the URL looks like the caller's own work in progress (localhost, LAN IP, file://, .adom.cloud, .local; classifier unit-tested 7/7), which is the lazy-AI case John described. Success responses only; never overwrites a handler that already spoke about verification. Also teaches ship.sh AD 1.9.180's caller-identity contract (ADOM_AI_THREAD + per-call reason on gated verbs).

Make pup insist the AI LOOKS at what it just rendered (John's ask). The common failure: an AI generates or edits an app, opens it in pup, sees ok:true, and reports success to the user without ever screenshotting the result — but ok:true only means the NAVIGATION worked, it says nothing about whether the page painted, whether CSS loaded, or whether a stack trace is filling the viewport. browser_open_window / browser_open_tab / browser_navigate / browser_reload now return a _verifyRender instruction with the exact browser_screenshot command, a concrete checklist of what to look for (blank page, unstyled HTML, error overlay, missing images, broken layout, Cannot GET, wrong build), and the ralph-test loop: fix, reload, screenshot AGAIN until the render is genuinely correct. Wording escalates when the URL looks like the caller's own work in progress (localhost, a LAN IP, file://, .adom.cloud, .local — classifier unit-tested 7/7), which is exactly the case John described. Success responses only; never overwrites a handler that already spoke about verification.

CRITICAL delivery fix found while testing the bug-report invitation: anything sendJSON attached to the OUTER response envelope was DROPPED on every SUCCESSFUL call. The conventional success shape is {success:true, output:''} and AD/the CLI unwrap output into the top level, discarding the rest of the envelope — measured: a browser_navigate success returned {durationMs, ok, sessionId, status, tabId, url} with NO _hint, _next, related, pitfalls or _reportIssues, even though sendJSON had set them. Failures survived only because their handlers write those fields on the outer object. So the canonical VERB_META hints — the SDK's whole 'every response teaches the caller' principle — were reaching callers only on failure, exactly backwards. sendJSON now merges the advisory fields INSIDE output when output is a JSON object string, never overwriting what a handler already set there.

Third attempt at the once-per-process bug-report invitation, this time with the actual cause. Machine traffic was eating it at TWO layers, each failing silently: AD's /health and /status probes flow through the same sendJSON chokepoint (fixed in 1.9.96 by requiring a verb), and AD ALSO calls pup's declared statusVerb (browser_readiness) through /command on spawn, so it arrived as a real verb and consumed the invite anyway. The orientation invite now fires on the first SUBSTANTIVE verb (an open/drive — the moment John described, 'when typical verbs are being invoked like open browser'), while read-only probes and enumerations neither consume nor carry it. A FAILURE still always carries the invitation regardless of verb, because that is when the evidence exists.

Fix the once-per-process bug-report invitation never reaching an AI: AD probes /health (and /status for the bridge chip) every ~15s and those replies flow through the same sendJSON chokepoint, so the first health probe after a spawn consumed the invitation and the first real verb carried nothing (measured after a restart). The invite is now VERB-SCOPED — it only counts responses that belong to an actual AI-facing command (res._adomCommand), so a machine-facing probe can neither consume the orientation invite nor advance the periodic counter.

Ask the AI to report bugs, in the response it actually reads (John's ask). pup now attaches a _reportIssues invitation naming its own wiki repo (adom/adom-desktop-puppeteer-bridge) with the exact adom-wiki issue list/create commands and what evidence to include. Deliberately throttled so it is signal, not noise: ALWAYS on a failure (the moment a bug is most likely and the evidence is still in hand), ONCE per bridge process on the first verb (orientation before anything breaks), and every 40th call after that. It also points AD-core problems at adom/adom-desktop instead, so reports land on the repo that owns the code. Injected at the sendJSON chokepoint so all 155 response sites are covered, and never overrides a hint a handler already set. Opt out with browser_configure {reportIssues:'off'}.

Fix issue #22 Finding 4 (AdityaAngajala): a stalled background Chrome-for-Testing prewarm blocked EVERY browser_open_window on a machine that had system Chrome AND Edge, while browser_readiness simultaneously reported browserSource:'system' with a valid chrome.exe. Two defects, both mine from the native-first change: (1) getOrLaunchBrowser still kicked the retired v1.8.71 'converge this box to CfT' background prewarm on a native launch — I removed that same kick from chrome.warmup() in v1.9.90 and missed this one, so a native launch still started a ~150 MB download nobody asked for. Removed; native-first fetches CfT only as the genuine last resort. (2) chrome.readiness() computed ready = found && !installing, conflating 'a background download is in flight' with 'nothing is drivable' — so an in-flight or STALLED last-resort download made the whole subsystem not-ready and the open gate refused on !rd.ready. ready now means only 'a drivable browser exists'; installing stays a separate informational field and never gates drivability.

Fix issue #16's residual: browser_list_windows reporting 0 windows while the windows are open and drivable by sessionId. Root cause: getActiveSession() was a RESOLVER that silently PURGED the session map — it deleted every session whose isSessionAlive() was false, with no _lostBrowser guard (unlike resolveSession, which deliberately keeps disconnected entries for rescan). And isSessionAlive() consulted ONLY the browsers map, so the instant handleBrowserDisconnect deleted that entry on a CDP blip, every session on the profile read as dead. Net effect: one call after a transient disconnect wiped the ENTIRE session map, destroying the exact entries the disconnect handler had just preserved for recovery. Fixes: (1) getActiveSession is now non-destructive — it marks _lostBrowser instead of deleting; removal belongs to the close/rescan paths. (2) isSessionAlive falls back to asking the session's own page whether its browser is still connected, so a drivable session can never report as not-alive. (3) Hardened the v1.9.89 orphan reap with the same lesson: it now REFUSES to sweep when the session map is empty while session files still exist on disk (recovery pending), so it can never mistake the user's live windows for orphans.

Reconcile the repo/release divergence (issue #19): merge Kyle's ten unreleased macOS fixes onto the true 1.9.90 tree. Takes his win32 self-guards on the three powershell.exe spawn primitives (removes a latent mac trap), the desktop_taskbar mac-gating rationale, platform-accurate describe hints for browser_wiki_set_view / browser_alert_window / browser_close / browser_configure, browser_configure now reporting platform + taskbarSupported, and the mac-aware Chrome .dmg install hint (no UAC/awaiting_uac phase on darwin). Reconciles his local _isWin against the module-level one added in 1.9.89. Also fixes bridge.json platforms.macos.supported, which had declared FALSE since the macOS port actually shipped in 1.9.74 and is the machine-read manifest a host reads to decide platform support. All 1.9.86-1.9.90 work verified intact (reap fix, wiki auto-sign, native-first).

Flip pup's default browser to NATIVE-FIRST. launchCandidates() now orders the user's installed Chrome, then Edge (ships on every Windows PC), FIRST, driven with a fresh isolated profile PLUS the noBrowserIdentityFlags that suppress Chrome's sign-in / set-up-a-work-profile merge dialog. Chrome-for-Testing is now the genuine LAST RESORT, fetched only when the box has no installed Chromium at all; warmup() no longer force-downloads CfT when a native browser is present. This makes native as clean as CfT (the identity-dialog reason for CfT-first was already invalidated: CfT shows the same dialog, the flags are the real fix and apply to any Chromium), with no 150MB download, always the user's current battle-tested build, and all taskbar identity overrides work identically. browser_use {browser:cft} still pins CfT for a managed/enterprise box whose policies interfere. Cold-start gate + hints updated; decision doc flipped.

Fix browser_close leaving core-pegging renderer orphans that froze the desktop. The teardown reap was fire-and-forget with an 8s full-Win32_Process enumeration that TIMED OUT exactly when the box was CPU-pegged by the runaway renderers it existed to kill (AdomLapper: 88-98% CPU, dwm starved, forced reboot; 6 CfT procs survived a close, 4 renderers near 100%). Now the reap is AWAITED, VERIFIED, and load-tolerant: WMI image-name filter is pushed server-side so only chrome/msedge rows materialize (fast at 98% CPU), close() awaits the profile-scoped kill of the parent tree PLUS any reparented renderer orphans, and every close response returns chromeProcsRemaining (should be 0). Adds a boot + periodic orphan sweep (reaps pup chrome whose profile has no live session, spared by profile) and a verified close-all sweep.

Wiki auto-sign: pup now signs its wiki window in AUTOMATICALLY from the user's identity that AD already stores at ~/.adom/session.json on the same desktop (mints a single-use browser-session magic link server-side from that bearer token and navigates the vault window to it), instead of ever making the user hand-type a login into pup's no-memory browser. Applies to BOTH the jump-list logged-in-view toggle and the AI wikiView:authed open path; manual /login is now only the fallback when AD itself is signed out or the session expired.

Recover from the 1.9.86 mac-parity regression: rebase onto Kyle's 1.9.85 unified base and re-apply only the puppeteer 24.43.1 / CfT 148 bump. Restores darwin support, recorder-icon.ico, and the AD-base resolver that 1.9.86 dropped.

Cache-bust re-cut of the puppeteer 24.43.1 / CfT 148 bump (1.9.85 release URL served a stale edge-cached zip)

Reunifies the two divergent release lines: John's 1.9.76-1.9.84 Windows work + the mac-parity line (hidden-app background, mac lower/raise/alert, dmg Chrome install, verified-AD-base resolver). Restores pup-cat category icons + recorder icons to the zip. Supersedes 1.9.75 and 1.9.84.

Extend the wiki sign-in auth re-check to ~90s so a real manual SSO+2FA sign-in also flips the glyph/label/icon to logged-in when it completes, stopping early on success or if the window closes

Wiki sign-in: after navigating to the login page, re-check auth in the background and flip the glyph/tab-label/category-icon to logged-in when the hydrogen SSO auto-completes (an already-alive SSO session lands back signed in with no form to fill)

Wiki logged-in toggle: when no wiki session exists yet, navigate THIS window to the sign-in page and raise it, instead of showing a dead-end sign-in-in-this-window toast on the public page

Make the orphan-renderer reap NON-BLOCKING: the v1.9.78 reap ran a synchronous 8s PowerShell CIM query on the close path, freezing the event loop and making the bridge unresponsive to AD's health check (self-inflicted restart). Fire-and-forget async instead

Reclassify a timed-out/detached tab op as the structured renderer-crashed error at the dispatch catch (first-verb fast-fail for issue #16)

Reclassify a timed-out/detached tab op as the structured renderer-crashed error at the dispatch catch, so even the first verb that discovers a crash returns the reload-to-recover hint instead of a generic 20s timeout

Survive renderer crashes (issue #16): detect a crashed tab renderer (page error + Inspector.targetCrashed), fast-fail its verbs with a reload-to-recover hint instead of hanging the window, clear the flag when reload/navigate respawns it, and reap orphaned/crashed renderers scoped to the session profile on close

Never block browser_open_window on a Chrome-for-Testing download when a system browser is available (issue #15): a machine with working Edge and Chrome could not open a window because the gate ignored system candidates, contradicting the documented last-resort behaviour

Power fix: Chrome power-saving flags are now OPT-IN via highFps instead of applied to every window forever (issue #14 battery drain). A highFps window holds a lease (default 20 min, max 120), an active recording holds it open indefinitely so a take is never cut off, and on lapse the window is DOWNGRADED by relaunch carrying its tabs rather than closed. Adds browser_highfps_extend, plus hints on every open so an AI discovers the capability

Self-heal a half-populated Chrome-for-Testing cache dir: delete the versioned folder when it exists without its executable, so a partial or interrupted download stops failing every later install attempt

Keep the log janitor (dedupe plus quieter drag and overlay lines) and record why the bridge owns log VOLUME while AD owns the file and its rotation

Log the missing-favicon case once per session instead of on every tab-badge update

Log janitor: collapse consecutive identical lines into one plus a repeat count, and stop the drag check emitting one line per tab when nothing moved

Park windows on RECOVERY and on RECLAIM (background-by-default was only enforced on the launch path, so after a reboot every recovered window sat in the foreground), and log every incoming verb for auditability

Let AD desktop_bring_to_front perform the raise after PowerShell clears WS_EX_NOACTIVATE, since SetForegroundWindow is silently ignored under the Windows foreground lock

Use PowerShell only to clear WS_EX_NOACTIVATE and un-minimize, then have AD desktop_bring_to_front perform the real raise, because SetForegroundWindow is silently ignored under the Windows foreground lock

Raise a pup window by resolving its hwnd from the session title and clearing WS_EX_NOACTIVATE before SetForegroundWindow, so a backgrounded Edge window actually surfaces (the PID path was skipped on every detached launch and only ever matched chrome.exe)

Raise a pup window by resolving its hwnd and calling desktop_bring_to_front, instead of relying on CDP setWindowBounds plus bringToFront which never raises an Edge window from the bottom of the z-order

Bake the deep-link into the minted magic URL by appending next= client-side (the endpoint ignores next, the CLI appends it), so an in-place view toggle lands back on the same wiki page instead of the root

In-place wiki view toggle: mint a single-use magic link from an already-logged-in page (browser-session endpoint works with just the session cookie, so the desktop needs no token) and navigate the window, instead of closing and relaunching it under another profile

Wiki view toggle now switches IN PLACE using Colby's browser-session magic link (a logged-in page mints its own single-use link, so the desktop needs no token) instead of closing and relaunching the window under another profile

Claim the jump-list dedupe key before the await so two concurrent callers cannot both commit (a redundant CommitList rebuilds the menu and dismisses one the user is opening)

Brand the jump-list header BEFORE stamping the new appId (Win11 bakes button art at creation, so branding after had no visible effect), and dedupe jump-list commits on appId+view so a CommitList cannot dismiss a menu the user is opening

Brand the jump-list header row: pass hwnd plus headerIcon to desktop_set_window_jumplist (AD 1.9.153). hwnd is required, titleContains silently no-ops. Log headerBranded and iconCheck so it is verifiable in code

Set the thumbnail tooltip from updateTabCountBadge so the normal open path gets one (it was only wired into refreshWindowChrome and the category-change hook, so freshly opened windows had no tooltip)

Rebuild all category icons with PNG-compressed 256 frames (Vista+ rule: a BMP 256 entry renders the generic white document on the jump-list header), bump icon generation to i3, and add the thumbnail tooltip using AD 1.9.152 desktop_taskbar thumbnailTooltip

Agent-activity indicator: taskbar progress bar marks which pup window a thread is currently driving (indeterminate while verbs land, cleared 2.5s after the last one); browser_configure agentActivity on|off

Self-healing session-title tag: collapse duplicate (session: id) tags to exactly one so the taskbar thumbnail caption is not bloated and AD title resolution cannot hit a duplicated tag

Retire adom-pup-browser3.ico as the default: new pup-cat-default9.ico matches the teal-tile category family for category-less windows and the base Adom Pup identity

Jump-list task rows now use the windows category icon (pup-cat-*9.ico) instead of the retired adom-pup-browser3.ico

Shorten wiki jump-list task titles to Switch to logged-in view / Switch to public view so the login word is no longer truncated; the page context stays in the description line

Fix jump-list first-right-click blip: stop stamping a transient .plain AUMID while a window is still loading (it created a jump-list-less button that Explorer resolved first), and clear an AUMIDs jump list when unregistering so stale CustomDestinations files stop piling up

Add Close-ALL-pup-windows jump-list task to every window, unregister AUMIDs on close-all, and reconnect+reattach disconnected-but-alive sessions via rescanProfile so a zombie window stops showing the old default icon

Stop reclaim adopting windows mid-launch: skip profiles with a launch in flight and require two consecutive sweeps before adopting

Inject the session title marker even when a page has no title, so title-less app pages stop making their window invisible to every branding call

Re-evaluate a window category when a tab finishes navigating, so a window whose tabs were still loading no longer freezes on the wrong taskbar icon

Reclaim unmanaged pup windows (openerless popups and orphans whose session died) so they can never sit unbranded in the taskbar

Replace the per-session recovery strike with a crash sentinel so a normal restart can no longer quarantine healthy sessions, and defer the AUMID prune so it cannot unbrand live windows

Add icon-generation token to the per-window AUMID so an icon or branding change forces Windows to rebuild the taskbar button, repairing already-baked white tiles

Fix white taskbar icon: write IconResource into HKCU ourselves because AD register_app_identity ignores iconPath when shortcut is false, leaving every AUMID unbranded; prune orphaned Adom.Pup AUMID keys on startup

Skip placeholder favicons, retry the overlay instead of failing silently, and strip every old session suffix while disconnecting the previous title observer

Skip the check when nothing is multi-tab and throttle it to once per 1.5s so a noisy desktop cannot turn it into a poll

Any adom.cloud slug host counts as an Adom app, and brandSweep re-evaluates categories for long-lived and recovered windows

Adopted dragged-out tabs now get their own session title suffix before branding

Grow the dark teal window 30 percent and keep a real margin between it and the glyph, plus corrected stroke weight

Remove the browser toolbar line, enlarge the category glyph to fill the window body, and embed the authentic Adom mark for app windows

Scale the inner content glyph 1.3x for legibility at taskbar size while keeping the frame and margins

Refresh identity icon, favicon overlay and jump list together with retries on both sides of a drag-out

Parse AD command responses defensively for both the relay wrapped shape and the bare loopback payload

Reuse an existing global window-opened watch instead of leaking one per restart, and ship the drag-out detection diagnostics

Log every step of the drag-out detection so a silent failure cannot hide

Stop filtering window-opened events by window name since a new window has none at creation time

Subscribe to the AD window-opened UIA event and adopt a dragged-out tab as its own session with its own identity and category icon

Match the proven raise path so a detached browser window is shown via CDP instead of PowerShell targeting the wrong window

pup skill gains the window-type icon section: five taskbar icons and their meanings, the wiki view toggle jump list, and the favicon-overlay rule

Log identity stamp failures and retry the category change re-stamp with backoff

Per-session appIds carry the category so a flip creates a fresh taskbar button, per AD's Win11 measurement

Seed the authed flag at session creation so the first taskbar icon is already the signed-in book plus person

Signed-in wiki icon becomes book plus solid person bust so login state reads at taskbar size

Solid dark window body with teal knockout category glyphs and proper margins per design review

Redraw category icons around a shared browser-window frame with the category as window content, Adom mark for apps

Re-stamp the base icon immediately when a window category changes instead of waiting out the ten minute brand debounce

Redraw the five category glyphs in the family dark teal instead of white, and document the Explorer icon-cache failure mode

Regenerate the five category icons with classic BMP frames because the shell RelaunchIconResource loader cannot parse PNG-compressed ICO frames

Give each session its own OS window so per-window branding resolves, add monochrome category icons per the brand icon law, and strip emoji from every user-visible string

Repaint the taskbar overlay after the wiki auth state is recorded so the plate colour is correct

Switch the signed-in plate and icon green from an ad-hoc Tailwind value to the Adom design-system green token

Recolour the overlay plate behind the site favicon green when signed in to the Adom wiki, keeping the favicon in the slot

Retry the identity re-stamp with backoff so the icon flip does not lose the race against the relaunched window title injection

Revert the overlay padlock and put the Adom wiki login state on the main icon as a solid green filled browser glyph

Move the Adom wiki login indicator to the taskbar overlay slot as a green closed or slate open padlock, readable at real 16px taskbar size

Swap the pup main icon between a browser-window outline and a solid padlock to signal Adom wiki login state, with state-keyed identity and AUMID caches

Consume AD 1.9.141/1.9.143/1.9.144: expiresInMs captions on the loopback API, relaunchCommand trio to brand the jump-list header, retire the in-page toast

In-page wikiToast feedback since desktop_caption is relay-only on this AD, caption call now logged not silent, branding waits for the title suffix

Escape JSON quotes in jump-list task args so the CLI receives valid JSON, plus desktop_caption feedback on switch start and completion

Async PS raise (no event-loop block), respond immediately after raise with background cosmetics, optimistic glyph with delayed auth-recheck self-correction

browser_wiki_set_view now does a real OS SetForegroundWindow raise via osRaiseSessionWindow plus a taskbar flash, so the clicked switch is visibly brought to front

Persistent circuit breaker quarantines crash-poison session files so recoverSessions can't loop-crash the bridge; jump-list task carries the pup icon

Jump-list toggle titles now lead with Adom wiki so the menu is self-describing, not generic

Add _launchInFlight dedup so concurrent opens on one profile can't collide and wedge the bridge; add recovery hints and skill troubleshooting

Add browser_wiki_set_view and per-window wiki jump-list toggle (logged-in vs public) via desktop_set_window_jumplist

Register per-session AUMIDs (#207) for alt-tab/jumplist Adom icon.

Word labels for wiki mode; refresh after login.

Favicons win the overlay; active tab, count in tooltip.

Adom-wide auth gating; overlay favicon(1)/count(2+).

Profiles moved out of the clobbered bridge cache to ~/.adom.

Gentle in-tab wiki mode glyph.

Wiki authed shared across threads; routing fix; sharper hints.