PER-ISA-NREPS was 18, inherited unchanged from local master, but every doc
comment (this file's own header, doe_region.h's own design comment) assumes
N=3 reps/cell -- 18 trials/ISA, 54 total across 3 ISAs. With the actual
constant at 18, MU-EXEC-CAMPAIGN's own math (n-reps * MU-N-CFG, MU-N-CFG=6)
produced 108 trials/ISA, 324 total -- well past the DoE region ring's
256-slot ceiling, silently dropping the oldest ~68 records to FIFO eviction
mid-campaign. Confirmed with Captain Bob: 3 is correct. Fixed.
AMD64-SEED/AARCH64-SEED/RISCV64-SEED/PER-ISA-NREPS are now VARIABLEs, not
CONSTANTs, so they're settable before a run instead of fixed at compile time.
New DOE ( seed reps isa-addr isa-u -- ) word: the common interface for
running any named experiment (not just the three fixed per-ISA ones) through
one entry point -- tags, checks resume count, runs the campaign.
RUN-AMD64-CAMPAIGN/RUN-AARCH64-CAMPAIGN/RUN-RISCV64-CAMPAIGN are now thin
wrappers over it, using the stored per-ISA seed/reps variables.
Live-verified on amd64: both capsules load via EXEC with zero errors, and
DOE itself was exercised directly (4567 3 S" doe-xyz" DOE) -- correctly
tagged, correctly checked DOE-RESUME-COUNT, and launched a real campaign
(confirmed by live per-tick physics output and growing trial state; a full
18-trial run takes the ~25-30 min/ISA CLAUDE.md itself documents, so the run
was stopped once the wiring was confirmed working rather than run to
completion for a syntax check).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Local master had 9 unpushed commits building block-backed DoE persistence on
Artemis's own disk (FABRIC-3.md SXXXV.3/.4/.12, designed and built 2026-09-17,
never pushed) that this branch never inherited after the Tripod/kernel
reshuffle diverged history. Ports the mechanism cleanly onto the current
Hera/Artemis/Hestia shape:
- doe_region.h/.c: growable, CRC-protected trial-summary ring in Artemis's
top-of-device metadata fence, immediately past log_region.c's own ceiling
(devblock_from_top 98-102). Same accessor/CRC discipline as log_region.c.
- log_words.c: DOE-PERSIST-TRIAL and DOE-RESUME-COUNT kernel-only FORTH words.
- multiuser-doe.4th: per-ISA tagging (MU-ISA-TAG!) and campaign resume support
(MU-EXEC-CAMPAIGN now takes a start-idx).
- per-isa-doe.4th (new): RUN-AMD64-CAMPAIGN/RUN-AARCH64-CAMPAIGN/
RUN-RISCV64-CAMPAIGN entry points, resuming from DOE-RESUME-COUNT.
- extract_doe_region.py (new): host-side reader, CRC-verified, no filesystem
assumptions -- reads the ring directly off a raw disk image.
Deliberately not ported: the R/LaTeX report-generation pipeline
(analyse_multiuser_doe.R, multiuser_doe_report.tex, build_multiuser_doe_report.sh)
-- not needed to prove persistence works, and unscoped for this pass.
Verified live on all three architectures: clean boot, word_count 530->532,
zero UNKNOWN WORD. amd64 and riscv64 both live-exercised end-to-end (write via
DOE-PERSIST-TRIAL, count via DOE-RESUME-COUNT, clean QEMU exit, then read back
correctly with extract_doe_region.py against the raw disk image -- no host
serial dependency, matching the real bare-metal requirement this campaign is
rehearsing for).
riscv64 finding (not a defect in this port, no fix applied): DOE-PERSIST-TRIAL
failed 3/3 on a first attempt against a fresh disk image with
"virtio_blk: vblk_io timed out". Root cause: disk/artemis.img is a sparse file
(180KB allocated of a 1GB apparent size); the new DOE region (devblock_from_top
98-102) is genuinely virgin territory on a fresh image, and riscv64's slower
TCG emulation missed the existing virtio_blk spin-bound budget (already
documented as fragile, FABRIC-3.md 2026-09-09) on that first cold touch.
Confirmed by isolation: a plain BLOCK/UPDATE at an already-warm LBN succeeded
instantly, the pre-existing LOG-ERROR" (same meta-zone mechanism, an
already-warmed offset range) also succeeded, and a reboot reusing the
now-partially-warmed disk let DOE-PERSIST-TRIAL succeed immediately and
verify correctly on read-back. Pre-existing environmental fragility, not a
logic bug in the ported address computation.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
