SchOS/docs/plan/README.md

What happens next

Everything in this directory is unbuilt. When a piece of it is finished it leaves — deleted from here, rewritten as a description in ../architecture/. See the rule.

Read 1.0.md first.

It draws the finish line, says where the system stands against it, and holds the register of unfinished work — the one place anything half-built is listed. No new capability starts until that register is empty, and a row leaves it only by being finished or by being deleted from the tree.

---

What is here

1.0.md	The finish line. What 1.0 is, the acceptance test and where each clause stands, the register, and everything explicitly deferred.
roadmap.md	Everything else that is scoped and agreed: storage and the installer, graphics, networking, the hardware that makes a laptop a laptop, SchFS beyond SchOS, the kernel's own gaps.
gpu.md	Linux's own amdgpu through LDLS, and the /dev/dri a process has to serve. Measured, with the work it needs written down.
finch.md	Later. The author's own LLVM language for SchOS's applications and tools in place of C. The language is finished and self-hosting in its own repository; the plan here is a target, bindings generated from include/uapi/, and the compiler in the image.
schapi.md	The long-term API layering and the compatibility promise. Direction agreed, nothing built.

What used to be here, and is built

Plans leave this directory when they are done. These did, and what replaced them is the description:

Was	Now
Descriptor passing, shared memory, sockets in the filesystem, dynamic linking, the event descriptors (foundations.md)	kernel.md, networking.md, syscalls.md
init.md	init.md
hybrid.md — drivers in processes, /dev/pci, a modeset API, the panic path, why USB stays	devices.md
ldls.md — Linux drivers in a process	ldls.md
debugger.md	debugging.md
alpine.md — an apk-managed root	packages.md
xorg.md — the desktop	desktop.md
The interactive crash screen (roadmap.md §4)	GMMOS, in graphics.md

And one that was decided against: wayland.md. Wayland needs DRM/KMS, libinput, udev and libseat, and DRM/KMS alone is a kernel graphics subsystem. The desktop is X. The reasoning moved to desktop.md. SchWM and SchDE, which were to be the window manager and the desktop on top of it, are gone from the tree: Window Maker is the window manager, and a panel or launcher is an ordinary client.

---

The order

Set by 1.0.md, which is the authority. In short:

1. Close the one open gate: decide what makes a root survive a reboot — the installer, or a narrower definition of 1.0 (see The one open decision there).
2. Empty the register. Delete projects/schcom/ and the unused in-kernel LDLS window, or say what they are for; build socket activation or remove the key.
3. Then, and only then, whatever roadmap.md says is next. GPU acceleration is the thing the laptop wants most (gpu.md), and Finch inside SchOS is the thing the author wants next (finch.md).

What this plan does not address

Stated here so it is not mistaken for covered:

• No IOMMU, so a driver in a process is isolated against its own bugs and not against a hostile driver.
• No page cache, so a general writable MAP_SHARED of a file is refused; memfd is the narrow answer.
• No installer, so nothing a live system writes survives a reboot.