live_session_may_be_ours (runs.py) documents its weak read as a decision: "An observation, so it degrades rather than raising... A listing that cannot answer reads as 'no session': that is already what the bundled backend returns for a missing multiplexer, a dead server or a failed query, and a guard that varied by backend would be worse than no guard." The cost side of that trade is now measured, on psmux 3.3.8:
- A reaped port file un-lists a live session for up to 5 s.
has-session deletes the port file on any failed 500 ms connect (src/main.rs, has-session block), the server's own source records the false negative under load (src/server/mod.rs:855), and the server re-creates registry files only on a 5-second tick (ensure_session_registry_files). During that window the listing omits the session and bmad-loop delete removes the run directory — the untagged session's only ownership proof — while the server PID lives (measured; the port file then reappears).
- A process whose PATH lacks the multiplexer reads every session as absent. The binary is per-process, the server is not;
delete from such a process removes the directory while the server survives (measured on installed 3.3.8).
A branch attempted to close this class with a proof discipline (transport-owned absence proofs, tri-state liveness, block-on-unproven) and withdrew it after four review rounds each refuted the newest proof source: the transports offer no proof of absence — psmux's registry is advisory and self-healing, a binary path is per-process, the listing is load-sensitive — so the strong guard either wedges cleanup behind --force on every degraded state, or keeps accepting refutable proofs. Whatever the right trade is (accept + document the measured window; retry-with-delay to ride out the 5 s tick; a tag-first read; something else), it is this guard's owner's to make — the degrade wording above is load-bearing in that decision.
live_session_may_be_ours(runs.py) documents its weak read as a decision: "An observation, so it degrades rather than raising... A listing that cannot answer reads as 'no session': that is already what the bundled backend returns for a missing multiplexer, a dead server or a failed query, and a guard that varied by backend would be worse than no guard." The cost side of that trade is now measured, on psmux 3.3.8:has-sessiondeletes the port file on any failed 500 ms connect (src/main.rs, has-session block), the server's own source records the false negative under load (src/server/mod.rs:855), and the server re-creates registry files only on a 5-second tick (ensure_session_registry_files). During that window the listing omits the session andbmad-loop deleteremoves the run directory — the untagged session's only ownership proof — while the server PID lives (measured; the port file then reappears).deletefrom such a process removes the directory while the server survives (measured on installed 3.3.8).A branch attempted to close this class with a proof discipline (transport-owned absence proofs, tri-state liveness, block-on-unproven) and withdrew it after four review rounds each refuted the newest proof source: the transports offer no proof of absence — psmux's registry is advisory and self-healing, a binary path is per-process, the listing is load-sensitive — so the strong guard either wedges cleanup behind
--forceon every degraded state, or keeps accepting refutable proofs. Whatever the right trade is (accept + document the measured window; retry-with-delay to ride out the 5 s tick; a tag-first read; something else), it is this guard's owner's to make — the degrade wording above is load-bearing in that decision.