The fix belongs in the kernel's compudynamics, not in the DoE capsule
steering its own scheduling. Logs from the stopped relaunch and the check
run stay committed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The first amd64 relaunch (stopped by Captain Bob after 1h41m) showed Hera's
busy wait taking an equal CPU share and writing 43% of all heartbeat rows.
100 WAIT charges her 100 beats of work heat per iteration while executing
almost nothing, so workers get the CPU. cfg-0 check: 115 s vs ~210 s,
fail=0, 2/2 dead.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Workload capsules the DoE births are definitions only; each defines WL-RUN
(its old birth-time work plus its entry word twice) and WL-DONE-ARGS. The
driver births N workers, SENDs each 'WL-RUN WL-DONE-ARGS SEND', waits in an
ordinary loop for N MU-DONE messages, KILLs them (parked idle), and emits
the marker. The serialized VM-EXEC round-robin is gone.
Kernel: no switch checkpoint after a payload's last word; work heat is the
assessed per-beat charge, and a VM gaining work is raised to the busy set's
floor (Captain Bob's ruling) -- fixes a live stall where a busy-waiting Hera
never yielded, without serializing batch starts.
Evidence: cfg-4 rows spread evenly over Hera and all 8 worker slots (44k
switches); full cfg-4 trials on amd64/aarch64/riscv64 end fail=0 with 8/8
KILL dead; Stage G interleave byte-identical on all three. Acceptance:
dict_hash unchanged, relay 3, idle growth 0.
Co-Authored-By: Claude Opus 5.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>
The full 360-trial campaign was launched, then killed after 4h39m of
CPU time with zero trials completed -- still stuck on the very first
touch of the very first trial.
Root cause, quantified from the workload's own source, not estimated:
RUN-CHAOS5 (workload-5.4th) is 1000000 0 DO CHAOS-FIELD CHAOS-RIPPLE
LOOP, multiplying out to ~2.4 trillion word executions for one call --
~495 days at the observed rate. Never designed to be called to
completion as a single touch in a repeatedly-birthed worker.
A second problem found computing the fix rather than discovering it
mid-run again: workload-1.4th's own birth-time self-execution (20
SQUARE-WAVE + 1500 SQUARE-BURST + 100000x MICRO-BURST, all three run
automatically at capsule load) sums to ~875 million words -- ~4.3
hours just to birth one worker -- and worker index 1 always maps to
it in heterogeneous mode, landing in half the campaign's cells
regardless of concurrency level.
Fix: two new capsules, workload-1-lite.4th and workload-5-lite.4th,
carrying the same word bodies verbatim but a bounded self-execution
tail, comparable in scale to the campaign's other workloads. The
originals are untouched; only multiuser-doe.4th's own WL-CAPSULE/
WL-ENTRY index 1 and 5 mappings were repointed.
Verified live before relaunching a third time: the actual worst case
in isolation (5 0 998 MU-RUN-TRIAL, concurrency=8 heterogeneous,
includes both fixed workloads plus RUN-OMNI) completed in ~20 minutes
wall-clock, Hera stayed healthy throughout. Clean 3-arch qemu boot.
Reps reduced 60 -> 30/cell (Bob's call after seeing the real per-trial
cost) -- still matches the project's "rule of 3's" DoE convention
(same as ACL-RWT's own 30 reps). 6 cfgs x 30 reps = 180 trials.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BWpNjdwPtFLuVLaAq44L9K
Builds the experimental control Bob correctly identified as still
missing after HB-ON/HB-OFF (§XXXIII.5): walk the shuffled matrix of
concurrency-level x workload-mode cells, birth the right worker count
per cell, drive each with two VM-EXEC touches, check VM-ERROR?, kill
them, print a trial marker. Built entirely from existing primitives
(WORKER-BIRTH, VM-EXEC, VM-HEAT, VM-ERROR?, KILL, HB-ON/HB-OFF) plus
doe.4th's own RUN-MATRIX/SHUFFLE-MATRIX pattern -- no new C primitives.
Real capsule-format bug found and fixed: a first draft, chunked purely
by a fixed 16-line count with no regard for word boundaries, split
several CASE...ENDCASE structures and one oversized colon definition
across Block headers. Result was a cascading [CAPSULE][DEFER] failure
from the first split forward -- every subsequent line failed to
compile, and MU-RUN-TRIAL was never actually defined (confirmed:
UNKNOWN WORD when called). Root cause traced to capsule_loader.c
directly: a :...; word and any control structure inside it must fit
entirely within one 16-line block -- the loader's per-block compile
pass has no persistent record of an open CASE's (or an overlong
definition's own) state across a Block boundary. Not previously
documented anywhere in this project's capsule-authoring guidance.
Fixed via manually curated block boundaries and factoring oversized
bodies into smaller helper words.
Reps ratified at 60/cell (not the 10 first drafted), matching this
project's own "rule of 3's" DoE convention (ACL-RWT's 3 seeds/30 reps,
std79's 3x9x3). 6 cfgs x 60 reps = 360 main-block trials.
MU-MAX-REPS raised 20 -> 63 for run-matrix headroom.
Verified live on amd64: one isolated trial (0 0 999 MU-RUN-TRIAL)
produced two real concurrent births, two clean kills, and the exact
expected marker (MU-TRIAL run=999 cfg=0 rep=0 nw=2 mode=0 fail=0).
Hera stayed healthy throughout. Clean 3-arch qemu boot.
Not yet run: the full 360-trial MU-EXEC-CAMPAIGN itself (a genuinely
long-running action under TCG, deliberately not started without
explicit confirmation) or the WIREBIND-automation fixed arm.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BWpNjdwPtFLuVLaAq44L9K
