{
  "summary": "## Investigation result\n\n### Established facts and principal conclusion\n\n- **[FIELD FACT, operator-established]** `gaki-n` was genuinely **spt-hosted**, not harness-only, and was launched from an elevated Windows Terminal.\n- **[FIELD FACT, operator-established]** On the same machine, `spt rc gaki-n` failed while `spt rc slammie-n` worked.\n- **[FIELD FACT, operator-established]** A canonical perri→gaki-n delivery landed, but a later canonical slammie-n→gaki-n shortform send failed.\n- **[FIELD FACT, assignment context]** `gaki-n` remained advertised while absent from the broker session table being queried.\n\n**Core source-grounded conclusion:** elevation of the `spt endpoint run` command process does **not** directly elevate the hosted PTY child. The command is only an IPC client. The actual chain is `cmd_endpoint_run` → `ensure_running` → `launch_harness_brokered_in` → `Brain::spawn_session_pid` → broker `dispatch_spawn` → `PtySession::spawn_program_in_env`. `SpawnReq` contains argv/cwd/env/endpoint metadata, but no Windows token or process handle. `portable-pty` creates the child in the broker process, so the child inherits the **broker's** user token, integrity level, logon/session context, base environment, and job/container relationships, with only manifest-declared env values overlaid. Therefore, a genuinely spt-hosted elevated `gaki-n` proves that the broker which spawned it was elevated. It does not prove that a fresh elevated caller bypassed de-elevation.\n\nThat limits the ways an elevated Windows Terminal can produce a genuinely spt-hosted elevated child to these source-supported mechanisms:\n\n1. the caller connected to an **already-running elevated broker**;\n2. daemon startup ran elevated but `spawn_deelevated` returned `Ok(None)` because there was no usable unelevated Explorer/shell token, such as a headless/service session, UAC-disabled uniformly elevated desktop, or elevated Explorer;\n3. an **older/stale binary** predating or bypassing the current de-elevation guard was already running, potentially from a scheduled task or prior manual start;\n4. the caller selected a **different SPT home/socket universe** whose broker happened to be elevated;\n5. a service/task or binary-version split selected a different broker image/lifetime.\n\nDirect token inheritance from the elevated `endpoint run` CLI into the PTY child is ruled out by the IPC architecture.\n\n## Ranked causal candidates\n\n### 1. Two broker universes, with `slammie-n` in broker A and `gaki-n` in broker B\n\n**Rank: highest for the full sibling differential.** This is the only candidate that directly explains all three simultaneous observations without treating `slammie-n` as contradictory: broker A can contain and attach `slammie-n`, while broker B genuinely hosts `gaki-n`; broker A's session table necessarily misses `gaki-n`.\n\nExact symbols:\n\n- `spt_store::perch::spt_home` selects `$SPT_HOME`, else `%LOCALAPPDATA%\\spt-core`.\n- `spt_daemon::endpoint::home_tag` hashes the `PathBuf` **lexically**, with no canonicalization.\n- `seed_socket_name` and `broker_socket_name` use that hash.\n- `daemon::is_running` probes only the seed pipe for the current home tag.\n- `harnesshost::launch_harness_brokered_in` connects only to the broker name derived in the caller's current universe.\n- `attach::resolve_local_session` and `rc::resolve_session` search only that broker's `SessionsReply` for an exact endpoint label.\n- `wansend::resolve_and_dial_owner` returns `NotFound` when registry resolution says the endpoint belongs to this same node but the local broker scan already missed it; it deliberately does not self-dial.\n\nThere are two variants:\n\n- **1A, strongest:** different lexical spellings of the same physical Windows home, for example case, separator, `..`, symlink, or junction aliases. Because `home_tag` hashes the uncanonicalized path, two spellings can create two pipe names and two brokers while both brokers share the same physical `owlery`, `identity/node.key`, and registry files. This produces the exact split-brain shape: disk advertisement says “this node owns gaki-n,” but broker A lacks broker B's `HostedSession`; RC sees a same-node stale row and refuses rather than dialing broker B. **[INFERENCE]** Windows path aliases producing different Rust `PathBuf` hashes should be confirmed by the isolated path-hash test below; the absence of canonicalization is directly observed.\n- **1B:** genuinely different physical per-user homes, commonly caused by elevation through a different administrator account or differing `SPT_HOME`. This also creates different brokers, but normally creates different `node.key` identities. Broker A should then see gaki-n as another node and attempt WAN attach rather than the same-node refusal. To reproduce the exact advertised-as-local failure, the two physical homes would also need shared/copied identity material, stale merged registry state, or ambiguous node labeling.\n\nWhy elevation matters: broker B can be elevated if it was pre-existing, old, or had no de-elevation target. `gaki-n`, its bind subprocesses, and its translation process then inherit broker B's elevated token. Broker A may remain ordinary medium integrity and host `slammie-n` normally.\n\nPredictions:\n\n- Two broker/daemon PIDs or two broker pipe names/home tags exist or existed.\n- `gaki-n`'s process ancestry leads to broker B; `slammie-n`'s ancestry leads to broker A.\n- Broker B and `gaki-n` have the same elevated token/integrity; broker A and `slammie-n` have the same medium token/integrity.\n- `KIND_SESSIONS` against A contains `slammie-n` but not `gaki-n`; against B it contains or previously contained `gaki-n`.\n- In the lexical-alias variant, canonicalized/final-handle paths and `node.key` file identity match even though the raw `SPT_HOME` strings and derived home tags differ.\n- Current livehost reconciliation in each broker will regard the other broker's sessions as absent. If both current brokers actively share one owlery, logs should show cross-offlining such as `LIVENESS_RECONCILE_OFFLINE:<other-id>` and statuses may oscillate or become stale. Absence of those tokens over multiple 5-second reconcile periods weakens the live two-broker/shared-owlery variant, unless one brain was old, wedged, or not running.\n\nFalsifiers:\n\n- One broker PID, one exact raw/canonical SPT home, one home tag, and one broker session query from both integrity contexts.\n- `gaki-n`'s parent chain leads to the same broker as `slammie-n` and that broker's session table shows no second lifetime or unlabeled row.\n\n### 2. `gaki-n` successfully bound and received a message, then its child exited; disk advertisement stayed stale\n\n**Rank: highest single-broker explanation and strongly supported by chronology.** The earlier successful perri delivery proves there was a working delivery path at that time. A later missing broker session plus failed send is naturally explained by a post-bind harness exit.\n\nExact symbols:\n\n- `api::startup::cmd_bind` → `establish_perch` writes durable `info.json`, stamps `controllable=Some(true)`, and for live-capable adapters stamps `status=online`.\n- Broker `dispatch_spawn` inserts `HostedSession`; its per-session waiter calls `wait`, broadcasts `Exit`, and removes the session from `Broker.sessions` when the child exits.\n- Broker session removal does not itself synchronously clear `info.json` status.\n- `registryhost::advertise_local` enumerates perches from disk and calls `advertised_status`; advertisement is not derived directly from `Broker.sessions`.\n- `livehost::reconcile_hosted_liveness` is the correcting edge. `spawn_live_host` queries `brain.sessions()` on boot and every `LIVE_RECONCILE_INTERVAL_MS = 5000`; an online/unbound spt-hosted perch with no broker session is stamped offline.\n\nThus “advertised but no broker session” is a legitimate transient of up to one reconcile interval. It can persist if the brain/livehost is absent, wedged, running an old version without the current reconcile, unable to query the broker, or has test-only `SPT_LIVEHOST_RECONCILE_DISABLE` in its environment.\n\nPredictions:\n\n- A single broker contains `slammie-n`; `gaki-n`'s recorded PID is dead and the broker no longer contains its endpoint label.\n- Broker stderr contains an exit around the failure time; within about five seconds a healthy current brain emits `LIVENESS_RECONCILE_OFFLINE:gaki-n` and the advertisement changes to suspended/offline.\n- If advertisement remains Active materially longer than five seconds, the brain is absent/stalled/old, its broker query is failing, or another daemon is rewriting/advertising the same files.\n- The successful perri delivery occurred before the child/session exit; the later slammie send occurred after it.\n\nFalsifiers:\n\n- `gaki-n`'s process is still alive under a different broker.\n- A current healthy livehost repeatedly completes broker session queries yet leaves `gaki-n` online with no session; that would contradict the current reconcile body.\n\nImportant implementation race that does **not** match the observed direction: in `dispatch_spawn`, the exit waiter thread is started before `sessions.insert`. If a child exits extremely fast, the waiter can remove before insertion and the later insert can leave a dead session row. That bug shape predicts a false-positive session row, not a missing row, so it does not explain this incident.\n\n### 3. Pre-existing elevated daemon, or current daemon with no de-elevation target\n\n**Rank: high for explaining the elevated child, but incomplete by itself for the sibling/session-table split.** Combine it with candidate 1 or 2.\n\nExact symbols:\n\n- `daemon::ensure_running` returns immediately when `is_running()` can ping the current seed pipe. It does not inspect the daemon PID, image version, token, integrity, or owning account.\n- `daemon::spawn_detached` first calls `deelevate::spawn_deelevated`.\n- Windows `spawn_deelevated` returns `Ok(None)` when the caller is not elevated, there is no shell window/token, or the shell token itself is elevated.\n- On `Ok(None)`, `spawn_detached` logs `ELEVATED_DAEMON` if appropriate and launches normally; the daemon and all PTY children inherit the elevated token.\n- `Daemon::run` repeats the de-elevation guard. With no target it serves elevated loudly rather than mixing identities.\n- Direct human `spt daemon run` from an elevated interactive shell with an unelevated shell target is refused by `cmd_daemon_run` (`DAEMON_RUN_ELEVATED`). A fresh current high broker is therefore not normally created by that command.\n\nCurrent Windows de-elevation does not actually use the UAC linked token despite historical shorthand in comments. `shell_primary_token` obtains Explorer's process token, duplicates it to a primary token, vets that it is not elevated, builds that user's environment with `CreateEnvironmentBlock`, overlays an explicit non-empty `SPT_HOME`, and calls `CreateProcessWithTokenW`. This is intended to land the daemon in the interactive desktop user's medium-integrity universe.\n\nPredictions:\n\n- For an already elevated broker, the broker and `gaki-n` share the high token; daemon logs predate the endpoint run or report `ELEVATED_DAEMON`.\n- For the no-target route, `GetShellWindow` was unavailable or the shell token itself was high; a standard medium Explorer token would falsify that route.\n- A current same-account UAC elevation with ordinary unelevated Explorer and no universe mismatch should produce a medium broker and medium hosted child.\n\nFalsifier for the full RCA: if `gaki-n` and `slammie-n` used the same elevated broker, elevation alone cannot explain why only `gaki-n` vanished from that broker's session table. A subsequent `gaki-n` exit is still required.\n\n### 4. Broker/service/version skew, especially an old broker accepting a new CLI\n\n**Rank: medium.** The code explicitly permits N-1 additive skew.\n\nExact symbols:\n\n- `frame::IPC_PROTOCOL_VERSION` and `MIN_COMPATIBLE_VERSION` are both 1.\n- The handshake accepts newer peers while serde ignores unknown fields.\n- `SpawnReq.endpoint`, `cwd`, `env`, adapter, and other fields are additive/defaulted.\n- `Broker::broker_image_version` reports the broker process's compiled image, explicitly because an update may restart only the brain while the old broker survives.\n- Windows `WindowsLogonTask::detected()` deliberately returns false. The at-logon task is boot-only and is not driven by `ensure_running`; if it already started something, ordinary discovery simply sees that existing pipe.\n- `logon_task_action_is_stale_bare` recognizes legacy task actions; current code warns but does not rewrite them.\n\nA sufficiently old broker that understands `spawn` but predates the endpoint label field will ignore `SpawnReq.endpoint`, genuinely host the PTY, and report a session whose endpoint label is empty or absent/defaulted. The harness can still receive injected ID env/argv and run `api bind gaki-n`, so the disk perch advertises `gaki-n` while RC cannot match it in `SessionsReply`. This is a precise advertised-but-unattachable failure.\n\nPredictions:\n\n- Broker session query contains an extra session with `endpoint=\"\"`, or an old sessions response that cannot label it.\n- Broker compiled image is older than the installed CLI/brain.\n- The scheduled task action points to an old binary or stale command.\n- Daemon logs lack current de-elevation/reconcile tokens.\n\nStrong falsifier: if the same broker correctly contains a labeled `slammie-n` session and both endpoints were spawned during that same broker lifetime using the same broker image, the broker clearly understands endpoint labels. Version skew cannot selectively erase only `gaki-n`; candidate 1 or 2 is then stronger.\n\n### 5. Named-pipe token ACL/integrity boundary\n\n**Rank: medium-low as a selector/amplifier, low as a complete cause.** Source comments explicitly document the historical hazard that an elevated Windows daemon's named pipes deny unelevated clients. However, `LocalSocketTransport::bind` uses `interprocess` `GenericNamespaced` defaults and supplies no explicit `SECURITY_ATTRIBUTES` or DACL, so the exact pipe ACL/mandatory-label behavior is not inspectable in this repository.\n\nACL can cause these transitions:\n\n- an elevated client may discover an elevated daemon that a later medium client cannot reach;\n- a medium `rc` can report daemon down or broker-connect failure even while the high daemon and child exist.\n\nACL alone does not create a second broker with the same home tag. **[INFERENCE, standard Windows named-pipe namespace semantics]** if a medium client cannot ping a high daemon but uses the same pipe name, its fallback daemon will fail to bind the already-existing name and `wait_until_up` should time out. A successful second broker therefore also requires a different home tag/socket name or the first daemon to have exited.\n\nPrediction: high-shell pipe ping/session query succeeds; medium-shell ping fails; both resolve the exact same raw home tag; the second spawn attempt logs broker/seed bind failure or times out rather than hosting another child.\n\nFalsifier: both integrity contexts can query the same broker session list.\n\n### 6. Direct elevated-child inheritance from `spt endpoint run`\n\n**Rank: ruled out for genuine spt hosting.** There is no direct `Command::spawn` in `cmd_endpoint_run` or `launch_harness_brokered_in`. Token inheritance occurs only in broker `dispatch_spawn` through `PtySession`. If the broker is medium, the child is medium even when the requesting CLI is high. A finding that the child token follows the caller rather than the broker would imply an untraced bypass and contradict the current source path.\n\n## How `slammie-n` can remain RC-able while `gaki-n` is advertised but absent\n\nThe system has two independent truth planes:\n\n1. **Broker session truth:** `Broker.sessions: HashMap<u64, HostedSession>` is the only RC authority. `attach::resolve_local_session` searches its `SessionsReply` for exact `session.endpoint == requested-id`. `slammie-n` works because that table has a labeled live `HostedSession` for it.\n2. **Durable/advertised perch truth:** `registryhost::advertise_local` walks disk perches and derives status from `info.json` plus rest intent. A prior `api bind gaki-n` can leave `status=online`, `controllable=true`, adapter/cwd/session metadata, and an advertised Active row after the broker session disappears or when the session belongs to another broker universe.\n\nFor a same-node advertised row, RC intentionally does not route around the discrepancy. After local-session miss, `resolve_and_dial_owner` sees that the registry owner is the current `node.key` and returns `NotFound`; it will not QUIC self-dial. That makes the mismatch visible as “no live session,” while `slammie-n` continues normally in the same broker.\n\n## Shortform send stages and what the differential proves\n\nThe canonical local send path is separate from RC but meets the same broker table at the injection stage:\n\n1. `cli::cmd_send` resolves sender/body/window/channel.\n2. `inject::is_spt_hosted_no_relay` classifies a target entirely from durable/local surfaces: online perch, no TCP relay address, `controllable=Some(true)`.\n3. `try_spt_hosted_inject` connects to the **current universe's** `broker_socket_name` and sends `KIND_ENDPOINT_INPUT`.\n4. `Broker::dispatch_endpoint_input` searches `Broker.sessions.values()` for `h.endpoint == req.endpoint`, then uses that session's translation binary. No matching hosted session returns `delivered=false, spool_deferred=false`.\n5. Default/prefer-native sends may fall back to `deliver::send_windowed` and spool; `--force-native` reports a hard `broker-spooled-no-binary`/not-hosted failure instead. If local delivery returns `NoPerch`, the WAN fallback resolves registry state; a same-node resolved instance returns `NotFound` rather than self-dialing.\n\nConsequences:\n\n- The successful perri→gaki-n delivery establishes that at that earlier moment either the correct broker had a matching session/working translation path or another valid delivery surface existed. Given the field-established relay-less spt-hosted topology, a matching broker session at that time is the strongest reading.\n- The later slammie→gaki-n failure is consistent with the session exiting between sends or slammie resolving a different broker universe.\n- A **plain default** send to an existing stale online perch with no broker session normally predicts a loud queue/spool, not necessarily nonzero failure. A hard failure therefore needs the exact output token to distinguish `force-native`, local `NoPerch`→WAN `NotFound`, broker unreachable, address ambiguity, or a wrapper interpreting queued as failure. Missing broker session alone should not be relabeled as a shortform parser failure.\n\n## Minimal read-only discriminating probes\n\nNo probes were executed because the assignment prohibits live actions. These are the smallest non-mutating observations that separate the candidates:\n\n1. **Token/process-parent census:** for Windows Terminal, active broker PID(s), brain PID(s), `gaki-n`, and `slammie-n`, query `TokenUser`, `TokenElevation`, `TokenIntegrityLevel`, `TokenSessionId`, image path/version, PID, PPID, and creation time. A genuine hosted child must match its broker's token/integrity, not necessarily the command shell's.\n2. **Universe census:** for each relevant integrity/account context, record the exact raw `SPT_HOME`, `%LOCALAPPDATA%`, `%USERPROFILE%`, resolved `spt_home`, derived seed/broker home tag, and final/canonical file identity of `owlery` and `identity/node.key`. Compare raw path spelling separately from final path/file ID. This distinguishes different users, different physical homes, and lexical aliases of one physical home.\n3. **Per-broker session snapshot:** query `KIND_SESSIONS` against every discovered broker pipe without starting anything. Record `(broker PID/image, home tag, session_id, endpoint label, controller_by)`. Look specifically for `gaki-n`, `slammie-n`, and an unlabeled `endpoint=\"\"` row.\n4. **Durable state snapshot:** read `owlery/gaki-n/info.json`, ready/idle markers, registry snapshots, and timestamps. Compare `status`, `controllable`, recorded session ID/PID, node identity, and registry owner against each broker session snapshot.\n5. **Existing logs only:** correlate `DEELEVATED_RESPAWN`, `ELEVATED_DAEMON`, `DEELEVATE_FAIL`, `ENDPOINT_RUN:gaki-n`, `BOUND:gaki-n`, session exit, `LIVENESS_RECONCILE_OFFLINE:gaki-n`, broker bind failures, and broker image/version. No restart, refresh, message, or endpoint mutation is needed.\n6. **Exact send token:** retain the later shortform command's machine token/output. `FORCE_NATIVE_UNDELIVERED ... leg=broker-spooled-no-binary`, `leg=cli-gate-not-hosted`, `WAN_NO_PERCH`, `WAN_UNCONFIRMED`, `AMBIGUOUS`, `NO_PERCH`, and `QUEUED` falsify different stages.\n\nA compact decision table:\n\n- **One broker; gaki PID dead; status online; reconcile later offlines:** candidate 2.\n- **Two broker PIDs/home tags; shared node.key/owlery; A has slammie, B has gaki:** candidate 1A.\n- **Two physical homes/node keys:** candidate 1B; expect remote-owner routing rather than same-node miss.\n- **Broker and gaki high; no second broker; medium cannot query pipe:** candidate 3+5; if gaki absent, add candidate 2.\n- **Extra unlabeled broker session; old broker image:** candidate 4.\n- **Broker medium but child high:** contradicts current source path and demands an untraced non-broker launch.\n\n## Deterministic isolated Windows test seam\n\nThe best deterministic seam is a process-isolated Windows integration test built beside `crates/spt-term/tests/winspawn.rs` and the existing real-broker tests, with one test process owning one temporary `SPT_HOME`:\n\n1. Use a tiny purpose-built token-probe fixture executable, not PowerShell or `whoami` text parsing. It writes JSON containing PID/PPID, user SID, `TokenElevation`, integrity SID/RID, token session ID, exact `SPT_HOME`/`LOCALAPPDATA`, cwd, and then waits on a bounded stdin/event so the broker session remains queryable.\n2. Run the test itself elevated on the admin-enabled Windows runner.\n3. Launch the real daemon through the existing `spawn_deelevated`/`daemon run --detached` path with an explicit temp `SPT_HOME`; connect via the real `Brain` transport; spawn the fixture through `launch_harness_brokered_in` or a real `SpawnReq`; query `KIND_SESSIONS`.\n4. Assert: broker child is under the unelevated desktop user token, the PTY fixture matches the broker's medium integrity/user/session, explicit `SPT_HOME` survived `CreateEnvironmentBlock`, and the session endpoint label is exact. This deterministically tests command→daemon de-elevation→broker→ConPTY inheritance, the currently missing OS-level contract.\n5. In a separate process-per-test case, construct two lexical aliases of one temporary Windows directory, including a junction or final-handle-verified case-insensitive alias, assert `home_tag`/pipe names differ while directory and `node.key` file IDs match, bind one real broker per name, spawn `slammie-n` into A and `gaki-n` into B, then prove A's `KIND_SESSIONS` misses gaki and same-node owner resolution returns `NotFound`. This is the deterministic split-brain reproduction.\n6. Keep the no-shell/uniform-high policy separately covered by the existing pure `plan_spawn(elevated, has_deelevation_target)` table; a real no-Explorer test belongs on an isolated Session-0/headless runner because destroying or replacing Explorer is not hermetic.\n\nExisting useful seams are `deelevate::tests` for pure spawn policy and env-block override logic, `spt-term/tests/winspawn.rs` for real ConPTY process creation, `spt-daemon/tests/attach.rs` for real broker/session attach, and the process-global-temp-home pattern used throughout `spt-daemon/tests`. None currently records the broker and PTY child's Windows tokens, which is the decisive missing assertion.\n\n**Static investigation status: DONE. No files, endpoints, daemons, messages, services, or test processes were modified or run.**",
  "files": [
    {
      "path": "crates/spt/src/cli.rs",
      "description": "`cmd_endpoint_run` resolves adapter/session/home, calls `ensure_running`, checks the current broker session map, creates the unbound skeleton, and sends the brokered spawn request. `cmd_daemon_run` refuses the normal elevated interactive foreground case. `cmd_send` exposes the local-inject, spool, and WAN fallback stages and their diagnostic tokens."
    },
    {
      "path": "crates/spt-daemon/src/daemon.rs",
      "description": "`is_running`, `ensure_running`, `spawn_detached`, and `Daemon::run` define daemon discovery/start and both Windows de-elevation enforcement points. `ensure_running` trusts only the current home's seed-pipe ping and does not inspect token/version."
    },
    {
      "path": "crates/spt-daemon/src/deelevate.rs",
      "description": "Windows token implementation: elevation probe, Explorer shell-token acquisition/duplication, `CreateEnvironmentBlock`, explicit `SPT_HOME` overlay, `CreateProcessWithTokenW`, and the `Ok(None)` no-target elevated fallback."
    },
    {
      "path": "crates/spt-store/src/perch.rs",
      "description": "`spt_home` is selected from `SPT_HOME`, else `LOCALAPPDATA`/`USERPROFILE`; the function does no canonicalization. This is the root of disk, identity, adapter, and owlery universes."
    },
    {
      "path": "crates/spt-daemon/src/endpoint.rs",
      "description": "`home_tag` hashes the lexical `spt_home` path; seed/broker/digest/drive/tunnel pipe names are per-tag. Different lexical aliases can therefore select distinct IPC universes."
    },
    {
      "path": "crates/spt-daemon/src/service.rs",
      "description": "Windows scheduled task behavior. The logon task is boot-only and `detected=false`, so `ensure_running` never controls it; stale task-action detection is advisory. Existing task-launched daemons can still win normal pipe discovery."
    },
    {
      "path": "crates/spt-daemon/src/harnesshost.rs",
      "description": "`launch_harness_brokered_in` prepares argv/env and sends `SpawnReq` to the selected broker. It never creates the child or passes a caller token; session self-registration is explicitly deferred to harness `api bind`."
    },
    {
      "path": "crates/spt-daemon/src/brain.rs",
      "description": "Broker IPC client and `spawn_session_pid`/`sessions` request path. Also exposes the running broker-image version needed to identify surviving old brokers."
    },
    {
      "path": "crates/spt-daemon/src/msg.rs",
      "description": "`SpawnReq` and `SessionInfo` schemas. Endpoint labels and later spawn fields are additive/defaulted, enabling old-broker/new-CLI skew and the possible unlabeled-session prediction."
    },
    {
      "path": "crates/spt-daemon/src/broker.rs",
      "description": "`Broker.sessions`, `dispatch_spawn`, PTY child creation, endpoint labeling, session insertion/removal, session listing, and endpoint-input lookup. This is the authoritative hosted-session table for RC and native injection."
    },
    {
      "path": "crates/spt-term/src/pty.rs",
      "description": "`PtySession::spawn_program_in_env` builds a `portable_pty::CommandBuilder`; it overlays requested env but supplies no alternate Windows token. The PTY child therefore inherits the broker process token/environment."
    },
    {
      "path": "crates/spt/src/api/startup.rs",
      "description": "`cmd_bind`/`establish_perch` self-register the durable perch, stamp `controllable=true` for spt-hosted live agents, and set online state independently of broker-table registration."
    },
    {
      "path": "crates/spt-daemon/src/registryhost.rs",
      "description": "Local registry advertisement walks disk perches and derives status through `advertised_status`; it does not consult the broker session table directly."
    },
    {
      "path": "crates/spt-daemon/src/livehost.rs",
      "description": "`reconcile_hosted_liveness` and `spawn_live_host` correct stale online/unbound spt-hosted perches by comparing disk state with broker `KIND_SESSIONS` at boot and every five seconds."
    },
    {
      "path": "crates/spt-daemon/src/attach.rs",
      "description": "`resolve_local_session` maps endpoint ID to an exact broker session label. No label/session means a clean refusal even if registry/perch state still advertises the endpoint."
    },
    {
      "path": "crates/spt/src/rc.rs",
      "description": "RC establishment checks only the current universe's broker first, then attempts remote-owner resolution on a local miss; it is connect-only and does not start a daemon."
    },
    {
      "path": "crates/spt/src/wansend.rs",
      "description": "`resolve_and_dial_owner` explicitly maps a registry row owned by the current node plus local broker miss to `NotFound`, never a self-dial. The same principle explains advertised-local yet unattachable behavior."
    },
    {
      "path": "crates/spt-daemon/src/inject.rs",
      "description": "Shared local/WAN spt-hosted delivery seam. Durable perch facts classify a target as hosted, then the function connects to the current universe's broker for endpoint injection."
    },
    {
      "path": "crates/spt-term/tests/winspawn.rs",
      "description": "Existing real Windows ConPTY integration seam. It validates `.cmd` launch but does not yet record or compare broker/child Windows tokens."
    },
    {
      "path": "crates/spt-daemon/tests/attach.rs",
      "description": "Existing real broker/session/attach test pattern suitable for the isolated token and dual-home Windows reproductions."
    }
  ],
  "architecture": "## Elevated Windows lifecycle, end to end\n\n```text\nElevated Windows Terminal\n  |\n  | spt endpoint run\n  v\nspt::cli::cmd_endpoint_run                         [high command process]\n  | resolve spt_home/adapters/perch\n  | daemon::ensure_running\n  |   `-- seedmap::ping(seed_socket_name(home_tag))\n  |         | success: use existing daemon exactly as-is\n  |         ` failure: daemon::spawn_detached\n  |             | Windows deelevate::spawn_deelevated\n  |             |   Explorer token + desktop-user env + SPT_HOME override\n  |             |   -> medium daemon when a target exists\n  |             ` Ok(None) -> inherited high daemon, loudly\n  |\n  | harnesshost::launch_harness_brokered_in\n  | Brain::cold_start(broker_socket_name(home_tag))\n  | Brain::spawn_session_pid(SpawnReq)\n  v\nBroker::dispatch_spawn                              [actual process owner]\n  | PtySession::spawn_program_in_env\n  |   -> ConPTY child inherits BROKER token/integrity/session/env\n  | create OutputLog/translation child\n  | insert HostedSession { endpoint: gaki-n, ... }\n  ` reply Spawned\n\nHosted harness process\n  | startup hook / adapter invokes `spt api bind gaki-n`\n  v\napi::startup::cmd_bind -> establish_perch\n  | write durable owlery/gaki-n/info.json\n  | controllable=true; status=online where live-capable\n  ` no atomic proof is made that this bind belongs to the broker currently\n    queried by some other CLI/home universe\n\nTwo independent read planes:\n\n  RC/control plane                              Presence/address plane\n  ----------------                              ----------------------\n  Broker.sessions                               owlery/info.json + registry snapshots\n  exact endpoint label match                    registryhost::advertise_local\n  attach::resolve_local_session                 advertised_status\n\nA broker miss plus a same-node registry owner is intentionally NotFound.\nThe livehost reconciler normally closes stale disk truth within 5 seconds,\nbut a second broker, old/wedged brain, failed query, or recent exit leaves a\nwindow where advertisement and RC disagree.\n```\n\nThe broker/brain split does not alter token ownership: `brainproc::spawn_brain_child` is a normal `Command::spawn` from the broker and inherits the broker token; the broker remains the process that owns PTYs and creates harness children. A brain update can therefore change logic without changing the broker token or broker image. This is why installed/current CLI version is not sufficient evidence about the running broker.\n\nThe decisive diagnostic axes are orthogonal:\n\n- **OS token/integrity:** determines whether broker and hosted child are high or medium.\n- **Per-user/home/socket universe:** determines which daemon/broker a command can discover and query.\n- **Broker session registration:** occurs synchronously at broker spawn and is keyed by broker-local numeric session ID plus endpoint label.\n- **Hosted perch registration:** occurs later from inside the child through `api bind` and persists on disk independently.\n- **Registry advertisement:** projects the durable perch, not broker ownership.\n- **RC:** requires an exact broker session label and refuses same-node self-routing on a miss.\n- **Shortform send:** first classifies from durable perch facts, then tries the current broker's endpoint/translation table, then spools or WAN-resolves according to flags and delivery outcome.\n\nThis separation permits the observed state without invoking harness-only topology: `gaki-n` can be truly broker/PTY-hosted in broker B, self-register into disk visible to broker A, and be advertised by the shared node identity, while `slammie-n` remains an ordinary live row in broker A. It also permits the simpler temporal state where both used one broker, `gaki-n` bound and received successfully, then exited and left a briefly or pathologically stale durable advertisement."
}