memory: Schcom v0, and the order change that put it before the installer

Records that the GUI stack moved ahead of the installer, that Schcom v0
runs and how to prove it, the decisions behind the protocol shape
(Wayland-shaped, MIT so linkable, shm id rather than SCM_RIGHTS for now),
and the one-display-device trap in the screendump test.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.claude/memory/MEMORY.md

@@ -34,6 +34,7 @@
 - [QR encoder](schunix-qr-encoder.md) — kernel/core/qr.c for crash reports; `make qrcheck`, and the segno padding bug that is not ours.
 - [Boot splash and logo](schunix-boot-splash-logo.md) — the loader draws the logo, not the kernel; STAGE2_SECTORS was in five places and is now in one.
 - [SchAPI direction](schunix-schapi-direction.md) — Schunix as a macOS-shaped *system*; the stable ABI is a library, not the syscall table.
+- [Schcom v0](schcom-v0.md) - the compositor runs; Wayland-shaped, verified by checking pixels from the host.
 - [Roadmap and projects/](schunix-roadmap-and-projects.md) — the agreed order through to Schcom/SchWM/SchDE; the GUI and installer live outside the OS tree.
 - [Driver infrastructure](schunix-driver-infrastructure.md) — dynamic IRQ registration, a DMA arena, PCI capabilities; PCI interrupts are level/active-low.
 - [Network stack choice](schunix-network-stack-choice.md) — don't write TCP; lwIP over FreeBSD over NetBSD, with the licence evidence.

.claude/memory/schcom-v0.md

@@ -0,0 +1,66 @@
+---
+name: schcom-v0
+description: "Schcom v0 runs — surfaces, shm buffers, commit semantics, input routing; Wayland-shaped on purpose, verified by checking pixels from the host"
+metadata: 
+  node_type: memory
+  type: project
+  originSessionId: d4821aa9-2e49-40da-91e7-90ef9ed9997e
+  modified: 2026-08-09T21:12:35.466Z
+---
+
+**Schcom v0 works** (2026-08-09, commit fe64620). A client connects over a Unix
+socket, is handed a shared buffer, draws and commits; the compositor composites
+and presents. `projects/schcom/`.
+
+Both blockers its README listed had already been done — AF_UNIX sockets and
+`/dev/input/eventN` — so nothing was actually in the way when this started.
+
+## How to build and prove it
+
+```sh
+make ports        # once: the sysroot libc it links against
+make projects     # builds, stages into sysroot/bin
+make              # rebuild the image so the binaries are on it
+make schcom-test  # boots, runs it, checks the pixels FROM THE HOST
+```
+
+`make schcom-test` is the part that matters. It screendumps the framebuffer
+through the QEMU monitor and asserts three pixels: the client's colour in the
+middle of the surface, the compositor background away from it, and the white
+border exactly at the requested origin — so "the buffer arrived" and "the buffer
+arrived at the wrong offset" cannot pass for each other. The compositor's own
+report that it composited something proves nothing.
+
+**Run it with one display device.** The test passes `-vga std` and *not*
+`-device virtio-gpu-pci`: with two, `screendump` captures whichever QEMU thinks
+is active, which need not be the one `/dev/fb0` maps.
+
+## The decisions worth not re-litigating
+
+- **Wayland-shaped from the start.** Surfaces, not windows; nothing visible
+  until `COMMIT`; the compositor tells clients when to draw. Wayland is
+  **MIT-licensed**, so linking it later is fine under Apache-2.0
+  ([[schunix-licensing]]), and Nexoniarz intends to add it.
+- **The one deliberate divergence:** a buffer handle is a System V shm id, not
+  an fd over `SCM_RIGHTS`. `struct schcom_surface` has a `handle_kind` field so
+  the switch is a new value, not a protocol break.
+- **The compositor owns the shm segment**, never the client — it must survive a
+  client dying mid-frame and must not be resizable underneath it.
+- **Every message carries its own length**, so an unknown message is skipped
+  rather than desynchronising the stream. That is what lets a v0 compositor talk
+  to a v1 client.
+- **Back buffer, one copy out.** Compositing straight into the framebuffer shows
+  every intermediate state.
+- **Placement is not Schcom's.** `CREATE_SURFACE` carries x/y only because there
+  is no SchWM yet to ask.
+
+## Not done
+
+Damage tracking (it repaints everything), multiple outputs, subsurfaces, any
+focus model beyond "topmost", and mode setting. All additions rather than
+rewrites — which was the reason for committing to surface/commit now.
+
+**SchAPI / `libschunix` is still not started.** See
+[[schunix-schapi-direction]]: the stable ABI is meant to be a library, not the
+syscall table, and Schcom currently talks to musl and raw syscalls like anything
+else. Nothing about Schcom blocks it.

.claude/memory/schunix-roadmap-and-projects.md

@@ -48,7 +48,17 @@ size, and dedups across images. Most of it exists — `tools/mkschfs.c` and
 `tools/mkfs.c` already do content dedup with an `(st_dev, st_ino)` fast path.
 `mksip` should share that code.
 
-## The installer, scoped 2026-08-09
+## Order changed 2026-08-09: Schcom and SchAPI come before the installer
+
+Nexoniarz: the GUI stack is what is actually needed, the installer can wait.
+**Schcom v0 is done** — see [[schcom-v0]]. SchAPI/`libschunix` is still not
+started, and is the other half of what was asked for.
+
+`projects/` has build glue now: `make projects` builds against the sysroot libc
+and stages into `sysroot/bin`. It is not a dependency of the OS build and
+`make` never descends there.
+
+## The installer, scoped 2026-08-09 (deferred, not cancelled)
 
 **A live CD is off the list.** The ISO boots a complete system from the
 ramdisk, so it already is the live environment; an installer makes a mountable