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/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.