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

projects/README.md

@@ -49,7 +49,7 @@ the other way, and nothing here is a dependency of the kernel build.
 ## Status
 
 All four are scoped and none is started. What each is waiting on is written
-in its own README, and the ordering is in `docs/roadmap.md`.
+in its own README, and the ordering is in `docs/plan/roadmap.md`.
 
 The short version: Schcom cannot start until the kernel has **unix domain
 sockets** (for the client protocol and for passing buffer handles) and **raw

projects/schcom/README.md

@@ -54,7 +54,7 @@ make schcom-test     # boots it and checks the pixels
 | Framebuffer geometry via the fbdev ioctls | done |
 | Unix domain sockets | done |
 | Raw input events — key down/up with modifiers | done |
-| `SCM_RIGHTS` | done, and **not yet used** — see below |
+| `SCM_RIGHTS` | **not implemented** — there is no `sendmsg`/`recvmsg` at all |
 | Mode setting and double buffering | partial — virtio-gpu binds, no modeset API yet |
 
 ## Design notes
@@ -75,15 +75,24 @@ make schcom-test     # boots it and checks the pixels
 
 ## On Wayland
 
+> **Decided: Schcom moves onto Wayland**, replacing the protocol below while
+> keeping the architecture. See [`docs/plan/wayland.md`](../../docs/plan/wayland.md).
+
+
 The protocol is deliberately Wayland-shaped — surfaces rather than windows,
 buffers attached and made visible only on commit, and the compositor telling
 clients when to draw. Wayland is **MIT-licensed**, so it can be linked against
-without any conflict with Apache-2.0 (see `docs/architecture/licensing.md`), and
+without any conflict with Apache-2.0 (see `docs/licensing.md`), and
 supporting it later is intended.
 
 The one place v0 knowingly diverges: a buffer handle is a System V shared memory
 id passed as an integer, where Wayland passes a file descriptor over
-`SCM_RIGHTS`. The kernel supports `SCM_RIGHTS` already; an integer simply needs
-no ancillary-data handling on either side. `struct schcom_surface` carries a
-`handle_kind` field precisely so that switching is a new value rather than a
-protocol break.
+`SCM_RIGHTS`. `struct schcom_surface` carries a `handle_kind` field precisely so
+that switching would be a new value rather than a protocol break.
+
+**That field cannot save us, and this README used to claim `SCM_RIGHTS` was
+done.** It is not — there is no `sendmsg`/`recvmsg` in the kernel at all. And
+Wayland's `wl_shm_create_pool` passes a descriptor with no alternative form, so
+*our* protocol being flexible is not the flexibility that is needed. Adding
+descriptor passing is item 1 of
+[`docs/plan/foundations.md`](../../docs/plan/foundations.md).

projects/schde/README.md

@@ -1,5 +1,12 @@
 # SchDE — the SchOS Desktop Environment
 
+> **Superseded as a directory, not as an idea.** A panel, a launcher and a
+> settings app are ordinary Wayland clients using `wlr-layer-shell`. This
+> directory is to be deleted; they need no home of their own until one of them
+> is written.
+>
+> See [`docs/plan/wayland.md`](../../docs/plan/wayland.md).
+
 The parts you actually look at: a panel, a launcher, settings, a file
 manager, a terminal.
 
@@ -16,7 +23,7 @@ designing a panel before there is a compositor to put it on.
 ## What it will need that does not exist yet
 
 - **Text rendering.** Everything here is text, and the console's fixed 8×16
-  CP437 grid is not usable for it. See phase 4 of `docs/roadmap.md` — a real
+  CP437 grid is not usable for it. See `docs/plan/wayland.md` — a real
   glyph cache and rasteriser, and layout as a library in `lib/` so the
   terminal and the file manager are not each solving it.
 - **A widget toolkit**, however small. Even a panel needs buttons, labels and

projects/schwm/README.md

@@ -1,5 +1,12 @@
 # SchWM — the SchOS Window Manager
 
+> **Superseded.** In Wayland the compositor *is* the window manager — there is
+> no protocol by which a second process places another's windows. This directory
+> is to be deleted, and what it argues for survives as a module boundary inside
+> Schcom rather than a process boundary.
+>
+> See [`docs/plan/wayland.md`](../../docs/plan/wayland.md).
+
 Policy. Where windows go, which one has focus, what happens when you drag a
 title bar, how alt-tab behaves, what a window looks like at its edges.