# 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/](../architecture/). See [the rule](../README.md#the-rule-that-keeps-this-from-rotting).

> ## Read [1.0.md](1.0.md) first.
>
> It draws a finish line and puts most of the work below on the far side of it.
> **Anything not named there is not being worked on**, and the documents in this
> directory describe more than 1.0 contains.

---

## The three current decisions

Taken together, because they turn out to need the same foundation.

| | |
|---|---|
| **[wayland.md](wayland.md)** | The GUI stack becomes Wayland. SchWM and SchDE are deleted; Schcom survives and changes its wire format. |
| **[hybrid.md](hybrid.md)** | The kernel becomes hybrid — drivers move out into userspace processes, starting with the GPU. |
| **[init.md](init.md)** | PID 1 stops being a process and becomes a role the kernel guarantees is filled. |

And the one they all wait on:

| | |
|---|---|
| **[foundations.md](foundations.md)** | Descriptor passing, shared memory, sockets in the filesystem. The critical path. |

And the one that says which parts of the above are actually being worked on:

| | |
|---|---|
| **[1.0.md](1.0.md)** | The finish line. Four gates, and everything else explicitly deferred. |

Two longer-horizon documents sit behind these: [schapi.md](schapi.md), the API
layering and the compatibility promise, and [roadmap.md](roadmap.md), which holds
everything still open that is not one of the three above.

---

## The order

Set by [1.0.md](1.0.md), which is the authority. In short:

### 0. Fix what is already wrong — **first**

Not a document of its own; it is Gate 0 of [1.0.md](1.0.md), assembled from the
*What it does not do* sections in [../architecture/](../architecture/).

**Before any new capability**, and the reason is the one that put
`netdev_selftest()` before the TCP/IP stack: a compositor built on a kernel with
an unexplained hang and a socket layer that reports success for things it did not
do will fail in ways indistinguishable from its own bugs.

### 1. `foundations.md` — the critical path

Both the Wayland work and the hybrid work stop here. Descriptor passing and
shared memory are the substrate for handing a buffer to a compositor *and* for
handing a device to a driver process. **Doing it once for both is the entire
reason these are one plan rather than three.**

### 2. `init.md` — before the desktop, not after

A compositor being brought up for the first time crashes constantly, and
something that restarts it and says why is worth far more during that work than
at the end of it.

### 3. `wayland.md` — with the GPU driver still in the kernel

W1–W3 and a terminal. W4 and W5 are post-1.0.

### 4. `hybrid.md` — **after 1.0**

Deliberately last: **designing a userspace driver interface with no driver
consuming it produces an interface that is wrong in ways nobody can see.** The
compositor is the demanding consumer that makes the interface judgeable, so it
has to exist first.

---

## In one sentence

> Fix what is broken, build the descriptor-passing and shared-memory substrate,
> make init survivable, put a terminal on the screen — and only then use the
> compositor as the pressure that shapes the userspace driver interface.

---

## What this plan does not address

Stated here so it is not mistaken for covered:

- **No IOMMU**, so the hybrid work isolates against bugs and not against a
  hostile driver.
- **No page cache**, so `foundations.md` delivers a `memfd` and not a general
  answer to shared file mappings. The general answer is still owed.
- **No dynamic linking**, so no Mesa, no accelerated clients, and no third party
  shipping a `.so` for anything.
- **A new compatibility surface** between PID 1 and PID 2, created by a plan
  whose own [schapi.md](schapi.md) §3 spends a section warning about those.
- **The three open networking items** — `getsockname`, routing, and
  interrupt-driven receive — are untouched by any of this and still open. They
  are in [roadmap.md](roadmap.md).