Pup - the AI's own browser

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.