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.
This commit is contained in:
parent
cda5908660
commit
3182da3965
47 changed files with 2810 additions and 0 deletions
34
.claude/memory/schunix-verify-by-driving-shell.md
Normal file
34
.claude/memory/schunix-verify-by-driving-shell.md
Normal file
|
|
@ -0,0 +1,34 @@
|
|||
---
|
||||
name: schunix-verify-by-driving-shell
|
||||
description: "Boots to a prompt" is not a passing test for Schunix — drive real commands over the serial console
|
||||
metadata:
|
||||
type: feedback
|
||||
---
|
||||
|
||||
Reaching `init: ready (pid 1)` and a `#` prompt proves almost nothing about
|
||||
Schunix. A filesystem change shipped looking "verified" that way and the user
|
||||
found the breakage by typing one command.
|
||||
|
||||
**Why:** nothing in the boot path opens a file from `/bin` or reads a
|
||||
non-root inode. An image with corrupt inodes boots to a perfectly healthy
|
||||
prompt and dies on the first `ls`.
|
||||
|
||||
**How to apply:** after any change to `tools/mkfs.c`, the on-disk format, or
|
||||
`kernel/fs/*`, drive actual commands and read the output. QEMU's serial line is
|
||||
an input console, but it has no flow control — a burst of piped input loses
|
||||
about half its characters, and input sent before the shell is up is discarded
|
||||
entirely. Both problems go away with: wait ~20s for boot, then send one
|
||||
character every ~0.12s.
|
||||
|
||||
```sh
|
||||
send() { s="$1"; i=0
|
||||
while [ $i -lt ${#s} ]; do
|
||||
printf '%s' "$(expr substr "$s" $((i+1)) 1)"; sleep 0.12; i=$((i+1)); done
|
||||
printf '\n'; sleep 7; }
|
||||
sleep 20; send "ls"; send "ls /bin"; send "cat /etc/motd"
|
||||
```
|
||||
|
||||
Pipe that into `qemu ... -serial stdio -display none` and read the log. `ls`,
|
||||
`ls /bin` and `cat` on a real file are the minimum bar.
|
||||
|
||||
See [[schfs-v2-and-ramdisk]], [[schunix-build-environment]].
|
||||
Loading…
Reference in a new issue