docs: locate the remaining action flakiness in assert_socket

Records the exact function and the two defects in it (judging liveness on the
first message received, and deleting a live socket on a transient
ConnectionRefused), plus what the resize fix did and did not solve. The
handshake change is deliberately left unmade rather than rushed.

2 files changed, 29 insertions, 3 deletions

diff --git a/VERSION b/VERSION
index 17e51c3..d917d3e 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-0.1.1
+0.1.2
diff --git a/docs/roadmap.md b/docs/roadmap.md
index 77086ed..22fd270 100644
--- a/docs/roadmap.md
+++ b/docs/roadmap.md
@@ -145,8 +145,34 @@ The CLI works around it (idempotent reads are retried with backoff, which took
 consumer of `zellij action` on a slow machine will hit this, and most will
 conclude their session is dead.
 
-Not yet investigated: whether it reproduces upstream, and whether it is a
-socket-connect timeout or a race in session enumeration.
+**Partly fixed in `sl0p: stop suspended panes spamming resize errors`.** Half of
+it was self-inflicted: every resize logged one error per `start_suspended` pane
+on the server's hot path, and sl0ppi puts a suspended agent in every project. On
+the same box that took `list-tabs` against a two-suspended-pane session from
+5/12 failing to 6/30, with the error storm gone entirely (126+ -> 0).
+
+**The remaining ~25% is a real IPC bug, and it is now located.** Every
+`zellij action` calls `sessions.rs::assert_socket()`, which connects to the
+session socket, sends `ConnStatus`, and waits for exactly `Connected`:
+
+```rust
+match receiver.recv_server_msg() {
+    Some((ServerToClientMsg::Connected, _)) => true,
+    None | Some((_, _)) => false,          // <- anything else means "dead"
+}
+```
+
+So a server that is momentarily busy, or that happens to send a different
+message first, is reported as **no session at all** -- which is why the failure
+surfaces as "There is no active session!" against a session that is demonstrably
+alive. Worse, the `ConnectionRefused` arm above it `remove_file`s the socket, so
+a transient refusal can delete a live session's socket.
+
+Proposed fix (not yet made, because it changes the client/server handshake and
+deserves its own session): read messages for a short bounded window looking for
+`Connected` rather than judging on the first one, and do not delete a socket on
+a single refusal. The attach-time "lost connection to the server" drop is a
+different path (the client's receive loop) and needs separate measurement.
 
 ## Standing risks