Carry project memory in the repo, with tools/memory-sync.sh

Claude Code keeps per-project memory at <home>/.claude/projects/<key>/,
where <key> is the project's absolute path with every separator and the
drive colon turned into a dash. That makes it both rename-fragile and
machine-specific, and this project has hit each of those once:

  - D:\DEV\Schunix -> D:\DEV\SchOS changed the key, and 43 memories were
    invisible until moved across by hand.
  - Development happens from Windows and from Linux, and each looks in a
    different place for the same checkout.

Committing .claude/memory/ fixes both -- git carries it across renames
and between hosts -- and `import` puts it wherever the local machine
expects. .claude/settings.local.json stays ignored: those are per-machine
permissions.

The colon maps to a dash rather than being dropped. Deleting it gives
D-DEV-SchOS, which matches nothing and silently finds zero memories; that
was the first attempt. On Git Bash the key comes from `cygpath -w`,
because Claude Code is a Windows program and sees D:\DEV\SchOS, not
/d/DEV/SchOS.

.claude/memory/schunix-doom-acceptance-test.md

@@ -0,0 +1,46 @@
+---
+name: schunix-doom-acceptance-test
+description: "The full-stack acceptance test (a ported 1993 shooter) was removed on 2026-08-08 — what it found, why it went, and what to do instead."
+metadata: 
+  node_type: memory
+  type: project
+  originSessionId: 9d8a2aef-bcf0-47a0-96c6-f706efab4a95
+  modified: 2026-08-08T12:19:38.682Z
+---
+
+**Removed 2026-08-08 at Nexoniarz's request** ("we don't need it anymore because
+we know that doom works"). Do not re-add it, and do not reintroduce the name into
+comments — they also asked for trademark words to be cleared from the tree, and
+it is now at zero references outside `dist/`.
+
+Deleted: `ports/fbdoom/`, `tools/doomtest.ps1`, `tools/doomtest2.ps1`, the
+`doom`/`doomtest`/`doom-uninstall` Makefile targets, `NOTPORTS := fbdoom`.
+**The WADs were moved, not deleted** — `dist/wads/` — because `doom1.wad` was a
+shareware download that existed nowhere else in the tree, while `freedoom1.wad`
+is recoverable from `dist/freedoom-0.13.0.zip`.
+
+**What it was worth, because the shape is worth repeating.** A large program
+somebody else wrote, exercising `/dev/fb0`, evdev, `mmap`, the ELF loader,
+`gettimeofday` and a fixed-rate tic loop at once, is harsher than any in-house
+test *because it was not written against our bugs*. It found: the
+`fcntl(F_SETFL, O_NONBLOCK)` no-op; the evdev backlog replayed to each new
+opener; and the missing `EVIOCGRAB`. All fixed, all now covered by
+`tools/bootcheck.ps1 -Evdev` / `-Sock` — which are narrower and do **not** prove
+the whole stack composes. That is the honest cost of the removal.
+
+**Why it went beyond being asked:** ~100k lines of GPL-2.0 engine on
+non-redistributable shareware data, whose safety depended on two separate
+opt-outs (`NOTPORTS` and `RAMDISK_EXCLUDE`) both staying correct — and the
+ramdisk is linked *into the kernel binary*, so a slip there makes the kernel
+undistributable, not just the image. See [[schunix-ramdisk-root-sizing]] and
+[[schunix-licensing]].
+
+**Two techniques from it that transfer:**
+- Assert on *pixels*, not log lines. A log-only harness once passed on a blank
+  screen. `tools/splashshot.ps1` counts distinct colours for this reason.
+- For a crash inside a program you did not write, run `llvm-nm` against the
+  faulting `rip` to get a function name, then use the fault offset to identify
+  the exact field. "Null pointer plus 24" alone is nearly useless.
+
+Both lessons are written up in `docs/roadmap.md` Phase 7 and
+`docs/architecture/kernel-history.md` §10 and §12, with the program genericised.