A command line runs as its own command pane unless it is clicked at a shell's prompt

A middle click, an exec write or a tag word that no builtin knows was typed
into some terminal for the pane's directory, sharing whatever state that
shell was in and answering nothing, so a misspelling vanished into a shell.
Now only a line clicked at an interactive terminal's prompt is typed there.
From anywhere else it runs as a command pane: a terminal whose child is
$SHELL -c the line in the pane's directory, full emulation, which shows its
output and then exit N from the host's reaping of the child, and stays. A
finished command pane is the next command's for its directory, which runs
below what it showed after a '% line' line (acme appends to +Errors and never
clears it, util.c:213); a running one gets a second pane. Kill ends a command
pane's whole process group, the log records run and exit, exec reads back the
command pane's serial, and a line is at most 1 KB, read off the pane as the
host forks rather than carried in every spawn effect. ttyForDir's search for
a free shell is gone. The goldens of chordcut, cmdword and layout-open change
where a file's exec now opens a command pane, and ttytaken is rewritten to
exec from the terminal itself; docs/open-questions.md records the decision.

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

2 files changed, 33 insertions, 11 deletions

diff --git a/docs/fs.md b/docs/fs.md
index f98a1ae0..3efc5b36 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -123,9 +123,10 @@ and opens into the new editor, which acme, whose Load only adds windows,
 never needed); and `Kill`, which
 does not quit but stops commands, as acme's does: bare, every command pardes
 started, and `Kill make ls`, those whose line begins with one of the words. A
-command pardes started is a line it typed into a terminal (a word written to
-`exec`, a middle click on one, a `pty/run`), from its shell's start mark (C)
-to its end mark (D); Kill sends its foreground job SIGTERM -- acme posts the
+command pardes started is a command pane's, until its child exits -- Kill
+sends its whole process group SIGTERM -- or a line it typed into a terminal (a
+word written to `exec`, a middle click on one, a `pty/run`), from its shell's
+start mark (C) to its end mark (D), where Kill sends its foreground job SIGTERM -- acme posts the
 "kill" note, which ends a process -- and never signals the shell itself;
 in a shell running without job control (`set +m`) the job shares the
 shell's group, so there is none to signal: Kill says `Kill: no job to
@@ -232,13 +233,19 @@ same tree without leaving the process.
 - a line written to `exec` is a middle click: a command word from
   `src/builtins.zig` (`Save`, `Del`, `New`, `Newcol`, `Mount NAME DIAL`,
   `Unmount NAME`, `Dump`, `Restore`, `Msg TEXT`, `Find`, `Grep`, `Tty`, ...),
-  or anything else, which is typed into a terminal: the pane itself when it
-  is a terminal at its prompt, otherwise a terminal in the pane's directory
-  that is at its prompt, and failing both a new one made below the last
-  column. That is not an error, whatever the shell makes of the line, and a
-  misspelled builtin word ends up there too (whether it should is an open
-  question, docs/open-questions.md). `echo Tty > pane/<n>/ctl` makes a
-  terminal in that pane's directory outright.
+  or anything else, a command line. Written at a terminal at its prompt it
+  is typed into that shell. From anywhere else -- a file, a scratch, a tag,
+  a terminal whose tty a program holds -- it runs as a command pane: a
+  terminal whose child is `$SHELL -c` the line in the pane's directory,
+  which shows its output and then `exit N` (its tag reads `<dir> (<line>)
+  running`, then `exit N`), and stays. The directory's next command runs in
+  that pane once it is done, below what it showed, after a `% <line>` line;
+  one still running gets a second pane. A command pane's own exec starts
+  the next command there too. The log says `run <serial> <word>` and `exit
+  <serial> <N|?>`; `exec` reads back the command pane's serial; Kill ends
+  its whole process group; a line is at most 1 KB. A misspelled word is a
+  command that says so and ends `exit 127`. `echo Tty > pane/<n>/ctl` makes
+  an interactive terminal in that pane's directory.
 
 The root's pair clicks at the active pane and `/pane/<n>/look` and
 `/pane/<n>/exec` at that pane. Blank lines are skipped, and every other line
diff --git a/docs/open-questions.md b/docs/open-questions.md
index db491213..a2ce2086 100644
--- a/docs/open-questions.md
+++ b/docs/open-questions.md
@@ -6,7 +6,22 @@ picked up without redoing the research.
 ## Where does an unknown command word run?
 
 Raised 2026-09-27 in the review of pardes against acme (Plan 9 source at
-`~/05-genizah/principia-softwarica`). Undecided.
+`~/05-genizah/principia-softwarica`).
+
+**Decided 2026-09-28: a command pane.** Clicked or written at an interactive
+terminal at its prompt, the line is typed into that shell, whose state the
+clicker can see. From anywhere else it runs as its own terminal pane whose
+child is `$SHELL -c` the line in the pane's directory: full emulation
+(colours, `less`, `vim`, `sudo`'s prompt work), the exit status from waiting
+on the child (`exit N`, `exit 127` for a misspelling, no prompt marks
+needed), Kill signalling its process group, `run`/`exit` records in the log,
+and `exec` answering its serial. One command pane per directory is reused
+once done, and keeps what it showed, as acme appends to `+Errors` and never
+clears it (util.c:213-221). Chosen over acme's process-into-`+Errors` because
+it keeps interactive programs working without a streaming runner, and over
+a PATH check before typing into a shell, which misjudges builtins, aliases
+and functions and leaves the shell's state in the way. The analysis below is
+what it was decided from.
 
 **Today.** A middle-click, an `exec` write or a tag word that is not a builtin
 is typed into a terminal pane: the pane itself when it takes a command line,