From c0302211818a95acb7a276abdba7a32eac2358d5 Mon Sep 17 00:00:00 2001
From: Gabriel Schneider <gbrls@0x4200.cafe>
Date: Mon, 28 Sep 2026 17:16:55 -0300
Subject: pardes builds against cloud9 2a7137c, whose 9ns reads a reply that
 came in before a hang-up

9ns failed every waiting call as soon as one send met a closed socket, so an answer the server sent just before hanging up could be lost: the Restore write's, when pardes cuts its connections. The docs no longer say the Restore write usually fails through a mount; only an older 9ns could, and the log stays the authority.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 .agents/skills/pardes-9p/SKILL.md | 6 ++----
 build.zig.zon                     | 4 ++--
 docs/fs.md                        | 6 +++---
 3 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/.agents/skills/pardes-9p/SKILL.md b/.agents/skills/pardes-9p/SKILL.md
index 0643e209..8332d8fb 100644
--- a/.agents/skills/pardes-9p/SKILL.md
+++ b/.agents/skills/pardes-9p/SKILL.md
@@ -252,10 +252,8 @@ A Restore puts a new editor under every client: the Restore write is
 answered, then every connection is hung up (their fids name the old
 editor's panes); dial again, and the new log names the restored panes then
 `restore <path>` -- the authority, since a slow client may see the cut
-before the answer. Through a 9ns mount the Restore write itself usually
-fails with ECONNRESET although the Restore went ahead: 9ns fails a request
-whose reply is already in when the hang-up breaks its next send. Trust the
-log. `Dump` writes `pardes-<date>-<time>.zon`, the time in UTC, under
+before the answer. A 9ns older than cloud9 2a7137c could fail the Restore
+write with ECONNRESET although the Restore went ahead; trust the log. `Dump` writes `pardes-<date>-<time>.zon`, the time in UTC, under
 `DumpDir` (`$XDG_DATA_HOME/pardes`, else `~/.local/share/pardes`) and logs
 `dump <path>`.
 Read the event implementation before building an interceptor. Close handles in
diff --git a/build.zig.zon b/build.zig.zon
index 4cfba514..f9dff0ea 100644
--- a/build.zig.zon
+++ b/build.zig.zon
@@ -9,8 +9,8 @@
         // read-only HTTPS URL is what a manifest can carry. Re-pin with
         // `zig fetch --save=cloud9 git+https://git.sr.ht/~gbrls/cloud9#<commit>`.
         .cloud9 = .{
-            .url = "git+https://git.sr.ht/~gbrls/cloud9#a8c7a7158cc9d3bde78e34db6de11c084fde3d65",
-            .hash = "cloud9-0.1.0-yt86qjLsHQC_9qrMuOQEcDOan4KTH6ermuxZvm0kgwpL",
+            .url = "git+https://git.sr.ht/~gbrls/cloud9#2a7137c644eb955d39ce3f07d75bf9c8fd9c932e",
+            .hash = "cloud9-0.1.0-yt86qhn8HQDWL3p4nttyOx-iqHcNYsukfOIq0cuEeQxW",
         },
         // ZLS as a LIBRARY, not a language server: src/lsp_zls.zig imports the
         // `zls` module its build.zig publishes and calls the analyser in
diff --git a/docs/fs.md b/docs/fs.md
index 86f44501..445aa725 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -117,9 +117,9 @@ asks the same first -- `Dump` writes `pardes-<date>-<time>.zon` (UTC) in
 and logs `dump <path>`, and `Restore` with no path takes the last one; a
 Restore puts a new editor under every client, so the write of it is
 answered and then every connection is hung up, their fids naming the old
-editor's panes (through a 9ns mount the write usually fails with
-ECONNRESET all the same: 9ns fails a request whose reply is already in once
-the hang-up breaks its next send, so trust the log): dial again, and the new
+editor's panes (a 9ns older than cloud9 2a7137c could fail the write with
+ECONNRESET all the same, when another request's send met the hang-up
+before the answer was read; the log is the authority): dial again, and the new
 log names the restored panes and
 `restore <path>`. The answer has 200 ms to leave before the cut, so a slow
 client may see only the cut; the log's `restore <path>` is what says the
-- 
cgit v1.3