Pup - the AI's own browser

@@ -109,6 +109,38 @@ loaded gun pointed at the user's click. - **A repair must not depend on the bookkeeping that the broken state destroys.** Resolving "which   session is this?" via the visible-window enumerator to fix an invisible window is circular; key   population-wide repairs off the owning PROCESS instead.+- **Never authorize a DESTRUCTIVE act on an inference when ground truth is one loop away**+  (v2.0.256/257, the day pup destroyed three of John's windows — see below). Killing a browser,+  clearing a lock, reaping an "orphan": before any of them, count the live sessions bound to that+  profile. If the answer is not zero, the thing you are about to destroy is the thing serving the+  user's windows.++## The window-destruction incident (2026-08-20) — read before touching any kill path++Two bugs, both the same shape: a destructive act authorized by a guess.++1. **The lock-file "orphan" kill** (the one that did the damage). Pre-launch cleanup kills whatever+   holds a profile's `SingletonLock`, reasoning "a lock exists and I could not reconnect, so the+   holder is a dead orphan from an unclean shutdown." But the reconnect gives up after a 3s probe ++   a 5s `puppeteer.connect`, and **a healthy Chrome on a loaded machine misses those deadlines.**+   So opening ONE new window on the shared `adom-you` profile killed the live Chrome hosting three+   windows — two other threads' dashboards and the window John was actively using. pup then+   relaunched them and reconciled them away as "closed", so from his side they simply vanished.+   Now: live sessions on the profile veto the kill outright; pup retries the reconnect patiently+   (20s) and adopts it, and failing that fails THAT LAUNCH rather than destroying other work.+2. **`refCount <= 0` kills.** #434 established "decide from ground truth, not the cached refCount"+   but converted only ONE of four call sites. The counter is provably wrong right after a restart:+   recovery re-creates the browser entry with `refCount: 0` and never counts the sessions it just+   restored. All four sites now go through `killProfileBrowserIfUnused`.++**The rule both bugs violate:** a failed launch costs a retry; a wrong kill costs windows the user+cannot get back. When those two are the options, always pay the retry.++**And a diagnosis trap from the same session, worth as much as the fixes:** a disconnected `--target`+returns a `target_not_found` ENVELOPE, not an error exit — so a parser reading `.sessions` off it+sees `[]` and you conclude the user's windows were destroyed again. They were not; the laptop had+briefly dropped off. Check `adom-bridge targets` before believing any sudden "everything is gone",+and never report a loss you have not confirmed against a CONNECTED machine.  ## ab 2.0.16 migration note