Pup - the AI's own browser

@@ -245,22 +245,35 @@ moment (200ms in or 2 minutes in) has nothing running against it and always stic loop that re-parks after the initial park — every such loop, no matter how clever (input-timing, short windows, stability watches), eventually yanks a real user's click. John proved each variant failed. -The full background open sequence (`tryDetachedLaunch` + `osBackgroundWatchdog`):+**THE FINAL ALGORITHM (v1.8.55, John-verified "those seemed to open nicely") — DIRECT APIs, one+tiny Win32 call, no PS window-hunting, no timers, no loops.** Lives in `tryDetachedLaunch` (flag) ++`parkSessionWindowDirect` + `osBottomUnlessForeground`:+ 1. Spawn with `--no-startup-window --window-position=-32000,-32000` (no `--start-maximized`).-2. Connect CDP; `newPage()` creates the window (off-screen, unfocused — the OS denied foreground).-3. ONE hidden-PS park: wait for the window to EXIST (EnumWindows @50ms, pid-list refresh only every-   500ms — refreshing every tick blew the process budget under parallel opens), then:-   - **Launch-gap escape hatch (v1.8.52):** FIRST check `GetForegroundWindow() == pup`. Because-     `--no-startup-window` means Chrome cannot raise itself, pup-foreground has exactly ONE possible-     cause: **the user clicked the taskbar button during the launch gap** (while the window was still-     at its off-screen coords, where activating it shows NOTHING — that was the "first 2 seconds the-     click does nothing" bug). In that case: `SetWindowPos(HWND_TOP, 0,0,scrW,scrH, SWP_SHOWWINDOW)`,-     leave the user's focus on it, report `user-foreground`, exit. This check is only valid BECAUSE-     of the launch flag — without it, pup-foreground is ambiguous and every heuristic fails (see-     dead ends).-   - Otherwise: `SetWindowPos(HWND_BOTTOM, 0,0,scrW,scrH, SWP_NOACTIVATE)`, self-verify, report-     `backgrounded`, EXIT. The open response awaits this verdict.-4. Nothing ever re-parks. `foreground:true` opens skip all of this and launch maximized on-screen.+   `tryDetachedLaunch` only sets `_needsPark` — there is NO window yet to manage.+2. Connect CDP; in launchSession `newPage()` creates the window (off-screen, unfocused — the OS+   denied it the foreground). **The park runs right here — the `await` on newPage IS the+   "window exists" event. No wait loop, no polling.**+3. `parkSessionWindowDirect(page, sessionId)`:+   - hwnd via **AD `desktop_find_window`** (native, matches the "(session: <id>" title suffix the+     welcome page just set; ~4 quick retries).+   - `osBottomUnlessForeground(hwnd)` — the ONE residual Win32 PS call (3 lines): reads+     `GetForegroundWindow()`; if it's the pup window, that can ONLY be a user's taskbar click+     during the launch gap (the launch flag makes Chrome self-raise impossible) → CDP places+     on-screen + AD `desktop_bring_to_front`, report `user-foreground`. Otherwise+     `SetWindowPos(HWND_BOTTOM, NOMOVE|NOSIZE|NOACTIVATE)` — z-order only.+   - **Geometry via CDP `Browser.setWindowBounds`** addressed by windowId — parking the WRONG+     window is structurally impossible (the PS EnumWindows/pid-hunt version parked a phantom under+     parallel opens and the window stayed invisible off-screen). Sequence: `normal` → move to+     primary monitor → **`windowState:'maximized'`** (OS-true full size; never compute pixels from+     `screen.availWidth` — the probe can fail mid-navigation and ships undersized windows).+   - **Self-verify POSITION** via CDP `getWindowBounds` (left/top > -5000), NOT focus — a+     focus-only verify passed while the window sat off-screen ("backgrounded" lie).+4. The open response awaits the verdict (`_bgPromise`); badge (`badgePupTaskbar`) + flash fire the+   INSTANT the park lands — no blind 1.5s/3.5s badge timers.+5. Nothing ever re-parks. `foreground:true` opens skip all of this and launch maximized on-screen.+6. Remaining AD gap (issue filed): a `send-to-back` window state; when AD ships it, delete+   `osBottomUnlessForeground` and pup is 100% PS-free.  **The 4 techniques (still true, now mostly belt-and-suspenders):** @@ -330,6 +343,17 @@ must clear it first.   a 50ms-reaction stability watch fought a click in the first 2s. The ONLY correct fix is   `--no-startup-window`: no steal can happen, so no loop is needed. If you think you need a re-park   loop, you have re-broken the launch flag — fix that instead.+- **`document.hasFocus()` (CDP) as the user-click signal** → LIES for CDP-created windows: reports+  internal focus even when the OS never foregrounded them. False-fired `user-foreground` on EVERY+  open (1.8.53). The only honest signal is Win32 `GetForegroundWindow()`.+- **PS window-hunting (EnumWindows / `MainWindowHandle` / pid+CIM child walks) to find the window** →+  heavy (~1-2s process+compile per park = the whole "first 2 seconds" gap) AND mis-resolved under+  parallel opens (parked the wrong/phantom window; the real one stayed invisible off-screen while the+  focus-only verify said "backgrounded"). CDP addresses the exact window by windowId; AD+  `desktop_find_window` resolves the hwnd natively. PS is for the one call with no direct API.+- **Computing "full-size" from `screen.availWidth` via page.evaluate** → the probe can fail+  mid-navigation and the fallback ships undersized (1600×900) windows. Use CDP+  `windowState:'maximized'` — the OS defines full-size. - **`WS_EX_NOACTIVATE` on the window** → Chrome self-activates anyway (so it doesn't fix R4), AND a   non-activatable window can't be brought up by a taskbar click (breaks R2). Rejected. - **Minimize→re-show loop as the focus drop** → on an on-screen window the minimize/restore is a visible