docs: four directories, and a rule for when a thing leaves the roadmap

docs/ was ten files where a plan, a description, a guide and a bug report all
sat next to each other. It is now architecture/ (what SchOS is), plan/ (what it
will be), guides/ (how to work on it) and history/ (why it is like this), with
an index that states the one rule holding it together: when something is
finished it moves from plan/ to architecture/ and is rewritten as a description
of the thing rather than a record of building it.

A ticked checkbox says the work happened. It does not say what the work
*produced*, and six months later the checkbox is all that is left. The network
stack proved the point: finished, verified end to end, and for a month the only
description of it anywhere was a checkbox four levels of indentation deep.

So roadmap.md went from 534 lines to 181 -- nothing deleted, the done work
graduated. Seven subsystems that were finished and undescribed now have
descriptions: boot, kernel, syscalls, filesystem, networking, graphics, usb,
init. Every one ends with "What it does not do", which is the section that pays;
a document listing only strengths is marketing, and the reader who needs it most
is the one about to trip over a limitation nobody wrote down.

schfs.md still opened with "phases 1 through 3 1/2 are done, phase 4 is next"
long after all five had landed. It is a description now, with the phase record
and the hard-won bugs moved to history/.

Three corrections found on the way, all load-bearing:

  * projects/schcom/README.md claimed SCM_RIGHTS was done. There is no
    sendmsg/recvmsg in the kernel at all, and an entire GUI plan rested on it.
  * The root README said "No TCP/IP" months after the stack landed.
  * history/kernel.md sec.7 was marked "in progress" on a problem that process
    groups solved.

Also adds plan/1.0.md, which draws a finish line so the open list stops being
infinite, and marks schwm/ and schde/ superseded: in Wayland the compositor is
the window manager, so that split dissolves rather than being abandoned.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2

README.md

@@ -4,7 +4,7 @@
 
 **A 64-bit operating system, written from the metal up.**
 
-SMP · copy-on-write filesystem · PCI, USB and virtio drivers · TrueType text · Linux syscall ABI
+SMP · copy-on-write filesystem · TCP/IP · PCI, USB and virtio drivers · TrueType text · Linux syscall ABI
 
 </div>
 
@@ -57,6 +57,10 @@ generation counter advancing as writes commit.
 displays, **xHCI** USB with HID, hub and mass-storage class drivers, IDE, PS/2,
 serial. `/dev/fb0` speaks the Linux fbdev interface.
 
+**Networking** — ARP, IPv4, ICMP, UDP, TCP and DHCP, on lwIP behind a
+driver-agnostic interface class. Verified end to end from the host, both
+directions, rather than by inspection.
+
 **Userland** — musl, toybox and mksh, built from source. `ls`, `cat`, `ps`,
 `top`, `wc`, `cp`, `mount` and the rest behave the way you expect, because they
 are the real programs.
@@ -80,9 +84,9 @@ make iso      # a bootable ISO for VMware or real hardware
 Builds on **Linux, macOS, FreeBSD/OpenBSD/NetBSD and Windows** (Git Bash). The
 toolchain is clang + lld everywhere — it is a cross-compiler by construction, so
 one LLVM install targets the bare-metal kernel, the 16-bit boot code and musl
-userland from any host. See **[docs/building.md](docs/building.md)** for
+userland from any host. See **[docs/guides/building.md](docs/guides/building.md)** for
 prerequisites per platform, and
-**[docs/moving-to-linux.md](docs/moving-to-linux.md)** for moving a checkout
+**[docs/history/moving-to-linux.md](docs/history/moving-to-linux.md)** for moving a checkout
 between machines.
 
 ## Testing
@@ -109,9 +113,14 @@ boot/       uefi/ (PE loader)  common/ (shared loader UI)
 lib/ cmd/   first-party userland runtime and programs
 ports/      third-party software built from source
 tools/      windows/ (.ps1)  posix/ (.sh)  python/ (.py)  and .c/.pl
-docs/       architecture, roadmap, licensing, building
+docs/       architecture/ (what it is)  plan/ (what's next)
+            guides/ (how to work on it)  history/ (why it's like this)
 ```
 
+**[docs/README.md](docs/README.md)** is the index. If you are reading the tree
+for the first time, [docs/architecture/README.md](docs/architecture/README.md)
+is the system layer by layer.
+
 One rule worth knowing: **the kernel and the host tools compile the same SchFS
 source**. `mkschfs` cannot disagree with the kernel about the on-disk format,
 because there is only one implementation — found and fixed on the host, where a
@@ -122,9 +131,16 @@ Another: **syscalls are declared in exactly one place**,
 
 ## Not there yet
 
-- No TCP/IP. The decision is made — port lwIP rather than write one — but it is
-  not done. The e1000 driver works; nothing speaks to it yet.
-- No compositor, window manager or desktop. That is the next large piece.
+- **No desktop.** Schcom composites and routes input; the plan is now to put it
+  on Wayland and delete the homegrown protocol. See
+  [docs/plan/wayland.md](docs/plan/wayland.md).
+- **No descriptor passing.** No `sendmsg`/`recvmsg`, so no `SCM_RIGHTS` — which
+  is what the GUI work stops at. [docs/plan/foundations.md](docs/plan/foundations.md).
+- **No dynamic linking.** `exec` handles static `ET_EXEC` only.
+- **No page cache**, so writable `MAP_SHARED` of a file is refused rather than
+  faked.
+- **A USB disk cannot be booted from** — the root device is compiled in rather
+  than selectable.
 - SchFS has no Linux driver yet; the plan is on-disk format version first, then
   FUSE, then a kernel module.
 - CFF/OpenType outlines and TrueType hinting are deliberately out of scope.