v3/include/version.h is written by every build (kernel/Makefile and
v3/Makefile, both FORCE), with a timestamp and the last build's ARCH; the
committed copy was stale (LITHOS_VERSION 2.1.0). Untracked, and .gitignore's
entry corrected: it said include/version.h, the path before the move to v3/,
and matched nothing.
capsules/BLOCK_MAP.md differed on every build only in mkcapsule's
"Generated ... <timestamp>" header. The timestamp is dropped, so the manifest
changes only when the capsules do; two runs are byte-identical.
mkcapsule's warnings unchanged (5, #143).
Captain Bob, 2026-11-11: untrack version.h and fix the ignore; drop the
manifest timestamp.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
One doe-<arch>-<time>.csv is written by each QEMU boot; the 96 from the
boots of steps 6 to 6d were untracked. Committed so that the tree is
clean before step 6e begins: this commit is its rollback point.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Traced what a "Block NNNN" collision actually means before designing
a fix for it: capsule_loader.c's block-write path routes through the
generic block-subsystem API, which kernel_main.c registers as two
devices in a fixed order -- the volatile ramdrive first (LBN
2048-3071), then Artemis's real virtio-blk device immediately after
(LBN 3072+, backed by disk/artemis.img). Every capsule this project
has lands in Artemis's persistent range, not the ramdrive, and
blk_update()'s dirty-marking + repl.c's idle-loop flush write that
content through to the real disk file on every boot. A block-number
collision is therefore a silent, persistent overwrite of real disk
content surviving reboots, not a transient RAM mixup.
The existing collision gate (check_block_conflicts(), already a hard
non-interactive build failure) already catches capsule-vs-capsule
collisions across the whole flat range. The real gap: zero visibility
into blocks something other than a capsule owns (Artemis's own
non-capsule persistent data), and no device-boundary/capacity
awareness at all.
Added, scoped step by step before writing any code:
- tools/capsule-claims.txt -- derived, auto-created/regenerated,
git-ignored. Lets --resolve tell "this capsule's own content
changed" apart from "genuinely new collision with something else."
- tools/capsule-reserved.txt -- human-authored, git-tracked, seeded
with nothing yet rather than guessed at. Checked by both the plain
build gate (new check_reserved_conflicts()) and --resolve.
- tools/patches/ -- git-tracked, one file per accepted interactive
renumber; a structured old->new block list, not a generic diff,
since that's the only thing a renumber ever changes.
- mkcapsule --resolve <dir> -- the only interactive mkcapsule mode,
a deliberate separate invocation from the plain build path (which
stays non-interactive so CI never blocks on a prompt). Suggests a
renumbering that preserves a capsule's own existing block spacing,
prompts y/N, rewrites the .4th source in place on acceptance.
Found and fixed a real bug during verification: the registry's
empty-block-list case (workload-5.4th, zero Block headers) serialized
with a stray trailing space that the reader parsed back as a phantom
block 0, causing spurious re-registration every run -- caught by
testing idempotency directly, not assuming a clean first run meant
it worked.
Verified: isolated collision tests confirm both accept and reject
paths, confirm a resolved collision doesn't re-prompt the other side,
confirm reserved-range collisions are caught by both --resolve and
the plain build gate. Full 3-architecture rebuild via the real
Makefile.starkernel succeeded clean; amd64 boots with an unchanged
dict_hash/capsule_hash from every prior boot this session.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXieurDfDSsDFdnSyusuWo
Reversing the earlier decision to track fb/ in git (made when first
setting up the directory for item 4.3.2). Captain Bob: these are
disposable screenshots for eyeballing framebuffer output during Console
work, never meant to be committed. Removed from git tracking (git rm
--cached) and added to .gitignore; files that still exist locally are
untouched, deletions already made locally are left as-is.
Also fixes item 4.3.4's amd64-only blind spot found in the process:
aarch64/riscv64 had no framebuffer device at all (GOP: protocol not
found) -- the "all three architectures boot clean" checks run all session
were REPL/dict_hash parity, a different thing from GOP presence, and
conflating the two was an error. Added -device ramfb (EDK2's
firmware-only GOP framebuffer) to both architectures' qemu targets in
Makefile.starkernel. Both now report GOP: linear framebuffer found at
800x600; cube rendering verified correct on both (screenshots not
committed, per the untrack above -- verified visually this session).
Standard three-arch acceptance boot re-run afterward, all clean,
dict_hash identical and unchanged from before this fix.
Claude