LithosAnanke is now its own repository rather than a branch inside the combined StarForth/LithosAnanke monorepo, so this drops the old master(StarForth)/lithosananke(kernel) branch-topology framing in favor of the current reality: this repo's master is the sole LithosAnanke production line. Ground-truths numbers that had drifted (kernel tree file count, word_source file count, capsule count), reframes the vendored VM source as the embedded engine it actually is rather than a second production target, and independently verifies the ACL kernel-parity and DoE-campaign claims against the actual current code. Fixes README's self-referential "see master branch" link to point at the separate StarForth repo instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
.claude/
Project-level configuration and instructions for Claude Code (claude.ai/code) when working in this repository.
CLAUDE.md— the authoritative reference for how an AI agent should work in this codebase: hard rules (branch discipline, never work onmasterwithout permission, never stash without permission, report bugs rather than fixing them unprompted), build commands for both the hosted VM and the LithosAnanke kernel, architecture summaries, and pointers into the rest of the documentation tree.docs/CLAUDE.mdis an older, hosted-only snapshot kept for historical reference — this file supersedes it.TRIPOD.md— architectural constraints for the Tripod: the three-VM fleet (Hera the governor, Hermes the messenger, Artemis the memory/ storage owner) that LithosAnanke boots. Defines each VM's contract and what NOT to put in each one (e.g. no storage logic in Hermes, no event routing in Artemis).HERMES.md— Hermes VM architecture: the message-routing VM. Read in full before touching any Hermes-related code.ARTEMIS.md— Artemis VM architecture: the block-storage/persistence VM, including its free-map allocator. Read in full before touching any Artemis-related code.settings.json— Claude Code session/tooling configuration for this repository.
All four .md files here are binding constraints, not suggestions — they
are read in full before any work on the subsystem they cover, per this
project's own stated policy.