The docs: the raw paste's second Enter, event flags and write-back, a new Tty's ls

Round 14's doc findings: a raw pty/data paste of more than one line needs
the second \r unless it ends in a newline (not only an indented last
line); the event flag bits (1 builtin, 2 expansion, 4 filename, 8
chorded, with its two records) and what writing back each record kind
does; why a new Tty types ls; and the sam box's N+1 for text without a
final newline (out of range).

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

2 files changed, 21 insertions, 10 deletions

diff --git a/.agents/skills/pardes-9p/SKILL.md b/.agents/skills/pardes-9p/SKILL.md
index f0ae51e4..c9b1be23 100644
--- a/.agents/skills/pardes-9p/SKILL.md
+++ b/.agents/skills/pardes-9p/SKILL.md
@@ -181,9 +181,10 @@ command pane shows `exit ?` and does not run again, and REPLs are unbound. Multi
 written to `pty/data` should be a bracketed paste, `\e[200~<code>\e[201~`,
 then, in a separate write once the REPL has echoed the paste (Python 3.13+
 takes a `\r` read with the paste as part of it, even for one line), `\r`.
-End the pasted code with a newline and that one `\r` runs it; without one, a
-code whose last line is indented (a `def` or `for` body) needs a second
-`\r`, as one Enter leaves such a block open. Sent line by line, a blank line ends a Python block, and Python
+A paste of one line needs that one `\r`; a paste of more than one line
+needs a second `\r` unless the pasted code ends in a newline (one Enter
+leaves a multi-line input at `...`). A middle click, or an event
+write-back, sends what it needs by itself. Sent line by line, a blank line ends a Python block, and Python
 3.14's REPL auto-indents each line it is typed. Every refused 9P write adds an `err <serial|->
 <file>: <why>` record to `$m/log`; through a mount the write itself only says
 `Invalid argument`.
@@ -218,8 +219,9 @@ env printf 'Edit ,x/foo/{\ni/</\na/>/\n}\n' > $pane/ctl
 > **sam gotchas** (as sam does them, pardes too)
 > - `$-1` is the last line when the text ends in a newline (`a\nb\n`: `b\n`),
 >   but the one before it when it does not (`a\nb`: `$` is on `b`, so `a\n`).
-> - A line past the end is the empty line there, not an error: `N+1` at the
->   last line is `#<len>,#<len>`; only the line after that is out of range.
+> - With a final newline, the line after the last is the empty place at the
+>   end, not an error: `N+1` at the last line is `#<len>,#<len>`. Without one
+>   (`a\nb`), the last line runs to the end and `N+1` is out of range.
 > - `^` and `$` match at the text's end too: `/^/` from the end finds the
 >   empty place after a final newline.
 > - `2,1` is no error: it is `#<start of 2>,#<end of 1>`, an empty range at
diff --git a/docs/fs.md b/docs/fs.md
index 7c13d223..1e65bd00 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -386,9 +386,8 @@ is no gesture and is never sent: a script writes to the REPL pane's
 `pty/data`, multi-line code as a bracketed paste (`\e[200~<code>\e[201~`,
 then `\r` in a write of its own once the REPL has echoed the paste --
 Python 3.13's REPL takes an Enter read with the paste as part of it, even a
-one-line one -- and, only when the pasted code does not end in a newline
-and its last line is indented, a second `\r`: one Enter leaves such a block
-open; a middle click does all of this
+one-line one -- and, for a paste of more than one line that does not end
+in a newline, a second `\r`: one Enter leaves a multi-line input at `...`; a middle click does all of this
 itself, holding the Enter until the REPL answers the paste), since line by line a blank line ends a Python block and Python
 3.14's REPL auto-indents each line typed into it. The REPL gets the text
 wherever it is -- at a `pdb` or `input()` prompt too. Over 9P, a range of a
@@ -655,7 +654,9 @@ an open renders its frame; stat the entry.
 `/log` is one ring (64 KiB) that records whether or not anyone reads it:
 `new`, `del`, `rename` (a terminal's too, as its shell changes directory --
 a new terminal is `new N /` until its shell says where it is, then renamed;
-it runs `ls` once at its first prompt, a greeting that shows the directory --
+it runs `ls` once at its first prompt, a greeting that shows the directory
+it opened in, since a terminal is named by its directory and nothing else
+on it says where it is --
 since a terminal is named by its directory), `exit <serial> <N>` before
 the `del` of a terminal whose shell exited by itself, `ask <serial> <what>
 <choices>` when a pane asks a question (answered by `answer` on its ctl),
@@ -707,7 +708,15 @@ files, the editor's own lines), `K` (the keyboard) or `M` (the mouse); the
 action's case says where: `x`/`l` a click executed or looked at in the tag
 (its offsets count the tag's whole text, path included, as `tag` reads),
 `X`/`L` in the body, `I`/`D` text put in or taken out of the body, `i`/`d`
-of the tag. Read `n` bytes of the text, not up to a newline -- bytes here, where acme counts runes. Every offset and
+of the tag. The flag is acme's: 1 the text is a builtin's word, 2 the range
+was expanded from a click (a second record gives the original range), 4 (a
+look) the text is a file name or address, 8 (an exec) chorded: two records
+follow, the argument's text and where it came from, `<file>:#q0,#q1`.
+Written back, an `X`/`x` record executes and an `L`/`l` record looks, as
+the click would have (a chorded one with its argument); the origin letter
+written back is ignored but for `F` on `X`, which runs as the command it
+was rather than going to a bound REPL; `I`, `D`, `i` and `d` are reports and
+are refused. Read `n` bytes of the text, not up to a newline -- bytes here, where acme counts runes. Every offset and
 count pardes serves is in bytes, `#n` and `q0`/`q1` too; the event count
 follows them rather than switch alone, so an acme library reads pardes
 correctly for ASCII text and not beyond it. Offsets are bytes, but every