TRIPOD.md: fix stale Immediate Goal section, Hera does not auto-spawn at boot

Item 0.1 pruned capsules/init.4th to Hera-alone; TRIPOD.md was never updated to match. Corrected to reflect current on-demand-birth reality and distinguish Artemis-the-storage-device (auto-attaches at boot, kernel_main.c) from Artemis-the-VM-patron (not auto-spawned). Partial closure of FABRIC-2.md item 5.3 -- the doc's broader shrink-to-three-lines scope remains open.

.claude/TRIPOD.md

@@ -27,15 +27,31 @@ or work execution logic in Hera — stop. You have the wrong VM.
 
 ## The Immediate Goal
 
-Hera must spawn Hermes and Artemis at boot, and all three must cooperate
+**Corrected 2026-08-13 — stale since item 0.1 (`FABRIC.md` Phase 0), flagged in
+`FABRIC-2.md` §A item 5.3, never fixed until now.** This section used to say Hera spawns
+Hermes and Artemis automatically at boot. She does not, by deliberate design: item 0.1
+pruned `capsules/init.4th` to boot Hera alone (confirmed current —
+`capsules/init.4th` births no other VM). Hermes and Artemis-as-VM-patron births happen
+on demand today, via test tooling (`tools/hermes_smoke.sh`,
+`tools/hermes_channel_smoke.sh`, `tools/hermes_tripod_smoke.sh`) and manual capsule
+swaps, not automatic boot behavior. Separately, and not to be confused with a VM birth:
+Artemis's block-storage *device* (the virtio-blk disk, `disk/artemis.img`) does attach
+automatically at boot at the C level (`kernel_main.c`'s M7.pre step) on all three
+architectures — that is real and live, but it is storage attachment, not Artemis
+initializing as a compudynamic VM patron.
+
+The goal below is still the eventual target; it describes where the Tripod is headed,
+not what boot does today.
+
+Hera must be able to spawn Hermes and Artemis, and all three must cooperate
 compudynamically under K≡1.0 conservation.
 
 That is the complete scope. Nothing else.
 
 Acceptance criteria:
 1. Hera boots and initializes her own compudynamic state.
-2. Hera spawns Hermes. Hermes initializes his own compudynamic state.
-3. Hera spawns Artemis. Artemis initializes her own compudynamic state.
+2. Hera can spawn Hermes. Hermes initializes his own compudynamic state.
+3. Hera can spawn Artemis. Artemis initializes her own compudynamic state.
 4. All three VMs are running. Fleet K = sum of individual VM K values. K≡1.0 holds.
 5. Hera can reap (cleanly terminate) a child VM.
 6. The system is stable across a long-running test workload.

FABRIC-2.md

@@ -48,6 +48,19 @@ and recorded.
   Goal section still describes Hera spawning Hermes and Artemis automatically at boot — item
   0.1 undid that behavior, and the doc was never updated to match.
 
+  > **Pending edit fixed 2026-08-13; the item's larger scope (actually shrinking the four
+  > documents) remains open.** `TRIPOD.md`'s "Immediate Goal" section corrected: it now
+  > states plainly that Hera boots alone by design (confirmed live —
+  > `capsules/init.4th` births no other VM), that Hermes/Artemis-as-VM-patron births are
+  > on-demand via test tooling today (not automatic boot behavior), and separately notes
+  > that Artemis's block-storage *device* does auto-attach at the C level at boot
+  > (`kernel_main.c`'s M7.pre step) — distinct from, and not to be confused with, an
+  > Artemis VM patron birth. The acceptance criteria were reworded from "Hera spawns X"
+  > to "Hera can spawn X" to stop asserting automatic behavior that doesn't exist. This
+  > closes only the one stale claim this document already flagged — `ARTEMIS.md`,
+  > `HERMES.md`, `CONSOLE.md` were not read for similar staleness, and none of the four
+  > documents' actual line-count reduction (the item's real ask) has been attempted.
+
 ---
 
 ## B. Live and unmeasured — deferred while Tripod was pruned to Hera-alone, now genuinely live since item 4.2 restored Hermes