Robert Allan JamesandClaude Sonnet 5
5a9425b91b
Prompted by reading the std79-doe K report: checked whether the campaign's
"real cross-VM dispatch load" was actually concurrent or strictly
serialized. It's serialized at two levels -- VM-EXEC's vm_interpret(target,
...) is a direct synchronous C call (Hera fully blocked until it returns),
and even the background physics tick (vm_tick(), vm_runtime.c) is driven
by each VM's own execution loop, so idle identities accrue zero ticks
between their own turns. K's perfect conservation (FABRIC-3.md §XVIII)
verifies sequential per-VM accounting correctness, not concurrent-access
safety, since there was never concurrent access to test.
Agreed direction: fix this without a scheduler, by reusing the same
least-dense-candidate judgment stadium_admit() already trusts for
eviction, applied to "whose turn is next" instead of "who gets evicted" --
a fleet-level turn-attractor giving the next turn to whichever live
identity currently has the lowest execution_heat_q48, no fixed round-robin,
no priorities, no preemption. Lives beside Stadium in
capsule_vm_physics.c (already the fleet-level consumer of Stadium
primitives, e.g. the K mechanism itself), not inside stadium.c ("the
floor" -- residency/eviction, a different concern from turn order) and
not a new subsystem.
This pass lands only the primitive the mechanism needs: VM-HEAT
( c-addr u -- heat-q48 ), pushing a named VM's current
execution_heat_q48 via vm_physics_heat_of() -- previously C-internal
only (doe_log_heat_by_name(), doe_log.c), never exposed to FORTH. Silent
0 on an unknown/dead name (no print/error), since a turn-attractor
scanning many candidates every turn shouldn't have to filter console
noise for names that simply aren't live. Registered everywhere
VM-EXEC/VM-CALL already are. Builds clean on all three architectures;
live-tested on amd64: Hera -> 65452, Hermes -> 43, unknown name -> 0, no
faults.
The turn-attractor loop itself (std79-doe.fth's trial ordering) is not
yet built -- next step, not done here.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXieurDfDSsDFdnSyusuWo
capsules/
FORTH personality files loaded by the VM at boot. A capsule is an immutable, content-addressed payload; its XXHash64 hash is its identity. Any mutation changes the hash and the birth protocol rejects the image.
Key files
| File | Type | Purpose |
|---|---|---|
init.4th |
(m) MAMA_INIT |
Default Mama VM personality — loaded at LBN 2048 |
ACL.4th |
user | Word-level ACL system; self-activating at boot |
zuse.4th |
user | Bootstrap superuser; loaded by ACL.4th |
doe.4th |
user | DoE workload words (EXEC-DOE) — opt-in |
init-0.4th … init-9.4th |
(p) |
Numbered personality variants |
init-l8-*.4th |
(p) |
L8 Jacquard mode variants (stable/volatile/diverse/temporal/transition/omni) |
hermes/init.4th |
(p) |
Hermes baby VM personality |
artemis/init.4th |
(p) |
Artemis baby VM personality |
Block namespace
Block ranges are shared across all loaded capsules — collisions cause silent word-definition overwrites.
| Range | Owner |
|---|---|
| 2048–2099 | init.4th |
| 2100–2199 | doe.4th |
| 3000–3999 | workload capsules |
| 4000+ | user-defined (ACL.4th, zuse.4th, …) |
Each block is limited to 1024 bytes. Verify with wc -c before committing.
See also
experiments/bare_metal/README.md— DoE protocols and block namespace rulesdocs/03-architecture/word-acl/DESIGN.md— ACL system designtools/mkcapsule.c— assembles capsules intocapsule_generated.c- Project root