The docs: the one rule covers pty/ctl exec, misses and gone directories are ENOENT, #100,#50 past the end, --detach forks

The one rule's wording left out a pane's pty/ctl and the ENOENT a Find,
Grep or missing directory now answers; `#100,#50` in a short text says out
of range, its ends checked first; and the skill now says --detach forks,
the pid being /status's.

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

2 files changed, 15 insertions, 9 deletions

diff --git a/.agents/skills/pardes-9p/SKILL.md b/.agents/skills/pardes-9p/SKILL.md
index d89a3ac3..5ac1ba46 100644
--- a/.agents/skills/pardes-9p/SKILL.md
+++ b/.agents/skills/pardes-9p/SKILL.md
@@ -17,7 +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/`). Inside a pane, `$PARDES_9P` is that session's
+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
 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:
 
@@ -162,9 +164,10 @@ it again. Each command line runs once whole, however a mount cuts a big write; a
 line with no newline runs when the open closes, and an Edit block still open
 then fails there (an `err`: ``unmatched `{'``, or an a/c/i text with no `.`
 line), changing nothing. One rule: a builtin that fails, whether through a
-ctl, look, exec, tagexec or a column's exec, fails the write (EINVAL for a
-malformed line, else EIO or an errno that fits) and logs one `err` with the
-reason, no `msg`. A look that finds nothing is no failure: it answers
+ctl (a pane's pty/ctl `exec` too), look, exec, tagexec or a column's exec,
+fails the write (EINVAL for a malformed line, ENOENT for what is not there --
+a directory gone, a Find or Grep with no hit -- else EIO or an errno that
+fits) and logs one `err` with the reason, no `msg`. A look that finds nothing is no failure: it answers
 nothing and logs one `err`. A command line run in a command pane is judged
 by its `exit` record. A word no builtin
 knows (a typo included) is a command line: written at a terminal at its
diff --git a/docs/fs.md b/docs/fs.md
index 8ca23c85..cb9d7a45 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -697,7 +697,8 @@ An address that does not evaluate fails the write with why: `bad address
 syntax`, `no match for regexp`, `address out of range`, `bad regular
 expression`, `regular expression search gave up, ...`, or sam's
 `addresses out of order` for a range that ends before it starts
-(`#100,#50`), which acme lets through. A failed write to `addr` leaves no
+(`#100,#50`), which acme lets through. Each end is checked first, so in a
+text shorter than 100 bytes `#100,#50` says `address out of range`. A failed write to `addr` leaves no
 address at all, where acme
 keeps the old one: until a good address is written, `addr` reads empty
 (as an unset `limit` does), and reading, writing or truncating `data` and
@@ -712,13 +713,15 @@ while `mark` is 1; to make a loop's writes one step, write `1` (an undo
 point here), then `0`, the writes, then `1` again.
 
 One rule for what fails: a write fails whenever what it asked for fails,
-whether it came to a `ctl` (the root's, a pane's, a column's), `look`,
-`exec`, `tagexec` or a column's `exec`, or to any other file -- with an
+whether it came to a `ctl` (the root's, a pane's, a column's, a pane's
+`pty/ctl` -- its `exec` included), `look`, `exec`, `tagexec` or a
+column's `exec`, or to any other file -- with an
 errno that fits, EINVAL for malformed input (an unknown word, a control
 character, a command line over 1024 bytes, a `size` or `winsize` out of
 range, a bad address or event record), else EIO or the errno the words
-name (ENOENT for a pane or file gone, ENOSPC for no room or slot, EBUSY
-for a held lock) -- and logs its reason exactly once, as `err <serial|->
+name (ENOENT for a pane, file or directory gone and for a Find or Grep
+that finds nothing, `grep: no match, not found`, ENOSPC for no room or
+slot, EBUSY for a held lock) -- and logs its reason exactly once, as `err <serial|->
 <file>: <why>`, with no `msg` for it. A builtin a click runs (Save, get's
 `Modified`, Tty with no room, Edit) is no exception. What is not a
 failure: a look that finds nothing answers nothing and logs one `err`