Attempted 4.4g's console_fb_init() reorder twice this session: once bare, once with the fb_scroll_rows() volatile fix applied. Both stalled boot indefinitely (12,000+ lines logged, still running after 3 minutes vs. a normal few-second boot) instead of completing. Root cause traced past the scroll fix to Makefile.starkernel building the kernel at -O0 -- no optimization flag has ever been configured there, verified against the file's full git history (17 commits, only ever one unrelated host-tool -O2 line). Both the kernel's own vendored hosted Makefile and the standalone StarForth repo's Makefile default to -O2 (up to -O3/-flto on faster targets); Makefile.starkernel was written fresh for the bare-metal target and never got that ladder. Documented as new item 4.6: enabling optimization is not a safe drop-in change on its own. Found one confirmed, isolated correctness hazard first -- TimeTrustState.ticks (timer.h:90) is written directly in ISR context on all three architectures (heartbeat.c:163) and read directly by mainline (heartbeat.c:200-202, including a busy-wait in kernel_main.c:880) without being volatile, unlike every other ISR-shared global checked (g_spurious_count, g_plic_claim_count, g_pending_counter/g_pending_valid/ g_adaptive_period_ns are all correctly volatile already). Reverted the console_fb_init() reorder itself (uncommitted, so a plain git restore) -- 4.4g stays open pending 4.6. Both the reorder attempts' logs (stalled, never reached ok>) and this session's routine three-arch artifacts (capsules/BLOCK_MAP.md, disk/ artemis.img, DOE CSV) are committed as audit trail per CLAUDE.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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