docs: README, plan, guides and the site describe what is built now

README: rewritten around what runs (Linux software, Xorg, apk, Linux's drivers), the honest gaps, measured numbers.
plan/: 1.0.md is the finish line, where each clause of the acceptance test stands, and the register (one failing
clause: a root that survives a reboot); built plans (foundations, hybrid, alpine, xorg) and the decided-against one
(wayland) are gone, their content lives in architecture/; roadmap.md is only what is still open.
guides: building/layout/testing/adding-a-driver (Linux code may be used). history: four entries (ls -lR, TLB
shootdowns, MDIO 0x02460246, netlink MSG_TRUNC). Website: cards, stack, download page, docs index.
Code comments that pointed at deleted plan docs point at the architecture docs.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EVRhxi9zpdW2uDUN4FVcao

docs/guides/testing.md

@@ -12,7 +12,7 @@ reporting that it started.
 
 | | What it runs | What it proves |
 |---|---|---|
-| `make schfs-check` | Host-native unit suites | The filesystem's logic, in about a second |
+| `make schfs-check`, `make kmem-test`, `ldls-inspect`/`ldls-run` | Host-native unit suites and the Linux-module loader run on the build machine | The filesystem's logic, the slab allocator's bookkeeping, and a `.ko`'s layout, in about a second |
 | `tools/windows/bootcheck.ps1` | A real boot, driven over the serial console | That the system answers correctly |
 | `make crashqr`, `make schcom-test` | A boot, then pixel assertions from the host | That the *screen* is right |
 
@@ -77,6 +77,22 @@ dropped every byte would pass any check made from one side alone.
 Under QEMU's user-mode networking the host is `10.0.2.2` seen from inside, and
 SLIRP connects to the host's loopback — so the listener binds there.
 
+## Test programs that run on SchOS
+
+Several first-party programs in `cmd/` exist to be run **on** the system and print which of their checks
+failed, because only the system can say whether its own interfaces behave. `bootcheck` runs the ones it
+can; the rest are run by hand or by a script:
+
+| | Checks |
+|---|---|
+| `socktest`, `nettest`, `netecho` | Unix and INET sockets, `SCM_RIGHTS` and credentials, `setsockopt`'s refusals |
+| `shmtest`, `memfdtest` | System V shared memory; `memfd` mapped by two processes, and one sent over a socket |
+| `pcitest` | `/dev/pci`: claim, map, DMA, interrupts, release |
+| `evtest`, `locktest`, `sigtest` | the event descriptors; `flock` and record locks; signals |
+| `dynhello` | dynamic linking: TLS, the heap, a forked child that still has its libraries |
+| `xready` | every kernel call Xorg makes, before Xorg is started — the evdev queries, the fbdev ioctls, the console calls, the `/sys` files |
+| `tools/python/ldls_check.py` | what LDLS needs from a kernel's BTF |
+
 ## Pixel assertions
 
 ```sh
@@ -148,10 +164,12 @@ leak.
 - **No automated test runs on real hardware.** Everything above is QEMU.
 - **SMP is exercised but not stressed** — boots on 1, 2 and 4 processors are
   checked; nothing hunts for races.
+- **Nothing asserts the desktop by pixel.** `xready` checks the calls Xorg makes; whether Window Maker
+  and an `xterm` appear on a real screen is looked at in screenshots, not asserted.
 - **No fuzzing anywhere**, and no `fsx`/`xfstests` against SchFS. Getting SchFS
   under those is the main argument for the FUSE implementation in
   [../plan/roadmap.md](../plan/roadmap.md).
 - **The SchFS round-trip test needs symlinks and hard links**, so it skips on a
   Git Bash host and only runs on Unix.
-- **`make ports` does not work on Windows.** musl, toybox and mksh must be built
+- **`make ports` does not work on Windows.** musl, toybox, mksh and the rest must be built
   once on a Unix host and staged.