From a9a99146ae65563aaa90f6fe1e8081c2ea99f1ff Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Thu, 13 Aug 2026 10:40:50 -0400 Subject: [PATCH] ARTEMIS.md: fix stale 'boots live in fleet on every boot' claim, same pattern as TRIPOD.md capsules/init.4th births no VM but Hera (item 0.1). Artemis's disk device auto-attaches at boot (kernel_main.c M7.pre, real, unchanged); Artemis-as-VM-patron capsule birth does not. --- .claude/ARTEMIS.md | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/.claude/ARTEMIS.md b/.claude/ARTEMIS.md index 6ebf2b2..9983897 100644 --- a/.claude/ARTEMIS.md +++ b/.claude/ARTEMIS.md @@ -136,8 +136,20 @@ not remember *heat*. Every join is a cold join. Implementation happened; this section used to say "do not begin without explicit instruction" — that instruction was given and the work is done for this scope. `capsules/artemis/init.4th` implements the full flat-pool -target above, and Artemis boots live in the Tripod fleet (announces ready -to Hermes) on every amd64/aarch64/riscv64 kernel boot. +target above. + +**Corrected 2026-08-13 — the "boots live in the Tripod fleet... on every +kernel boot" claim below is stale since item 0.1 (`FABRIC.md` Phase 0), +same pattern already found and fixed in `TRIPOD.md`.** Two distinct things +were being conflated: Artemis's block-storage *device* (the virtio-blk +disk, `disk/artemis.img`) genuinely does auto-attach at the C level at +boot (`kernel_main.c`'s M7.pre step) on all three architectures — that +part is real and unchanged. But Artemis-as-VM-patron (capsule birth, +`CD-INIT`, announcing ready to Hermes) is not automatic: confirmed +`capsules/init.4th` births no VM but Hera, same as Hermes. Artemis's own +capsule work below (`ART-BOOT-DETECT`, `ART-FORMAT`, etc.) is real and +verified, but it runs on demand today, not as a boot-automatic fleet +join. Acceptance criteria status, verified 2026-08-02: 1. ✅ `ART-BOOT-DETECT` — BLANK/LithosAnanke/Unrecognized classification,