Captain Bob, 2026-11-12: "correct deficiencies". heartbeat_capture_tick_snapshot
wrote cache_hits_delta and bucket_hits_delta as 0 ("TODO: wire ..."), though
physics_hotwords_cache.c counts both. Now each is read from the VM's hot-words
cache as a delta since the previous tick, the way word_executions_delta is
(and after the cache's stats are reset, the count since then); a VM with no
cache has 0. word_executions_delta was measured already: doe_log.c's "TODO: 0"
for it was stale, and its three column notes are corrected.
kernel/tests/test_heartbeat_export.c, 4 checks: a VM in memory with a cache
whose counters the test sets, captured tick by tick. Against the code as it
was: 3 failures (the hits 0 where the cache counted 5 and 3, then 7 and 7).
Now: 0. Built for amd64, aarch64, riscv64 and the hosted v3. Shared v3 code,
under the ruling. v3 is not part of acceptance; no DoE has run since 2026-09-16.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
logs/20261112-182015/PROTOCOL.md, for the kernel host-test chunk: the harness
and #170, #171, #176, #177, #178, #182. The four boots 538/538 -- a data stick
enumerating through the moved USB descriptor walk, genesis through the identity
code's new seed handling -- word_count=318, dict_hash 0x8c92508f748f99cf on all
three; test-32 39 programs, 1,869,223 checks, 0 failures; the proofs (37 s);
the images, no race; the documents. The tree clean before and after.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
sk_v4_genesis never wiped its seed or its read-back; sk_v4_drive_arrived
never wiped the proxy's seed after her login; sk_v4_real_zuse_arrived wiped
the seed only on a match. (The logged-in Zuse's own key stays in g_zuse_seed,
by design.)
Option 1: the three use one buffer the identity module owns, g_seeds (seed,
then its read-back), and sk_v4_drive_arrived -- which every drive goes through,
and which alone calls the other two -- runs the drive's handling (now
handle_drive()) and then wipes it, whichever way it went.
sk_v4_identity_seeds() lets the host tests read it.
kernel/tests/test_sk_v4_identity.c, 10 checks, through the real drive-arrival
path: a fake xHCI controller marks a slot attach-pending, the identity code's
idle beat handles it, the real gpt.c reads the stick's table from the RAM disk;
the block layer, signatures, key mint, marker and console faked. Genesis; a
genesis not read back; the proxy logging in; a real Zuse named, then her stick
logging in. Against the code before the wipe: 5 failures (every case's seeds
left). Now: 0. The harness gains fake_disk_bind. Built for amd64, aarch64,
riscv64. #176 done with 2bac2ac8 (the mint).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
sk_v4_mint_zuse wiped seed and rseed only when the real Zuse was minted; its
refusals and every failure after YES left them in stack memory.
Option 1 (Captain Bob, 2026-11-12: "1 is great"): the seeds are in a 64-byte
buffer the caller owns. sk_v4_mint_zuse_with(seeds) runs the mint (now a
private mint()) and then wipes the buffer, whichever way it returned -- one
place, every exit; sk_v4_mint_zuse() gives it a buffer of its own.
kernel/tests/test_sk_v4_mint.c, 17 checks: the real gpt.c on the RAM disk, the
identity code, key mint, signature checks, marker and keyboard faked; each of
the mint's eight exits run with the buffer filled with 0xEE first -- no stick,
under 64 MiB, not YES, the key mint failing, the read-back not hers, no
marker, the marker write failing, and minted. Against the mint as it was: 7
failures (every exit but success). Now: 0. Both runs in logs/20261112-181719/. Built for
amd64, aarch64, riscv64. The identity code's two (sk_v4_genesis,
sk_v4_real_zuse_arrived) follow.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
sk_v4_grow.c's dev_rw4k computes 1 KiB block numbers as (uint32_t)devblock * 4,
which wraps past 4 TiB; Artemis is capped at 256 GiB (STICK_ARTEMIS_CAP_GIB,
kernel/Makefile), so it is latent -- but nothing said so where the cast is. Now
a compile-time check there (the C99 negative-array pattern the tree uses): a
cap past 4 TiB stops the build, and a cap not defined at all is an #error, not
a skipped check. gpt.c's casts are bounded by the disk's own size, itself a
32-bit count of 1 KiB blocks, checked before each: each now says so.
kernel/tests' check_cap, seen to fail first (a 4096 GiB cap built); now 3
checks, 0 failures -- 256 GiB builds, 4096 GiB and none refused. Built for
amd64, aarch64, riscv64. The plan's increments 2 and 3 marked.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
sk_v4_idle allocated a controller's slot array again whenever max_slots + 1
was more than it held -- the old array dropped, neither copied nor freed --
while the identity code holds pointers into it (g_offered, g_spare,
g_pending_real, g_real_drive, g_zuse_dev). Its two slot loops then ran to
max_slots whatever the array held.
sk_v4_slots_get() (kernel/src/v4/sk_v4_slots.c): allocated once, zeroed, at the
size first asked for; never replaced; the slots that may be used are those it
has. sk_v4_idle uses it, and its loops stop at the array's end.
kernel/tests/test_sk_v4_slots.c, kmalloc_aligned faked, seen to fail first
against the allocation as it was (4 failures: replaced when more were asked
for, 17 said usable where 9 existed, a held pointer left behind, an allocation
for 0); now 6 checks, 0 failures. Built for amd64, aarch64, riscv64; latent
today (max_slots does not grow), so the boots show no change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
sk_v4_run's three stops -- "not started", "did not let go of POST's
blocks", "stopped on a fault" -- ended in for (;;) { }: a core spinning at
100%, the thing #151 removed from the prompt. Each now calls sk_v4_stop()
(kernel/src/v4/sk_v4_stop.c): interrupts off, then arch_halt() for ever. Each
still says why first. sk_v4_stop.c added to the loader's and the kernel's v4
sources.
kernel/tests/test_sk_v4_stop.c, with arch_halt and arch_disable_interrupts
faked (the halt jumps back out after three calls; an alarm fails a spin):
against the stop as it was -- "spun for 2 s without halting"; now -- 2
checks, 0 failures: halts in a loop, interrupts off before the first halt.
Built for amd64, aarch64 and riscv64. #177's "seen on the three
architectures": no boot reaches these stops, so it is shown on the host only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
a8824655's evidence log shows its "before" run failing to compile: the copy
of usb_config.c with the old decision was cut at the wrong brace by my script.
The failure the commit describes was real (seen in the session), but the log
did not show it. Rerun with a correct copy:
test_usb_config-before-rerun.log -- 20 checks, 10 failures (wTotalLength 1 to
9 asked for again; the cut unsaid). The first log is kept, as what it is.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
After the configuration descriptor's first 9 bytes the event loop asked for
min(wTotalLength, 128) whatever it was. A wTotalLength of 9 or less was then
asked for again as "short" -- for ever, that slot never leaving enumeration
(#170); 0 also issued a zero-length data stage. A set longer than the 128-byte
buffer was cut without a word, its later interfaces never seen (#171).
The decision is usb_config_request_length() (moved out of the event loop,
then fixed): 9 or less is 0 -- "xhci: a configuration of N bytes has no
interface -- not used", and nothing more is asked; longer than the buffer is
cut and said -- "xhci: config of N bytes cut to 128 -- rest unseen" (at most
53 characters). The buffer stays 128 bytes; its size is #171's to rule.
kernel/tests/test_usb_config.c, seen to fail first against the decision as it
was (10 failures: wTotalLength 1 to 9 asked for again, the cut unsaid), now
20 checks, 0 failures. Both runs in logs/20261112-180140/kernel-tests/. Built for amd64,
aarch64 and riscv64; the boots come with the protocol. #171's other box, a
composite device on the SER5, is Captain Bob's.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
Captain Bob, 2026-11-12: "Build an appropriate test harness! Love the idea."
The kernel had no tests below the boots, so defects QEMU cannot provoke could
not be tested first. Plan: docs/v4.0.0/plans/2026-11-12-kernel-host-tests.md.
kernel/tests/: one host program per kernel source, built with that source as
it is, the kernel's flags (-std=c99 -Wall -Wextra -Werror), and fakes --
the console captured line by line, a deterministic RNG that can fail, and a RAM
disk whose reads, writes or flushes fail at chosen 1 KiB blocks.
make -C kernel/tests test runs them; SRC_<test>= runs a test against other
code, which is how a test is seen to fail against the code before a fix.
test_gpt.c, 12 checks: a table written and read back; 16, 17 and 18 used
entries against max 16 and an entry out of range after the 16th (#180); the
RNG, the first write, a later write and a flush failing (#168). Against gpt.c
before #168 and #180: 4 failures, each defect caught. Now: 0. Both runs in
logs/.../kernel-tests/. Not yet a protocol stage: to rule (the plan, step 5).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
logs/20261112-164108/PROTOCOL.md, for the batch #172, #169, #185, #144, #143,
#181, #180 and the #187 test: the four boots 538/538, word_count=318,
dict_hash 0x8c92508f748f99cf on all three -- the new dict-hash stage (#172)
naming each; test-32 39 programs, 1,869,223 checks, 0 failures (the manage
test's 78 among them, #169); the proofs (43 s); the images, no race (#185);
the documents. The tree clean before and after.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
gpt_read() stopped at max used entries (16 for the identity code, 4 in the
mint): a disk whose StarshipOS partitions came after the first max read as
having none, and the entries after max were never range-checked.
Now every entry is checked and every used one counted; a good table with more
used entries than max is GPT_MANY (the first max in parts), and the identity
code says "GPT: a USB drive has more than 16 partitions -- not used". Other
callers treat anything but GPT_OK as before.
Tested first, seen to fail: qemu_session.py gpt_many -- a data stick with its
two partitions as entries 17 and 18 after 16 others, and the same with an entry
19 past the usable range: both "not this system's stick" before (silently cut,
entry 19 never checked; logs/20261112-162236). After: "more than 16
partitions" and "a damaged partition table" (logs/20261112-162921).
Regressions: gpt_bad_entries, gpt_foreign PASS. gpt_zuse FAILS, on a stale
expectation unrelated to this change -- an identity-only GPT drive with no
system stick has been held silently as a possible real Zuse since #92 Task 4;
its log is kept here. The gpt_many images are made before the boot: a first
version made them after, failed in sgdisk and left its QEMU running, stopped
by hand (logs/20261112-162003).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
A data stick hot-plugged with every read at its identity partition's first
sector (LBA 2048) failing, after a boot with no drive; it expects a message
naming the identity partition, Artemis let go (both partitions or neither,
#179), no prompt, and the same stick without the fault going on to genesis.
add_stick() takes fail_read_sector for it.
It FAILS today, and is kept so (Captain Bob, 2026-11-12: "keep the test"):
the partition attaches anyway and Zuse is minted onto it, because
blk_format_or_load_disk() ignores the header read's result and takes an
unreadable disk as blank -- filed as #187. #179 is parked: its half-attached
state cannot be reached from a disk fault. The run: logs/20261112-160050.
Not part of acceptance.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
kernel/Makefile gave capsules/v4/sys/map-64.f18 and map-32.f18 one rule with
two plain targets -- in GNU make, two rules sharing a recipe. Under -j both
ran at once: two make -C v4 sysmap built and ran the same v4/build/mkmap-<w>
side by side (Build run 255's RASPI job: "mkmap-32: Permission denied").
Now one grouped target (&:, GNU make 4.3+, as here and in the CI image).
Seen to fail first: the two targets with -j8, mkmap removed each time, 12
runs -- 6 failed ("Text file busy", "Permission denied"). After: 0 of 12.
Both sets of runs in logs/20261112-152711/race-185/. The map files are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
v4_manage_serve took its arguments with v4_dstack_pop and never checked the
stack's depth: a request with too few values acted on stale ring values, and
one whose results did not fit dropped the oldest silently -- around the D-16
guards. Now each request's arity (manage.h) is checked first: fewer values
than it takes, or no room for what it leaves, is error 12 with the stack as it
was -- as a block request is refused (blocks.c).
test_manage.c, written first and seen to fail (12 of 13 requests at both cell
widths; NODE-BORN passed only because the stale value read was below 1): every
request with one value fewer than it takes, and NODE-ME and CAPSULE-CELL on a
stack with no room -- refused, the stack unchanged. After: 78 checks, 0
failures at 32 and 64 bits; all v4 tests at 64 bits, 40 programs, 1,871,313
checks, 0 failures (logs/20261112-152602/v4-test).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
logs/20261112-124144/PROTOCOL.md: the four boots 538/538, word_count=318,
dict_hash 0x8c92508f748f99cf on all three; test-32 39 programs, 1,869,197
checks, 0 failures; the proofs (StarForth, 37 s); the images; the documents.
The tree clean before and after.
Stage 3 (riscv64) was stopped while booting, when Captain Bob interrupted to
mean the build pipeline; its partial serial log and console output are kept,
labelled, in logs/20261112-124831/. It was rerun on the same commit and
passed (logs/20261112-130801).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
failed() printed "MINT-ZUSE: failed -- nothing changed" on every failure
after YES, though by then gpt_write_one() had rewritten the stick's partition
table and the identity partition's first blocks had been zeroed.
gpt_write_one() now tells the two apart: GPT_EIO when its first write failed
(nothing written), GPT_PART when a later write or flush failed (the disk is
changed). MINT-ZUSE keeps "failed -- nothing changed" for GPT_EIO only, and
says "failed -- the stick was erased; Zuse not minted" for every failure
after the table is written. The marker is still written last.
Tested first, seen to fail: qemu_session.py mint_part_fail (writes fail only
at the identity partition's first sector, LBA 2048) -- "nothing changed",
logs/20261112-122132. After: mint_part_fail PASS; mint_fail (every write
fails) still "nothing changed", PASS; replace (the success path) PASS. Their
logs here. FABRIC-3 XLVIII.20.
Captain Bob, 2026-11-12: "start #168".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
logs/20261112-114545/PROTOCOL.md: one stage per foreground command (paused
between stages 2 and 3 for Captain Bob's emergency, then resumed on the same
commit): the four boots 538/538, word_count=318, dict_hash
0x8c92508f748f99cf on all three; test-32 39 programs, 1,869,197 checks, 0
failures; the proofs (StarForth, 44 s); the images; the documents. The tree
clean before and after.
The evidence for the held batch: plan section 8 (the FMEA in the PR review),
the notes, and scripts/ci_litter_check.sh (#129).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
logs/20261112-001304/PROTOCOL.md: scripts/nightly.sh protocol, one stage per
foreground command: accept amd64, aarch64, riscv64, stick-high -- 538/538,
word_count=318, dict_hash 0x8c92508f748f99cf on all three; test-32 39 programs,
1,869,197 checks, 0 failures; the proofs (StarForth, 36 s); the images (PC,
RASPI, MILKV); the documents (book, fabric, dictionary, vol1-3, api). The tree
clean before and after. Every stage's output in logs/20261112-001304/protocol/,
the boots' serial logs and DoE CSVs beside it.
The first protocol run: the evidence the PR's Acceptance check now asks for.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
logs/20261111-193825/v4-test: make -C v4 test on feb740c5 -- 79 programs,
3,740,484 checks, 0 failures, at V4_CELL_BITS=32 and 64. CI's v4-tests job
(Build run 247) was cancelled at 0 s by the shared qemu concurrency group
(#140), so this is the run of record for that job.
logs/20261111-185352/nightly: what scripts/nightly.sh wrote only under
build/nightly for 9415d7ed's acceptance (d6846b34) -- the four accept
summaries, test-32 (39 programs, 0 failures) and the images stage (PC,
RASPI, MILKV). The test-32 output of the earlier 90c5c140 run was
overwritten in build/nightly before it was kept, and is not recoverable.
Captain Bob, 2026-11-11: all logs are evidence.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
Run one stage at a time in the foreground through scripts/nightly.sh:
20261111-185352 amd64 PASS
20261111-185600 aarch64 PASS
20261111-185950 riscv64 PASS
20261111-190128 stick-high PASS
PARITY:V4_POST tests=538 pass=538 fail=0, POST: PASSED, [zuse@Hera] ok>
on every boot; word_count=318 dict_hash=0x8c92508f748f99cf on all three;
test-32 39 programs, 0 failures.
scripts/nightly.sh images -- the stage the version.h put-back had broken --
built PC, RASPI and MILKV and left the tree as committed.
DoE CSVs for every boot (empty, as every v4 acceptance boot's: #141).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
amd64, aarch64, riscv64 (clean qemu), stick-high, test-32, run one at a
time in the foreground through scripts/nightly.sh:
PARITY:V4_POST tests=538 pass=538 fail=0, POST: PASSED, [zuse@Hera] ok>
on every boot; PARITY:V4_SYSTEM word_count=318
dict_hash=0x8c92508f748f99cf on all three; test-32 39 programs, 0 failures.
No tracked file changed across the five builds.
20261111-170703 amd64 PASS
20261111-170909 aarch64 PASS
20261111-171235 riscv64 PASS
20261111-171410 stick-high PASS
Also kept as evidence:
20261111-170134 amd64 on aec7ddb5 (before the clean-tree fix), PASS
20261111-170544 amd64 on 90c5c140, stopped by me during boot: it had been
started in the background, against the protocol, and was
rerun in the foreground as 20261111-170703
DoE CSVs for every completed boot (experiments/bare_metal/runs).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
These logs/ files were committed as plain text even though
.gitattributes routes logs/**/*.log through the LFS filter, so every
fresh clone showed them all as modified. Renormalize them so they are
stored as LFS pointers. File contents are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017RzZgrf7V7Zk2iczBXDRbm
Task 5 of plan 2026-10-29-stick-5, accepted in full, and with it #92:
- amd64, aarch64, riscv64: PARITY:V4_POST tests=538 pass=538 fail=0,
POST: PASSED; word_count=318 dict_hash=0x8c92508f748f99cf on the three
- the PC stick as built, loaded high: 538/538, the prompt
- make -C v4 test-32: 39 programs, 0 failures
Sessions: fallback, replace, mint_fail, system_pull_real; regressions:
every Task 4 session, genesis, stick_genesis, screen_dark_until_login,
screen_dark_after_logout, kbd_typeahead, emergency. Verdicts in
logs/20261110-075036/verdicts/. The plan's Task 5 ticked; STICK.md 11
increment 5a done; FABRIC-3 XLVIII.17; the SER5 bench steps in
boards/BRINGUP.md 4.2.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Task 4 of plan 2026-10-29-stick-5, accepted in full:
- amd64, aarch64, riscv64: PARITY:V4_POST tests=538 pass=538 fail=0,
POST: PASSED; PARITY:V4_SYSTEM word_count=318 dict_hash=0x8c92508f748f99cf
on the three (MINT-ZUSE, the lone node's second word)
- the PC stick as built, loaded high: 538/538, the prompt
- make -C v4 test-32: 39 programs, 0 failures
Sessions: mint_zuse on the three; mint_zuse_refuse, mint_small,
mint_zuse_used, mint_pull_system, zuse_stick_first; regressions genesis,
two_sticks, hotplug, midpull, typeahead. Verdicts in
logs/20261110-051726/verdicts/. The plan's Task 4 ticked; FABRIC-3 XLVIII.16.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Accepted in full:
- amd64, aarch64, riscv64: PARITY:V4_POST tests=538 pass=538 fail=0,
POST: PASSED, [zuse@Hera] ok> on a fresh data stick; dict_hash
0xfec8c47cfc6f437f on the three
- the PC stick as built, loaded high: 538/538, the prompt
- make -C v4 test-32: 39 programs, 0 failures
- regressions: v3_keys, genesis on the three, stick_grow, midpull, hotplug
SAVE-BUFFERS on the 16 GiB stick: 5.1-6.1 s before, 1.1 s after; the BAM's
bytes the same (verdicts in logs/20261108-145611/verdicts/). FABRIC-3
XLVIII.14.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Not yet accepted. bam_flush_to_disk() and bam_sync_from_disk() read and
wrote every page of the BAM; with the stick's BAM sized for 256 GiB (6144
devblocks, 24 MiB) every flush of a dirty block moved 24 MiB each way.
They now touch only the pages that hold the slot's bits -- its reserved
bits and one per user block (bam_pages_used()) -- the pages past them are
never set, so the bytes on disk are the same.
Test (qemu_session.py bam_flush, --target qemu-stick --stick-gib 16):
three SAVE-BUFFERS of an Artemis block, each timed, then the BAM hashed.
Before: 5.1 / 5.6 / 6.1 s (the 2 s limit fails; it was set after seeing
this baseline). After: 1.1 / 1.1 / 1.1 s. The BAM's bytes the same either
way: sha256 79197a40...b9e44b50, 5 non-zero bytes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Task 3 of plan 2026-10-29-stick-5, accepted in full:
- amd64, aarch64, riscv64: the proxy Zuse minted on a fresh data stick,
PARITY:V4_POST tests=538 pass=538 fail=0, POST: PASSED, [zuse@Hera] ok>;
dict_hash 0xfec8c47cfc6f437f on the three
- the PC stick as built, loaded high (stick_genesis): 538/538, the prompt
- make -C v4 test-32: 39 programs, 0 failures
Regressions pass. v3_keys failed once (a virtio_blk request never completed,
logs/20261108-132844) and passed on its rerun (logs/20261108-141539).
The plan's Task 3 steps ticked; FABRIC-3 XLVIII.13.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
system=v3: Hestia logged 'virtio_blk: request never completed'; Hera reached the Zuse drive's attach and no further. Task 1's v3_keys (logs/20261108-043612) has no such line and passed. The drives were the same three, passed explicitly. To be rerun; bisected against Task 1 if it fails again.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Not yet accepted (plan 2026-10-29-stick-5, Task 3).
- kernel/Makefile: a v4 `qemu` boot attaches a fresh data stick
(DATASTICK=1) and nothing else; ARTDISK/ZUSEDISK keep the minted pair only
for system=v3 (QEMU_V3_BOOT, from KERNEL_ARGS).
- qemu_session.py: the Makefile's defaults for every mode but those that ask
for the pair by name (stick_artemis, two_sticks, artemis_unsigned,
raw_ident, v3_keys) or for no drive; `zuse` now expects the genesis line.
- nightly.sh: accept stick-high runs stick_genesis (the stick as built).
- .claude/CLAUDE.md "The disks", the stick-high line; disk/README.md (the
pair: tests and v3 only); STICK.md 11, increments 3 and 5 done.
Before the change: zuse on amd64 FAIL -- the pair's "identity confirmed",
no genesis line (logs/20261108-130732).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
Claude