feat(v4): no identity drive, headless; Zuse's drive, a console

The identity gate on the v4 boot (plan 2026-10-26-engine-step4-identity-gate,
task G2; ENGINE.md 2, ruled 2026-10-20). As v3, by the kernel with no v3 VM:
after POST and the block chain, Zuse's public key from the genesis marker,
every xHCI controller brought up, the heartbeat started; then headless until
her drive is attached and checked (capsule_zuse_boot_check, G1). A drive that
arrives is given to the block subsystem by the kernel (Artemis is the
kernel's); her session is kept in the kernel for Hera, never in a node's
memory. The prompt is v3's, [zuse@Hera] ok>; pulling her drive ends the
session and the system goes headless; putting it back brings the prompt.
A blank pair stays headless: genesis writes Artemis's disk, Phase 5 (D2).

kernel/Makefile: ARTDISK and ZUSEDISK default to the minted pair,
disk/zuse-scratch/ (D4); .claude/CLAUDE.md's acceptance says so.

Fixed with it, at Captain Bob's word:
- kernel/Makefile: the ROM-and-map rule is a grouped target (&:). As two
  targets of one plain rule its recipe ran twice at once under -j and the
  copies met ("cp: cannot create regular file ... File exists"): 3 of 20
  parallel builds failed, now 0 of 20.
- The v4 boot drops the logger to --log-level after POST, as v3 does
  (sk_log_level_after_post, shared by both paths); INFO lines after POST,
  3 before, 0 now.

Accepted: three clean qemu boots as built to [zuse@Hera] ok>, POST 538/538,
dict_hash 0xfec8c47cfc6f437f on all three (unchanged), 0 INFO after POST;
the hot-plug session (attach, line, detach, headless, re-attach) on amd64,
aarch64 and riscv64; headless with no drive; make -C v4 test test-32
sanitize hosted-check EXIT 0; make -C v4 test-32 0 failures.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
rajames
2026-10-26 11:06:37 -04:00
co-authored by Claude Opus 5.5
parent 75785fb025
commit 8d9c91b2bc
6 changed files with 309 additions and 31 deletions
+7 -1
View File
@@ -341,9 +341,15 @@ audit artifacts — they are committed to the repo. Do not delete them. There is
timestamped convention (self-documented via its own README); not a contradiction, just a
second, less-structured log location.
**The disks (Captain Bob, 2026-10-26, the identity gate):** with no identity thumbdrive the system
is headless -- no prompt -- so every boot needs Zuse. `kernel/Makefile`'s `ARTDISK` and `ZUSEDISK`
default to the minted Zuse pair, `disk/zuse-scratch/artemis.img` and `zuse-thumb-ident.img` (a
pair: her genesis marker is on that Artemis disk; `disk/README.md`). Put both back as committed
(`git checkout -- disk/zuse-scratch`) before each architecture. The prompt is `[zuse@Hera] ok> `.
Do not claim a change is accepted until all three architectures have booted, and their logs are
present in `logs/`:
- **as built (v4)** to `ok> `, with `PARITY:V4_POST tests=538 pass=538 fail=0` (the count
- **as built (v4)** to `[zuse@Hera] ok> `, with `PARITY:V4_POST tests=538 pass=538 fail=0` (the count
grows with v4's POST) and `POST: PASSED`, and `PARITY:V4_SYSTEM ... dict_hash=` equal across
the three;
- **the 32-bit build** (Captain Bob, 2026-10-14: "the 32 bit build needs to go into the