Robert Allan JamesandClaude Sonnet 5
70c259dad0
find and fix the real ACL-TTL measurement bug (zuse session never authenticated, ACL enforcement never active) Two mistakes corrected in sequence, both documented in full in FABRIC-2.md Section R: 1. HEARTBEAT-TICKS@ was swapped to read heartbeat_ticks() -- a newer, kernel-only ISR hardware-timer counter (src/starkernel/heartbeat.c, the M5 TIME-TRUST engine) -- based on a misreading of which counter "the one clock" law refers to. Reverted to vm->heartbeat.tick_count, Loop #7 "Adaptive Heartrate", the actual year-plus-old counter the whole physics runtime is built on. Removed the now-irrelevant HEARTBEAT-PERIOD-NS@ accessor added to diagnose the wrong counter's adaptive re-arm period. Three-arch QEMU re-acceptance: POST 1012/0/0 on amd64/aarch64/riscv64, HEARTBEAT-TICKS@ confirmed returning 77 (matching the original pre-heartbeat_ticks() acceptance) on all three. 2. The real bug, found after the revert: every "ACL enabled" measurement in this investigation (Section P's 18-cell campaign, Section Q's pilot) loaded ACL.4th and ran EXEC-DOE from the bare `ok>` prompt without ever authenticating a zuse session. repl.c:303 keeps emergency_console=1 until zuse_session=1; vm_core.c:755 skips the entire ACL check block (TTL decrement and acl_recheck()) whenever emergency_console is set. ACL was configured but never armed. capsules/zuse.4th's pre-existing self-pin bug means the documented automatic zuse activation doesn't work either (still flagged, not fixed) -- worked around by invoking the directly-registered ZUSE-AUTHENTICATE word explicitly. Validated pilot (amd64, seed 12345, 30 reps, same build, disabled vs. genuinely zuse-authenticated-enabled): +117 ticks, +0.0448% overhead. Disabled-arm determinism double-confirmed (261064 ticks, exact repeat on a fresh boot) -- the 117-tick difference is real signal, not noise. Reconciles with the original ACL-RWT campaign's own heartbeat-tick result (+0.0054%-0.0088%, same order of magnitude). Section P's wall-clock numbers and Section Q's "instrument blind" conclusion are both marked invalidated/corrected in place, not deleted. n=1 per arm, one architecture -- not yet a full campaign. Scoped as next step, not undertaken in this pass. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
disk/
QEMU disk images used for Artemis (block-storage VM) persistence testing.
Mounted via Makefile.starkernel's ARTDISK variable (default
disk/artemis.img) as a virtio-blk-pci device on all three
architectures' kernel QEMU boots — not scripts/rundisk.sh, which targets
a separate, currently-unused disks/ (plural) directory for the hosted
VM's --disk-img= flag instead.
artemis.img— standard Artemis persistence test disk. Reformatted 2026-08-02: this image had been stuck in a corrupted state (validLithosAnankemagic header, but data not matching whatART-READ-TESTexpects) since before this repo's own git history begins (git logshows it already broken at the initial commit, carried over from the pre-split monorepo). Chasing down the resulting persistentFAIL: persist-readtraced to the data, not the code — the write→reboot→read round trip works correctly on a fresh image (seeartemis-debug-roundtrip.imgbelow). Reformatted by blanking the file and letting a normal boot format+write-test it; verifiedPASS: persist-readon amd64, aarch64, and riscv64 against the same image afterward (cross-arch resume, matching the arch-neutral on-disk format.claude/ARTEMIS.mdspecifies).artemis-debug-roundtrip.img— round-trip regression fixture created during that investigation. Known-good: format → self-test → write-test → reboot → resume →PASS: persist-read, confirmed 3 times in a row. Keep this in a passing state; if a future change breaks it, that's a real regression, not a stale-fixture artifact likeartemis.imgwas.artemis-persist-test.img— persistence round-trip test image (pre-existing; history/state not re-verified during the above investigation).artemis-poison.img— a separate test image (exact scenario not documented elsewhere in the repo as of this writing; name suggests an adversarial/corruption test, not confirmed).artemis-unrecognized-test.img— exercisesART-HALT-UNRECOG(.claude/ARTEMIS.mdacceptance criterion #6). Regenerated 2026-08-02: the previous copy of this file had itself been silently reformatted by a since-fixed bug in the generic block subsystem (src/block_subsystem.c) — it carried a valid low-level'STFR'/v2 header despite being meant to represent foreign disk content, direct forensic evidence of the bug described in.claude/ARTEMIS.md's Build Status item 6. Regenerated as 30MB of a repeatingPOISON-UNRECOGNIZED-DISK-TEST-FIXTURE--NOT-BLANK-NOT-STFR-NOT-ARTEMIS--ASCII pattern — deliberately neither blank, nor the block subsystem's own'STFR'magic, nor Artemis's"ARTEMIS\0"marker. Verified on amd64 and riscv64 post-fix: boot correctly halts (ARTEMIS HALT: unrecognized disk content) and the file's sha256 is now byte-for-byte identical before and after boot. Keep this fixture in this poisoned state — if a future change makes its sha256 change across a boot, that is exactly the regression this fixture exists to catch.
Note on incidental header churn: artemis.img picks up a few changed
header bytes on every ordinary boot even though no user data changes —
blk_subsys_attach_device() always records a fresh mounted_time on a
successfully recognized disk, which gets flushed at shutdown. This is
expected bookkeeping, not a bug; revert it before committing rather than
carrying timestamp noise in git history.
These are regenerable QEMU raw disk images, not source — see
.claude/ARTEMIS.md for the storage model they exercise.