fs.md says a line held to the close reports its failure only as the log's err, and that a script needing the result ends its write with a newline

fs.md said an Edit block never ended "fails at the close" with
``unmatched `{'``, which reads as the close failing. The close reports no
error (round 24's decision: no clunk-time errors), and the write that sent
the block had already succeeded. The failure is only the log's err record.
The same holds for the tail of a 4096-multiple write that the close runs.
fs.md now says so, gives both err texts, and tells a script that needs a
line's result to end its write with a newline. tree.zig's "an Edit block
still open when its open closes fails there with an err and changes
nothing" is the test.

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

1 files changed, 7 insertions, 2 deletions

diff --git a/docs/fs.md b/docs/fs.md
index 020fce58..7111de1c 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -160,8 +160,13 @@ whole, so its last line runs even without a newline (`printf Save > exec`),
 unless it is a multiple of 4096 bytes: that is where a writer's buffer (stdio,
 a mount's page cache) filled and cut a line, so its tail waits for the next
 write or the close. An `Edit` whose `{` or
-`a`/`c`/`i` text is still open waits for the next write on that open, and
-fails at the close if it never ends (``unmatched `{'``). A line held past
+`a`/`c`/`i` text is still open waits for the next write on that open. A
+line held to the close (a 4096-multiple write's tail, an `Edit` block never
+ended) runs there, and its failure is only in the log, as its `err` record
+(``err <serial> ctl: unmatched `{'`` or `a, c or i text not ended by a .
+line`): the close itself reports no error, and the write that sent it had
+already succeeded. A script that needs a line's result ends the write with
+a newline, so the line runs, and fails, with its write. A line held past
 1 MiB is refused.
 
 **Answers.** Reading `look`, `exec` or `tagexec` answers the serials the