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-devfs-procfs.md

@@ -0,0 +1,49 @@
+---
+name: schunix-devfs-procfs
+description: "How /dev and /proc work in Schunix; ps and top work as of 2026-08-08"
+metadata: 
+  node_type: memory
+  type: project
+  originSessionId: a665e14b-86bd-4b41-a228-51377f3e9225
+  modified: 2026-08-08T16:24:48.813Z
+---
+
+**/dev** nodes are created by `cmd/init/main.c` with `mknod()` at every boot,
+and served by `kernel/dev/cdev.c`'s `devsw[major]` table. Minor numbers under
+major 1 follow Linux's mem-major layout where free: null=2, zero=5, full=7,
+random=8, urandom=9. `/dev/hole` (minor 4) was deleted 2026-08-01 — an
+abandoned experiment nothing referenced.
+
+**/proc** (`kernel/dev/procfs.c`, major 6) synthesises eight global files:
+meminfo, uptime, cpuinfo, version, stat, loadavg, mounts, filesystems. Each is
+a device node with its own minor; reading renders the whole text and returns
+the slice at the caller's offset.
+
+**Two gotchas that shaped it:**
+
+1. `devsw[].read()` used to be called as `read(ip, 1, addr, n)` — every caller
+   passed the literal `1` where an offset belongs, so a device could never
+   know where a read started. Fine for a stream like the console, fatal for a
+   /proc file: without an offset every read returns the whole text again and
+   `cat` never terminates. `kernel/fs/file.c` now passes `f->off` and advances
+   it by the amount returned.
+
+2. `/proc/mounts` must list `/` **last**. df keeps the last mount point that
+   prefixes the path it was asked about, so listing root first made `df /`
+   report /proc's numbers.
+
+**Per-process `/proc/<pid>/` directories now exist and `ps`/`top` work** —
+re-verified 2026-08-08 with `tools/bootcheck.ps1 -Ps`: ps finds init and the
+shell, `-o ppid` shows the real parent, top reads `/proc/meminfo`. This entry
+used to say they were impossible without a VFS rewrite; that was overtaken by
+`kernel/fs/procfs.c`, which implements /proc as a real filesystem behind
+`struct fs_ops` with synthetic inodes (`pid<<8` encoding) rather than touching
+`fs.c`. See [[schfs-phase3-writes]] for the `fs_ops` dispatch.
+
+One cosmetic gap remains: `ps -o comm` shows `[init]` in brackets, because
+toybox `readlink()`s `/proc/<pid>/exe` and ours is a regular file, not a
+symlink. Needs symlink support in procfs.
+
+`sysinfo(2)` also reports real memory now (`PHYSTOP` and
+`kalloc_free_bytes()`); it used to return hardcoded 256MB/128MB, which is what
+`free` reads.