Files
LithosAnanake/capsules
Robert Allan JamesandClaude Sonnet 5 704573bdfc
Build / build-amd64-iso (push) Waiting to run
Build / build-aarch64-iso (push) Waiting to run
Build / build-riscv64-img (push) Waiting to run
FABRIC-2.md §I.9: root-cause the terminal defect, not fixed (identify-only)
No code changed. This is a closure annotation on an existing open item
where it lives (FABRIC-2.md, marked archival by CLAUDE.md, but §I's punch
list landed there after the FABRIC series rename and genuinely still
lives there) -- not new design content in an archival doc.

Used QMP send-key to inject a real keypress into a running headless QEMU
guest -- no physical keyboard needed, overturning this item's own
"no way to observe the live QEMU GTK window from this environment"
assumption. A first pass (amd64 + aarch64, real first keypress after a
fresh boot, pre/post log captures) actually reproduced the defect but
misread it as clean: both logs showed the echoed key on a bare new
"[Hera]" line instead of appended to the still-visible "(zuse) ok> "
line, which looks like normal REPL output unless you know the prompt
should still be there. QMP screendump on aarch64 confirmed it visually.

Root cause traced to two specific interacting lines, not guessed:
console_ensure_line_start() (hal/console.c:312) emits its newline via
the tx-count-exempt console_putc_inner(), by design, so idle chatter
doesn't spam the REPL's prompt reanchor. But sk_repl_idle() (repl.c:178)
calls it unconditionally on every ~1s idle beat, including at a bare
prompt with nothing typed (n==0, repl.c:610) -- forcing a real but
tx-count-invisible newline that the reanchor check (repl.c:633) never
notices, so the prompt is never reprinted. The next real keystroke
echoes onto the now-blank line with a lazily-emitted "[VMName] " prefix,
indistinguishable from Enter having already been pressed. Not a
first-keypress race -- it fires on any ~1s+ human pause at a bare
prompt, i.e. nearly always, matching "consistent and reproducible."

repl.c's own comment at lines 598-609 already half-diagnosed this
exact failure mode and gates it for n>0 (mid-edit); the gap is the
identical n==0 case (bare prompt) was treated as harmless. Likely fix
location noted, not designed here.

Verified reproducible on both amd64 (i8042) and aarch64 (virtio-input)
input paths; riscv64 shares aarch64's virtio-input code path. Evidence:
three fresh boot logs plus before/after screendump PNGs
(evidence/aarch64/qemu-screenshot-20260905-013835-i9-*.png). No 3-arch
acceptance boot run for this commit -- no code changed, and these
logs/screenshots are themselves the evidentiary artifact, not a
generic regression check.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
2026-09-05 01:47:53 -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