Files
LithosAnanake/capsules
Robert Allan JamesandClaude Sonnet 5 19916717b2
Build / build-amd64-iso (push) Waiting to run
Build / build-aarch64-iso (push) Waiting to run
Build / build-riscv64-img (push) Waiting to run
Turn-attractor rebuilt on real messaging: two live defects found and fixed before the full campaign (FABRIC-3.md §XXI)
Rewrote EXEC-STD79-DOE-CD's dispatch to coordinate via MSG-SEND/
MSG-TICK instead of blocking VM-EXEC, now that Hera can genuinely
message (§XX). RUN-TEST/EXEC-STD79-DOE (the serialized baseline) are
untouched, kept as a byte-for-byte-reproducible historical comparison
point.

A small 2-identity smoke test before any multi-architecture
commitment caught two real defects the design alone didn't predict:

1. Absolute VM-HEAT can't produce fine-grained interleaving -- a
   fresh identity starts at heat=0 against Hera's ~62000+, a gap no
   1..24 divisor closes, so priority locked onto whichever identity
   had executed least, for its entire campaign. Fixed with BASE-HEAT:
   each identity's heat is snapshotted once at campaign start, and
   priority is computed from heat gained *this campaign*, not
   lifetime heat.

2. Single-test-per-message granularity silently drops most of a
   campaign's data: MSG-SEND no-ops on MSG-ALLOC failure, and the
   turn bookkeeping advanced regardless, so rows looked complete
   while missing most of their tests. A live reservoir probe showed
   Hera's own STADIUM-RES@ draining ~725/cycle with no
   replenishment observed -- a 648-send full campaign would exhaust
   it almost immediately. Fixed by dispatching a whole rep (24 tests,
   one concatenated command, measured 442 bytes, well under
   VM-EXEC's 1025-byte cap) per message instead -- 27 sends for a
   full campaign, not 648.

Re-verified after both fixes: 99/99 expected test outputs present,
zero drops, zero faults, genuine rep-level interleaving instead of
either the serialized baseline's fixed order or the first cut's
72-test lock-in.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXieurDfDSsDFdnSyusuWo
2026-09-12 16:53:01 -04:00
..
2026-08-01 07:49:56 -04:00

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.4thinit-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
20482099 init.4th
21002199 doe.4th
30003999 workload capsules
4000+ user-defined (ACL.4th, zuse.4th, …)

Each block is limited to 1024 bytes. Verify with wc -c before committing.

See also