nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions
SchOS/.claude/memory/schunix-layout-migration.md
Nexoniarz 3182da3965 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.
2026-08-09 14:27:22 +02:00

2.1 KiB
Raw Blame History

name description metadata
schunix-layout-migration The bt/ -> ports/ + lib/ + cmd/ restructure done 2026-08-01, and the two build traps it exposed
node_type type originSessionId modified
memory project d1a1ea76-f919-411c-b0ef-0e1bc5064563 2026-08-01T17:17:12.984Z

Restructured Schunix's tree on 2026-08-01. bt/ became ports/ (third-party only, Makefile + patches, nothing else), first-party userland split into lib/ (runtime glue) and cmd/<name>/main.c (programs), tarballs to dist/, and all generated output to build/. Documented in docs/layout.md. Verified: full build passes and the image boots to init: ready (pid 1).

Two traps that bit during this and will bite again:

  1. ld -r -b binary derives symbol names from the input file's path. The kernel embeds initcode and entryother this way, and the root Makefile has --redefine-sym _binary_build_lib_initcode_start=... lines. Move either blob's build location and the link breaks.

  2. A stamp file inside the directory it guards is always out of date. ports/musl's $(SRCDIR)/.patched rule depended on $(SRCDIR), but creating the stamp bumps that directory's mtime, so the rule re-ran on every build and failed (a patch does not apply twice). Same class of bug in toybox and mksh. Fixed by making $(SRCDIR) an order-only prerequisite (| $(SRCDIR)) in all three ports.

A real thing that was silently lost-in-waiting: musl's patch file claimed two modified files; the build tree actually had five. The three undocumented ones were in mallocng — two are inert debug tracing under #ifdef SCHUNIX_MALLOC_DEBUG, but glue.h had a required build fix (forward declarations for __mmap/__madvise/__mremap) that existed only as a hand-edit in the build tree. Any make distclean would have silently lost it. The patch was regenerated from a real diff against pristine musl 1.2.5 and dry-run verified.

Backups from that session (delete when confident): the pre-migration tarball ~/schunix-backup-20260801-1856.tar.gz and ~/toybox-known-good, both inside WSL.

See schunix-build-environment, schunix-rewrite-priorities.