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 were removed from the tree as READMEs with no code: Schcom is its own window manager, and SchDE returns as ordinary clients of Schcom when there is a Schcom to build them on. Meanwhile the window manager is Window Maker.

---

The order

Set by 1.0.md, which is the authority. 1.0 is reached (a live system; persistence is not part of it). What is left before anything new starts:

1. Empty the register: decide the unused in-kernel LDLS window (delete it, or use it), build socket activation or remove the key, and give projects/schcom/ its first client.
2. Then, whatever roadmap.md says is next. The two things the owner wants most are the installer drawn by Schcom — SchOS's own compositor, and the road to SchDE (roadmap.md §5) — and GPU acceleration on the laptop (gpu.md). Finch inside SchOS (finch.md) comes after.

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 — by decision, for 1.0.