The docs: --detach runs the editor as $!, a line with no newline fails only in the log, data reads to the end

The skill said --detach forks and $! was not the editor's pid; it is, and
/status agrees. A line written with no newline runs at the close, after
the write is answered, so its failure is in the log alone: end lines
with their newline. And `cat data` reads from the address to the end of
the text, as acme's does; xdata is the range.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

2 files changed, 10 insertions, 6 deletions

diff --git a/.agents/skills/pardes-9p/SKILL.md b/.agents/skills/pardes-9p/SKILL.md
index 5ac1ba46..0575fab7 100644
--- a/.agents/skills/pardes-9p/SKILL.md
+++ b/.agents/skills/pardes-9p/SKILL.md
@@ -17,9 +17,9 @@ Check `$NINE_MOUNT` first. `9ns --mntgen` sets it for every process it starts
 (an interactive shell on this machine runs inside one), so a set `$NINE_MOUNT`
 means the posted-9P registry is mounted there, usually `/mnt/9p`, and each
 running editor is a directory `$NINE_MOUNT/pardes/<pid>/` (a `--detach=NAME`
-session's is `pardes/NAME/`; `pardes --detach=NAME` forks, its parent
-returning at once, so the running editor's pid is not `$!`: read it from
-`$m/status`, whose first line is `pid <n>`). Inside a pane, `$PARDES_9P` is that session's
+session's is `pardes/NAME/`; `pardes --detach=NAME &` runs the editor as
+that process, so `$!` is its pid, and `$m/status`'s first line, `pid <n>`,
+says the same). Inside a pane, `$PARDES_9P` is that session's
 socket (`/run/user/1000/pardes-9p-<pid or NAME>.sock`), which names the
 directory either way, and `$PARDES_PANE` is the calling pane's serial:
 
diff --git a/docs/fs.md b/docs/fs.md
index c53f83d6..9b5b9d64 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -502,7 +502,10 @@ whole: a mount cuts a big write at its message size (4 KiB through the
 kernel's, 8 KiB from a client that asks), anywhere, and each piece comes as
 a write of its own, so the open keeps a last line with no newline yet, or
 an Edit block whose text has not ended, until its next write, and runs it
-then; what is left when it closes runs at the close, where an Edit block
+then; what is left when it closes runs at the close -- so a line written
+with no newline (`printf Save > exec`) runs only as the file closes, after
+the write has been answered, and its failure is in the log alone: end each
+line with its newline to have the write itself fail -- where an Edit block
 whose `{` or `a`/`c`/`i` text never ended fails and changes nothing
 (``unmatched `{'``, or `a, c or i text not ended by a . line`, logged as an
 `err`): sam takes the end of input for a `.`, but a block that reaches Edit
@@ -606,8 +609,9 @@ The three range files `addr`, `dot` and `limit` each read the pair of offsets
 they also accept, so copying one onto another is all that acme's `addr=dot`,
 `dot=addr` and `limit=addr` ever were. A write is either that pair or an
 address expression (`#0,#5`, `/pattern/`, `2+1`, and pardes's own `12:5`,
-below); `addr` selects what `data`
-and `xdata` read or replace, `dot` is the editor's own selection and moving it
+below); `addr` selects where `data` reads from -- to the end of the text,
+as acme's does, so `cat data` reads everything after the address -- and
+the range `xdata` reads, just that; either replaces the range, `dot` is the editor's own selection and moving it
 scrolls the pane into view, and `limit` bounds only the end of a forward
 search, as acme's does, and reads empty until it is set. Truncating `dot` empties it, truncating `limit` lifts it --
 though a write after the truncation that fails puts the old limit back, so