## B. Arm the relay — one PERSISTENT background task

<!-- [doc->REQ-SKILL-LIVE-SPT-HOSTED-BRANCH] normal-session arm; the spt-hosted arm is live-hosted.md -->

This session is **normal** (you launched this Claude Code yourself, no pre-bound perch), so the
resident Monitor relay IS your one delivery pipe. Run it via the **Monitor** tool. One resident
process IS the live delivery pipe.

The Monitor tool launches the relay under a `bash.exe` child whose pid breaks two by-pid resolutions,
so the bare `spt api listen <id>` FAILS on a normal session.

<!-- [shipped->REQ-LIVE-ANCHOR-WIN32] check-then-run: the anchor check sits ABOVE the command so an
     agent never runs the chain with an empty --pid (a clap exit 2; gaki-n 2026-07-16). -->
**FIRST resolve your anchor pid — check BEFORE running anything:**

- `$SPT_HOST_PID` set AND numeric AND > 1 → use it verbatim (the adapter resolved the real
  `claude`/`claude.exe` pid at SessionStart). This is the normal case.
- `$SPT_HOST_PID` empty OR bogus (e.g. `1` — an msys artifact) → do NOT run the chain with it (an
  empty `--pid` is a hard usage error). Find the real `claude`/`claude.exe` pid yourself by walking up
  this session's process tree (e.g. pwsh: `Get-CimInstance Win32_Process` from `$PID` upward; unix:
  `ps -o ppid=`), and use that NUMBER everywhere `$SPT_HOST_PID` appears below.

Then run the robust chained form — every delta is load-bearing:

- `command:` (one line):
  ```
  spt api seed --pid $SPT_HOST_PID --session-id $OWL_SESSION_ID && spt api --adapter claude-spt listen <id> --parent-pid $SPT_HOST_PID
  ```
- `persistent: true`
- `description: "« spt event »"`

Why each delta (do NOT drop them):

- **Fresh chained seed** — the SessionStart seed is ephemeral (consumed within seconds) and is GONE
  for a session that goes live minutes+ later or after a daemon restart. Re-seed atomically so
  `listen` always has a live seed; re-running the whole command re-seeds if anything below refuses.
- **`--adapter claude-spt`** (a GROUP flag, BEFORE `listen`) — the Monitor's `bash.exe` child makes
  by-pid adapter resolution see `bash` → `ADAPTER_UNRESOLVED`; the explicit adapter bypasses it.
- **`--parent-pid $SPT_HOST_PID`** — the same bash child breaks seed-anchor discovery (it finds the
  bash pid → `NO_SEED`); the anchor you resolved above is the real claude.exe pid. `$OWL_SESSION_ID`
  is session env — use it verbatim.

**Multi-subnet node:** `listen` refuses `HOME_REFUSED: this node holds N subnets (…)` without a
`--subnet` (core does not guess the home). To skip that retry, run `spt subnet status` FIRST and put
`--subnet <name>` in the initial command. If you do hit `HOME_REFUSED`, append `--subnet <name>` and
re-run the WHOLE chained command (the refusal burns the seed, so the chain's re-seed is required).
Single-subnet nodes need no `--subnet`.

- `spt api listen` enters the poll loop inline; the stream stays alive across messages and emits one
  `<EVENT type="msg|alarm|echo_commune|init_signoff" ...>body</EVENT>` line per delivery.
- It **blocks for the session's life**: backlog drains first, then each delivery streams to stdout.

### Across boundaries — the wake marker

Your skill doc explains what commune, recharge, and signoff ARE (recharge is the current name; the
older "commune across" spelling still means the same thing). The operative mechanic: when
the operator asks you to **recharge**, embed `!!wake!!` near the TOP of the commune body — one
marker ⇒ default wake; a PAIR ⇒ the text between them is your custom wake directive (the message your
next session opens with). Near the top matters: only the first ~16KB is readable back once spt has
filed the commune, so a trailing marker in a long commune resets nothing. Write it BARE — a marker in
backticks or a fenced code block is a quotation and fires nothing (same rule as the shortform peer
tag), so writing ABOUT the marker never arms a reset. Author it inline that turn; the clear+wake fire automatically. Sign off with
`spt endpoint shutdown`.