Pup - Puppeteer Bridge

Windows survive an upgrade AND the user's close is final. pup relaunches a missing window only when it knows the browser died for this pass (it ended it for an upgrade or restart, it crashed, or it was already dead at boot); any other missing window was closed and is forgotten. Closing a window during a relaunch queue cancels the queued relaunches of that thread (its taskbar icon). 2.0.681 dropped every window after the first on an upgrade; 2.0.680 and earlier reopened windows the user closed while pup restarted (John, AdomLapper, 2026-09-23). Promoted to public on 2026-09-23.

Windows survive an upgrade AND the user's close is final. pup relaunches a missing window only when it knows the browser died for this pass (it ended it for an upgrade or restart, it crashed, or it was already dead at boot); any other missing window was closed and is forgotten. Closing a window during a relaunch queue cancels the queued relaunches of that thread (its taskbar icon). 2.0.681 dropped every window after the first on an upgrade; 2.0.680 and earlier reopened windows the user closed while pup restarted (John, AdomLapper, 2026-09-23).

The user's close is final during a restore too: closing a window while an upgrade relaunches a thread's windows cancels every queued relaunch of that thread (the same taskbar icon), and each relaunch first picks up closes reported since the last one. Before, closing a thread's icon mid-queue brought its next window back 13-28 s later (John, AdomLapper, 2026-09-23). Plus 2.0.681: a window is restored only when its browser is gone.

A window is restored only when its browser is GONE (crash, sleep, upgrade). If the browser is alive and does not have the window, the window was CLOSED and pup forgets it. Before, any missing window read as a crash to repair, so windows the user closed while pup was restarting came back at the next boot (John, AdomLapper, 2026-09-23).

The cache prune never races a browser install: it refuses while one is in flight (the boot pass waits for it) and never touches a folder written in the last 5 minutes, so a first install unpacking into .partial cannot be deleted under it. Plus everything in 2.0.679.

