docs/03-architecture/tripod/
Architectural constraints for the three StarForth VMs that make up the Tripod. These documents are binding — read the relevant one in full before touching any Tripod code. Violating the mythological contract they describe is treated as an architectural error, not a style preference.
- TRIPOD.md — The Tripod as a whole: Hera (VM-HERA=0,
governor — spawns/manages/reaps VMs), Hermes (VM-HERMES=1, messenger —
moves events), Artemis (VM-ARTEMIS=2, memory — owns block storage).
Covers capability-based dispatch (no heat-based routing), the CD-TICK
heartbeat, the K≡1.0 compudynamic conservation invariant, the DoE test
fixture's role, and explicit prohibitions (no heat-based VM routing, no
primitives added without instruction, no
BLOCKcalls outside the 0–3071 ramdrive range). - HERMES.md — Hermes VM architecture: the messenger role.
- ARTEMIS.md — Artemis VM architecture: the memory/block- storage role.
All three documents share a non-negotiable constraint: Tripod implementation is StarForth dialect only — no C99 without Captain Bob's explicit written permission for that specific construct.
See also
docs/birthing/— birthing plan and QEMU acceptance logs for the Hera-spawns-Hermes/Artemis constellation described here.- Project root