@@ -173,3 +173,139 @@ alone changes nothing.
   state.
 - Quality gate: clean-code, architecture, and QA lanes, since this is a protocol
   change with cross-repo consumers.
+
+---
+
+## A lost lease leaks a browser window
+
+**Baseline:** branch `dev`, commit `76eaf68`.
+**Found:** 2026-07-29, Phase 3b soak run 1.
+**Severity:** every device-loss incident strands a Chrome window that only a human will close. Compounds without bound.
+
+### What was observed
+
+The soak's device missed its heartbeat past `DEVICE_LOST_MS`, so the coordinator marked its lease `lost`. Hours later the server reported `used 1/2` and the side panel reported `1/2` — both correct — while **two** `example.com` windows were open on screen. Tab `2134210655` belonged to the destroyed lease and was never closed.
+
+### Why it happens
+
+Declaring a device lost sets `status = 'lost'` **and `release_at`** on its leases. But the closure list a device receives on sync, in `apps/backend/src/tenant-coordinator.ts:300`, is:
+
+```sql
+SELECT * FROM lease
+ WHERE device_id = ? AND status IN ('closing','expired') AND release_at IS NULL
+ ORDER BY created_at
+```
+
+`release_at IS NULL` excludes exactly the leases that were just released. The server frees the slot and considers itself done; the extension is never told to close the tab, so it doesn't.
+
+### Proposed fix
+
+Close the loop on reconnect rather than widening the query blindly — a `lost` lease has `release_at` set precisely because the server has finished with it, and other logic depends on that.
+
+**Recommended:** on device sync, send a separate *orphan* list — leases with `release_at` set whose device is now back — instructing the extension to close those tabs and forget the assignments. It is advisory, needs no acknowledgement, and is safe to repeat.
+
+*Rejected:* dropping `release_at IS NULL` from the closure query. Closures are part of the release handshake; feeding already-released leases into it would have the extension re-acknowledge closures the server has settled.
+
+**Also acceptable and complementary:** have the extension, on reconnect, close any controlled tab whose assignment the server does not acknowledge. That defends against the general case rather than this one path.
+
+### Verification
+
+- Coordinator test: a device that reconnects after its leases were lost receives the orphan list.
+- Extension test: receiving it closes exactly those tabs and leaves untracked user tabs alone.
+- Manually: force a device loss, reconnect, confirm no window survives and the count matches the side panel.
+
+---
+
+## Reconnect backoff does not survive service-worker eviction
+
+**Baseline:** branch `dev`, commit `76eaf68`.
+**Found:** 2026-07-29, inferred from soak run 1 timings. **Mechanism not yet proven** — see the test plan in `docs/plan-network-blip-resilience.md`.
+**Severity:** suspected cause of a six-second network blip costing every session on a device.
+
+### Evidence
+
+Both reconnect paths schedule with `setTimeout`:
+
+- `apps/extension/src/core/ws-client.ts:134` — `this.reconnectTimer = setTimeout(...)`, backoff 500 ms doubling to a 30 s cap (`:14`, `:15`).
+- `apps/extension/src/core/profile-client.ts:716` — `this.retryTimer = setTimeout(...)`, same shape (`:28`, `:29`). This is the **device control socket**, the one carrying the heartbeat.
+
+An MV3 service worker is evicted when idle, and a `setTimeout` dies with it. Losing the socket removes the very activity that was keeping the worker alive, so the pending retry is discarded at the moment it is most needed. Recovery then depends on the 30-second `ws-backstop` alarm (`apps/extension/src/entrypoints/background.ts:99`).
+
+That should still bound recovery near 30 seconds, which is why this is **suspected rather than established**: run 1's device stayed offline for minutes, not tens of seconds. Either the alarm was delayed, or reconnect attempts were firing and failing for another reason — DNS, in the incident that produced this. The test plan is designed to tell those apart.
+
+### Proposed fix (contingent on the test)
+
+Do not fix before the mechanism is confirmed; the wrong fix here is easy to justify and useless. If reconnection proves to be timer-death:
+
+- drive retries from `chrome.alarms` rather than `setTimeout`, accepting the 30-second floor, and keep `setTimeout` only for sub-30-second attempts while the worker is known alive;
+- treat the backstop alarm as the authority for "should I be connected", which it nearly is already.
+
+### Verification
+
+Reproduce per the plan, capture whether the worker was evicted, whether the alarm fired, and whether reconnect attempts occurred at all. Only then choose the fix.
+
+---
+
+## Ninety seconds without a heartbeat destroys every session on a device
+
+**Baseline:** branch `dev`, commit `76eaf68`.
+**Found:** 2026-07-29, Phase 3b soak run 1.
+**Severity:** design question for unattended operation, not a coding error.
+
+### The numbers
+
+`apps/backend/src/tenant-coordinator.ts:10-11`:
+
+```ts
+const DEVICE_OFFLINE_MS = 75_000;   // reported offline
+const DEVICE_LOST_MS    = 90_000;   // every lease on the device -> 'lost'
+```
+
+Ninety seconds is roughly four missed heartbeats (`HEARTBEAT_MS = 22_000`). Crossing it sets `status = 'lost'` and `release_at` on every lease the device holds — terminal, `410` to the consumer, work discarded, and a leaked window per the entry above.
+
+### Why it is a problem
+
+The tolerance is thinner than the recovery path it must accommodate. Recovery is gated on a 30-second alarm, leaving at most three alarm cycles of slack, and only if every one succeeds. Meanwhile the events that cause a gap this size are utterly routine: a VPN connecting, a Wi-Fi roam, a DNS change. One was enough on 2026-07-29 — and 1Password's socket, hit by the same event, was back in six seconds.
+
+For an attended session an operator notices and retries. An unattended fleet silently discards in-flight work.
+
+### Proposed fix
+
+**Recommended:** separate *capacity reclamation* from *lease destruction*. Freeing a device slot quickly is legitimate; destroying the consumer's session is a different decision that does not need the same deadline. Add a suspended state where the lease stops counting against capacity but remains adoptable if the device returns within a longer window, and destroy only past that.
+
+*Rejected:* simply raising `DEVICE_LOST_MS`. It trades one arbitrary number for another and delays capacity reclamation for every genuine loss to buy tolerance for transient ones.
+
+Consider alongside the reconnect entry above — a fix there reduces how often this threshold is reached, but does not make the threshold right.
+
+### Out of scope
+
+`DEVICE_OFFLINE_MS`. Reporting a device offline after 75 seconds is accurate and harmless; it destroys nothing.
+
+---
+
+## A leaked browser window is invisible to API monitoring
+
+**Baseline:** branch `dev`, commit `76eaf68`.
+**Found:** 2026-07-29 — the window leak above surfaced only because an operator looked at their own screen.
+**Severity:** an acceptance gate that measures less than its name claims.
+
+The Phase 3b soak checks `capacity_leak` as `deviceUsed > 1`, which is server-side accounting. In the observed leak that accounting was **correct** — the server had released the slot. The leak was entirely client-side, and no API-driven check can see it: nothing exposes how many tabs or windows the extension actually holds versus how many the server believes it holds.
+
+Any soak or monitor built on the public API therefore cannot enforce "no capacity leak" as written; it can only enforce "no server-side capacity leak".
+
+**Proposed fix:** have the device report its observed controlled-tab count in the heartbeat, and have the coordinator flag a divergence from its own lease count. That makes the leak detectable remotely and turns the gate into what it claims to be. Until then, treat the gate as partial and confirm tab counts visually during acceptance.
+
+---
+
+## Chrome's debugger banner appears across profiles
+
+**Baseline:** branch `dev`, commit `76eaf68`. **Chrome behaviour, not a defect in this repo.**
+**Severity:** an operator can detach the canary's debugger by accident, from a window they have no reason to associate with it.
+
+Attaching `chrome.debugger` shows the "controlled by automated test software" banner on windows belonging to **other Chrome profiles**, not only the controlled one. Confirmed by the canary operator as long-standing behaviour on this machine.
+
+`apps/extension/RUNBOOK.md` instructs operators not to click that banner's detach control, but the instruction reads as being about the controlled window. Someone seeing the banner over an unrelated profile may reasonably dismiss it there — detaching the canary and, per the reconnect entries above, potentially destroying its leases.
+
+It also means the banner is **not** a per-tab indicator of whether a given tab is under CDP control, so it cannot be used as a diagnostic. That mistake was made once already during this rollout.
+
+**Proposed fix:** documentation only. State in the extension runbook that the banner is process-wide, that dismissing it anywhere detaches the canary, and that it must not be read as evidence about a particular tab.
@@ -0,0 +1,168 @@
+<!-- Content type: How-to -->
+
+# Plan: diagnose and fix network-blip session loss
+
+**Baseline:** branch `dev`, commit `76eaf68`. Understudy version
+`e0673967-0ca5-4cca-81ee-50d4088cec33`. Extension `0.1.1` from
+`5cc969024b32380f1a3e14ff6f72e8d0c808b086`. Canary device
+`aaf119f2-a85f-46b4-8b53-8e92196d6275`, credential version 2.
+
+Line numbers are as-of that commit and must be re-confirmed before editing.
+
+## What happened, and what is actually established
+
+Phase 3b soak run 1 died 40 minutes in. `docs/unattended-production-rollout.md`
+holds the full record; the essentials:
+
+| Fact | How it is known |
+|---|---|
+| Tailscale activated its interface and **reconfigured DNS** at `06:02:16Z` | `journalctl`, inside the failure window |
+| A second long-lived socket (1Password's notifier) dropped at `06:03:00Z` and recovered at `06:03:06Z` | same journal — **six seconds** |
+| Understudy's device was still `offline` at `06:09:49Z`, lease already `lost` | soak sample |
+| The machine never slept and Chrome never restarted | four-week uptime, zero suspend records, Chrome process older than the soak |
+
+**The problem is not the outage. It is the recovery.** A six-second
+interruption that another application shrugged off cost this device every
+session it held, terminally, plus a leaked window.
+
+## What is NOT established
+
+Be careful here — two plausible mechanisms have already been written down and
+one has already been wrongly declared dead.
+
+1. **Timer death.** Both reconnect paths use `setTimeout`
+   (`apps/extension/src/core/ws-client.ts:134`,
+   `apps/extension/src/core/profile-client.ts:716`), which does not survive
+   service-worker eviction. But the `ws-backstop` alarm
+   (`apps/extension/src/entrypoints/background.ts:99`) fires every 30 seconds
+   and calls `ensureConnection`, which *should* bound recovery near 30 seconds.
+   It did not. So either the alarm was delayed, or attempts were firing and
+   failing.
+2. **DNS.** The trigger was a DNS reconfiguration, not a plain link drop. If
+   resolution for `understudy.proofof.tech` stayed broken or poisoned inside
+   Chrome for minutes, reconnect attempts would fail no matter how promptly they
+   were scheduled. 1Password may well have been holding an established
+   connection or a cached address, which would explain its six-second recovery
+   without contradicting this.
+3. **Backgrounded Chrome / MV3 eviction.** Still open. An 18-minute attempt to
+   test it was **invalid** — the operator was switching windows throughout, so
+   the condition never held. Do not cite that run as evidence in either
+   direction.
+
+The tests below are designed to separate these, not to confirm a favourite.
+
+## Sequencing
+
+**These tests destroy any running soak.** Breaking connectivity is exactly the
+condition that kills a lease. Either let the current soak finish and record its
+result first, or accept restarting it — do not run both and then argue about
+which caused what. Phase 3b's clock restarts either way.
+
+## Instrumentation
+
+The monitor cannot live on the machine whose network is being broken. It does
+not need to: **the recovery latency is measurable from the server side alone.**
+
+- `t_break` and `t_restore` are chosen by the operator, so both are known exactly.
+- `GET /v1/devices` returns `lastSeenAt`. Polls during the outage fail; that is
+  fine. The first poll after `t_restore` whose `lastSeenAt` is fresh (< 30 s old)
+  gives `t_device_back`.
+- **`recovery_latency = t_device_back − t_restore`** is the number this plan
+  exists to produce. Run 1 implies minutes. Anything above a few seconds is the
+  defect.
+
+Capture at the same time, because they discriminate between mechanisms and only
+an operator at the machine can see them:
+
+- `chrome://extensions` — does the card read `service worker` or
+  `service worker (Inactive)` during the outage? Answers eviction directly.
+- The service-worker console — are reconnect attempts logged during the outage,
+  and do they fail with a DNS error or a connection error? Answers 1 versus 2.
+- The side panel's local event log, which survives longer than the console.
+- Tab and window count afterwards, for the leak.
+
+## Test A — pure connectivity loss, DNS untouched
+
+Isolates "does reconnection work at all" from anything DNS-specific. Block
+egress to the service without disturbing the resolver:
+
+```bash
+# resolve first so the rule pins addresses, not names
+getent ahosts understudy.proofof.tech
+sudo iptables -I OUTPUT -d <each-resolved-ip> -j REJECT
+# ... wait the test duration ...
+sudo iptables -D OUTPUT -d <each-resolved-ip> -j REJECT
+```
+
+Run at **10 s, 30 s, 60 s, 120 s**, with a live session each time, recording
+`recovery_latency` and whether the lease survived.
+
+Expected if healthy: recovery within a few seconds of restore at every
+duration; the lease survives 10 s and 30 s, and is `lost` at 120 s by policy
+(`DEVICE_LOST_MS = 90_000`).
+
+The interesting failure is a **short** outage producing a **long** recovery.
+That is run 1's signature and points at mechanism 1.
+
+## Test B — replicate the actual trigger
+
+```bash
+sudo tailscale down    # observe
+sudo tailscale up      # observe
+```
+
+Same measurements. This reconfigures DNS, which Test A deliberately does not.
+
+- Test A clean, Test B slow → the problem is DNS-specific, and the fix is about
+  resolution and connection re-establishment, not timers.
+- Both slow → reconnection is broken generally; timers or alarm delivery.
+- Both clean at every duration → the mechanism is not reproducible this way, and
+  the next suspect is sustained backgrounding, tested properly this time: machine
+  genuinely untouched, Chrome fully occluded, sampled from elsewhere.
+
+## Fixes, chosen after the tests and not before
+
+Deliberately not pre-committed — the wrong fix here is easy to justify and
+useless, and two mechanisms are still live.
+
+**If timer death (1):** drive retries from `chrome.alarms` rather than
+`setTimeout`, keeping `setTimeout` only for sub-30-second attempts while the
+worker is known alive, and treat the backstop alarm as the authority on whether
+a connection should exist — which it nearly is already.
+
+**If DNS (2):** the socket must be re-established in a way that re-resolves
+rather than reusing a poisoned or cached answer, and repeated resolution failure
+must not push the backoff to its 30-second cap and stay there.
+
+**Independent of both, and worth doing regardless** — these are already recorded
+in `DEFERRED.md` and are what convert a blip into destroyed work:
+
+- **Ninety seconds destroys every session on the device.** Separate capacity
+  reclamation from lease destruction: free the slot promptly, but keep the lease
+  adoptable for a longer window and destroy only past that.
+- **A lost lease leaks a browser window.** Send an orphan list on device sync so
+  the extension closes tabs for leases the server has already released.
+
+Fixing recovery lowers how often the cliff is reached. It does not make the
+cliff the right shape.
+
+## Verification
+
+- Test A at 10 s and 30 s: lease survives, `recovery_latency` within a few
+  seconds, no leaked window.
+- Test A at 120 s: lease is `lost` **by policy**, and — once the leak fix lands —
+  no window survives.
+- Test B: indistinguishable from Test A at the same durations.
+- A soak that spans at least one real network transition without losing its
+  session.
+- Quality gate on any code change: clean-code, architecture, and QA lanes.
+
+## Out of scope
+
+- `DEVICE_OFFLINE_MS`. Reporting a device offline at 75 seconds is accurate and
+  destroys nothing.
+- The heartbeat interval. 22 seconds is not implicated; the heartbeat was fine
+  until the socket went away.
+- Metamind. Its sweep already handles a terminal understudy session correctly —
+  it settles the lease rather than retrying forever. Nothing here needs a
+  consumer change.