HERTZ CORRECTED REPORT — gaki-n elevated spt-hosted RC + slammie-n shortform Status: OPEN / root not proven. This replaces the gaki-n causal claims in my prior elevated-endpoint report. Two adjacent defects from that report remain independently valid (harness-only refusal copy; qualified-target canonicalization), but neither explains gaki-n. Corrected field facts from operator: - gaki-n was launched with direct `spt endpoint run` from an elevated Windows Terminal. - It was genuinely spt-hosted, not harness-only. - Bare `spt rc gaki-n` returned the target-side no-live-session/stale-row refusal. - At the same time, the same machine successfully hosted an active `spt rc slammie-n` session. - A canonical perri→gaki-n send was visibly received by gaki-n. - Directly afterward, slammie-n emitted `@` at the END of its final reply. No confirmation appeared, and gaki-n never received that body, including later. - slammie-n adapter was 0.23.x; target core was 0.30–0.32. - SPT_HOME was not explicitly set in the elevated shell. Hard deductions: 1. The exact remote RC copy means the node reached for gaki-n returned EOF before any PTY output because `dispatch::resolve_local_session` found no HostedSession whose endpoint equaled bare `gaki-n` (or the access gate refused). Since slammie-n was attachable, this was endpoint-selective session/registry divergence, not a dead broker or pipe-wide elevation ACL failure. 2. `spt endpoint run` normally sends SpawnReq to the broker; `broker::dispatch_spawn` creates the PTY/session. A de-elevated broker spawns an unelevated child regardless of caller token. Therefore caller elevation alone cannot explain a missing session in the same broker. The incident requires either (a) different broker/state universe than assumed, (b) gaki's broker session ended while a perch/listener/registry row stayed live, or (c) version-specific spawn/session registration failure plus a separately live registration path. 3. Hyphen parsing is falsified. Adapter 0.23's parser copies gaki-n verbatim and builds argv `spt send --from slammie-n gaki-n`. 4. `no confirmation` at end-of-turn is not itself a failure token. The adapter deliberately drops successful Stop-path confirmations; only a visible failure should be self-sent in newer 0.24. In 0.23, silence can mean scanner miss, SENT, QUEUED, or failed confirmation loss. Target non-receipt proves the body did not surface, but does not distinguish those stages. Ranked, falsifiable RC hypotheses: R1 — session ended, liveness residue survived (highest). A spt-hosted HostedSession disappeared, but an api-listen child/perch row remained active long enough to gossip and receive the perri body. Prediction: target broker `sessions` lacks gaki while info/listener rows say live; parent/session process tree shows orphan relay or rebound listener. Core 0.30–0.32 lifecycle history contains exactly this general class (sessionless controllable row / orphan-listener fixes), but incident artifacts are absent, so applying it to gaki is still inference. R2 — two broker universes on one physical Windows machine. Prediction: gaki spawn command and reached dispatcher derive different broker socket names/home tags or node keys; daemon status/PIDs/socket tags differ between elevated and ordinary shells. A real source hazard exists: broker names hash `spt_home()` lexically, not a canonicalized Windows path, so case/alias variants can point at the same files while creating distinct in-memory brokers. However operator reports no explicit SPT_HOME; common alias trigger is therefore unproven. Different-user LOCALAPPDATA would create separate physical homes/node identities and must be checked, not assumed. R3 — elevation token causes session-table visibility failure inside one broker. Low rank. Broker session map is in-process and spawn is performed by the broker; integrity does not selectively hide one session. Prediction would be a Spawned reply without a map insert only on elevated callers, which source does not support. R4 — access gate refusal. Low rank unless logs show it. Same wire symptom, but endpoint/source access policy would need to differ for gaki; elevation is not an input. Ranked shortform hypotheses: S1 — Stop scanner did not observe/finalize the last transcript entry (highest stage-specific candidate). Prediction: adapter hook trace has Stop but no scan/dispatch for the final tag; no core send token/op exists. End-of-turn is the exact scanner-sensitive leg; units do not substitute for a live provider transcript integration. S2 — send ran and returned QUEUED/SENT, but delivery entered a state universe/spool not consumed by gaki. Prediction: hook trace records argv + success token; spool row exists under slammie's core home and not under gaki's effective home, or remains undrained. This would connect to R2. S3 — send ran and failed NO_PERCH/owner-resolution, while 0.23 failed to surface the final failure. Prediction: hook trace records NO_PERCH/refusal and Stop does not self-send it. Peri's immediately prior receipt proves gaki was routable from perri, but does not prove slammie's local resolver/state universe matched. S4 — parser rejected hyphen. FALSIFIED by source and focused passing unit. Why exact RCA cannot yet be claimed: - gaki-n/slammie-n are no longer present in current registry. - Their target node's daemon stderr, hook-trace, endpoint info.json, session table, spool, process tree, effective LOCALAPPDATA/SPT_HOME, node key, and broker socket tag from the incident were not captured here. - A UAC-elevated Windows reproduction cannot be run hermetically from this unelevated OMP session without an interactive elevation grant. Required deterministic reproduction/capture: A. On one Windows node/core image, record normal-shell and elevated-shell: whoami/user SID, integrity, LOCALAPPDATA, effective spt_home display, node key, daemon pid, broker socket/home tag, and `daemon status --json`. B. Start control endpoint normally and gaki-shaped endpoint via elevated `spt endpoint run`; assert Spawned session id, then query broker sessions from both shells. Repeat 3×. RC both from a remote node. C. While gaki is visibly receiving canonical WAN, emit an end-of-final-reply shortform from slammie. Capture adapter hook-trace around Stop, generated argv, spt exit/status token, target spool row, and target receive/poll trace. This single trace distinguishes S1/S2/S3. D. Repeat shortform with a subsequent tool call (PreToolUse leg). End-only fail + PreToolUse pass pins scanner/finalization; both dispatch but only one state universe drains pins routing/spool. E. Add a pure core guard that canonicalizes/case-folds Windows spt_home before home_tag hashing, but only after the two-alias test proves two spellings of one physical path currently mint different sockets. Do not pre-label this as gaki's fix. No corrected root cause is asserted. The right next action is capture/repro, not another seed based on topology inference.