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-linux-open-flags.md

@@ -0,0 +1,37 @@
+---
+name: schunix-linux-open-flags
+description: "include/fcntl.h must hold Linux's open-flag values — the userland is all Linux-ABI, and a mismatch silently corrupts files"
+metadata: 
+  node_type: memory
+  type: project
+  originSessionId: a665e14b-86bd-4b41-a228-51377f3e9225
+  modified: 2026-08-03T13:59:19.392Z
+---
+
+**`include/fcntl.h` holds Linux x86-64 open-flag values, and must keep holding
+them.** Every program in the userland is built against a libc that sends Linux
+values; the kernel reads them with these constants. Do not "tidy" them into a
+neat sequence — they are an external interface.
+
+They disagreed until 2026-08-03, and the symptoms looked like filesystem
+corruption rather than a header mistake:
+
+- Linux `O_APPEND` (0x400) landed on Schunix's `O_TRUNC`, so **`cmd >> file`
+  truncated** the file it was supposed to extend.
+- Linux `O_TRUNC` (0x200) landed on `O_CREATE`, so **`cmd > file` did not
+  truncate** and left whatever was past the new end in place.
+
+Found by making `tools/bootcheck.ps1` do ordinary shell work — write a file,
+append to it, `wc -c` the result — instead of only booting to a prompt. The
+byte count was the only thing that said which failure had happened. See
+[[schunix-verify-by-driving-shell]].
+
+Two related traps fixed at the same time, both worth re-checking after any
+syscall work:
+
+- `sys_openat` silently dropped `O_TRUNC` and `O_APPEND` while `sys_open`
+  honoured both, so the same redirection behaved differently depending on which
+  entry point libc called. **Any flag handled in one must be handled in both.**
+- `rmdir` was `NO_LINUX` in `kernel/sys/table.inc`, so every Linux-ABI program
+  got ENOSYS. A syscall with no Linux number is unreachable from userland —
+  see [[schunix-syscall-single-table]].