{
  "summary": "Production-log forensics conclusion: the strongest freeze root is the v0.30.4 non-draining resume subscription deadlock, not peer-dial churn or PTY echo verification. The source itself records the causal chain: `resume_sessions` subscribed the supervised daemon brain's request/reply connection to live PTY output even though that brain did not continuously drain output; output backed up; the broker subscriber writer held the connection's single `SharedSend` path across a blocking write; heartbeat `net_status()` / `sessions()` replies were then starved on the same connection. This is explicitly called the “v0.30.4 field re-wedge” at `crates/spt-daemon/src/brain.rs:1036-1049` and “SharedSend self-deadlock that re-wedged v0.30.4” at `crates/spt-daemon/src/brainproc.rs:193-199`. v0.30.5 changed the supervised brain to cursor-only resume (`brainproc.rs:193-203`; CHANGELOG.md:33-47). v0.30.6 then bounded and canceled every physical connection write so any still-black-holed controller/viewer is retired instead of freezing the daemon (`CHANGELOG.md:12-31`; `broker.rs:1325-1384`).\n\nTimestamp limitation: neither stderr file prefixes records with wall-clock time. The only reliable cadence anchors are `PAIR_MEET_UP ... step=N`, which are 30-second TOTP steps. Converting `step * 30` to UTC gives step 59456230 = 2026-07-10 12:35:00Z, step 59456297 = 13:08:30Z, step 59456308 = 13:14:00Z, step 59456345 = 13:32:30Z, and step 59456424 = 14:12:00Z. Events between two step lines can only be assigned to that 30-second window, not an exact instant. There is no operator-supplied freeze timestamp in the evidence, so the logs cannot prove that any particular event window coincided with the human-visible freeze.\n\nCadence and co-occurrence:\n- `CONN_WRITE_POISONED` is absent from the rotated log and first appears in the current log at `daemon.stderr.log:16314`, immediately after candidate v57 promotion and five session resumes at lines 16299-16307. From step 59456230 onward, it repeats in every sampled 30-second meet window, typically 2–6 times per step, with no multi-minute quiet period: lines 16314-16323 (five poisons in the first window), 16330-16339 (five in the next), 16431-16436 (five), 16584-16589 (five), 17168-17188, 17776-17783, and still at 18725-18768 / steps 59456421-59456424. Thus the protected post-v0.30.6 system is continually encountering black-holed/failed physical consumers for at least ~97 minutes (12:35 through 14:12 UTC), but is retiring them rather than indefinitely blocking. These lines are protective aftermath/diagnostics, not evidence that poison handling causes a freeze.\n- `PUMP_PEER_FAIL ... submit-dial exceeded the 10s bound` is high-rate ambient churn. It appears throughout the rotated pre-poison log (`daemon.stderr.log.1:137,260,267-268,390,505-507,623,738,745-746,777,892,1094-1096`) and continues before and during the current poison storm (`daemon.stderr.log:36-38,45-47,60-62,69-70,77,85-86,93`; then 16315-16319, 16331-16335, 16421-16424, 16597-16602, 17168-17174, 17776-17783, 18725-18768). It is independently bounded at 10 seconds and occurs against several peer hashes, especially `ecb39e...`; reachable meet activity continues every 30 seconds. This falsifies “one slow peer serially freezes all work” for these versions and matches the v0.30.2 release change to concurrent independent peer outcomes (`CHANGELOG.md:89-101`). It can add load and align with protected write retirement, but the evidence does not place it on the PTY/controller lock path.\n- PTY settle timeouts are intermittent and bounded, not multi-minute stalls. Enumerated anchors show 27 observed current-log timeouts and 20 rotated-log timeouts: current lines 50,127,331,342,2321,2348,2933,3006,3265,4249,4381,4753,4954,5598,6493,6651,6677,7735,9607,10048,16131,16446-16447,16632,17171,17779-17780; rotated lines 124,975,1239,1530,2200,4217,4574,4734,4961,5330,5538,6087,9800,10362,10395,13858,14057,14226,16555,17756. Each line explicitly says it waited 400 ms and is “proceeding.” The implementation confirms a bounded deadline and returns false (`broker.rs:1928-1960`). At current lines 7722-7735, liaison probes tickets 13–22 every ~40 ms, every PTY write completes in 3–7 microseconds, yet no ring high-water advance occurs before the 400 ms timeout; that is positive evidence of an unobservable echo, not a blocked PTY writer.\n- Echo re-drive/loud-spool is rare relative to settle timeout and is a non-default confounder because this daemon has `SPT_INJECT_VERIFY_ECHO` enabled. Only three `INJECT_ECHO_MISS` events and one terminal loud spool are observed: flynn lines 925-927 re-drives then `INJECT_HEAD_LOSS_SPOOL`; doyle lines 2319-2321 and 2346-2348 re-drive once but then only settle-timeout. The implementation says echo verification is default-off and only valid for harnesses known to echo (`broker.rs:2164-2176`); a miss causes exactly one retry, then recoverable loud respool (`broker.rs:2210-2270`). This can duplicate/re-spool an individual message and add ~400 ms settle cost, but the observed bounded behavior does not explain a multi-minute global PTY freeze.\n- Viewer/controller black-hole events are freeze-capable. Historical `BRAIN_SUBSCRIBER_STALL_EVICT` records occur at current lines 2177, 2349-2350, 3036, 3851 and rotated line 24303, each explicitly reporting a controller writer blocked >15 seconds and detaching it. Current v0.30.6 physical poison begins directly after the lines 16299-16304 daemon-restart-resume of deployah, doyle, flynn, lia, and perri; that temporal proximity supports resumed/reattached consumer connections as the source class. However, `CONN_WRITE_POISONED` has no session/endpoint/connection identifier, so the log cannot identify which resumed endpoint owns any poison.\n- Resume/reattach does not clear the ambient poison storm: perri `SPAWN_DEDUP` + `WAKE_RESUME` at lines 17325-17326 (step 59456308, ~13:14 UTC) is immediately surrounded by poisons at 17323-17324 and 17327-17329, and poison continues in subsequent meet windows. This is consistent with other independent black-holed physical connections surviving while one endpoint resumes; it is not evidence that perri itself caused those poison events.\n- Endpoint activity continues while poison and peer failures occur, which distinguishes “daemon completely frozen” from bounded per-consumer stalls. Examples: bh-rig-a/b injections and two 400 ms timeouts at lines 16444-16447; deployah injection/timeout at 16631-16632; doyle parked drain/timeout at 17169-17171 and two further injections at 17182/17186; todlando+deployah injections/timeouts at 17777-17780; todlando injection at 18743. These successful dispatch/inject attempts coexist with write retirement, demonstrating continued global scheduling and narrowing any freeze to particular consumer/PTY paths.\n\nFalsifiable hypotheses:\n1. SUPPORTED: v0.30.4 global freeze arose when the supervised non-draining brain subscribed resumed sessions on its request/reply connection. Prediction: active PTY output fills that connection; its blocking subscriber writer prevents heartbeat replies even with healthy peers. Exact source comments and the v0.30.5 cutover satisfy this prediction.\n2. SUPPORTED as a second freeze-capable class, not necessarily the reported original incident: an arbitrary controller/viewer that stops reading can block an unbounded pre-v0.30.6 physical write. Prediction: >15 s stall-evicts or, after v0.30.6, repeated poison/retire records while other endpoints continue. Both are observed.\n3. FALSIFIED as primary root: submit-dial timeouts serially stop the PTY subsystem. Prediction: PTY/endpoint activity should cease during peer failures or failures should form a unique incident cluster. Instead failures are continuous across both files and endpoint injection/resume continues; each failure is independently bounded at 10 s.\n4. NOT SUPPORTED as primary root: `SPT_INJECT_VERIFY_ECHO` causes the multi-minute global freeze. Prediction: freeze windows should show repeated same-endpoint echo misses/re-drives/loud respools. Only three misses and one loud spool occur, while dozens of 400 ms settle misses merely proceed. It remains a measurement confounder for injection latency and duplicate/loud delivery.\n5. UNRESOLVED: one named endpoint repeatedly causes all `CONN_WRITE_POISONED` events. Prediction: poison records should carry session/connection identity or tightly bracket a single endpoint's output. They carry neither; multiple endpoints remain active. The same-endpoint claim is therefore not testable from these logs.\n\nMissing correlation inputs: exact operator freeze start/end timestamps (preferably UTC with seconds), the affected endpoint/session, whether the symptom was “PTY output stopped,” “input stopped,” or “rc/viewer attach hung,” and whether recovery followed reattach/update/restart. Without those, the TOTP-derived windows can establish cadence and mechanism but cannot bind the operator-visible incident to a specific poison, settle, re-drive, resume, or endpoint event.",
  "files": [
    {
      "path": "C:/Users/decid/AppData/Local/spt-core/logs/daemon.stderr.log",
      "description": "Primary evidence. Key anchors: 925-927 echo re-drive+loud spool; 2177 and 2349-2350 logical 15 s subscriber stalls; 6095-6109 and 6462-6469 microsecond controller writes; 7722-7735 bounded lia settle probes; 16299-16314 v57 promotion/resumes then first poison; 16314-16689 dense per-30-second poison/dial cadence; 17168-17188 doyle injection amid poison; 17323-17329 perri resume amid poison; 17776-17783 dual injection/timeouts amid poison; 18725-18768 poison still continuing ~97 minutes later."
    },
    {
      "path": "C:/Users/decid/AppData/Local/spt-core/logs/daemon.stderr.log.1",
      "description": "Historical/control evidence. Contains pervasive bounded peer failures and 20 observed settle timeouts but no `CONN_WRITE_POISONED`; key logical stall anchor 24303. Shows peer churn predates the post-v0.30.6 physical-write protection and is ambient."
    },
    {
      "path": "C:/Users/decid/Documents/projects/spt-core/crates/spt-daemon/src/brain.rs",
      "description": "Lines 1036-1049 explicitly document the v0.30.4 field self-deadlock: non-draining resume subscription fills one connection, broker subscriber write holds `SharedSend`, and request/reply traffic is starved. Lines 894-912 define ordinary draining attach behavior."
    },
    {
      "path": "C:/Users/decid/Documents/projects/spt-core/crates/spt-daemon/src/brainproc.rs",
      "description": "Lines 184-203 implement v0.30.5 cursor-only resume for the supervised non-draining brain and explicitly name the v0.30.4 re-wedge. Lines 250-289 show heartbeat `net_status`/`sessions` requests whose replies were starved and the logical stalled-controller reap."
    },
    {
      "path": "C:/Users/decid/Documents/projects/spt-core/crates/spt-daemon/src/broker.rs",
      "description": "Lines 1325-1384 show v0.30.6 bounded/cancelable viewer/controller writes and stall accounting. Lines 1928-1960 prove settle timeout is bounded and proceeds. Lines 2164-2176 declare echo verify default-off/capability-gated; lines 2210-2270 prove one re-drive then recoverable loud spool."
    },
    {
      "path": "C:/Users/decid/Documents/projects/spt-core/CHANGELOG.md",
      "description": "Lines 12-31 describe v0.30.6 physical write bounds; 33-47 v0.30.5 resume-channel flood fix; 49-61 v0.30.4 observer reattach; 63-87 v0.30.3 update handoff/reap; 89-101 v0.30.2 concurrent independent peer dialing."
    }
  ],
  "architecture": "Relevant path: the always-on broker owns PTYs and per-session controller/viewer subscriber connections. Session output is fanned to dedicated subscriber writers through a `SharedSend`-backed physical connection. The supervised brain uses the same broker IPC connection for heartbeat request/reply (`net_status`, `sessions`). In v0.30.4, restart resume used the draining-caller API on this non-draining heartbeat connection: session output accumulated, a broker subscriber write blocked the physical send path, and heartbeat replies could not acquire/use that path, producing a dead-peer-independent self-deadlock. v0.30.5 separated cursor restoration from output subscription for the supervised brain. v0.30.6 hardened the lower layer by bounding every physical write and poisoning/retiring the entire connection at 15 seconds, so one suspended controller/viewer cannot retain the writer indefinitely. Peer pumping is a separate brain↔network path with per-peer 10-second bounds and concurrent outcomes; its failures add churn but do not share the PTY subscriber causal lock. Injection is another per-endpoint worker path: a 400 ms PTY readiness settle probe, optional default-off echo verification, one re-drive, then loud respool. Current logs show all three subsystems interleaved, but only the subscriber/shared-connection path has both an unbounded historical blocking mechanism and exact source evidence naming the v0.30.4 freeze."
}