1 files changed, 50 insertions, 0 deletions
diff --git a/next-steps.txt b/next-steps.txt
index 3546da42..60605edc 100644
--- a/next-steps.txt
+++ b/next-steps.txt
@@ -2,6 +2,56 @@ WHAT THIS IS: a wishlist, in the author's own words. The items below are left
 exactly as written; this header is the only thing kept in sync with the code,
 because a list that reports shipped work as pending is worse than no list.
 
+9P (docs/9p.typ is the note, docs/registry.typ the argument). SIX NEW THINGS,
+each verified against a running program and not assumed:
+
+1. A DETACHED SESSION CAN BE SCRIPTED. `pardes --detach=work --fs` mounts its
+   own /dev/fuse and polls it in the same poll(2) as its frontends and pane
+   shells, so it needs no wake thread — less than the desktop shells pay. The
+   one configuration whose panes outlive every terminal was the one no script
+   could reach. Proof: examples/acmefs/pardesctl panes|new|send|body|del.
+
+2. TERMINALS ARE SCRIPTABLE. Every terminal pane grows `pty/ctl`, `pty/status`
+   and `pty/data`. `winsize 80 24`, `sig INT|TERM|HUP|QUIT|KILL`, `exec`; a
+   write to `pty/data` is input to the process and a read is its RAW output,
+   escape sequences and all. A script could only ever write into a terminal
+   that already existed; now it can start one, resize one and signal one.
+
+3. THE TREE IS SERVED OVER 9P. `--fs9` puts acme's control filesystem on a unix
+   socket as base 9P2000 (src/9p.zig — codec and a sans-io server, no threads,
+   no allocator, builds freestanding). plan9port drives it: `9p -a <sock> ls /`,
+   `read /index`, `write /1/body`, `stat`, a walk through `..`. Errors come back
+   as STRINGS Linux's table knows, not numbers. `--fs` and `--fs9` serve the
+   same tree at once: a write over one reads back through the other.
+
+4. A PATHNAME WITHOUT MOUNTING ANYTHING OURSELVES. `9pfuse <sock> <dir>` and
+   ordinary tools work — ls -l with the right modes, cat, shell `>>`, permission
+   denied on the write-only files. That is the route macOS and the browser take,
+   neither of which has ever had a control filesystem.
+
+5. ONE PARDES READS ANOTHER. The `9p <dial> <path>` word walks another
+   instance's tree and opens the bytes in a pane. Before this, two instances
+   could shout one line at each other (nested.zig, write-only, no reply) or
+   REPLACE one another (`Attach` deinits the local core); they could not ask a
+   question. Proof: B read A's /1/body byte-identically to plan9port.
+
+6. THE BOARD SERVES ITS OWN TREE. A second ESP32-P4 image where UART0 carries
+   9P and nothing else — no ANSI, no vaxis, no allocator — 88 KB against the
+   console image's 809 KB. Its GPIO tree comes from a comptime table
+   (src/board9p.zig) that is the single description: one entry fans out to a
+   directory per pin. The console firmware is untouched and still what
+   `-Dplatform=esp32p4` feeds. No board was attached, so only what builds and
+   what the host tests cover is claimed.
+
+AND ONE THING THAT WENT AWAY: pardes no longer depends on the ../05-zig-p4
+toolchain checkout to build. It used to be a path dependency named in
+build.zig.zon, and because `@import` in a build script resolves when the SCRIPT
+compiles rather than when the branch needing it is taken, anyone without that
+sibling could not build pardes at all — not the firmware, the terminal shell.
+The object is the seam: `-Dplatform=esp32p4` emits it here with no toolchain,
+and the toolchain repository links the flashable images, which it already knew
+how to do.
+
 SHIPPED (verified against the tree, not assumed):
 - "version tracking" -> done. `build.zig` reads `.version` from build.zig.zon
   via an untyped `@import`, `gitCommit(b)` reads the commit at configure time,