Pup - the AI's own browser

@@ -124,8 +124,46 @@ ALPHA opens a window; BETA calls `browser_open_tab` with NO sessionId, then WITH **Expect:** first refused `no_target_window`; second refused `session_owned_by_another_thread`; ALPHA's tab count unchanged both times. +## 10. Jam-resilience under heavy load (the "pup looks frozen" test, 2026-07-28)+Root cause established live: John's "pup seems frozen" is USUALLY a **CDP jam, not a crash**. Under+heavy load (many heavy SPAs on the one shared Chrome + memory pressure) Chrome stays ALIVE (check+`Get-Process chrome` count — it's ~45, not 0) but every CDP verb times out. The pre-1.9.172+`browser_list_windows`/`browser_status` did uncapped CDP reads (`page.title()` + a focus `evaluate`)+SERIALLY per window, so ONE busy window hung the whole handler and the CLI returned `count: null` —+the frozen symptom. Fixed 1.9.172: both verbs gather sessions in PARALLEL with a 2.5s per-session+timeout and an in-memory `getSessionInfoFast` fallback; busy windows come back marked `degraded`.+**Test:** open 5-6 heavy windows (maps, earth.google, youtube, figma, diagrams), force memory+pressure (`browser_eval` pushing `new Uint8Array(1MB)` x50 per window), and hammer+`browser_list_windows` x15 WHILE the allocations run.+**Expect:** 15/15 return the full list (never `null`/timeout), each < ~2.5s; `_degraded` appears+only if a window is genuinely mid-jam. Proven 1.9.173: 15/15 live, 37-226ms, 0 null.++## 11. Crash self-heal + the reclaim race (2026-07-28)+Open 3 windows on the shared profile → kill EVERY `adom-you` chrome (simulates the real crash) →+do nothing 55s.+**Expect:** the health/heal loop (15s tick) relaunches every crashed session at its last URL,+signed-in, in the background — final window count == pre-crash count, with **0 "session not found"**+in the `[heal]` log. The not-found failure (seen on 1.9.171 under stress) was a RACE:+`reclaimUnmanagedWindows` reaped the crashed session + deleted its file before the heal relaunched+it. Fixed 1.9.172-173: disconnect stamps `_lastUrl`; reclaim skips `_lostBrowser` sessions for a+2-min heal window; recovery falls back to the cached URL. (The `[heal] relaunched OK` lines scroll+off a 50-line log read under load — the count-based check is the reliable proof.)++## 12. TORTURE (the "never crash" push, 2026-07-28)+The full brutal load, with an INDEPENDENT monitor thread proving pup never goes frozen mid-storm.+From thread `pup-monitor`, sample `browser_list_windows` every 3s for the whole run. From thread+`pup-torture`, open 6 heavy windows and run several rounds of {50MB alloc x6 + navigate churn to+earth/youtube}. Then settle 40s and check recovery.+**Expect:** the monitor's null/timeout count is **0** across every sample (pup is NEVER frozen to a+second, independent thread even while another thread hammers it); final count recovers; any Chrome+crash shows `[heal]` recovery, not stranding. This is the standing "push it to the limits" run —+re-run it after any change to the CDP/verb/heal paths.+ ## When a scenario fails Get the RAW error before theorizing (the parse-wrapper hides fields). Then check, in order: the-up-gate (was the bridge actually ready?), the log for `[park]`/`[flash]`/`[janitor]` lines, a-single sequential repro of the failing call, and only then the code. Two of the three "total-failures" on 2026-07-26 were the harness (npm window, outer timeout), not the bridge.+up-gate (was the bridge actually ready?), the log for `[park]`/`[flash]`/`[janitor]`/`[heal]` lines,+a single sequential repro of the failing call, and only then the code. Two of the three "total+failures" on 2026-07-26 were the harness (npm window, outer timeout), not the bridge. NOTE on+distinguishing jam vs crash: `shell_execute` still answers when only the CDP path is jammed (the+Node event loop is fine), so `Get-Process chrome | Measure` tells you alive-but-jammed (~45 procs)+vs actually-crashed (0) in one call — do this BEFORE assuming a crash.