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

docs/licensing.md

@@ -68,7 +68,7 @@ specification rather than ported.
 ## 3. NetBSD in particular
 
 `src-trunk/` is a NetBSD checkout kept as reference material and a parts bin
-(see [architecture/schapi.md](architecture/schapi.md) §5). NetBSD is **not
+(see [plan/schapi.md](plan/schapi.md) §5). NetBSD is **not
 uniformly licensed**, and the difference matters per file:
 
 | Template | Status |
@@ -142,7 +142,7 @@ the FreeBSD Foundation and Juniper Networks -- all BSD-2 or BSD-3.
 
 So if BSD networking code is taken, it must come from **FreeBSD, not NetBSD**,
 and the specific reason is TCP. This reverses the earlier assumption in
-`docs/roadmap.md` that NetBSD was the intended starting point; NetBSD remains
+`docs/plan/roadmap.md` that NetBSD was the intended starting point; NetBSD remains
 the better-written reference to *read*, but FreeBSD is the one that can be
 copied from.
 
@@ -159,7 +159,7 @@ FreeBSD's `sys/netinet` is not a library -- `tcp_input.c` alone is 122 KB and
 reaches into mbufs, `epoch(9)`, netisr, VNET, `uma(9)`, sockbufs, inpcb hash
 tables and FreeBSD's locking. Taking it means porting FreeBSD's kernel
 infrastructure first and finding the TCP somewhere underneath, which is the same
-conclusion `docs/roadmap.md` §1 already reached about `sys/dev/usb`.
+conclusion `docs/guides/adding-a-driver.md` already reached about `sys/dev/usb`.
 
 lwIP was written for the case SchOS is in: a small operating system with a raw
 Ethernet driver and no infrastructure to speak of. Its port layer is a handful
@@ -225,7 +225,7 @@ has since been removed. It is worth recording *why* it was safe: it was never in
 `PORTS`, and its 33 MB of data was excluded from the ramdisk. It is equally
 worth recording that the safety depended on two separate opt-outs staying
 correct, which is a lot of standing risk for a test that had stopped finding
-bugs. See `docs/roadmap.md` Phase 7.
+bugs. See `docs/guides/testing.md`.
 
 ---