pup accepts only plain-version folders as a usable browser build, so a half-unpacked .partial folder or a renamed copy is never launched (found while testing ab 2.1.153's prewarm of pup, which works end to end: ab calls pup_prewarm, pup downloads and unpacks the pinned build in the background, ab records ok). Plus everything in 2.0.678.

pup-bridge#126: bridge.json declares prewarm.verb pup_prewarm (timeout 900 s), so ab 2.1.153+ asks pup to fetch its browser in the background once per installed version instead of the first window paying for it. Plus everything in 2.0.677.

pup-bridge#125: pup prunes its browser download cache a minute after every boot and on demand (pup_cache_prune, with dryRun): superseded builds, the Node-era headless-shell builds and partial downloads go; the pinned build, the newest complete build when the pinned one is missing, and anything a running process or the default browser uses are kept. Plus everything in 2.0.676.

pup-bridge#124 (one verb surface, image fullPath/safePath, ok and output fields on every reply) plus two recovery fixes for multi-tab windows after an upgrade: a new extension-lane tab opens only in the window pup names (the extension refuses rather than guess; tabs had landed in another thread's window), and reopened tabs are de-duplicated by exact URL (stripping the query had dropped different pages on one path).

pup-bridge#124 (one verb surface, image fullPath/safePath, ok and output fields on every reply) plus: a new tab on the extension lane opens only in the window pup names (a live tab of it, or its Chrome window id); the extension refuses rather than guess. After an upgrade, recovery used to reopen a window's extra tabs into another thread's window (AdomLapper, 2026-09-22).

pup-bridge#124: one verb surface (bridge.json and pup_describe generated from the same 96 routed verbs; the build stops if one lacks a catalog entry; pup_describe carries verbCount and its notes). Every image reply carries ab's fullPath and safePath so ab auto-pulls the picture. pup now lifts its output fields onto every reply and always states ok true/false itself, because ab 2.1.14x stopped doing both: ok had vanished from error replies and pup_record_stop reported the call time as the recording's duration.

pup-bridge#124: one verb surface (bridge.json and pup_describe generated from the same 96 routed verbs; the build stops if one lacks a catalog entry; pup_describe carries verbCount and its notes). Every image reply carries ab's fullPath and safePath so ab auto-pulls the picture. And pup now lifts the fields of its output block onto every reply itself, because ab 2.1.14x stopped doing it: 'ok' had vanished from error replies and pup_record_stop reported the call time as the recording's duration.

pup-bridge#124: one verb surface. bridge.json's verb list and pup_describe are generated from the same list of routed verbs (96 each; they said 55 and 85), the build stops if a routed verb has no catalog entry, and pup_describe carries verbCount and its advisory notes separately. Every image reply (pup_screenshot and friends) now carries ab's fullPath and safePath, so ab's CLI auto-pulls the picture to the caller.

Every profile's lane survives a restart in its own jar: pup restores each profile's lane browser at boot (validated by the folder its processes run), adopts an unknown lane browser only into the profile it reports and only after that restore, re-adopts each window on its own profile's lane, and relaunches any window it finds inside another profile's browser. Before, the first unknown browser after an upgrade became the adom-you lane, so adom-you windows ran with another profile's cookies, and windows on a second profile were never re-adopted (AdomLapper and CRR, 2026-09-21). Promoted to public on 2026-09-21.

Every profile's lane survives a restart in its own jar: pup restores each profile's lane browser at boot (validated by the folder its processes run), adopts an unknown lane browser only into the profile it reports, and relaunches any window it finds inside another profile's browser. Before, after an upgrade the first unknown browser became the adom-you lane, so adom-you windows ran with another profile's cookies (AdomLapper, 2026-09-21).

Windows survive an upgrade: recovery no longer counts a window that is still on screen (waiting for the extension to reconnect) as a failed relaunch, so it never deletes a live window's record. Before, three quiet checks after a restart forgot the window, leaving it ownerless with no taskbar badge and making its thread open a duplicate. The identity audit also reads ab's nested reply now instead of reporting every window as unstamped.

No more taskbar-identity residue: a window's AUMID is unregistered when it closes; a sweep a minute after boot (and pup_sweep_identities on demand) unregisters every thread, per-window and category identity no live window holds, deletes dead shortcuts in pup's Start Menu folder and stale tile/icon generations. arav-rog had 116 dead keys and 20 dead shortcuts (John, 2026-09-20). Promoted to public on 2026-09-21.

No more taskbar-identity residue: a window's AUMID is unregistered when it closes; a sweep a minute after boot (and pup_sweep_identities on demand) unregisters every thread, per-window and category identity no live window holds, removes its Start Menu anchor and deletes stale tile/icon generations. arav-rog had 116 dead keys (John, 2026-09-20).

No more taskbar-identity residue: a window's AUMID is unregistered when it closes, a sweep a minute after boot (and pup_sweep_identities on demand) unregisters every thread/category identity no live window holds, removes its Start Menu anchor and deletes stale tile/icon generations. arav-rog had 116 dead keys.

No toast when a human raises a pup window: the jump list's relaunch command (pup_focus_window as user-taskbar-menu) used to warn the user about their own click. The foreground gate now judges by pup browser PID so a user's own Chrome can no longer fail it. Promoted to public on 2026-09-20.

extension lane: a stuck mouse button is released before the next mouse event (the jump-list gate caught it; same bookkeeping as the CDP branch) Promoted to public on 2026-09-20.

skills + README for the public publish: extension-lane mental model, CDP off by default, isolation per lane, landed, vault; no code change from 2.0.662

dock health: serve /dashboard/status and /dashboard/health as aliases of /status (the dock appends its health path to the served URL; the LED read HTTP 404)

skills only: one owned window + explicit tabs (PR #1 ported), Windows Firewall prompt note (#91); no code change from 2.0.660

pup-bridge#113/#112: per-profile extension lanes (isolated:true and profile: open their own lane browser, no CDP); throwaway lanes end with their last window, staging removed, swept at boot

pup-bridge#113/#112: the extension lane is per profile; isolated:true and profile: open their own lane browser with their own staged extension, token and queue, no CDP; throwaway lanes end with their last window and are swept at boot

extension lane: no readiness wait or page scripts on blank/extension pages (20 s per about:blank navigate); smoke gaps closed (download fields, wiki view + auto-sign, owner chip); adom-desktop -> adom-bridge; CDP lane off by default

diagnostic: readiness wait logs each attempt

extension lane: page scripts after the wiki view flip; readiness wait accepts about:blank; carries the smoke gap fixes, the adom-bridge rename and the CDP-off default

extension lane: wait for the navigated document before page scripts, the landed probe and the wiki probe (scripts ran in the old document); owner chip, download fields, wiki view; adom-desktop -> adom-bridge; CDP lane off by default

extension lane: owner chip script built exactly as the CDP path builds it (an unreplaced placeholder threw before the chip drew); download fields, wiki view + auto-sign; adom-desktop -> adom-bridge; CDP lane off by default

extension lane: pup_download reports savedTo/bytes at top level; wiki view probe + desktop-token auto-sign; owner chip + floaty per page (the smoke on the extension lane found all three); carries 2.0.652 rename + CDP off by default

adom-desktop -> adom-bridge everywhere (vault service renamed with in-store key migration); CDP lane off by default (cdp_lane_disabled), John: the extension lane must solve every use case

HOTFIX: vault migration no longer holds the cache lock across save (2.0.650 hung every vault verb) and saves before deleting legacy entries; upgrade cycle takes hwnds from live sessions

vault migration keyed by the real service name (adom-desktop-pup); upgrade cycle waits for the old windows to vanish before relaunching them

pup-bridge#122 DPAPI secret store (no Credential Manager slot per login; legacy entries migrated and freed); #107 selector targeting for pup_input_dispatch; #106 captured metadata on every screenshot + identity guard on the OS-window path; #105 recording encode is a pollable job

pup-bridge#104 fetch_url: credentials fallback for wildcard CORS, binary-safe body (bodyBase64 + sha256), typed failure stage; #120 trusted input on the extension lane (Input.* through the worker's cdp action); #112 isolated:true mints an iso- profile removed on close; #90 slow opens answer loading:true after 35 s and finish in the background

pup-bridge#121: a stale lane worker after an upgrade is cycled through the crash-restore path (every window relaunched from its file); worker version reset on every lane kill; orphan sweep at launch; pup_readiness orphanedBrowser

pup-bridge#121: orphaned lane browser ended at launch (WMI by profile dir) and reported by pup_readiness; no in-place worker reload after an upgrade, pup's own kill + recovery restore instead

pup-bridge#119: HTTP auth from the vault on the extension lane (retry keyed per request); no_credential on navigate/fetch; pup_fetch_url on the extension lane; skill note

pup-bridge#119: HTTP Basic/Digest auth answered from the vault on the extension lane (onAuthRequired -> /extauth, registrable-domain match); no vault entry cancels the challenge and navigate/fetch return no_credential with the host; pup_fetch_url runs on the extension lane

landed probes the DOM: a visible Log in link means NOT signed in (chatgpt.com/codex fooled the URL rule); a password or email+continue form means a sign-in page; also on pup_open_tab

open/navigate responses carry landed:{url,title,loginPage,signedIn,_hint} so an AI never asks the user to sign in where the profile already is; login recipes for claude.ai and chatgpt.com

birth hold: busy spin for the first 100 ms after the first show (Chrome re-tops between 1 ms re-bottoms)

birth: bottomed in the same instant Chrome first shows it (native spin) and held 300 ms; the park never re-shows a visible window

birth: park while still invisible (the watcher holds the handle 150 ms before Chrome's first show); normal unfocused birth instead of minimized (no restore surface)

z-watch armed before the extension creates the window (names the window and the last pup action when a newborn reaches the top)

no ab attention-clear on pup's own open/navigate paths (it raised and briefly activated every newborn, z-watch measured 40-80 ms); native FlashWindowEx stop instead; install.sh and package.json say adom-bridge, not adom-desktop

z-watch instrumentation during birth grace, ms log timestamps, last-log; re-show keeps z-position

cold birth: arm the birth watcher after the launch (it expired before the window existed, so the cold window wore the stock CfT icon for 12 s); stamp identity at the token bind as a backstop

default ext lane finally gets --no-startup-window + --keep-alive-for-test (2.0.617 only put them on the stock branch): Chrome's New Tab startup window was on top at every cold start

cold launch: no empty url argument on the default lane either (Chrome opened its cwd as a file listing on top); gate counts by process

ext birth.js (CSP blocked inline token script); cold launch passes no url so --no-startup-window holds (unowned about:blank window sat on top 18 s)

The Rust half of the birth-token binding, which 2.0.630 shipped without: pup binds every newborn by its birth-page title token before anything else, falls back to the set-diff handle only when the token is not found, and navigates every birth from the birth page to its real URL after the window is bound and parked.

Every extension-lane window is born on the extension's own birth page with a unique token as its title, and pup binds the OS window by that title, deterministically, before anything else: the set-diff bound a placeholder Chrome makes at launch and parked that while the real window came up unparked (measured: 4.5 s on top on every cold start). The real URL is navigated to only after the window is bound and parked. The birth re-assert starts at 40 ms.

The birth re-assert runs after every extension-lane birth, dense in the first second (measured: the cold window was pulled back down within seconds while warm windows, which had no re-assert, came up on top and stayed). The post-navigate park uses the idle-hands rule. The fit step sets bounds only and never restores a minimized window: state normal was a raise, and it un-minimized windows the user had put away.

The idle-hands rule applies on the extension lane too: a cold first window is activated by Chrome's own restore (measured: the re-assert answered foreground with no input since birth), so a foreground window inside the birth grace with no input since birth is Chrome's raise and is bottomed; any input means a person and pup stands down. A birth that bound a placeholder and rebinds the live window later now parks that window and re-asserts from there; it used to stamp it and leave it on top.

A cold birth's first window gets the doctrine's bounded re-assert inside the birth grace, at 1, 2.5 and 5 seconds: measured with the fixed bottom call, a warm birth ended behind at z11 while the first window of a fresh browser settled on top after every park. The primitive never touches a foreground window, so a human's click is never undone. The foreground-proof harness clears every thread's windows by name first.

The park raised the window. Measured from a fresh process on the conference-room box: SetWindowPos(HWND_BOTTOM, NOMOVE|NOSIZE|NOACTIVATE) on a pup Chrome window returned true and moved it to the TOP, where it stayed; the same call with SWP_NOOWNERZORDER put it at the bottom and it stayed. Chrome's frame owns helper windows and without that flag Windows re-orders the owner with them. Every 'parked at z-bottom: true' was a raise: the birth flash, the navigate that surfaced the window, the lower that succeeded with the window on top. One flag on every bottom call.

The minimized birth is created with no bounds: Chrome answers 'Invalid value for state' when minimized is combined with a rect, which failed every open in 2.0.624. The fit step sizes the window right after birth, as it always has.

The extension lane's birth transient is MINIMIZED, not off-screen and not in place: the extension API refuses off-screen bounds, and a visible in-place birth measured on top for 42 of 52 samples even unfocused with no startup window. A minimized window cannot be raised or activated, pup shows it already at the bottom the moment it has the handle, and it can never strand because a taskbar click restores it. tools/foreground-proof.sh counts truncated titles correctly.

A warm open that finds the worker silent relaunches the lane by re-entering the open routine; it did so while holding the non-re-entrant birth lock, so the open deadlocked on itself and every later open queued forever (exact 60 s timeouts, a dead-looking lane, no launch line). The lock is released before the re-entry. Bites whenever the browser dies between a poll and an open.

The extension API refuses an off-screen window (bounds must be 50% on screen), so the extension lane births each window in place at its final rect, one call, relying on R2: with --no-startup-window the browser holds no foreground rights. A window the browser refuses is reported as ext_open_failed with Chrome's own message, not as a busy lane.

The extension lane follows placement rule R1 at last: every window is born off-screen at -32000,-32000 and moved on-screen within 50 ms, unconditionally, the way the CDP lane has since v2.0.276. Gone with it, per the doctrine: the hide-until-ready watcher (a strandable staging state), every focus handback (deleted in August for foregrounding the wrong window), the minimized birth, and the post-navigate attention clear, whose Bridge implementation raises the window (adom-bridge#199) and was the navigate-puts-it-on-top bug. tools/foreground-proof.sh is the gate: a pinned window, a cold lane, opens and navigates, zero samples with a pup window on top.

A navigation no longer leaves a pup window on top of the user's work. Measured: a navigate makes the pup window ACTIVE, and Windows refuses to lower whatever is active, so every lower reported success while the window stayed in front. The order is forced: return the screen to the window the user was in, which makes the pup window ordinary again, and only then lower it. Either half alone does nothing.

The extension reports which path a navigate used, and pup logs a fallback to Chrome's tab API with the reason, because that path surfaces the window and the failure was invisible.

A navigate no longer surfaces the window. Measured with a window pinned in front: the pup window sat behind it, and one chrome.tabs.update({url}) moved it to the very top, which every later call then inherited. That is what flashed a pup window at the user several times per sign-in. Navigation now goes over the DevTools channel (Page.navigate), which does not touch Chrome's tab or window UI.

The cold start is invisible and the consent prompt is gone. The lane launches with --no-startup-window so Chrome never draws or activates a window of its own, plus --keep-alive-for-test which holds a windowless browser open: without it the browser exited within 6 seconds on John's laptop, which is why 2.0.611 had to revert the first flag. The first pup window is now created by the extension like every other one, minimized and shown already at the bottom.

The screen goes back to the user ONCE, at the end of the open and at the end of a Google sign-in, instead of in the middle where the rest of the flow walks over it. Measured on John's laptop: a consented cold start held his screen for 40 seconds because every navigation re-activates the window and Windows will not lower an active window.

The cold-start consent prompt reads ab's answer fields instead of searching the response text. ab echoes both button labels back, so the old contains("not now") check turned every 'Open it' click into a decline and pup opened nothing three times in a row.

Windows will not send the ACTIVE window to the bottom, which is why every park call succeeded while the pup window stayed on top: z-order and focus are one problem. A warm open is invisible. A cold one cannot be, so pup now ASKS the user with a two-button toast and waits for the answer before starting the browser, and afterwards raises the window they were working in so the park finally sticks.

Either invisible or warned, never a surprise. A warm open is invisible: the window is created minimized and made visible already at the bottom of the z-order. A cold open has to start the browser, which draws its own window before pup owns anything, so pup now TOASTS THE USER FIRST and waits a beat before launching.

A pup window is never drawn in front of the user. The keyboard-restoring code is gone: it treated the symptom. Windows are created minimized, the cold-launch watcher HIDES anything new before it is drawn, and the window is then made visible ALREADY at the bottom of the z-order in one call. Foreground happens only when the user is warned or clicks the toast.

Windows pup creates are born minimized and shown without activation, so they never take the keyboard. The cold start keeps its startup window: an extension-lane Chrome launched with --no-startup-window exits before its worker calls home, which broke three opens in a row on John's laptop. The focus guard covers that one case.

pup windows can no longer take the keyboard. The extension creates every window MINIMIZED and pup shows it with SW_SHOWNOACTIVATE before dropping it to the bottom, and the cold lane launches with --no-startup-window so Chrome never makes a window of its own. The CDP lane has carried --no-startup-window since the Node build called it THE fix for the focus-steal war; the extension lane, which is the default, never got it.

The focus guard WATCHES instead of peeking. Checking once right after the park is a race: Chrome can take the keyboard a beat later, after the check has passed, which is how the third of three windows stole it while the first two did not. pup now holds the user's focus for the whole open and for several seconds after a navigate, and hands it back every time a window it owns takes it.

pup gives the keyboard back. Pushing a new window behind the user's work was never enough: Chrome's startup window ACTIVATES, so the user loses whatever they were typing. pup now remembers which window held focus before it opens anything and hands focus straight back the instant a pup window takes it, on both the cold launch and the per-window birth.

A window an AI navigates while the user never asked to see it goes straight back behind their work. It came forward on the navigate, which is how a pup window landed in front of John with the explaining toast 21 seconds behind it. Never applies to a window that is foreground or that he has touched recently.

The cold-launch window watcher now outlives the launch call, which returns as soon as the process ids appear, seconds before Chrome paints its startup window. The first cut of this parked nothing at all.

A cold browser launch no longer throws its startup window over the user's work: pup watches from the instant it spawns the browser and puts any new window behind within 25ms, which is the one case the birth park could not cover.

A new pup window goes behind the user's work the instant its handle exists, instead of after the identity, fit and jump-list work: measured 4 seconds of every new window sitting on top of what the user was typing in. Raising now warns first and the warning is clickable: the toast carries the window, is a warning not an info, and the raise waits a beat behind it.

pup toasts the user the moment it needs them for a password, and the toast carries the window: clicking it opens the exact pup window that is waiting. Covers the Google sign-in answers, a site with no saved login, and the browser-login import's consent wait, which arrives as a Hydrogen notification and was being missed.

Login capture works on the DEFAULT lane. It only ever existed on the CDP lane, so a password typed into a normal pup window was thrown away and pup kept asking for it (John, 2026-09-17). The extension now injects the same capture rail and forwards the credential to pup over loopback, and on a Google password page, which has no username field, it takes the address Google prints on the page.

mac: hide and raise a pup window through NSRunningApplication instead of System Events, so macOS never prompts to control System Events (Kyle's PR #2, merged). Node shell for the public tier. Promoted to public on 2026-09-17.

pup's own kill is no longer read as the user closing a window: a browser pup ends itself (profile handover, lane relaunch, restart) has its windows restored, and only a browser that exits on its own with code 0 is forgotten. Lane adoption no longer learns the pids of a CDP browser pup already owns on another profile, which made a lane relaunch kill it.

A pup holding a lane token whose browser is gone now adopts the live token-less one instead of refusing every poll until a restart (measured on a test PC: 20 minutes of dead lane). Every no-password answer names ab's credential reader, with its real limit: a browser never saves the password of the account it is itself signed in as.

Google sign-in survives the 60s command cap: it runs in the background and re-attaches when called again, instead of reporting a timeout while pup is mid-sign-in (same fix as the password import). Includes the merged mac window fix (PR #2, NSRunningApplication, no System Events prompt) and the pup-bridge#118 embedded-file push fix so a fresh checkout builds.

Google sign-in as the right account: pup_google_accounts searches every browser profile, nb's profiles, the vault and pup's own signed-in sessions; pup_google_signin fills the email and that account's saved password, hands back the verification step with the exact next call, and never guesses between accounts. The vault keeps one login per site and username. pup_login no longer reports success when it filled nothing. The browser-login import runs in the background and re-attaches instead of timing out while the user approves it.

Google sign-in as the right account: pup_google_accounts searches every browser profile, nb's profiles, the vault and pup's own signed-in sessions; pup_google_signin fills the email and that account's saved password, hands back the verification step with the exact next call, and never guesses between accounts. The vault keeps one login per site AND username (a second Google account no longer overwrites the first). pup_login no longer reports success when it filled nothing.

The user's close is final: a pup window closed by hand is forgotten at once and never restored; restore only on a proven browser crash (nonzero exit code) or a pup restart. The orphan about:blank sweep no longer closes a lane's last window or a window being born (it killed a cold lane and triggered a 7-window restore on 2026-09-15). rust/ ships with every release (pup-bridge#117).

skillpack install script deploys pup-lanes (it was in the tarball but not in the install list, so every container kept the pre-parity lane text; pup-bridge#116).

skills: the main pup skill's capability paragraph and the screenshots-and-recording skill now describe the extension lane as it is (input parity, pup_select, CSP and Trusted Types eval fallback, recording through ab's native recorder); the old 'no trusted input, not in the session model' text and the three-recorder table were from the era when the lane was a fallback verb and sent the Work thread to file pup-bridge#116.

pup_select {selector, value|label}: choose a option in the background on both lanes (DevTools evaluate, CSP and Trusted Types cannot refuse it); pup_eval on the extension lane falls back to DevTools for Trusted Types refusals too (Google Calendar, Admin). Closes pup-bridge#116.

pup_eval on the extension lane falls back to DevTools for Trusted Types refusals too (Google Calendar, Admin); the fallback matched only the CSP wording (pup-bridge#116).

extension worker: the packaged port.json read had no deadline and hung on every fresh worker instance after a reload in place (hellos continued, /extcmd never hit; measured on winvm), which is the 'worker stalls after a cold launch or update' bug. Now a 2 s deadline with the last good lane and port remembered in extension storage, and every poll step bounded. Plus 2.0.589: per-command deadlines, an unsticking drain guard, the hello on its own alarm, and the birth grace that demotes only a no-input-since-birth self-raise on the CDP lane.

worker watchdog: every extension command races a deadline (a hung Chrome API answers as a named error instead of freezing the lane; measured: fit after a cold launch, debugger capture), the drain guard cannot stick, and the hello has its own alarm so pup can always tell a quiet worker from a dead one. Birth grace: pup may demote a newborn only when nobody has touched the machine since it was born, CDP lane only; any input, a 200 ms taskbar click included, is a person for the full 10 minutes.

the user's foreground window is the user's, always: the demotion primitive no longer expires a raised window after 5 s of idle reading (only a NEWBORN self-raised with idle hands inside the birth grace is demoted); the silent-lane restore checks ground truth first and never relaunches a session whose window is alive on glass (it relaunched a window John was looking at); a relaunch refuses a file whose window is alive; the attention-clear workaround re-checks foreground after the clear.

close: the lane's close result is checked, an unbound extension session resolves its handle before the OS close, and a window that survives both keeps its session and is reported (close_failed) instead of being left ownerless on the user's glass (eight orphans after a worker reload, 2026-09-15).

extension lane: a cold open blocks until the lane is up and relaunches once if the first browser never calls home, returning a real window or a real error instead of starting:true with no session (the caller's next verb hit session_not_found; parity's pup_open_tab, and other threads' trouble opening pup).

z-order: ab's desktop_clear_window_attention raises the window to z1 (adom-bridge#199), undoing every park at open and after navigation; pup re-bottoms after any attention clear unless the window is the user's foreground. Plus 2.0.584: input beats the birth grace, extension windows park at birth, inset frame.

foreground doctrine: the birth grace may override session flags, never input (a human taskbar click inside the first 8 s was undone by the +2.5 s re-assert); extension-lane windows park to z-bottom once at birth (they landed at z1, right under the active window) with no re-assert, since Chrome never self-activates an unfocused-created window; the lane's fit uses the standard 10 px inset frame.

overlay badges: SVG favicons rasterize (resvg, pure Rust); the wiki serves only an SVG icon and every wiki window wore the generic globe since the compositor moved into the binary in 2.0.568. The favicon guard now rejects HTML only. Lane status counts live windows correctly when no lane pids are known (an empty pid list meant no filter and counted the user's own browsers).

recording via ab: frames, bytes and duration ride at the top level of pup_record_stop (the CLI drops a non-string output; ab-smoke reads frames there); start carries width/height/fps at the top level too.

recording rides ab's native recorder: pup_record_start/stop/status/list delegate to desktop_record_window_* keyed on the window's hwnd (Windows Graphics Capture, hardware H.264 MP4; a covered window records live; measured 2542x1520, 2.1 MB per 20 s). Works on the extension lane. The CDP screencast remains only as a fallback where ab's recorder is absent.

recovery: a lane whose worker goes silent (3 min with no lane window on glass, or 10 min regardless) is declared dead and every extension session is restored from its file, tabs included (a dead lane sat listed as 1 window for 14 h); a relaunch whose open answers starting:true waits for the worker and opens again instead of dropping the session; the another-caller guard compares Chrome window ids and treats a missing session as a failed relaunch; a token-less extension browser after a restart is adopted (token minted into port.json, pids learned from CfT frames); status reports live lane windows.

ext lane: pup_type inserts the whole string in one trusted Input.insertText on the extension lane (per-key dispatch was two poll round trips per character and overran 30 s on a 20-char password); CDP lane unchanged.

ext lane at input parity: click, hover, type, press_key, scroll, fill, element and full-res screenshots, and CSP-proof eval now run on extension-lane windows through nbe's DevTools driver (one driver, synced from nb; chrome.debugger attached on demand). Recording and selector downloads still need lane:cdp (they wait on DevTools events).

ext lane: windows born with the early native stamp now get their jump list (right-click menu) too; a busy lane no longer gets relaunched by an unanswered open (that killed every thread's windows five times today), the open fails with ext_busy instead; lane-rule refusals are logged.

ext lane: launch with CalculateNativeWinOcclusion disabled (as the CDP lane always has) so screenshots of a pup window buried under the user's other windows capture; compositor-only, nothing on the wire. The 2.0.575 debugger screencast produced no frame for an occluded tab and stays only as a fallback.

ext lane: screenshots of a fully occluded window now capture via a one-frame Page.startScreencast under chrome.debugger (a captured tab is treated as visible; Page.captureScreenshot never returns for an occluded tab in stock Chrome and hung the lane in 2.0.574). Every debugger await has a deadline so a capture can never freeze the lane again.

ext lane: screenshots work on a fully occluded window. captureVisibleTab first; on Chrome's image-readback failure the extension attaches chrome.debugger to that one tab, Page.captureScreenshot, detach (Page domain only, no port, no automation flag). --silent-debugger-extension-api hides the bar.

ext lane: one AI thread, one window. Restored the birth lock (R4) so only one window birth is in flight at a time, refused any hwnd another session already owns, filtered births to the lane's own Chrome pids (Edge shares the window class), and dropped the sole-window guess that handed every asking session the same handle. Also ships the annotate preview thumbnail as raw RGBA.

pup-bridge#114: users hear 'pup window'. A naming rule at the top of the root skill (never name the browser build or how pup drives it unless asked), the build taken out of the frontmatter descriptions of pup, pup-lanes, pup-browsers-and-chrome and pup-why-cft (the last two are marked maintainer detail), and plain mode described as the browser's own stock button. Skills only, no code change from 2.0.571.

Skills describe what shipped on 2026-09-14: the thread tile and the overlay badge are composed in the binary (pup-taskbar-states); annotate works on both lanes and the CDP-only list shrinks accordingly, plus the worker self-reload note (pup-lanes, pup-settings); the extension lane's architecture for maintainers, from the shared birth watcher to the queued channel (pup-bridge-dev). The last 41 em-dashes are gone from pup-settings and pup-taskbar-states. No code change from 2.0.570.

Two fixes found by 2.0.569's proofs. (1) The extension-lane command channel is a QUEUE: it was one slot, so two callers at once (the annotate watcher polling every 500 ms and a pup_eval, or the health tick's overlay and a verb) overwrote each other, one timed out, and the annotate watcher died on its first read. Commands queue by id, results are keyed by id, the worker drains the queue on every poll, and everything the worker had taken is re-queued on a fresh hello. (2) The annotate overlay no longer uses innerHTML: pages that enforce Trusted Types (Google Docs) refused it, so annotate had never worked there on either lane. Carries 2.0.569 (annotate on the extension lane, worker self-reload after an install).

Annotate works on the extension lane, and a pup update no longer waits for every window to close. (1) pup_annotate on the default lane: the overlay script is now ONE file shipped in the extension (src/extension/annotate-overlay.js), file-injected into the page's MAIN world on the extension lane (a page CSP cannot refuse a file injection, unlike eval; the pen showed 'Annotating...' and did nothing on Google Docs, John 2026-09-14) and evaluated over CDP on the CDP lane; start, result polling and the Done callback go through lane-generic helpers (inject_script, call_window_fn, read_window, capture_viewport_png); the capture's caption strip and preview are composed in the binary (pup_identity::badge::annotate_compose, fontdue text) instead of an in-page canvas. (2) Worker self-reload: on each health tick, if the lane's worker is behind the bridge version, pup re-stages the extension folder in place and asks the worker to chrome.runtime.reload(); it comes back on the new files with the same lane token and in-flight commands are re-queued. Carries 2.0.568 (overlay badge in the binary) and 2.0.567 (ext windows branded before first show).

The taskbar overlay badge is composed IN THE BINARY (pup_identity::badge) for both lanes. It used to be JavaScript evaluated inside the page, which a strict Content-Security-Policy refused (Google Docs, claude.ai, the wiki), so those windows never got an overlay: 'no badge could be composed' (John, 2026-09-14, the all-engineering agenda). Same card as before: 48 px, radius 6, #202124 or #f1f3f4 when the icon is dark-dominant and transparent, the icon cover-fitted into a 44 px inset, scaled to overlaySize and pinned north-east; the generic globe and PDF sheet are embedded PNGs. The icon is sourced per lane: the extension reads by injected function (page CSP cannot refuse it) and fetches with the page's cookies; the CDP lane reads the hrefs over Runtime.evaluate and the bridge fetches; /favicon.ico is the fallback with the same 30 min negative cache. badge_js and the extension lane's duplicate composer are deleted. Carries 2.0.567 (ext windows branded before first show).

Extension-lane windows are branded BEFORE Chrome shows them, with the same birth watcher the CDP lane has had since 2.0.446 (now one function shared by both opens): the AUMID is registered ahead of time, a thread polls every top-level frame every millisecond from before the window exists, and the newborn is stamped natively while still invisible so the shell bakes pup's icon into the button at its first show. Until now the ext lane stamped only after the page had navigated, so every ext window was born on the stock Chrome icon (John, 2026-09-14, opening the all-engineering agenda). The ext lane's own 6 s bind loop is deleted; the watcher's hwnd is the window.

Extension-lane channel survives a service-worker restart. An MV3 worker can be torn down between taking a command and answering it (measured 2026-09-14: a second hello 31 s after the first, mid-command); the reply never came and the bridge waited out the full timeout, which on a cold open pushed pup_open_window past ab's 60 s and the AI saw a timeout while the window opened anyway. The bridge now remembers the command it handed out and re-issues it when a fresh hello arrives from the lane. Cold-open budgets also fit inside 60 s now (brands 6 s, tabs 10 s, birth navigate 30 s, badge eval 25 s). Carries 2.0.565 (ext eval matches the CDP result contract) and 2.0.564 (extension lane default, CDP opt-in, pup-lanes skill, dashboard on ext).

pup_eval on the extension lane now returns exactly what the CDP lane returns: a string result stays a string even when its text is JSON (JSON.stringify(...) expressions came back as objects on this lane, which broke any caller written against the CDP contract, ab-smoke's dashboard check first). The worker tags the result type; the bridge reconstructs it. Carries 2.0.564 (extension lane default, CDP only on explicit lane:cdp, pup-lanes skill, dashboard on the extension lane).

Same as 2.0.563 (extension lane is the default; CDP only on explicit lane:cdp; pup-lanes skill) plus: pup_dashboard opens like every other pup window, on the extension lane on adom-you, with no profile and nothing from CDP (John, 2026-09-14: why does pup_dashboard even need cdp). The Node-era pup-dashboard profile is retired. ab-smoke on 2.0.563 had caught the dashboard being refused by the new cdp_lane_required rule.

The extension lane IS pup (John, 2026-09-14): it is the lane every vendor site loads on, so it is the default and the CDP lane opens ONLY on an explicit lane:"cdp". The silent fallback to CDP for profile/isolated/highFps/webSecurity requests is gone; such a request without lane:"cdp" is refused with cdp_lane_required and the fix. New user skill pup-lanes compares the two lanes with pros and cons, lists exactly which verbs need CDP, and states the cost of lane:"cdp" on adom-you. pup-taskbar-states no longer says the browser renders the name tile.

Extension lane: no more orphan about:blank windows. A lane relaunch or a concurrent open went through the worker's open action and left Chrome's startup window on the desktop (John, 2026-09-14). pup now sweeps, after every ext open and on each health tick, every window no session owns whose tabs are all about:blank, the same rule the CDP lane applies in close_orphan_blank_targets. Carries 2.0.561 (a session is matched to its own window by title) and 2.0.560 (thread tile rendered in the binary; stamp at birth and on re-adoption).

Extension lane: a session is matched to ITS OWN OS window by the active tab's title (Chrome titles a window ' - Google Chrome for Testing'), because one lane browser now hosts several threads' windows and 'the lane window' was ambiguous: 2.0.560's rebind bound one thread's session to another thread's window and then to a dead handle. With no title match pup leaves the session unbound and says so in pup_audit_icons rather than guess. Carries 2.0.560 (thread tile rendered in the binary; stamp at birth and on re-adoption).

Same as 2.0.559 (thread tile rendered in the binary; the extension lane stamps the live window at birth and on re-adoption) minus a dead 'tile' action left in the extension worker by an earlier revert.

The thread tile is rendered in the binary (John, 2026-09-14: 'it should just be in pup's rust binary. why would we use javascript?'). Until now the taskbar name tile was JavaScript evaluated inside whatever page the window was on, a leftover from the Node bridge that could not draw text; a strict Content-Security-Policy (claude.ai, the wiki) refused it and the button silently fell back to a nameless per-window icon. pup_identity::tile now lays out and rasterises the tile with fontdue from the same Familjen Grotesk Bold face (fg-700 converted to TTF), same layout rules, same plate, every ICO entry at its own pixel size; output verified pixel-for-pixel against the browser-rendered tiles on the laptop. The page-evaluation path, tile_js and the embedded woff2 are deleted. Also: the extension lane stamps the LIVE window before pup_open_window returns (birth used to bind Chrome's transient launch window), and recovery stamps a re-adopted window immediately; the 15 s health-tick rebind is now only a backstop. identity.rs was reconstructed after a bad restore this afternoon; all identity and verbs tests pass.

Extension-lane taskbar identity, second pass, from pup.log rather than theory. Birth bound the window to a TRANSIENT hwnd (the about:blank launch window Chrome replaces) and the stamp failed with 'not a valid window'; recovery then re-adopted the real window after each bridge restart but never stamped it; 2.0.557's late rebind only handled hwnd None so it skipped a window that was bound-but-unstamped. Now the health-tick rebind covers all three states (unbound, bound to a dead hwnd, bound but unstamped) and stamps. pup_audit_icons reads identity back from Windows through ab instead of trusting the in-memory app_id, which does not survive a restart and produced a false 'unstamped' finding on a correctly stamped window.

Taskbar identity regression in the extension lane, fixed (John, 2026-09-14: 'why is my windows taskbar icon just this? did you regress on the windows taskbar icons?'). An ext-lane window whose birth outran open_window_ext's 3 s hwnd wait (the 2.0.545 birth goes about:blank, identity shim, then the real URL, which can take longer on a cold browser) kept hwnd None for ever, so identity::stamp had nothing to stamp and the button wore Chrome's stock icon under its native per-profile AUMID. Three changes: (1) extdrive::rebind_unbound runs on every 15 s health tick and on pup_rescan, binding every unbound ext session to the lane window and stamping it exactly as a timely birth would; (2) pup_audit_icons now reports an unbound or unstamped session as a finding instead of zero findings; (3) pup_rescan judges ext sessions by the lane's liveness rather than a debug port they deliberately never have, so it stops calling a live ext window 'their Chrome is gone'. The birth wait is also 6 s. Carries 2.0.556's --disable-extensions-except bubble fix.

The real fix for the external-extension Action required bubble, replacing the 2.0.553 attempt. Diagnosis: on Windows, extension settings live in Secure Preferences under MAC protection, not in Preferences, so pre-seeding extensions.settings..ack_external (2.0.553) never landed and is removed as an approach. The registry-installed extensions (Adobe Acrobat efaidnbmnnnibpcajpcglclefindmkaj, Application Launcher for Drive lmjegmlicamnimmfhcmpkclmigmmcbeh) were confirmed present in adom-you Secure Preferences with location 6 (external registry) and unacknowledged, which is exactly the state that raises the bubble. Fix: every Chrome for Testing launch now passes --disable-extensions-except=<pup's own extension paths> alongside --load-extension, so only pup's toolbar extensions are enabled and Chrome's external registry providers do not install anything into pup profiles. Profile-scoped via launch flags; the machine registry is untouched.

Corrects a claim 2.0.552 through 2.0.554 shipped, and labels an unproven fix honestly. (1) WITHDRAWN: the statement that neither profile state nor cookie history is the discriminator for Akamai vendor sites. That rested on a warm-versus-fresh profile comparison, but isolated:true does not create a separate profile (it forces the CDP lane and the anonymous tile while the jar stays adom-you, filed as pup-bridge#112), so the comparison ran adom-you twice. Profile state is now documented as UNTESTED rather than excluded, across the root skill, pup-why-cft and pup-bot-walls. (2) The ack_external seeding added in 2.0.553 for the external-extension Action required bubble is retained but is UNVERIFIED: repeated readings of the same profile disagreed and extensions.settings read back empty, so there is no evidence it suppresses the dialog. Do not describe the bubble as fixed. (3) Carries forward 2.0.554's corrected 19-of-20 vendor-site score with analog.com intermittent, the measurement-hygiene section, pup_close_all_windows, and the em-dash sweep.

Skills updated with what today actually established, replacing what it only appeared to. (1) The 20-of-20 vendor-site score is corrected to 19 of 20: analog.com was denied as the 7th of 20 sequential loads having rendered fine on a single visit minutes earlier, and the clean run did not reproduce. analog.com is documented as intermittent under sequential load rather than solved. (2) New measurement-hygiene section in pup-browser-detection covering the five mistakes that produced four wrong causal stories in one day: comparing pup against a hand-rolled Chrome launch, reading window titles instead of screenshots, poisoning your own egress reputation by repeated probing, promoting a single passing run to documentation, and leaving orphaned Chrome processes holding profiles. Carries forward 2.0.553's ack_external fix for the external-extension Action required bubble, pup_close_all_windows, and the em-dash sweep.

Three fixes. (1) The Action required bubble: Chrome's ExternalInstallManager gates the 'Another program on your computer added an extension' dialog per-extension on extensions.settings..ack_external, NOT on the extensions.alerts.initialized flag pup was setting, so the old suppression never applied to it (John hit it again on 2026-09-14 for Application Launcher For Drive). prepare_profile now pre-acknowledges every machine-wide registered id, profile-scoped; pup still never edits the machine's registry. The registry read lives behind a new defaulted Host::external_extension_ids implemented only in host-win. (2) pup_close_all_windows is served instead of erroring not_in_rust_yet with no equivalent named, the same defect class as #108; it aliases onto close_window's existing all:true path, so it closes only the caller's own windows. (3) Em-dashes removed from the four pup skill files, 156 of them, per John's standing style rule.

Two corrections. (1) adom/pup-bridge#108: pup_list_sessions now resolves to the same caller-scoped implementation as pup_my_windows (registered passive, so it never launches a browser) and carries a catalog entry that survives regeneration, instead of erroring not_in_rust_yet while naming no supported equivalent. (2) WITHDRAWN across the root skill, pup-why-cft, pup-browser-detection and pup-bot-walls: the claim that matching CfT to the installed Chrome is what makes vendor sites load. That comparison was uncontrolled, every denied trial was a raw hand-rolled Chrome launch without pup's flag set while every passing trial was pup. Re-measured with screenshots on 2026-09-14, analog.com renders in pup on CfT 152 on both a warm profile and a brand-new isolated jar, so neither the build nor the cookie jar is the established discriminator. Keep the pin near the installed Chrome as hygiene, not as an explanation.

Correct the causal story for vendor walls in the skills: a stale Chrome-for-Testing did NOT break Akamai's bmak sensor. analog.com answered HTTP 403 from AkamaiGHost on CfT 148, which is a refusal at the HTTP layer before any page JavaScript runs; CfT 148 executes JavaScript fine. typeof bmak === undefined on a deny page is a symptom (the Access Denied page carries no sensor script), not the cause. The discriminator is the connection fingerprint (the TLS ClientHello differs between CfT builds); which element flips the verdict is not isolated. Corrected in the root pup skill, pup-why-cft, pup-browser-detection and pup-bot-walls.

A Chrome-for-Testing version bump now actually fetches the new build. detect_cft falls back to any cached CfT so an offline box still drives, but ensure_background short-circuited on that fallback, so 148 stayed cached and the pinned 152 was never downloaded. ensure_background now gates on the PINNED build: present = ready; missing = download it in the background while a cached fallback drives meanwhile, so a box upgrades on its own after a bump.

Match Chrome for Testing to the user's installed Chrome: CFT_BUILD_ID 148.0.7778.97 -> 152.0.7977.82 (the CfT build closest to the measured installed Chrome 152.0.7977.83). Pup drove CfT 148 while presenting 152 in the UA, a version mismatch that shows in the TLS ClientHello: the extension SET Chrome offers changes between 148 and 152 (post-quantum key share, ECH, cert compression roll in over versions), which is where the lane's JA4 diverged from real Chrome and where Akamai on analog.com keys. Matching the version makes the UA rewrite truthful and the ClientHello native-152. The box fetches 152 on the next pup_prewarm / ext open (~150 MB); the identity brand-list shim still runs because CfT omits the Google Chrome brand regardless of version.

Correction to 2.0.546's claim: the startup-promo bar was NOT suppressed by disabling the named features (read from a screenshot after the promotion, which was my error). The promo is field-trial gated; laneFieldTrials (default on) adds --disable-field-trial-config to the stock launch when off, the flag that removed the bar in 2.0.505. Whether that flag changes what analog.com's edge sees is measured before it becomes the default.

The stock lane launch keeps the UI-only suppressions. 2.0.545's stock flag set brought back the 'Chromium now launches when Windows starts' bar (John's 2.0.505 fix) and the sign-in promos, because it dropped the whole feature list. The startup-promo and sign-in features are disabled by name again; they change nothing on the wire. Field trials stay on, since --disable-field-trial-config alters feature rollouts and with them the request fingerprint that this launch exists to keep stock (analog.com denies the non-stock one).

analog.com loads on the extension lane. Measured on AdomLapper 2026-09-13: with the lane presenting the installed Chrome 152 on the wire and in JS AND launching with only the firewall guards (no QUIC, no Cast/mDNS) and everything else stock, analog answered its real page with the Akamai sensor running; the identity alone under the old flag set was still denied, so the launch flags (the TLS ClientHello they shape) were the decisive tell. laneStockFlags now defaults on. A cold launch goes to about:blank, applies the identity, and only then navigates, so the very first real request carries it (the launch page used to load before the rule existed).

JS identity shim that actually holds: navigator.userAgentData is a NEW object on every access in Chrome 148 (measured: navigator.userAgentData === navigator.userAgentData is false), so a property defined on one instance was lost and userAgentData.brands still read Not/A)Brand/99 Chromium/148 while the wire said 152. The shim now installs a Navigator.prototype.userAgentData getter that wraps the real object in a Proxy (brands, fullVersionList, getHighEntropyValues, toJSON), and userAgent/appVersion on the prototype too. Plus laneStockFlags (default off): an experiment lever that launches the lane with only the firewall guards (no QUIC, no Cast/mDNS listener) and everything else stock, so the TLS ClientHello is real Chrome's, for edges that still deny after every header matches (analog.com).

The extension lane presents the user's INSTALLED Chrome, on the wire and in JS. Measured via nbe on AdomLapper: the user's Chrome is 152 and sends Chromium;v=152, Not?A_Brand;v=24, Google Chrome;v=152, while Chrome for Testing 148 sent Not/A)Brand;v=99, Chromium;v=148 and analog.com's edge denied it as real Chrome passed on the same IP over the same protocol. The lane now rewrites User-Agent, Sec-CH-UA and Sec-CH-UA-Full-Version-List to the installed version with real Chrome's brand order and GREASE (consumerBrandsHeader pins the exact header), and a document_start MAIN-world shim (baked at staging) mirrors navigator.userAgent and userAgentData. The CDP lane's metadata uses the same order and GREASE, so both lanes match the user's Chrome.

A lane browser that outlives a pup update no longer runs the old extension unnoticed. The hello now carries the worker's versioned filename; pup_status.extensionLane reports workerVersion and stale, with a hint; and the health tick cycles a stale lane the moment no extension-lane window is open, so the next open stages the current extension (measured: worker.2-0-539 kept serving under pup 2.0.541, and the brand rewrite shipped in .540 never ran until the lane was cycled by hand). Also pup_clear_site_data {origin|origins}: cache, cookies, storage and service workers for an origin, through chrome.browsingData on the lane and Storage.clearDataForOrigin over CDP.

Apply the consumer brand rewrite at the session birth (2.0.540 hooked it into dress_window, which the session-based birth never calls, so it never ran). setBrands now reports whether Chrome accepted the declarativeNetRequest rule and how many dynamic rules are live, so a silently ignored header shows in the log instead of being guessed at.

The extension lane sends real Chrome's brand list. Measured on AdomLapper: Chrome for Testing's first request carries Sec-CH-UA without the Google Chrome brand ('Not/A)Brand;v=99, Chromium;v=148'), and analog.com's Akamai edge answers that first request with a live 403 (cache bypassed, cookies cleared, sensor never runs) while arrow, mouser and st accept the same jar, IP and UA. The control extension now installs a declarativeNetRequest rule rewriting Sec-CH-UA and Sec-CH-UA-Full-Version-List to what real Chrome sends, applied once per lane browser (consumerBrands, default on). The CDP lane already patched brands over CDP; this is the lane's own way to do it.

pup_clear_cookies {domain, names?} is wired (2.0.538 shipped its transport half only: a heredoc failure slipped past the ship gate). Drops a site's cookies in the window's jar, HttpOnly included, on either lane. Built to test and fix the analog.com case: loads on a fresh jar, Access Denied on adom-you, which points at Akamai's verdict cookie carried over from the CDP-lane visits.

pup_clear_cookies {domain, names?}: drop a site's cookies in the window's jar, HttpOnly included, on either lane (chrome.cookies in the control extension; Network.getAllCookies + deleteCookies over CDP). Built to test and then fix the analog.com case John keeps asking about: it loads on a fresh jar and answers Access Denied on adom-you, which points at Akamai's verdict cookie (_abck at -1) carried over from the CDP-lane visits, not at the browser as it is now.

No duplicate tabs. A recovery relaunch that raced a caller's opens re-added the saved tab list on top of the caller's tabs (ti.com twice, 33 tabs for 20 sites, John 2026-09-13). Two fixes: pup_open_tab on the extension lane de-dups by URL the way the CDP lane has since 2.0.478 (a second open of a URL the window already holds activates that tab); and a relaunch reopens its saved tabs ONLY into the window it made itself, never onto a newer window for the same id.

An extension-lane window survives a pup restart intact. On the 2.0.535 restart, recovery declared the lane gone two seconds after boot, before the extension's first heartbeat, KILLED the live browser ('ended 5 stale browser process(es)'), rebuilt the 20-tab window from its file, and then did it all again 17 s later because the orphan pass (CDP-shaped) removed the rebuilt session and the file pass (pid 0 reads as gone) relaunched it. Three fixes: readopt_ext waits up to 8 s for the first heartbeat when the lane's pids were re-attached; ext session files never enter the CDP reconnect, at boot or on the health tick, and are relaunched only when the lane is really dead; the tabless/orphan pass skips ext sessions.

The default lane logs in and downloads; nothing on it is a silent no-op any more. ab-smoke on 2.0.534 failed login and download because both go through resolve_tab, the seam every CDP-only verb uses, which found no CDP handle on an ext session and did nothing. resolve_tab now refuses an ext session loudly (lane_needs_cdp, saying what works here and how to opt into CDP), so all 25 CDP-only call sites fail visibly instead of silently. pup_login has an ext arm: the same locate/fill/submit scripts and the same wall detector (hoisted to WALL_JS), evaluated through the transport; realKeystrokes stays CDP-only. pup_download has an ext arm through chrome.downloads in the control extension, returning savedTo/filename/bytes in the same envelope.

The identity button shows the user's avatar. Chrome lets an extension set its action icon at any time (chrome.action.setIcon with imageData), so the identity extension now has a service worker that fetches the adom-you avatar through a new pup endpoint, GET /identity/avatar (pup fetches it server-side with its own token, cached 10 min, so the extension needs no host permission for wherever the avatar lives), draws it circle-cropped onto the family's teal tile at 16/32/48/128, and sets it as the button; refreshed every 10 minutes and retried every 30 s until pup answers. John: 'you should be showing my avatar up in your button in the chrome toolbar ... or can you just do it dynamically whenever you want?' Yes, dynamically.

An extension-lane session is re-adopted across a pup restart, never relaunched, while its Chrome window is still in the lane browser. Recovery's liveness check is CDP-based, which an ext window never satisfies, so a restart declared both ext sessions' Chrome gone and relaunched them as new windows beside the originals (the 17-tab proof window orphaned, a duplicate opened next to it). The session file carries windowId; the live tabs listing says whether that window still exists and which tabs it holds, and the session is rebuilt from that, at boot and on the health tick.

Two gaps from the 20-site proof. (1) A command in flight counts as alive: the worker does not poll while it executes a command, so a slow site's tab open (nordicsemi, ~30 s) stopped the heartbeat, alive() read the lane as dead, and the next three tab opens were refused with 'browser not running' while the browser was fine. Heartbeat window is 20 s and an in-flight command holds it. (2) A tab open that outlives the CLI relay is no longer lost: the ext tab wait is 20 s so it returns before ab's ~60 s relay, and refresh_all adopts any tab Chrome has in the session's window that pup does not track, the way the CDP lane's adopt_window_tabs does. 17 of 20 tabs were in the window; pup recorded 16.

No lane verbs, gated on the edit and the build this time (2.0.529 and 2.0.530 shipped without it). pup_ext_* are gone from the verb surface and every hint: a lane window is a pup window, driven by pup_open_window / pup_navigate / pup_eval / pup_screenshot / pup_open_tab / pup_list_tabs / pup_switch_tab / pup_close_window. Lane health is the extensionLane field of pup_status.

No lane verbs (2.0.529 shipped without this by mistake: an assertion fired before the edit was written). pup_ext_* are gone from the verb surface: a lane window is a pup window, driven by pup_open_window, pup_navigate, pup_eval, pup_screenshot, pup_open_tab, pup_list_tabs, pup_switch_tab, pup_close_window. Lane health is the extensionLane field of pup_status. SKILL.md and every hint updated.

No lane verbs. pup_ext_open/navigate/eval/tabs/tab/activate/screenshot/close/status/diag are gone from the verb surface (John: 'why am i still seeing you talk about verbs that have ext in them'). A lane window is a pup window: pup_open_window, pup_navigate, pup_eval, pup_screenshot, pup_open_tab, pup_list_tabs, pup_switch_tab, pup_close_window. Lane health (connected, lastPollMsAgo, processes, windows) is a field of pup_status. SKILL.md examples updated; the profile_owned_by_ext_lane hint no longer names removed verbs.

A killed lane reads as dead at once. alive() is heartbeat-based and a browser killed 3 s after its last poll still counted as alive for 7 more seconds, so the next pup_open_window took the warm path and waited 60 s on a dead channel until ab timed out (the first cold open of the 20-site proof, 2026-09-13; the retry two minutes later came up in 7.3 s). kill_extdrive now zeroes the heartbeat, and a warm open whose channel does not answer within 20 s falls back to a cold launch instead of failing.

lane:cdp takes the adom-you profile back from the extension lane, symmetric with the ext birth taking it from CDP. The two lanes cannot share one --user-data-dir (Chrome is one process per profile), so an explicit lane:cdp open on adom-you now closes the ext windows and launches CDP instead of failing with a raw profile_owned_by_ext_lane error. Default stays ext; lane:cdp is the opt-in for CDP-only features (iframes, trusted input, annotate).

captureVisibleTab needs : added it to the pup control extension so pup_screenshot works on the extension lane (it hit 'the or activeTab permission is required'). session_row now reports transport/lane so pup_list_windows and pup_status show which lane a window is on. Follows 2.0.525 making the lane a first-class session.

The extension lane is a first-class pup session. Session gains transport (cdp|ext, round-tripped through the session file); verbs/src/transport.rs is the ONE seam a verb reaches the page through (navigate, evaluate, screenshot, open/activate/refresh/close tab, close window), with a CDP arm and an extension-channel arm. pup_open_window picks the lane before any browser launches: defaultLane is ext, so a plain open is an extension-driven window on adom-you with no debug port; lane:cdp opts into CDP-only features (iframes, trusted input, annotate, highFps, isolation). identity's tile and badge are composed through the transport, so an ext window wears the same thread tile and the same 75% badge; list_tabs, open_tab, switch_tab, close_tab and close_window branch on the transport; recovery relaunches a window on the lane it was born on. pup_ext_* remain as aliases of the session verbs. This is the structural answer to John's 'why is the non-cdp lane a whole new set of code'.

Share the progress-bar code instead of the lane keeping its own. Extracted activity::progress_on_hwnd as the single implementation (the filling, running-average-estimated bar capped at 92% until work finishes, then 100% and cleared); with_progress is now a thin session-keyed entry point and the extension lane calls the same function with its window's hwnd. The lane previously hand-rolled a flat 35% bar and discarded ab's reply. Part of ending the pattern John called out: the lane reinventing code the CDP lane already has. Overlay (badge_js) and identity (stamp_hwnd) are already shared; progress was the remaining duplicate primitive.

One overlay composer for both lanes. The extension lane's badge (2.0.520/521) was my own full-bleed 32px PNG composed in the worker, ignoring everything identity::overlay already does: overlaySize (default 75, because at 100 the badge covers the thread tile's bottom line of text, John's 2.0.262 request), the adaptive contrast card, the generic fallback. It stamped over the tile's name. John: 'go look at your overlay icon code ... you fucked up the sizing on your overlays.' The lane now runs identity's badge_js through its own eval channel (it has no CDP), with the same second-rail fetch_favicon_oob fallback, and paints with the same desktop_taskbar call. The worker's private composer is deleted.

Give the nbe-in-pup button a DISTINCT icon; prune retired staged extension folders. nbe's own icon is byte-identical to pup's identity icon (both the teal two-teardrop glyph), so on the shared adom-you toolbar the identity and nbe buttons were indistinguishable and read as a duplicated, broken button (John: 'what the fuck did you do with the adom-you browser extension button'). The pup-staged nbe copy now carries a distinct browser-window mark (same teal family, same filenames so the manifest and the key-derived extension ID are untouched; tools/sync-nbe.sh re-applies it so a re-sync from nb's repo never restores the colliding icon). Separately, stage_extensions_lane now prunes any pup-*-extension folder no longer in the build, so a retired placeholder like pup-lane-extension cannot linger and add a stray icon.

Overlay badge: compose the favicon to a 32px PNG in the extension before handing it to ab. Raw favicon bytes worked for PNG-serving sites (st.com, mouser) and failed the moment a site served an ICO/SVG: digikey's badge was refused by ab's LoadImageW, so the button kept showing Mouser's M after the navigate. The CDP lane never hits this because badge_js draws onto a canvas and ships a PNG; the worker now does the same with createImageBitmap + OffscreenCanvas. Progress bar: use exactly the shape activity.rs sends (state normal with a value, then none) and log a refusal instead of discarding ab's reply, which is why the first cut could not say whether the bar ever showed.

The extension lane keeps the taskbar contract the CDP lane keeps. John: 'why are you causing flashing of the windows taskbar icon when we've been through this 100 times ... you're supposed to default to showing progress bars in the icon. and why do i not see the overlay icon'. The lane made none of the three ab calls the CDP lane makes. Now: an indeterminate progress bar on the lane's button while open/navigate/tab run, cleared after (honouring taskbarActivity and minimalTouch exactly as activity.rs does); the active tab's favicon painted as the overlay badge, fetched by the extension itself since this lane has no CDP to fetch it with; and clear_attention after each of those, which removes the tint Windows paints when it denies Chrome the foreground. That tint was the flash: pup never called desktop_flash_window for this lane, the OS did it.

Re-assert the lane window's size and normal state on every open. fit ran only when dress_window first dressed a window, so a window that later ended up minimized was never corrected: pup reported the lane up and John had nothing on his screen, three times now. Chrome's own saved placement was already the full work area, so this is purely the window being minimized at the OS level afterwards. chrome.windows.update with state normal also restores a minimized window, and it does it without raising anything, which is why this goes through the extension rather than ab geometry.

Complete the adom-you handover, and stop the portless launch from dumping tabs into another thread's window. 2.0.517 closed the CDP browser only if it was in ctx.browsers, which is EMPTY right after a pup restart while a Chrome from before the restart is still holding the directory (pup reconnects to those lazily). So the handover no-opped, the portless launch forwarded to that browser, and Chrome opened the lane's URL as a tab inside the kicad-bridge thread's window: John saw a tab appear in someone else's pup window, which is the exact discourtesy this project has a rule about. The profile's own DevToolsActivePort is the source of truth, so the lane now closes whatever is on that port and waits for SingletonLock to clear before launching. Also fixed pup_ext_status still reporting the retired adom-you-ext profile name.

The extension lane runs on adom-you. One profile, the user's real jar, which is what John has said all along should never be anything else: the separate adom-you-ext jar carried none of his cookies, logins or history (measured, 0.2 MB of History against adom-you's 6.3 MB), which is both a pointless divergence and the empty-profile shape bot walls score against. It was only ever separate because Chrome allows ONE process per --user-data-dir and this lane must run with NO debug port, so it cannot coexist with a CDP browser on the same directory. The lane now TAKES the profile: any CDP browser holding adom-you is closed first (otherwise the portless launch forwards to it and exits, silently handing back a window that still carries a debug port), and a CDP launch on adom-you while the lane owns it is refused with a hint to drive pup_ext_* instead of failing 30 seconds later on a missing DevTools port. Nothing is refused once the lane is closed.

Stop labelling the extension lane anonymous. The identity extension was picked with profile == 'adom-you' exactly, and the lane runs on adom-you-ext, so every lane window wore the anonymous tile: 'not signed in as you, isolated throwaway jar, logins here do not enrich adom-you'. That is false, the lane profile is pup-owned and durable, and John flagged the second-order cost too: a window that advertises itself as an empty throwaway is the profile shape bot walls score against. Any adom-you* jar now wears the signed-in identity. This corrects the LABEL only; the lane still keeps its own cookie jar, which is the substantive issue.

nbe always rides the extension lane; remove the nbeInLane flag. 2.0.509 hid nbe behind that flag because the lane looked dead with it loaded, which was wrong: the lane was equally dead without it and the real cause was pup wiping its own lane token in launch_extdrive (fixed in 2.0.513). The flag was never registered as a settings key either, so pup_configure silently ignored it and reported nbeInLane=None. John needs nbe's toolbar icon as the at-a-glance signal for which lane a window is on: three teal buttons means the CDP lane, four means the extension lane.

Adopt a running extension browser pup has lost track of. When nothing has been served since this pup launched and a browser on pup's own profile says hello with a lane token, pup takes that token instead of fighting it. That case is unwinnable otherwise: the browser is unkillable because pup no longer knows its pids (a restart, or a close whose kill missed the main process and deleted lane.json on the way out), and each new launch simply forwards to it and exits, which is the '1 process(es)' line that has haunted this lane all day. Adoption cannot hijack a working lane, because a working lane has served at least one poll.

Publish the lane token AFTER the stale-browser kill, not before. 2.0.510 taught kill_extdrive to clear EXTDRIVE_LANE, which is correct on its own, but launch_extdrive set the token first and called the kill afterwards, so every launch wiped the token for the launch it was preparing: the extension polled with the correct lane and pup compared it against an empty string and refused, forever. That is why the lane looked dead since 2.0.510 and why I wrongly blamed nbe, then the port.json memo. The /exthello line added in 2.0.512 printed the mismatch in one line: 'carrying lane ext-... (pup wants "")'.

Make the extension lane observable. It deliberately runs with NO CDP debug port, which is the whole point of the lane and also means that when its extension goes quiet there is no way to look inside: today the window launched, loaded all three toolbar extensions, sized and stamped correctly, and the control channel stayed silent with nothing anywhere saying why, so I was reduced to guessing. The extension now POSTs /exthello on every poll attempt BEFORE the lane gate, carrying the lane token it actually holds plus whether its port.json read succeeded, and pup logs it throttled to one line per distinct lane per 30s, saying plainly whether that browser may take work. A token mismatch is now a log line instead of silence.

Fix the poisoned port.json memo that made the extension lane permanently silent. packagedPort() memoized on 'if (_pkgPort !== null)' while its catch set _pkgPort = 0, so ONE failed first read (it races service-worker startup, and sweepBadges can trigger it before the drive loop) locked the memo forever: 0 is !== null so it never retried, and _pkgLane stayed empty, which pupExtPoll treats as 'not the drive browser' and returns. Measured on AdomLapper: the lane window launched, loaded all three toolbar extensions, was stamped and sized correctly, and lastPollMsAgo was never set. Only a SUCCESSFUL read is memoized now; a failure leaves the memo unset so the next tick retries. Also correcting the record from 2.0.510's note: pup_ext_diag attaches over CDP to the adom-you browser by design and never talks to the lane, so the 2.0.506 worker it reported was not cross-talk.

Re-attach to an extension browser that outlived the pup process. EXTDRIVE_LANE and EXTDRIVE_PIDS were in-memory only, so every bridge_install (which restarts pup) orphaned a running ext browser permanently: take_command_for rejects every poll while the token is empty, so the live extension could never re-attach, alive() stayed false, the next pup_ext_open launched a SECOND Chrome that forwarded to the running instance and exited at once (the '1 process(es)' line in the log), and pup_ext_close killed nothing because it knew no pids. Measured on AdomLapper: pup reported browserRunning:false while two of its own Chrome for Testing windows were on John's screen. This also invalidated every nbe measurement taken today, including the one that made me blame nbe for the lane being down. The lane token and pids are now parked in extlane/lane.json, restored at boot against live pids only, and cleared when the lane is closed.

Put the nbe side-load behind pup_configure {nbeInLane}, default off, so the extension lane works again while the cause is found. Measured on AdomLapper: with nbe in the --load-extension list Chrome for Testing spawns and exits within 6 seconds, no load-error dialog, where 2.0.506 came up every time. nbe itself stages correctly now (src/sw.js and the untouched 0.2.13 manifest verified on disk, and the staging sanity gate raises no objection), so the failure is in launching Chrome with it, not in the copy. Default off is the honest state until that is understood.

Fix the staging bug that made Chrome refuse nbe, and never hand Chrome an unverified folder again. tools/gen-assets.py listed only TOP-LEVEL files, so nbe's src/ and icons/ folders were dropped and the staged copy was a manifest pointing at a src/sw.js that was never written: Chrome answered with a modal 'Error Loading Extension ... Could not load background script' in John's face and loaded nothing. The generator now walks recursively, and the Rust staging creates parent directories before writing (it had ignored the failed write). Added a sanity gate: before a folder is passed to --load-extension pup checks that every file the manifest references (service worker, popup, icons) is actually on disk, and drops the folder with a log line instead of letting Chrome throw a modal.

Load the REAL nbe into the extension lane instead of my placeholder. John, correctly: 'i thought that was the whole point of me saying to you, just use the nbe inside pup'. On 2026-08-22 I agreed to add nbe as the 4th --load-extension and then wrote a 259-line control channel of my own instead; measured against nbe it has no click, type, dialog, upload, console or full-page capture at all, so it was a weak duplicate of code we already own. pup now stages nb's extension folder verbatim (src/extension-nbe, synced by tools/sync-nbe.sh, nb's repo stays the source of truth) and adds exactly one file: toolbar.json {toolbarIcon:on}, the packaged default nb built for pup on 2026-09-12 so the icon shows in a pup window while the user's own Chrome keeps Chrome's unpinned default. pup pins it, since an extension cannot pin itself and pup owns the profile. nbe's manifest is deliberately NOT version-stamped the way pup's own extensions are: nb's readiness compares per-profile extension versions and a rewrite would report the user's browser stale. Open question this ships to answer: whether Chrome for Testing finds the inc.adom.native_browser native-messaging host at all.

A fourth teal toolbar button on the extension-driven lane (John: 'i want a 4th icon showing in this bar that's teal and looks similar to your 3 browser extensions you load already so that i can differentiate between CDP lane pup windows and nbe lane pup windows'). New src/extension-lane: an MV3 tile in the existing toolbar family (the same teal rounded square and ink glyph as the dots, pen and identity marks), drawn as a browser window, with a popup saying what the lane is. It stages ONLY when a lane token is set, so three buttons means the CDP lane and four means the extension lane. Note for the record: pup loads no nb extension, so nothing of nbe's was involved; the buttons on a pup window are pup's own four extensions.

One shared DISABLE_FEATURES list across both browser lanes. The ext lane carried a hand-trimmed copy that had lost the startup-promo feature ids, so John saw Chromium's 'now launches when Windows starts so you can begin browsing instantly' bar on an extension window; it also never passed --disable-field-trial-config, which is what gates promos like that one. Both lanes now build their --disable-features from the same constant, so the two cannot drift again.

extdrive window sizing + taskbar identity + the CfT infobar. Three flags/paths the Rust ext lane never inherited from the CDP lane: --start-maximized (window opened at the profile's remembered ~60% width), --disable-infobars (CfT's 'only for automated testing' bar, which docs/WHY-CFT.md has always said pup suppresses this way), and dress_window running on every verb path instead of only the cold-launch path that returns early (pup.log had zero stamp lines). Identity now goes through the shared identity::stamp_hwnd so an ext window wears the same thread tile a CDP window does. Geometry goes through the extension's new fit action (chrome.windows.update, plain bounds, logical px both sides) rather than ab's desktop_set_window_bounds or a maximize, per the geometry rule: both of those raise the window.

extension windows get pup taskbar identity and placement

ext control channel scoped to its own browser via a per-launch lane token

extension lane gains tabs, screenshots and activation

pup_ext_eval awaits promises

extension service worker re-registered every release via a versioned script URL

extension updates load on existing profiles (manifest version stamp); --disable-quic back (no firewall prompt)

pup_ext_diag: read the extension service worker over CDP

extension-driven launch clears a stale browser and the profile lock first

make the extension control channel observable

the toolbar extension finds pup on any port (port.json), not just two hardcoded ones

extension-driven: restore network-quieting flags, real kill, fast open

no third-party extension prompt in a fresh pup profile

restore the takeover audit log and make pup_close everyone a user-only action

teach extension-driven mode in the pup skill (#109)

extension-driven mode: correct tab targeting, liveness and close (#109)

extension-driven windows: pup drives a Chrome with no CDP debug port (#109)

stockFlags setting: near-stock Chrome launch flags (#109 experiment)

ECH off again: it broke st.com/mouser on AdomLapper's network

a browser pin survives relaunch (pup_use actually takes) (#109)

cdpQuiet setting: skip the Runtime.enable CDP leak (#109 experiment)

consumer-Chrome transport (ECH+QUIC), languages, no pre-granted permissions, native-code EME shim (#109)

pup mirrors the installed consumer Chrome version in UA + client hints (#109)

restore Chrome sign-in/sync prompt suppression flags dropped in the Rust port

pup presents as consumer Google Chrome (UA brand + EME shim), unblocking Akamai brand walls (#109)

renderCheck ok:false + nbrowser hint on chrome-error pages; hide navigator.webdriver; pup_download fails fast or polls (#109)

a window never gains a duplicate tab for a URL it already has (pump + relaunch dedup)

Chrome never restores its own session (wipe tab-restore files); pup owns every tab

a bulk close cancels an in-flight restore instead of blocking on it

the restore drain waits for the whole batch (reservation set), not a single relaunch

a bulk close waits for an in-flight restore so no window lingers behind it

a window mid-restore ignores Chrome's auto-restored phantom tab

restart waits for an in-flight restore to finish; toolbar pen resolves _tabUrl to the foreground window

relaunch counter resets on success (no window given up after two good relaunches); _tabUrl prefers a live, recently driven window

pup_close deletes the session file before closing tabs (no ghost windows after an update); crash recovery runs the instant the browser socket closes

crash recovery drops every session before relaunching any (no dead tabs listed mid-recovery)

restart never re-attaches a relaunching window to another window's tab; file re-attach skips live tabs

A tab pup opens is tracked the instant it is attached, so recovery no longer duplicates tabs; adoption margin 1.5 s

pup_restart_browser returns at once with a restoring list; the relaunch runs on a helper thread

pup_restart_browser relaunches every window from its file synchronously and reports restored tabs; found by the soak on arav-rog

pup_restart_browser waits for the profile lock to clear so the next open succeeds

Idle browsers are released after a grace period (idleBrowserQuitMin, default 10) instead of holding a gigabyte forever

pup reports box RAM, free percentage and the cost of a tab back to the calling AI on every open and every survey

Wedged-browser watchdog with an honest toast, pup_restart_browser, and session files that carry every tab so a restart is lossless

A click never leaves the mouse button down: press and release are one unit, retried, and an orphaned press is released by the next mouse verb

Focus-emulation policy reaches the file-based re-attach path, converges on the health tick, and moves into Ctx so a session clone cannot clobber it

Focus emulation follows the active tab instead of every attached tab, so Chrome throttles and can reclaim background tabs

Esc always closes the annotation overlay: listener kept after a quick capture, registered on window, document and canvas, canvas focused when armed

Recovery adopts a window's other tabs at boot and reconnect; boot Page.enable off the blocking path

Adopting a discarded tab no longer blocks 30 s (page setup on a helper thread); attach_tab idempotent

Boot recovery repaired after 2.0.453: discovery replay ignored, adoption only into window-owning sessions, named sessions recovered first, no double re-attach, failures logged

Window survives its tab being replaced (tabless grace + re-attach by CDP window id); user-opened tabs join their window; toolbar pen resolves by _tabUrl

Every bundled SKILL.md parses as strict YAML (#103: pup-adom-wiki description folded); ship.sh aborts on an invalid frontmatter

Desktop recording guidance: ab's native GPU-accelerated recorder first, pup's Meet-style screen share as the broadly compatible fallback; in hints and skills

winAttentionFlash setting (default off) in the Settings dialog: the Windows attention flash on new windows, off = focus:false births

New windows created with focus:false: Chrome never asks Windows for the foreground, so no denied activation and no orange attention state on the button

Thread tiles drawn at every size Windows shows them (t10): each ICO entry rendered by the canvas at its own size, no resampling

Born wearing the tile: newborn stamped natively before Chrome's first show (watcher thread + in-process property store); window icon posted after commit

Born wearing the tile: newborn stamped natively before Chrome's first show (watcher thread + in-process property store); frame_windows_all + stamp_identity

Tile token hashes tile content (Node v2.0.271 parity): regenerated tiles keep their AUMID, no button rebuild under an open jump list; rolling pup.log file

Annotate this page from the jump list raises the window again (Node v2.0.293 user-caller rule); ralph asserts the raise

Closes verified against the OS window (ab WM_CLOSE fallback), orphan windows swept on connect; tile text width on the rounded plate

• v2.0.441 candidate (rust): Thread tiles through the brand raster pipeline (Lanczos3, IM unsharp, alpha clamp) in Rust on the Adom rounded plate; two lines, no ellipsis; tile generation t9 (John Lauer)
• Publish 2.0.441 (John Lauer)
• v2.0.440 candidate (rust): Windows placed in CSS pixels measured from the page and placed again once settled (Node v1.8.66 and v1.9.342): no overhang on scaled displays, no cascade drift (John Lauer)
• Publish 2.0.440 (John Lauer)
• v2.0.439 candidate (rust): Windows placed in CSS pixels measured from the page (Node v1.8.66), no overhang on scaled displays (John Lauer)
• Publish 2.0.439 (John Lauer)
• Update 3 file(s) (John Lauer)
• v2.0.438 candidate (rust): pup_open_window honours the declared owner (Node ownerSource declared); tile cache generation bumped so every thread tile re-renders with the multi-size renderer (John Lauer)
• Publish 2.0.438 (John Lauer)
• Update 21 file(s) (John Lauer)
• v2.0.437 candidate (rust): CSP-safe favicon badges, thread tiles rendered natively at every ICO size, one taskbar button born with the thread tile (no button during the first paint, then stamp and AddTab), focus handed back when a birth takes it, identity audit is a detector only (John Lauer)
• Publish 2.0.437 (John Lauer)
• v2.0.436 candidate (rust): CSP-safe favicon badges, thread tiles rendered natively at every ICO size, one taskbar button born with the thread tile (no button during the first paint, then stamp and AddTab), identity audit is a detector only (John Lauer)
• Publish 2.0.436 (John Lauer)
• v2.0.435 candidate (rust): CSP-safe favicon badges, thread tiles rendered natively at every ICO size, one taskbar button born with the thread tile (park first, settle, DeleteTab, stamp, AddTab), identity audit is a detector only (John Lauer)
• Publish 2.0.435 (John Lauer)
• v2.0.434 candidate (rust): CSP-safe favicon badges, thread tiles rendered natively at every ICO size, one taskbar button born with the thread tile (on-screen within 50 ms, ITaskbarList DeleteTab, stamp, AddTab), identity audit is a detector only (John Lauer)
• Publish 2.0.434 (John Lauer)
• v2.0.433 candidate (rust): CSP-safe favicon badges, thread tiles rendered natively at every ICO size, one taskbar button born with the thread tile (ITaskbarList DeleteTab, stamp, AddTab; the window is never hidden), identity audit is a detector only (John Lauer)
• Publish 2.0.433 (John Lauer)
• v2.0.432 candidate (rust): CSP-safe favicon badges, thread tiles rendered natively at every ICO size, one taskbar button born with the thread tile (stamped hidden, re-shown off-screen, attention flag cleared, then moved on-screen), identity audit is a detector only (John Lauer)
• Publish 2.0.432 (John Lauer)
• Publish 2.0.431 (John Lauer)
• v2.0.430 candidate (rust): CSP-safe favicon badges, thread tiles rendered natively at every ICO size, one taskbar button born with the thread tile (stamped hidden, re-shown off-screen, then moved on-screen), identity audit is a detector only (John Lauer)
• Publish 2.0.430 (John Lauer)
• v2.0.429 candidate (rust): CSP-safe favicon badges (data: before blob:), thread tiles rendered natively at every ICO size as 32-bit DIBs, one taskbar button born with the thread tile (stamped while hidden, shown once), identity audit is a detector only (John Lauer)
• Publish 2.0.429 (John Lauer)
• v2.0.428 candidate (rust): Overlay badges as Node painted them: 48 px compositor with Node's card rules, globe/PDF fallback instead of the Adom mark, favicon rails and retries on open and navigate, tab-switch and settings repaint triggers, paint signature, dashboard provenance (John Lauer)
• Publish 2.0.428 (John Lauer)
• Fix wiki browser skill YAML so Codex can load its metadata (John Lauer)
• v2.0.427 candidate (rust): Overlay badges as Node painted them: 48 px compositor with Node's card rules, globe/PDF fallback instead of the Adom mark, favicon rails and retries, tab-switch and settings repaint triggers, paint signature, dashboard provenance (John Lauer)
• Publish 2.0.427 (John Lauer)
• Update 12 file(s) (John Lauer)
• v2.0.426 candidate (rust): Z-order doctrine restored from Node: no activation at birth (the 2.0.425 attention clear removed), bottom-unless-foreground at every re-park with birth grace and the user-in-use latch, foreground:true opens honoured (John Lauer)
• Publish 2.0.426 (John Lauer)
• Update 9 file(s) (John Lauer)
• v2.0.425 candidate (rust): Taskbar activity contract restored from Node: taskbarActivity progress|flash|off (dead keys openFlash/autoFlash/agentActivity/fgWatch refused), attention tint cleared after birth, icon-apply and screenshot progress bars, alert = progress pulse, four-count flash only in flash mode (John Lauer)
• Publish 2.0.425 (John Lauer)
• Update 10 file(s) (John Lauer)
• v2.0.424 candidate (rust): Jump-list tasks work again: human callers (jump list, toolbar, dashboard) bypass window ownership as in Node; tools/jumplist-ralph.py fires every task through the real shim path; release profile thin LTO (John Lauer)
• Publish 2.0.424 (John Lauer)
• v2.0.423 candidate (rust): Jump-list tasks and taskbar relaunch call pup's own exe (--jumplist mode) instead of powershell.exe + a .ps1; explicit pup icon on every task; the .ps1 is removed at boot (John Lauer)
• Publish 2.0.423 (John Lauer)
• v2.0.422 candidate (rust): Launch Chrome with --no-startup-window (Node v1.8.51 rule) and close orphan about:blank targets on connect: no more stock Chrome for Testing taskbar buttons beside the thread tile (John Lauer)
• Publish 2.0.422 (John Lauer)
• v2.0.421 candidate (rust): Start Menu anchor row (aumidShortcut) in the dashboard Settings dialog; jump-list row names the measured cause of the first-click flash (ab#155, pup-bridge#101) (John Lauer)
• Publish 2.0.421 (John Lauer)
• Update 2 file(s) (John Lauer)
• Update 11 file(s) (John Lauer)
• v2.0.420 candidate (rust): Runtime data under ADOM_BRIDGE_DATA_DIR (profiles/sessions/screenshots/recordings, legacy dirs moved once) with retention (screenshots 14d/1GB, recordings 30d/3GB); aumidShortcut maps to ab 2.1.49 anchor:true/anchorFolder 'Adom Pup'; demo driver take-2 fixes; pup-bridge#98 #99, ab#155 (John Lauer)
• Publish 2.0.420 (John Lauer)
• Update 5 file(s) (John Lauer)
• plan: vault sync, demo tour, ab#155/#157 state (John Lauer)
• v2.0.419 candidate (rust): The pup demo tour (tools/pup-demo.py + the 8-beat Play-the-demo prompt); consent toasts carry reason/aiThread/delegate for ab->ah forwarding (ab#157); misrouted desktop_record_* answers wrong_bridge (ab#150); pup_login reports credentialSource on the 2FA/captcha path; aumidShortcut setting (ab#155 anchor). (John Lauer)
• Publish 2.0.419 (John Lauer)
• pup demo tour driver (tools/pup-demo.py) + the 8-beat Play-the-demo prompt; consent toast reason/aiThread; aumidShortcut setting; recorder misroute wording (John Lauer)
• v2.0.418 candidate (rust): aumidShortcut setting: opt-in Start Menu shortcut anchor so jump lists stay on the first right-click (ab#155). (John Lauer)
• Publish 2.0.418 (John Lauer)
• v2.0.417 candidate (rust): Fix: pup_vault_sync peer accepts a same-account desktop egress (container-empty), still refuses cloud containers. (John Lauer)
• Publish 2.0.417 (John Lauer)
• v2.0.416 candidate (rust): Fix: pup_vault_sync cross-desktop egress no longer hardcodes the app name (peer ab infers it). (John Lauer)
• Publish 2.0.416 (John Lauer)
• v2.0.415 candidate (rust): Fix: pup_vault_sync consent toast now carries Allow/Deny buttons (2.0.414 rendered none). (John Lauer)
• Publish 2.0.415 (John Lauer)
• credentials skill: the serve-from-the-vault doctrine + pup_vault_sync (never ask the human for a password) (John Lauer)
• v2.0.414 candidate (rust): pup_vault_sync {peer,reason}: bidirectional adom-you credential union across the user's desktops (newest-wins, pup-to-pup, no AI sees a password), one consent toast; internal vault_export/import refused for relay. (John Lauer)
• Publish 2.0.414 (John Lauer)
• 2.0.413: missing verbs + behaviors (assisted_click, import, fg-watch, url lint, notices, chrome-stable, eval frame, move_to_workspace), issue #97 (disable on-device model, reap by age, CONSERVATIVE auto-janitor), goldens 37->56, macOS unsupported in the exe package (John Lauer)
• v2.0.413 candidate (rust): SAFETY: the auto profile-janitor now reaps only leaked iso-* jars + strips the on-device model dir; named durable profiles are deleted only by an explicit pup_reap_profiles call (the 2.0.409-2.0.412 janitor auto-deleted idle named profiles, which was wrong). (John Lauer)
• Publish 2.0.413 (John Lauer)
• v2.0.412 (insiders): Rust exe parity (missing verbs + behaviors, goldens 37->56 all matching) and issue #97 (disable the 4 GB on-device Chrome model download, reap stale profiles by age + strip the model dir, daily janitor). (John Lauer)
• v2.0.412 candidate (rust): Rust exe parity (missing verbs + behaviors, goldens 37->56 all matching) and issue #97 (disable the 4 GB on-device Chrome model download, reap stale profiles by age + strip the model dir, daily janitor). (John Lauer)
• Publish 2.0.412 (John Lauer)
• v2.0.411 candidate (rust): Rust exe parity (missing verbs + behaviors, goldens 37->57) and issue #97 (disable the 4 GB on-device Chrome model download, reap stale profiles by age + strip the model dir, daily janitor); aligned credential_delete/card_set/record_status/screenshot_element/full_res/progress/deps/install_toolbar/annotate output shapes to the Node build. (John Lauer)
• Publish 2.0.411 (John Lauer)
• v2.0.410 candidate (rust): Rust exe parity (pup_assisted_click, import verbs, fg-watch, URL lint, session notices, real-Chrome install, pup_eval frame, move_to_workspace; macOS unsupported; goldens 37->63) AND issue #97: disable the 4 GB on-device Chrome AI model download on every launch, pup_reap_profiles sweeps stale profiles by idle age and strips the model dir, daily profile-janitor. (John Lauer)
• Publish 2.0.410 (John Lauer)
• v2.0.409 candidate (rust): Rust exe parity: pup_assisted_click, pup_import_scan/browser_logins, the fg-watch, URL lint, session notices, real-Chrome install, pup_eval {frame}, move_to_workspace; macOS declared unsupported in the exe package; goldens 37->63. (John Lauer)
• Publish 2.0.409 (John Lauer)
• 2.0.408 on insiders: recovered tabs get their page scripts back; plan status (John Lauer)
• v2.0.408 candidate (rust): pup as one Rust exe (spawn.kind exe): the Node runtime leaves the package. Parity gate green on the loopback and through ab; recovery through the session file's cdpPort, relaunch when Chrome is gone (boot + health loop), recovered tabs get the owner chip, floaty and login capture back; panic log; port bind retry; pup_close everyone:true; render_html hint on origin CSP. (John Lauer)
• Publish 2.0.408 (John Lauer)
• 2.0.407: the Rust exe ships to insiders; rust-build/ship candidate flow, parity + ab-smoke gates, plan and docs updated (John Lauer)
• v2.0.407 candidate (rust): pup as one Rust exe (spawn.kind exe): the Node runtime leaves the package. Parity gate green on the loopback and through ab; recovery through the session file's cdpPort, relaunch when Chrome is gone (at boot and from the health loop); panic log; port bind retry; pup_close everyone:true; render_html hint on origin CSP. (John Lauer)
• Publish 2.0.407 (John Lauer)
• v2.0.406 candidate (rust): pup as one Rust exe (spawn.kind exe): the Node runtime leaves the package. Parity gate green on the loopback and through ab; recovery through the session file's cdpPort + relaunch when Chrome is gone; panic log; port bind retry; pup_close everyone:true; render_html hint on origin CSP. (John Lauer)
• Publish 2.0.406 (John Lauer)
• v2.0.405 candidate (rust): pup as one Rust exe (spawn.kind exe): parity gate green on the loopback and through ab; recovery through the session file's cdpPort + relaunch when Chrome is gone; panic log; bind retry; pup_close everyone:true; screencast diagnostics. (John Lauer)
• Publish 2.0.405 (John Lauer)
• v2.0.404 candidate (rust): pup as one Rust exe (spawn.kind exe): parity gate green on the loopback and through ab; recovery re-attaches through the session file's cdpPort and relaunches windows whose Chrome is gone; panics land in ~/.adom/bridge-logs/pup-rust-panic.log; the port bind retries for 10 s; pup_close honours everyone:true. (John Lauer)
• Publish 2.0.404 (John Lauer)
• v2.0.403 candidate (rust): pup as one Rust exe (spawn.kind exe); every success carries success:true + the full JSON output so ab's relay and CLI unwrap it (found by the via-ab parity run); recovery re-attaches through the session file's cdpPort and relaunches windows whose Chrome is gone. (John Lauer)
• Publish 2.0.403 (John Lauer)
• v2.0.402 candidate (rust): pup as one Rust exe (spawn.kind exe); recovery re-attaches through the session file's cdpPort and relaunches windows whose Chrome is gone (_cleanupReport). (John Lauer)
• Publish 2.0.402 (John Lauer)
• v2.0.401 candidate (rust): pup as one Rust exe (spawn.kind exe): the Node runtime leaves the package; parity gate green; ship.sh gains --shell and --candidate. (John Lauer)
• Publish 2.0.401 (John Lauer)
• rust: Phase 4 parity gate (tools/parity.py) green 37/37 on winvm; Node response envelope ported into dispatch (verb catalog, bug invite, output mirror, render probe), session rows carry lastAgentUpdate/ownerSource/overlay/flash, loop cadences in pup_status, default permissions granted at launch, Hydrogen proxy (John Lauer)
• rust: Phase 3 complete (vault, cards, wiki auto-sign + view flip, annotate, tab + screen recording, highFps lease, download, identity audit, Hydrogen proxy); placeholder crates removed; plan status updated (John Lauer)
• Delete rust/record/src/lib.rs (John Lauer)

Thread tiles through the brand raster pipeline (Lanczos3, IM unsharp, alpha clamp) in Rust on the Adom rounded plate; two lines, no ellipsis; tile generation t9

Windows placed in CSS pixels measured from the page and placed again once settled (Node v1.8.66 and v1.9.342): no overhang on scaled displays, no cascade drift

Windows placed in CSS pixels measured from the page (Node v1.8.66), no overhang on scaled displays

pup_open_window honours the declared owner (Node ownerSource declared); tile cache generation bumped so every thread tile re-renders with the multi-size renderer

CSP-safe favicon badges, thread tiles rendered natively at every ICO size, one taskbar button born with the thread tile (no button during the first paint, then stamp and AddTab), focus handed back when a birth takes it, identity audit is a detector only

CSP-safe favicon badges, thread tiles rendered natively at every ICO size, one taskbar button born with the thread tile (no button during the first paint, then stamp and AddTab), identity audit is a detector only

CSP-safe favicon badges, thread tiles rendered natively at every ICO size, one taskbar button born with the thread tile (park first, settle, DeleteTab, stamp, AddTab), identity audit is a detector only

CSP-safe favicon badges, thread tiles rendered natively at every ICO size, one taskbar button born with the thread tile (on-screen within 50 ms, ITaskbarList DeleteTab, stamp, AddTab), identity audit is a detector only

CSP-safe favicon badges, thread tiles rendered natively at every ICO size, one taskbar button born with the thread tile (ITaskbarList DeleteTab, stamp, AddTab; the window is never hidden), identity audit is a detector only

CSP-safe favicon badges, thread tiles rendered natively at every ICO size, one taskbar button born with the thread tile (stamped hidden, re-shown off-screen, attention flag cleared, then moved on-screen), identity audit is a detector only

Fix pup-adom-wiki YAML header so Codex loads the skill. Skill package update; runtime and bridge update manifest unchanged.

CSP-safe favicon badges, thread tiles rendered natively at every ICO size, one taskbar button born with the thread tile (stamped hidden, re-shown off-screen, then moved on-screen), identity audit is a detector only

CSP-safe favicon badges (data: before blob:), thread tiles rendered natively at every ICO size as 32-bit DIBs, one taskbar button born with the thread tile (stamped while hidden, shown once), identity audit is a detector only

Overlay badges as Node painted them: 48 px compositor with Node's card rules, globe/PDF fallback instead of the Adom mark, favicon rails and retries on open and navigate, tab-switch and settings repaint triggers, paint signature, dashboard provenance

Overlay badges as Node painted them: 48 px compositor with Node's card rules, globe/PDF fallback instead of the Adom mark, favicon rails and retries, tab-switch and settings repaint triggers, paint signature, dashboard provenance

Z-order doctrine restored from Node: no activation at birth (the 2.0.425 attention clear removed), bottom-unless-foreground at every re-park with birth grace and the user-in-use latch, foreground:true opens honoured

Taskbar activity contract restored from Node: taskbarActivity progress|flash|off (dead keys openFlash/autoFlash/agentActivity/fgWatch refused), attention tint cleared after birth, icon-apply and screenshot progress bars, alert = progress pulse, four-count flash only in flash mode

Jump-list tasks work again: human callers (jump list, toolbar, dashboard) bypass window ownership as in Node; tools/jumplist-ralph.py fires every task through the real shim path; release profile thin LTO

Jump-list tasks and taskbar relaunch call pup's own exe (--jumplist mode) instead of powershell.exe + a .ps1; explicit pup icon on every task; the .ps1 is removed at boot

Launch Chrome with --no-startup-window (Node v1.8.51 rule) and close orphan about:blank targets on connect: no more stock Chrome for Testing taskbar buttons beside the thread tile

Start Menu anchor row (aumidShortcut) in the dashboard Settings dialog; jump-list row names the measured cause of the first-click flash (ab#155, pup-bridge#101)

Runtime data under ADOM_BRIDGE_DATA_DIR (profiles/sessions/screenshots/recordings, legacy dirs moved once) with retention (screenshots 14d/1GB, recordings 30d/3GB); aumidShortcut maps to ab 2.1.49 anchor:true/anchorFolder 'Adom Pup'; demo driver take-2 fixes; pup-bridge#98 #99, ab#155

The pup demo tour (tools/pup-demo.py + the 8-beat Play-the-demo prompt); consent toasts carry reason/aiThread/delegate for ab->ah forwarding (ab#157); misrouted desktop_record_* answers wrong_bridge (ab#150); pup_login reports credentialSource on the 2FA/captcha path; aumidShortcut setting (ab#155 anchor).

aumidShortcut setting: opt-in Start Menu shortcut anchor so jump lists stay on the first right-click (ab#155).

Fix: pup_vault_sync peer accepts a same-account desktop egress (container-empty), still refuses cloud containers.

Fix: pup_vault_sync cross-desktop egress no longer hardcodes the app name (peer ab infers it).

Fix: pup_vault_sync consent toast now carries Allow/Deny buttons (2.0.414 rendered none).

pup_vault_sync {peer,reason}: bidirectional adom-you credential union across the user's desktops (newest-wins, pup-to-pup, no AI sees a password), one consent toast; internal vault_export/import refused for relay.

SAFETY: the auto profile-janitor now reaps only leaked iso-* jars + strips the on-device model dir; named durable profiles are deleted only by an explicit pup_reap_profiles call (the 2.0.409-2.0.412 janitor auto-deleted idle named profiles, which was wrong).

Rust exe parity (missing verbs + behaviors, goldens 37->56 all matching) and issue #97 (disable the 4 GB on-device Chrome model download, reap stale profiles by age + strip the model dir, daily janitor).

Rust exe parity (missing verbs + behaviors, goldens 37->57) and issue #97 (disable the 4 GB on-device Chrome model download, reap stale profiles by age + strip the model dir, daily janitor); aligned credential_delete/card_set/record_status/screenshot_element/full_res/progress/deps/install_toolbar/annotate output shapes to the Node build.

Rust exe parity (pup_assisted_click, import verbs, fg-watch, URL lint, session notices, real-Chrome install, pup_eval frame, move_to_workspace; macOS unsupported; goldens 37->63) AND issue #97: disable the 4 GB on-device Chrome AI model download on every launch, pup_reap_profiles sweeps stale profiles by idle age and strips the model dir, daily profile-janitor.

Rust exe parity: pup_assisted_click, pup_import_scan/browser_logins, the fg-watch, URL lint, session notices, real-Chrome install, pup_eval {frame}, move_to_workspace; macOS declared unsupported in the exe package; goldens 37->63.

pup as one Rust exe (spawn.kind exe): the Node runtime leaves the package. Parity gate green on the loopback and through ab; recovery through the session file's cdpPort, relaunch when Chrome is gone (boot + health loop), recovered tabs get the owner chip, floaty and login capture back; panic log; port bind retry; pup_close everyone:true; render_html hint on origin CSP.

pup as one Rust exe (spawn.kind exe): the Node runtime leaves the package. Parity gate green on the loopback and through ab; recovery through the session file's cdpPort, relaunch when Chrome is gone (at boot and from the health loop); panic log; port bind retry; pup_close everyone:true; render_html hint on origin CSP.

pup as one Rust exe (spawn.kind exe): the Node runtime leaves the package. Parity gate green on the loopback and through ab; recovery through the session file's cdpPort + relaunch when Chrome is gone; panic log; port bind retry; pup_close everyone:true; render_html hint on origin CSP.

pup as one Rust exe (spawn.kind exe): parity gate green on the loopback and through ab; recovery through the session file's cdpPort + relaunch when Chrome is gone; panic log; bind retry; pup_close everyone:true; screencast diagnostics.

pup as one Rust exe (spawn.kind exe): parity gate green on the loopback and through ab; recovery re-attaches through the session file's cdpPort and relaunches windows whose Chrome is gone; panics land in ~/.adom/bridge-logs/pup-rust-panic.log; the port bind retries for 10 s; pup_close honours everyone:true.

pup as one Rust exe (spawn.kind exe); every success carries success:true + the full JSON output so ab's relay and CLI unwrap it (found by the via-ab parity run); recovery re-attaches through the session file's cdpPort and relaunches windows whose Chrome is gone.

pup as one Rust exe (spawn.kind exe); recovery re-attaches through the session file's cdpPort and relaunches windows whose Chrome is gone (_cleanupReport).

pup as one Rust exe (spawn.kind exe): the Node runtime leaves the package; parity gate green; ship.sh gains --shell and --candidate.

• plan: Phase 2 status (48 verbs native, recovery, identity, dashboard measured on winvm); dashboard favicon fallback (John Lauer)
• rust: dashboard page + SSE snapshot + image/action routes, /api/status, /identity, embedded MV3 toolbar extensions with --load-extension and pinned prefs, pup_dashboard verb (John Lauer)
• rust: taskbar identity through ab (tiles rendered by the browser, AUMID register+stamp, jump list, favicon overlay), reconnect learns the browser pid, close waits for Chrome to exit (John Lauer)
• rust: Phase 2 part 1 (tabs, input, dialogs, viewport, history, fetch, render_html, maximize; event pump; recovery + health loop; raise/lower/alert/progress; configure/use/quit_idle/rescan); measured on winvm incl. kill+restart recovery (John Lauer)
• docs/contract: golden fixtures recorded from the Node build 2.0.399 for the Rust port (John Lauer)
• rust: Phase 0 (contract fixtures, ab asks, workspace) + Phase 1 skeleton (core, host, host-win, host-mac stubs, cdp, browser, session, verbs, dashboard, bridge); measured on winvm: CfT up in 769ms, background window in 1.75s, eval/navigate/screenshot/close in the Node shapes (John Lauer)
• docs: first-run contract in the Rust plan (arav-rog findings), changelog 2.0.397-2.0.399, ship.sh publishes pkg before release (John Lauer)
• v2.0.399 (insiders): pup-bridge#94: canonical pup_screen_record_*/pup_recorder_* names for the Chrome screen-share recorder (desktop_* names stay as aliases until ab-core serves them natively, adom-bridge#143), recorder responses carry the naming/ownership hint. ship.sh publishes the skills pkg before creating the release (a release-born version row never gets the tarball, adom/wiki#188). Archive size shown when the download is reused. (John Lauer)
• Publish 2.0.399 (John Lauer)
• v2.0.398 (insiders): Chrome for Testing unpack could hang forever in puppeteer's in-process extract-zip (arav-rog: 3 files then silence for 7 min, the origin of the half-populated folders). pup now downloads only and unpacks in a supervised child process (OS tar first, extract-zip worker fallback) with a stall watchdog, verifies the exe, renames the .partial folder into place atomically; readiness shows a real unpack phase. (John Lauer)

• Publish 2.0.397 (John Lauer)
• v2.0.397 (insiders): First-run fix (arav-rog): npm install can no longer fail on puppeteer's postinstall Chrome download (.puppeteerrc.cjs skipDownload; pup provisions CfT itself), and every cache folder without an executable is pruned at warmup. pup-bridge#92: waits on a human answer blocked_on_user (consent registry, 45s in-verb / 120s toast, re-attach on re-call; assisted click; login 2FA/captcha walls). pup-bridge#93: desktop_record_* labelled as ab-core's, served by pup until adom-bridge#143. (John Lauer)

Promoted to public on 2026-09-04.

Promoted to public on 2026-09-04.

Insiders 2026-09-02: card vault + pup_fill_card with per-charge approval (#84), pup_credential_reveal gated on X-Adom-Verified-Origin (#82), consent toasts retracted on timeout, annotate Auto/Multi modes + Alt+Shift+M, temporary browser pins + _toolbarNotice (#81), identity audit log (#83), insiders tier (#86). Promoted to public on 2026-09-02.

• Publish 2.0.353 (John Lauer)
• v2.0.353: Native dialog handling actually works now: detection scanned only the legacy sessionId so it never fired for the zero-id and window-label callers that everyone uses, and a modal blocks EVERY pup window rather than its own, so pup_dialog now finds and answers the dialog wherever it is and the skill warns about it up front. (John Lauer)

• v2.0.300: Settings: real captures for the rest (John: 'you need screenshots in here'). Overlay badges shows a real on/off pair; badge size is four choice cards, each the real tile at that size; the jump-list examples are re-captured from the CURRENT menu (Owned by, view switches, Annotate, Open dashboard, Close ALL, Move to my workspace) with a crop per task row; the activity set re-captured in one session so all three share the same layout, and the flash card shows the real steady attention highlight (the earlier dark capture caught the flash mid-cycle). (John Lauer)

• v2.0.299: Settings: visual rows without a real capture yet say 'Screenshot pending' instead of leaving the user guessing (settings-layout: never fabricate). (John Lauer)

• v2.0.298: Settings: dashboard saves are bounded at 5s (AbortController) per settings-layout; optimistic DOM already reflects the click. (John Lauer)

• v2.0.297: Settings modal polish after reading the pixels: choice cards never upscale their real crops (1:1, identical zoom across the set, max 270px cards), sidebar parents carry a caret, row prose no longer duplicates the card prose, caption-bar example cropped tight to the strip itself. (John Lauer)

• v2.0.296: Settings dialog rebuilt to the Adom settings-layout standard (adom-ui-design 1.7.1): dismissible modal from the header cog (Escape, X, click-outside), 25% dim never blur, radius element never scrolls, house scrollbar, category sidebar with jump-to + scroll-spy over ONE continuous pane, sections > cards (3px teal accent, live status, full-sentence mechanism prose) > rows (breadcrumb names with teal last part, full key in title, Default on every row), house toggles (role=switch), dependent settings indented under a spine and dimmed never hidden, choice cards with one REAL screenshot per option for taskbar activity / grouping / icon style, two-click auto-disarming Restore defaults (new dashboard action), local-first optimistic saves that keep scroll position. Zero em-dashes. (John Lauer)

• ship.sh publish guard actually works now: the old 'publish | tail || die' tested tail's exit code (always 0) so a failed publish still shipped silently (how 2.0.295's row went up empty). Now captures the real exit code AND verifies the registry top row carries a tarball before the ship passes. Local repo folder renamed to pup-bridge; path refs updated. (John Lauer)
• Publish 2.0.295 (John Lauer)
• v2.0.295: pup-bridge#66 follow-up: the pup-dashboard --print-url direct-127.0.0.1 fix was pushed to the repo AFTER the 2.0.294 tarball published, so installs still got the localhost:7380/proxy form (the exact artifact-predates-fix failure shape ship.sh was just hardened against). No bridge-runtime changes; this ship exists to republish the skillpack tarball in lockstep with the fixed tools/pup-dashboard. (John Lauer)

• settings consolidation (2.0.292): document taskbarActivity as the single taskbar-activity control; remove openFlash/autoFlash/agentActivity/fgWatch from pup-settings; note fgWatch folded into notMineCaption; off-screen-birth intro (John Lauer)
• v2.0.292: Settings audit/consolidation (John): collapse openFlash + autoFlash + agentActivity + fgWatch into the single taskbarActivity control (progress|flash|off) + notMineCaption. fgWatch's foreground-STEAL purpose died with off-screen birth; its 20s self-foreground caption now honors notMineCaption. Fixed stale titleTag description (resolution is the SetProp tag now, not the title). Removed the 4 rows + their whitelist/defaults. (John Lauer)

• v2.0.291: Settings dialog: visual examples for the non-obvious settings John flagged — Taskbar activity signal (progress/flash/off, image switches with the choice), Caption bar on captures, and Adom toolbar in Chrome. Illustrations shipped in src/icons/settings-ex. Also de-em-dashed the taskbarActivity description. (John Lauer)

• v2.0.290: Foreground caption now shows FIRST then raises (awaited, was fire-and-forget so it trailed the window ~5s), and names the initiating AI thread + reason (John). Applies to pup_raise_os_window and the osRaiseSessionWindow choke point. (John Lauer)

• NEW skill pup-taskbar-progress + install/package wiring for the taskbar progress-bar feature (v2.0.289) (John Lauer)
• v2.0.289: Taskbar PROGRESS BARS instead of the orange flash (John): determinate bar on a window's taskbar button sized to the running-average duration of the operation (persisted per-op timing). Built-in for icon-apply (open until the icon lands) and screenshots; withTaskbarProgress() wraps any op. New setting taskbarActivity=progress|flash|off (default progress) gates the auto-flash. New skill pup-taskbar-progress. (John Lauer)

• v2.0.288: Honest log fix: the birth-resolved line said 'locked set-diff' but the capture is the unique-title method now (v2.0.287); corrected to 'unique-title capture, concurrency-safe'. No behavior change. (John Lauer)

• CORRECT the birth sequence: unique off-screen COORDINATES do NOT work (Windows clamps off-screen coords on-screen) - the code births at fixed -32000 and identifies by a UNIQUE TRANSIENT TITLE (v2.0.287), not coordinate. Removes a false claim I'd made to John. (John Lauer)
• v2.0.287: Concurrency fix: birth-time hwnd capture uses a UNIQUE transient title per window (set on about:blank pre-navigation) instead of the set-diff that refused when >1 window materialized at once. Fixes random per-window failures on multi-open (no handle -> window foregrounds + gets wrong/no icon; which window lost was nondeterministic). (John Lauer)

• pup-render-test: record the blank-occluded-thumbnail CONCLUSION - focus-emulation foregrounds (reverted), launch flags can't be leased, so occluded hover-thumbnails are left blank on purpose; pup_screenshot (CDP off-screen buffer) works on bg windows without foregrounding and reveal renders natively, so impact is only the hover preview (John Lauer)
• v2.0.286: pup_screenshot: if a capture ever brings the window to the FOREGROUND (a window-level fallback when CDP can't serve it) with no recent user input, caption ' · screenshotting' so the user always knows what put a window on their screen. No-op on the common CDP path (measured 0/101 non-foregrounding). John: uncaptioned screenshot-foregrounds are why he kept catching me. (John Lauer)

• v2.0.285: REVERT the focus-emulation blank-window fix (v2.0.280-284): Emulation.setFocusEmulationEnabled activated the OS window and foregrounded a background pup window (the exact focus-steal off-screen birth prevents), and did not reliably fix the blank thumbnail. Removed the birth call, the render lease, and its watchdog. Blank-occluded-window remains an open problem to solve WITHOUT touching OS focus. (John Lauer)

• v2.0.284: Render lease production value (5 min). Also documents the DWM-cache finding: a window renders while loading (focus-emulation on), DWM caches that frame so the taskbar thumbnail shows content thereafter; the lease keeps it fresh for 5 min then throttles for battery. (John Lauer)

• v2.0.283: Render LEASE (John's pick): a window keeps its render surface (thumbnail/reveal show content) for a lease after each interaction, then throttles to blank to save battery - mirrors the highFps lease. Reconciled by a watchdog. [shipped with 90s TEST lease to prove the cycle; 5min to follow] (John Lauer)

• v2.0.282: Blank-window fix v2: keep focus-emulation ON (retained), not a one-shot. Measured via DWM thumbnail that the one-shot failed (Chrome releases an occluded window's page surface, so the single frame is discarded). Retained focus-emulation keeps the composited surface alive so occluded thumbnails/reveals show content; static pages still idle (no continuous render). (John Lauer)

• NEW ralph render test (John's taskbar-hover method, automated): tools/ralph-render-test.ps1 captures the DWM thumbnail (ground truth for whether an occluded window PAINTED, without forcing a render like a screenshot does) + dev-skills/pup-render-test. Proven: DigiKey/TI render in background (distinct 13-14), a blank window ~9; pair with DOM bodyLen to tell a render bug from an empty bot-wall page. (John Lauer)
• v2.0.281: Blank-window fix is now a ONE-SHOT pulse, not continuous render (John: 'one rAF to get a rendering to occur'): pulse focus-emulation on for two animation frames then turn it OFF, so the window paints its content once (Chrome retains the last frame while occluded) then returns to throttled/idle. No ongoing CPU/battery cost. (John Lauer)

• v2.0.280: Blank-window fix (John's theory, measured): a window born off-screen then parked occluded had visibilityState:hidden with rAF not firing, so it never painted its first frame and looked blank. Enable Emulation.setFocusEmulationEnabled per-page at birth so the renderer composites content while occluded; static pages still idle (no issue-#14 battery drain, unlike highFps launch flags). (John Lauer)

• v2.0.279: Deterministic identity: tag confirmed handles via _ensureWindowTagged at every resolution chokepoint (bestSessionHwnd short-circuit + resolver cached/birth/property branches), guarded to fire once per handle. Fixes tags never being written because bestSessionHwnd short-circuited before the resolver. (John Lauer)

• v2.0.278: Deterministic window identity, wiggle DELETED (dev-skills/pup-no-wiggle): every window is tagged with a Win32 SetProp('AdomPupSid=') property at first resolve; lost handles are re-found by GetProp property lookup (no geometry, no nudge). Geometry bounds-matching and the off-screen re-capture nudge are removed from resolveSessionHwndByBounds. (John Lauer)

• NEW dev-skill pup-no-wiggle: HARD BAN on geometry/wiggle window identification (banned 3x, kept getting reintroduced). Mandates deterministic identity: birth mutex + unique off-screen coord + set-diff hwnd capture + <50ms on-screen move + Win32 SetProp('AdomPupSid=') window-property tag (VERIFIED cross-process persistent 2026-08-22) recovered via EnumProps after restart. Title is NOT the tag (pages overwrite it). (John Lauer)
• pup-taskbar-states: record John's decision to LEAVE the crash-recovery bare-icon edge as-is (rare, self-limiting) (John Lauer)
• skills: pup-vendor-login gains the BACKGROUND Google-SSO click recipe (classic full-page accountchooser is fully background-drivable via elementFromPoint+full-event-sequence; only the FedCM One-Tap bubble needs a real cursor - proven signing John into Autodesk 2026-08-22); pup-taskbar-states records the owner-loss->category downgrade CLOSED (v2.0.277 tileOwnerName) and the remaining crash-on-shared-profile bare-icon root (John Lauer)
• v2.0.277: Tiles mode: every window wears a NAME TILE, never a category glyph - an owner-less/recovered window (issue #70) now derives a stable name tile via tileOwnerName() instead of downgrading to the pup category icon (fixes John's inconsistent taskbar icons). (John Lauer)

• doctrine: reconcile placement with v2.0.276 off-screen-birth + <50ms park (measured 27ms, 0/95 foreground steal); delete focus-handback; off-screen banned only as resting/staging/fallback, sanctioned as a guaranteed sub-50ms birth transient (John Lauer)
• v2.0.276: Off-screen birth restored, moved on-screen within 50ms, handback deleted (John). Root cause of tonight's regression: 2.0.259 moved birth on-screen, which lets Chrome activate the window and steal the foreground on every open; 2.0.260's handback then called desktop_bring_to_front(prevFg), and on a machine full of pup windows prevFg is usually ANOTHER pup window, so it foregrounded pup windows with no caption (the parade John saw). Chrome/CDP expose no no-activate create option and WS_EX_NOACTIVATE is a documented dead-end, so the only lever is WHERE the window is born: Chrome does not activate a window that is off-screen. So birth is off-screen again (zero focus steal), then a single local CDP getWindowForTarget+setWindowBounds repositions it on-screen WITHOUT changing z-order in ~20ms (budget 50ms), so it is clickable from one frame in and can never be stranded. The handback is gone; the remaining focus check is a diagnostic that fires only if off-screen birth ever fails to suppress the activation. (John Lauer)
• Publish 2.0.276 (John Lauer)
• NEW user skill pup-why-cft (John: 'we made a sub-readme so folks like adrian understand it, but now i realize we have to explain it to the ai as well'). docs/WHY-CFT.md was written for humans and no AI thread could ever discover it: it is not a skill, has no trigger words, and until this morning the pup skills contradicted it. This skill is the doc's AI-discoverable form: the five dated reasons (banner, --load-extension removal as the forcing one, determinism, no consumer chrome, binary isolation), the honest trade-offs incl. no Widevine and the CfT window title, what did NOT change, and the note that stops anyone fixing launchCandidates() backwards. Wired into install.sh, files[], and the /pup skill map in the same pass, because tonight proved a capability that ships without its references rots. (John Lauer)
• Skill sweep, browser-policy pass: the /pup mental model and the entire /pup-browsers-and-chrome sub-skill still taught the mid-2026 native-first policy (drives the browser already on the machine, CfT is the last resort), which docs/WHY-CFT.md reversed for good on 2026-08-10 (automation banner; branded Chrome 137+ removed --load-extension, which the toolbar needs). Both now teach CfT-first with installed Chrome/Edge as the spawn-verified fallback ladder, which is also what pup_readiness reports on a live box (browserKind: chrome-for-testing). The stale native-first editorial in chrome.js is flagged in place with a warning note, with the base order deliberately unchanged because it IS the fallback ladder. Also: the no-semicolons pup_eval reminder in the screenshots skill updated for the 2.0.274 statement support. (John Lauer)
• install.sh: purge the pup-bridge mis-slug alongside the old adom-desktop-puppeteer-bridge one. A pkg-layer install had deposited the start-here skill under the PAGE slug as a second user-invocable copy, so the slash menu showed /pup AND /pup-bridge, and the duplicate served week-old text because this installer never refreshed it. John caught it from the slash list itself. (John Lauer)
• pup-adom-wiki: the Historical note was written in present tense (do not claim you can see logged-in features, you cannot) directly under the section saying logged-in is the DEFAULT since 1.9.162 - rewritten as actual history, keeping the one surviving rule (never drive the SSO form with the user's password). Quick-start examples gained --ai-thread, without which ab refuses the calls outright. pup start-here: the No-semicolons-in-pup_eval rule is obsolete since 2.0.274 (statement lists run via Runtime.evaluate; bad code now fails honestly). (John Lauer)
• pup start-here skill: truth pass against the shipped code. Fixed four stale claims: windows described as opening MAXIMIZED (they are born at the 10px-inset work area in normal state since the 2026-08-20 placement rules; OS-maximize raises and is never used), split described as the taskbar default (tiles has been the default since 2.0.152), the audit section expecting exactly 1 AUMID key (tiles registers one content-token key per live thread since 2.0.271, so the old expectation reads every healthy machine as broken), and the badge described as favicon plus Adom mark (mark removed 2.0.192). Also replaced the audit's title-based window ground-truth step with hwnd resolution, since titleTag is off by default and the titleContains probe matches nothing. (John Lauer)
• install.sh: ACTUALLY deploy pup-taskbar-states and pup-progress (both shipped in files[] but were never installed by this script, so installed copies drifted stale between pkg publishes). NOTE: the two previous commits' messages claimed fixes that had NOT landed — my edit scripts asserted on stale text and aborted BEFORE writing, but the push in the same shell block ran anyway, shipping unchanged files under fix-claiming messages. The skill fixes landed in the commit before this one; this commit is the installer. Lesson recorded: never chain edit-and-push in one step. (John Lauer)
• pup-taskbar-states, for real this time (the previous commit message claimed these fixes but the script aborted before writing): cite #53/#54 as CLOSED with #70 as the open gap, fix the internal wipe-vs-converge contradiction (line 51 still said wiped while line 38 said converges), add overlaySize (John Lauer)
• Skill truth pass, triggered by John running the slash commands himself: pup-taskbar-states cited two CLOSED issues (#53, #54) as open gaps, described plain mode as a wipe when it has been native-AUMID convergence since the two-CfT-buttons fix, omitted overlaySize, and predated the bounded nudge retry + minimize preservation. pup-settings still claimed an Adom mark on the badge (removed 2.0.192; only the generic fallback glyph keeps it). Both now match the shipped code, and #70 is named as the one genuinely open gap. (John Lauer)
• pup-settings: document overlaySize (the badge-size percent added in 2.0.262, default 75) and the two lower-level keys pup_status surfaces (aumidIcons, threadTiles). The user-facing settings reference was missing a setting that had already shipped, which is how a skill quietly stops being the source of truth. (John Lauer)
• dockbar.json: add launch.console=show for parity with the two verified reference bridges, so the install/serve step output is visible while the card starts instead of looking hung (John Lauer)
• v2.0.275: Close the AUMID registration race introduced with 2.0.271. Making the thread AUMID content-derived was right, but it created a new failure: if the shell builds a button for a brand-new AUMID BEFORE the IconResource write is visible, Windows caches 'no icon' against that AUMID and it stays blank forever, because the AUMID never changes again on its own. Measured on John's 'oven' button, which showed as a bare overlay badge on empty space while its .ico, its registry entry and its AUMID were all provably correct; only deleting the tile to force a fresh token brought the art back. The button rebuild now waits (up to 2.5s, then proceeds) until the AUMID's IconResource is present AND points at a real file, so the shell always has art to read at first paint. (John Lauer)

• v2.0.274: Fix the second half of adom/pup-bridge#69: pup_evaluate ran nothing and reported ok. The eval is new Function('return (' + expr + ')'), which is EXPRESSION-only, so the reporter's location.assign('...'); 'navigating' was a SyntaxError: nothing ran, the page never navigated, and the handler still answered ok:true with the failure buried in result.__error. Reproduced verbatim. Two fixes. On a syntax error the source is retried through CDP Runtime.evaluate, which has devtools-console semantics (accepts a statement list, returns the completion value), so the same code now works; a context destroyed mid-eval is treated as SUCCESS because it means the page navigated. And a failed eval is now a FAILED verb with errorCode eval_failed instead of ok:true wrapping __error, which was the exact lie this issue is about. Also confirms the switch_tab half: after 2.0.272 all four switches including repeats land on the requested tab with activated:true; the earlier partial result was measured against a session that had been reaped, not a real failure. (John Lauer)

• Publish 2.0.273 (John Lauer)
• adom/pup-bridge#66: ship the Dock Bar card. dockbar.json (manifest 1.2.0) at the repo root, a real favicon at the declared path, and pup-dashboard — the container-side status page serving /api/status in the SDK payload shape (per-LED label/state/detail/_hint plus our own top-level rollup, cached with an internal budget under the declared 2000ms). Honors the three SDK rules that broke both other bridges: serve self-backgrounds by spawning a detached child and waiting for the port the CHILD actually bound before printing it, every child process gets ~/.local/bin prepended, and a second serve detects the live instance and prints ITS url. (John Lauer)
• v2.0.272: Fix adom/pup-bridge#69: pup_switch_tab reported ok while never switching the tab on any background window. page.bringToFront() is the only thing that actually changes Chrome's visible tab and it was gated on session._foreground; pup windows are background by default, so the normal case updated pup's own activeTabId bookkeeping, never told Chrome, and still returned success:true, while pup_list_tabs (which reads Chrome's real state) kept reporting the old tab. Reproduced on AdomLapper against a 3-tab window: asking for tab-1, tab-2 or tab-3 all left Chrome on tab-2. The v1.8.26 rationale was 'only raise the OS window for a session the user is watching', which conflated activating a TAB inside a window with raising that window. The activation now always runs, and because Target.activate can pull a window forward, the user's focus is handed straight back with the same one-shot handback used at window birth in 2.0.259 (never a timer, never a loop, the window itself is never moved). The verb also VERIFIES the switch by reading visibilityState back from Chrome and returns activated plus an honest hint when it did not take, because a verb that says ok while nothing happened is the exact class this issue is about. (John Lauer)

• tools: wiki-issue-monitor.sh — the wiki-issue-loop live Monitor (John: 'do a monitor every 5 mins today'). Seeds on the current unread set so it cannot fire a 387-notification firehose, treats a failed poll as neither an event nor fatal, and marks items on repos this thread maintains. (John Lauer)
• v2.0.271: THE AUMID IS THE ICON CACHE KEY. John's Bills window showed category art while every link in pup's chain was provably correct. Measured in order on that one window: AUMID registered with IconResource pointing at the right .ico; the .ico itself rendering the Bills name tile at 16/32/48/256; threadTiles off/on full re-register -> unchanged; registration-epoch bump for a fresh ab cacheKey -> unchanged; WM_SETICON with the tile on the window itself -> unchanged; stamping a NOVEL AUMID string -> correct instantly. Windows caches a taskbar button's icon per AppUserModelID, so repointing a seen AUMID at new art is ignored and only a virgin AUMID can move it. THREAD_TILE_GEN already encoded that but is hand-edited, so it cannot react when a tile is re-rendered, which is exactly when the art changes. The thread AUMID now folds in a hash of the tile's CONTENT: identical bytes give an identical AUMID (stable across restarts, no button churn), a re-rendered tile gives a virgin AUMID and the shell is structurally forced to re-read the art. Wrong art becomes unreachable rather than something the audit has to catch after the fact. (John Lauer)

• v2.0.270: Wrong taskbar ART that pup swore was correct (John's Bills window). Established by measurement: the AUMID was registered, its IconResource pointed at the right .ico, the .ico itself rendered the Bills name tile correctly at all four sizes, the button was correctly NAMED Bills, and a full threadTiles off/on re-register did not shift it — yet the shell drew the category tile. Cause: ab caches icon HANDLES by cacheKey for its process lifetime, and the thread-tile cacheKey versioned only on tile GENERATION, which changes only when we bump it. A handle cached from an earlier stamp (category art, before the tile finished rendering) therefore served forever. The cacheKey now keys on tile CONTENT (mtime+size), so any re-render is automatically a new handle and a stale one is structurally impossible. Also closes the audit's blind spot honestly: it infers art from _buttonBuiltAt vs tile mtime and cannot read the glass, so it reported CLEAN while John looked at a wrong icon. pup_audit_icons gains {force:true} to re-assert every icon with a fresh epoch regardless of findings, and the clean-verdict hint now says outright that a clean model is not proof of correct pixels. (John Lauer)

• v2.0.269: Move Favicon overlay badges and Badge size directly under Taskbar identity (John: 'this should be near the Taskbar Identity section since its highly related'). They are part of the same decision — the identity picker's own six examples are literally 'tiles + overlay' vs 'tiles' — so having the overlay toggle sit fifteen rows below the picker that illustrates it was a discoverability bug, not just an ordering preference. (John Lauer)

• v2.0.268: Settings dialog: the sticky header was being painted over by the scrolling content. position:sticky with z-index:auto creates no stacking context, so later siblings that make their own (every .mic is position:relative) drew straight over the title and the close button. One line: z-index on .dlghead. (John Lauer)

• v2.0.267: Finish the settings overflow: the plain-mode preview strip is six 44px flex:none cards in a non-wrapping row, a hard ~298px floor that no shrinking elsewhere could beat. It was the last 49px of horizontal overflow and the remaining seam past texstrip's background. Now wraps and centers. (John Lauer)
• v2.0.266: Settings dialog layout pass (John: 'why does your settings panel look so awful?'). Three real defects, all measured live rather than guessed. (1) The 'default' pill floating over the dialog's X: .mdef was position:absolute inside .stlbl, which is not positioned, so it escaped to #dlg and parked in the corner; it is now a plain inline chip in the label with no positioning to get wrong. (2) The hard vertical seam behind the taskbar-identity choices: those rows wanted 516px inside a 439px strip, so the sample icons spilled past .texstrip's dark background; the row now wraps, the label shrinks from a rigid 175px to 150px, .sticons is shrinkable with min-width 0, and the plain-mode explainer's hard max-width:330px (the single biggest contributor to the 516) becomes a flexible basis. (3) The -7px badge overhang could clip against the strip edge, so .sticons carries matching padding. Audited every other absolutely-positioned class for the same escaped-ancestor trap; .mbcard is the only other one and its .mic parent is correctly relative. (John Lauer)
• v2.0.265: Tighten the Badge size row copy. Seen in the live pixels: the long description wrapped into a narrow six-line column beside the dropdown, which read as cramped next to every other sub-row. The setting is unchanged; only the label text is shorter. (John Lauer)
• v2.0.264: Add 75% as an overlay badge size and make it the default (John, after comparing 100/66/50 on real tiles). Because 2.0.263 turned the setting into a straight percent with a clamped parser, this is one value per surface rather than a new branch: default, dashboard dropdown, set-setting whitelist, pup_configure validation and the fallback in overlayScalePct. (John Lauer)
• v2.0.263: Overlay badge size becomes a real PERCENT and gains 66, now the default (John tried 50 and asked to try 66). overlayScalePct() parses and clamps the stored value to 25-100 so a bad value can never composite a zero-size, invisible badge, and adding another stop is now a one-word change rather than a new branch. Options 50 | 66 | 100 across the dashboard dropdown, the set-setting whitelist and pup_configure. (John Lauer)

• v2.0.266: Settings dialog layout pass (John: 'why does your settings panel look so awful?'). Three real defects, all measured live rather than guessed. (1) The 'default' pill floating over the dialog's X: .mdef was position:absolute inside .stlbl, which is not positioned, so it escaped to #dlg and parked in the corner; it is now a plain inline chip in the label with no positioning to get wrong. (2) The hard vertical seam behind the taskbar-identity choices: those rows wanted 516px inside a 439px strip, so the sample icons spilled past .texstrip's dark background; the row now wraps, the label shrinks from a rigid 175px to 150px, .sticons is shrinkable with min-width 0, and the plain-mode explainer's hard max-width:330px (the single biggest contributor to the 516) becomes a flexible basis. (3) The -7px badge overhang could clip against the strip edge, so .sticons carries matching padding. Audited every other absolutely-positioned class for the same escaped-ancestor trap; .mbcard is the only other one and its .mic parent is correctly relative. (John Lauer)

• v2.0.265: Tighten the Badge size row copy. Seen in the live pixels: the long description wrapped into a narrow six-line column beside the dropdown, which read as cramped next to every other sub-row. The setting is unchanged; only the label text is shorter. (John Lauer)

• v2.0.264: Add 75% as an overlay badge size and make it the default (John, after comparing 100/66/50 on real tiles). Because 2.0.263 turned the setting into a straight percent with a clamped parser, this is one value per surface rather than a new branch: default, dashboard dropdown, set-setting whitelist, pup_configure validation and the fallback in overlayScalePct. (John Lauer)