rajamesandClaude Opus 5.5
0fd7648a77
Build / Image RASPI (push) Successful in 4m19s
Build / Image PC (push) Successful in 4m14s
Build / Image MILKV (push) Successful in 4m30s
Build / v4 tests (32- and 64-bit cells) (push) Successful in 11m19s
Acceptance / Acceptance (pull_request) Successful in 16m48s
Captain Bob, 2026-11-06: what a developer runs, what CI runs and what the nightly runs are one process, and "failures should not be allowed to be merged to master". acceptance.yml runs on every PR into master (opened, pushed to, reopened): .claude/CLAUDE.md's acceptance protocol through the same scripts/nightly.sh stages -- amd64, aarch64, riscv64 to [zuse@Hera] ok>, the PC stick loaded high (and the three agree on dict_hash), then make -C v4 test-32 -- one QEMU at a time, in one job. Its logs and DoE CSVs are kept, pass or fail. master's branch protection requires it. acceptance, nightly and release share the concurrency group qemu, so the runner never runs two of them at once: CLAUDE.md's one-QEMU rule holds in CI too. build.yml becomes the quick check on pushes only. .claude/CLAUDE.md's Hard Rules: commit and push directly on the working branch; master only through a PR that passed acceptance, no direct pushes; no approval required while there is one developer. Named: the Captain Bob method. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
.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.