Claude
afcaeebbc7
Reopened by instruction to add the sweep. The design phase stays closed and the prior close header is kept rather than overwritten, per the series' own rule against silently rewriting a prior state. A gap analysis of a series whose central rule is never silently drop a stale claim is an audit of whether it kept that rule. Mostly it did. The carry-forward chain held twice and then terminated. F0 to F1 held; F1 to F2 is independently verifiable, since F2 claims a non-sampled carry-forward of 51 items and grep returns exactly 51 today; F2 to F3 broke, with every long-lived F0 item id returning zero references in FABRIC-3. FABRIC-3 carries no checkboxes at all, which is a legitimate style choice but ends the mechanical audit trail -- after FABRIC-2, "is anything still open" stops being a grep and becomes a reading exercise, which is how the orphaned items went quiet without anyone deciding to drop them. FABRIC-2's close header claims every item was closed or left open pending a physical machine. Eight of its fourteen opens are the hardware boot checklist and the claim holds for those; six are design items with no hardware dependency and appear nowhere since. FABRIC-0's seven opens all remain, and three were re-derived by this document without either side knowing: 4.3's deferred tail is verbatim "Console as a fleet VM under Hera's birth protocol," which is §XVII and §XVIII; 5.2 already specifies the Isabelle target as one conservation theorem, almost certainly the K that §XV.4 rediscovered independently; and 5.3 already asked for §XXVI.1's subsystem-doc work. The urgent finding is that FABRIC-3 holds an open item contradicting §XV.3. The MSG-TICK/Stage-3 dual-ownership rough edge -- both mechanisms can independently move control between the same VMs -- is still open and not observed failing, which is a live instance of exactly the dual ownership §XV.3 forbids as a principle. §XIV.5's scheduler concern was a rediscovery of it, and kernel-Hermes lands directly on that seam by becoming the caller of sk_vm_switch_signal_mark_work(). Filed ahead of the kernel-Hermes work rather than alongside it. Also re-homes §17.4's undesigned framebuffer heat/decay as Hestia's, and records that three reported-not-scheduled registries exist with inconsistent hygiene -- §25.7 leaves two resolved entries unstruck, including a fleet heat leak closed in FABRIC-1 that still reads as live. No ruling in §I-§XXX is invalidated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VkM1zHGvBerLF6aqkHPweP
LithosAnanke v2.0.1
UEFI-bootable FORTH microkernel. Boots from firmware, initialises memory and interrupts, then runs the StarForth VM as its sole userspace runtime. No libc. No OS. Just stone and necessity.
Lithos (foundation) + Ananke (necessity) — the kernel under StarshipOS.
Status — M7.1 (Capsule System · Multi-VM Fleet)
| Milestone | Status | |
|---|---|---|
| M0–M6 | UEFI boot · PMM · VMM · IDT · APIC · heap · framebuffer VT100 console (v1.5.1-FINAL) | ✅ Complete |
| M7 | StarForth VM integration + parity validation | ✅ Complete |
| M7.1 | Capsule birth protocol · Mama FORTH vocabulary · Tripod multi-VM fleet (Hermes/Artemis) · Word-level ACL (Phases 1–7) | 🔄 In Progress |
| M8 | REPL — keyboard input, interactive Forth | Planned |
| M9 | Block storage — AHCI driver | Planned |
POST at boot: parity hash verified across amd64/aarch64/riscv64 · Mama capsule dictionary: 453 words
What's live in M7.1
- Tripod — a named multi-VM fleet (Hera the Mama VM, Artemis, two Hermes instances) births, runs, and re-births independently, verified booting live pre-REPL on all three architectures.
- Hermes — a 17-block inter-VM messaging/channel layer between fleet members, with async delivery and channel negotiation.
- Artemis — a Block Allocation Map (BAM) storage subsystem with Q48.16
block-heat tracking and cooldown/reclamation (
ART-COOL/ART-REAP). - Word-level ACL — every dictionary entry carries a TTL/allow/mode/pin
access-control record. Strict, TTL, and pinned modes; two console layers
(emergency
ok>and superuserzuse)ok>). Phases 1–7 complete (C infrastructure, FORTH policy layer,zusebootstrap superuser, Isabelle proof stubs, kernel parity); Phase 8 (Ed25519 PKI / thumbdrive challenge-response) is the only item remaining. Measured overhead once active on every check: +0.0054%–+0.0088%, CV = 0.000%, across a 3×3 Latin-square DoE campaign (architecture × seed × 30 replicates) — three orders of magnitude below the measurement floor. - VM Fleet Attractor physics — the L8 Jacquard mode selector now has a real per-VM heat channel into fleet-wide tuning, replacing hardcoded compudynamics constants with a dynamically-inferred rate.
- Kconfig build configuration — every physics/heartbeat/pipelining/ kernel-only tuning knob (~40 total) is now a discoverable, optional Kconfig symbol shared with the hosted VM build. See Quick Start below.
Quick Start
# Build kernel (requires cross-compilation toolchain, or native gcc)
make -f Makefile.starkernel ARCH=amd64
# Run in QEMU with OVMF
make -f Makefile.starkernel qemu
# Other architectures
make -f Makefile.starkernel ARCH=aarch64 qemu
make -f Makefile.starkernel ARCH=riscv64 qemu
Artifacts: build/amd64/kernel/starkernel_loader.efi · build/amd64/kernel/starkernel_kernel.elf
For the hosted VM by itself (Linux, no cross-compiler needed, no bare-metal tooling): see
the separate StarForth repository — LithosAnanke used to be a branch inside that repo,
now it's its own project with its own master.
Build configuration (optional)
Every kernel-only knob (STARFORTH_ENABLE_VM, PARITY_MODE, the shared
physics/heartbeat family, etc.) is an optional Kconfig symbol — a plain
make -f Makefile.starkernel uses the same defaults it always has unless
you opt in:
make -f Makefile.starkernel ARCH=amd64 menuconfig
make -f Makefile.starkernel ARCH=amd64 kernel_amd64_defconfig
Documentation
| System Architecture | Full kernel + VM design |
| HAL Reference | Hardware abstraction layer interfaces |
| Capsule System — M7.1 | Capsule birth protocol design |
| VM Fleet Attractor design log | Tripod/Hermes/Artemis physics + build-system history |
| Getting Started / Kconfig reference | Full symbol reference for both build targets |
| Changelog | Milestone-level history |
| Roadmap | Milestone plan through self-hosting |
License
Starship License 1.0 (SL-1.0) — free for personal, research, and educational use. Commercial use requires a separate agreement. Attribution to R.A. James (Captain Bob) must be preserved in all distributions.
Patent pending. USPTO provisional filed December 2025 — physics-grounded self-adaptive runtime system. This license does not grant patent rights. Licensing inquiries: rajames440@gmail.com
Robert A. James (Captain Bob) · Systems Engineer · Hacking since 1973