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>
Records that a mountable ISO 9660 root was called off -- the ISO already
boots a complete system from the ramdisk, so it is the live environment
and an installer makes a mountable disc redundant, which drops the ATAPI
driver and ISO 9660 filesystem entirely.
Also records the installer's shape (both firmwares from the start, .sip
before anything installs), the five-stage dependency chain, and the 4 GB
limit the raw block device carries.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
