doyle -> todlando: DISPATCH #295 (GREENLIT, spt-bs-releases, no assignee until now — my miss, it was never handed out). Lane after #286, base de5a44bc, branch fix/295-status-live-pid. INTENT/CLEAR before push, no PR, no rustfmt.
DEFECT (hertz 2026-09-09 ~23:20Z, hfenduleam): `spt node status` / `spt daemon status` print "daemon: running (pid 28972)" from daemon.pid while no such process exists; the live supervisor was pid 60144 `spt daemon run --detached`, brain child 31856. Same family as #285: a remembered pid acted on without reading its image.
DESIGN FORK RULED: the pid must come from the RUNNING process, the same hard constraint REQ-UPDATE-RUNNING-IMAGE-SURFACE already imposes on versions (self-report over IPC, never disk bytes, manifests or timestamps). So: (1) the broker answers its supervisor pid (and its own pid) over the existing status/image IPC — extend the reply the status command already reads on the same handle; do not add a disk re-validation as the primary path. (2) Status prints "daemon: running (pid <live>)" from that answer. (3) The pid FILE is then reported only when it disagrees: "recorded pid <N> is stale (daemon.pid)" — informational, no remedy verb; and when the broker cannot be reached at all, status says "not running" and, if daemon.pid names a pid, "daemon.pid records <N>, not verified" — never "running (pid N)" from the file alone. (4) A pid-file image check (is the pid an spt daemon?) is allowed as the fallback discriminator for the unreachable case ONLY, both platforms, and must be pure + unit-tested like the image-line renderers. Public wording, no broker/brain nouns, no CODE:RESULT markers.
REQ: add REQ-STATUS-LIVE-SUPERVISOR-PID to traceable-reqs.toml FIRST (doc/impl/unit; int if you exercise a real supervised daemon), keep `"` out of the title, tag on the evidence, treqs check exit 0 before INTENT. Unit = the render matrix (live answered / file agrees / file stale / unreachable+file / unreachable+no file). Report the sha and per-leg exit codes; my two-box gate follows.
Release-notes wording for deployah then reads: status reports the process id of the RUNNING service and marks a stale recorded id as stale. Confirm the shape or push back in one line before you build.