Robert Allan JamesandClaude Sonnet 5
d68223d43f
FABRIC-2.md closed archival at ~4,400 lines / 51 open items, same reasoning FABRIC.md itself was closed for at 7,595 lines -- continuing to append made still-open work hard to find. All 51 open items carried forward into FABRIC-3.md's new Section A, verified complete via programmatic diff against the source (49 unique + 2 confirmed pure duplicates from FABRIC-2.md's own F.3 cross-reference section, not dropped content). .claude/CLAUDE.md's pointer note updated to name FABRIC-3.md as current. New Section B: full audit of stadium_dispatch()'s four behaviour stubs (MIGRATE/DELIVER/EXPIRE/COOL), triggered by investigating "words/VMs/blocks/ messages should all be on the same engine". Found the picture is more nuanced than "everything's a stub" -- words are already fully live via a separate bespoke mechanism (stadium_word_dispatch(), wired into vm_core.c's real word-execution path, item 4.1), contradicting ONTOLOGY.md's stale "not yet migrated" claim (flagged for a follow-up fix). MIGRATE (blocks) and VM-COOL are genuinely stub with zero consumers; DELIVER (Hermes) and EXPIRE (ACL) are substantial, undecided subsystem integrations FABRIC.md itself already flagged as open, not touched here. New standing rule, saved as memory feedback_no_stubs_or_todos.md: stub implementations and TODO placeholders are never acceptable in this workflow, in any language, ever -- triggered by finding stadium_dispatch()'s stub handlers during this investigation. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CXjAPTEKrgY2Mrk25KoLDn
.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.