FABRIC-3.5.md §XIV: two rulings collapse the root dependency

Captain Bob, 2026-09-18. The existing FORTH messaging layer is legacy --
kernel Hermes is greenfield C, not a migration of messaging.4th, and the
dead FORTH gets retired by a separate cleanup pass. Persistence goes
through Artemis wherever possible; that part is ratified.

Together these dissolve rather than answer four open questions. §III.4,
named the root dependency throughout §X, is resolved in the "full
centralization" direction but without the migration cost that made it
frightening: with the FORTH legacy there is no live state to port. §III.3
loses its subject, and §XIII.1's 14-site inventory changes purpose rather
than content -- it now feeds the cleanup. §IV.2 dissolves via its own
option 3, exactly as that section predicted. The MANIFEST corrections are
absorbed into the cleanup pass. All four marked superseded in place with
pointers rather than rewritten.

Traced the layering question the persistence ruling raises, and it
answers cleanly: storage is already two layers, so no inversion is
needed. The block subsystem is kernel C below the floor
(block_subsystem.c, blkio_*.c, virtio_blk.c; capsule_loader.c:98-100
calls it with no Artemis involved), while Artemis is the storage policy
arbiter on the floor. Fleet persistence goes through Artemis; anything
kernel Hermes needs uses the same block layer Artemis sits on.

Flags the one hazard that ruling carries: Hermes must not depend on
Artemis for persistence at its own death, since reaching Artemis requires
the mechanism that is broken -- the same trap §VIII solved for signalling
with a semaphore. Recommends a stateless arbiter holding only
registry-reconstructible state, offered as analysis, not a ruling.

Also records the scheduler firewall as raised-but-unruled, and why the
legacy ruling makes it more urgent: eligibility marking moves inside the
arbiter by default once kernel Hermes replaces FORTH MSG-SEND as the
caller of sk_vm_switch_signal_mark_work().

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VkM1zHGvBerLF6aqkHPweP

FABRIC-3.5.md

@@ -205,6 +205,11 @@ its own routing failure) not a special case but a direct corollary — see §VII
 
 ### III.3 — The by-name `VM-EXEC` dependency has to go somewhere. Open.
 
+> **SUPERSEDED 2026-09-18 by §XIV.1/§XIV.2 — this question dissolved.** The three options below
+> all assume the existing FORTH callers must be preserved. Captain Bob ruled the FORTH
+> messaging layer legacy, so §XIII.1's inventory becomes input to a dead-FORTH cleanup rather
+> than a migration constraint. Left in place, not rewritten.
+
 §I.2's two Artemis call sites are the sharp edge. `S" ..." S" Hermes" VM-EXEC` requires a
 target VM with a dictionary. Three shapes are visible; **none is chosen here:**
 
@@ -225,6 +230,11 @@ been run exhaustively for this document and must be, repo-wide, before scoping.*
 
 ### III.4 — The per-VM-arena question. Open, and the biggest unknown here.
 
+> **RESOLVED 2026-09-18 by §XIV.1/§XIV.2.** Answered in the "full centralization" direction,
+> but without the migration cost this section feared: with the FORTH legacy there is no live
+> state to port. This was named the root dependency throughout §X; it is closed. Left in
+> place, not rewritten.
+
 Per §I.1 the arenas are per-VM dictionary allocations. If arbitration centralizes into the
 kernel, does `MSG-ARENA`/`CH-ARENA`/`MBR-ARENA` centralize with it, or does each VM keep its
 own outbox/inbox with only the *routing* centralized? These are very different amounts of
@@ -260,6 +270,11 @@ arbitration) unchanged. Console takes the slot Hermes vacates.
 
 ### IV.2 — The "never renumbered" collision. Open, needs a ruling.
 
+> **DISSOLVED 2026-09-18 by §XIV.1/§XIV.2 — via option 3 below, exactly as this section
+> predicted.** The FORTH routing table is legacy, so the slot-numbering question has no
+> subject. Option 3's own caveat ("settle §III.4 first") was the correct call. Left in place,
+> not rewritten.
+
 §I.3's comment commits to Hera/Hermes/Artemis at 0/1/2 and to identities at 3–10 *never*
 being renumbered. Hermes leaving index 1 forces a choice, and the existing comment forecloses
 the laziest option:
@@ -566,10 +581,12 @@ There is no other test.
 
 ## XII. Explicitly not decided anywhere in this document
 
-Collected so nothing here is mistaken for settled: §III.3, §III.4, §IV.2, §V.3 (all four),
-§VI.3, §VI.4, §VII.2 (number and consumer), §VII.3, §VII.4, §VIII.3 (all three), §IX.3 (both),
-and — added 2026-09-18 — §XIII.5's Console-singleton question (punch item 12), which gates
-§IV entirely. §XIII.5's proposed resolution shape is **analysis, not a ruling.**
+Collected so nothing here is mistaken for settled. **Updated 2026-09-18 after §XIV's rulings**
+— §III.3, §III.4 and §IV.2 have left this list (resolved or dissolved; see §XIV.2). Still open:
+§V.3 (all four), §VI.3, §VI.4, §VII.2 (number and consumer), §VII.3, §VII.4, §VIII.3 (all
+three), §IX.3 (both), §XIII.5's Console-singleton question (punch item 12, gates §IV),
+§XIV.4's message-durability trade (item 15), and §XIV.5's scheduler firewall (item 14).
+The proposed resolution shapes in §XIII.5, §XIV.4 and §XIV.5 are **analysis, not rulings.**
 
 What **is** decided, all by Captain Bob on 2026-09-18 and recorded in §III.1, §IV.1, §V.1,
 §VI.1, §VII.1, §VII.2, §VIII.1 and §IX.1: Hermes goes into the kernel and becomes the arbiter
@@ -766,3 +783,139 @@ Nothing found here dislodges §III.4 as the root dependency. Two adjustments:
   contents). Reported, not fixed.
 
 Items 3–11 unchanged and still open.
+
+---
+
+## XIV. Two rulings that collapse the root dependency (Captain Bob, 2026-09-18)
+
+### XIV.1 — RULING: the existing FORTH messaging layer is legacy. Kernel Hermes is greenfield.
+
+**Captain Bob, 2026-09-18, verbatim:** "as far as Hermes the VM and Hermes the kernel
+component, forget all the forth existing and call it legacy for now. We'll do a code cleanup
+for all the dead FORTH anyway."
+
+So kernel-Hermes is **not** a migration of `capsules/common/messaging.4th`. It is a new C
+implementation; the FORTH messaging layer becomes legacy on arrival and is retired by a
+separate dead-FORTH cleanup pass. This reverses the framing §III.3 and §III.4 were built on —
+both assumed the existing FORTH had to be carried across.
+
+### XIV.2 — What this collapses
+
+Four of this document's open questions dissolve rather than get answered:
+
+- **§III.4 (the root dependency) — RESOLVED by fiat, in the "full centralization" direction,
+  but without the migration cost that made it frightening.** The kernel owns message and
+  channel state; `messaging.4th`'s per-VM `CREATE`/`ALLOT` arenas are legacy, not something to
+  centralize. §III.4 feared a painful port of live FORTH state; there is no port.
+- **§III.3 (the by-name `VM-EXEC` dependency) — dissolved.** The three-option framing
+  (kernel primitives / vestigial name / birth-time registration) was about preserving callers.
+  With the FORTH legacy, §XIII.1's 14-site inventory stops being a migration constraint and
+  becomes an input to the cleanup pass. **§XIII.1's inventory is still the right list — its
+  purpose changed, not its content.**
+- **§IV.2 (routing-table slot numbering) — dissolved, exactly as §IV.2's own option 3
+  predicted:** "the routing table stops being a FORTH array at all... in which case this
+  question dissolves into §III.4's arena question." It did. `VM-NAMES-INIT`'s 0/1/2 pinning and
+  the "never renumbered" commitment are legacy artifacts, not constraints on the new design.
+- **§XI item 13 (the `MANIFEST.md` corrections) — absorbed.** Bob's "we'll do a code cleanup
+  for all the dead FORTH anyway" covers §XIII.2's findings. Still worth doing deliberately;
+  no longer a separate ask.
+
+**§XIII.1, §XIII.2 and §XIII.3 keep their value** — the C-side sites (§XIII.3) are *not*
+legacy and remain real edit sites, and the dead-FORTH inventory now feeds the cleanup.
+
+### XIV.3 — RULING: Artemis is the persistence path. And it needs no layering inversion.
+
+**Captain Bob, 2026-09-18:** "For persistence though, use Artemis as much as possible. We're
+good with that part for sure." Ratified.
+
+**A layering question this raises, traced 2026-09-18 and answered cleanly.** Artemis is a VM on
+the Stadium floor; kernel-Hermes sits *below* the floor. "Persist via Artemis" reads at first
+like an inversion — the kernel arbiter calling up into a floor VM. It is not, because storage
+is already two layers, not one:
+
+- **The block subsystem is kernel/shared C, below the floor:** `src/block_subsystem.c`,
+  `src/blkio_*.c`, `src/starkernel/virtio/virtio_blk.c`. `capsule_loader.c:98-100` calls
+  `blk_subsys_init()` and `blk_subsys_add_raw_device()` directly, with no Artemis involved at
+  all.
+- **Artemis is the storage *policy arbiter* on the floor:** it owns attach/registration
+  (`blk_subsys_attach_device()` via the `BLK-ATTACH` primitive — `repl.c:525-531` states it
+  outright, "Artemis's own domain now, not Hera's") and the on-disk Artemis format.
+
+So the ruling is satisfiable without inversion, by keeping the two straight: **floor-level and
+fleet persistence goes through Artemis, its domain and its format; anything kernel-Hermes
+itself needs uses the same block subsystem Artemis is built on — never a new one, and never by
+messaging Artemis.**
+
+Worth recording that the kernel *already* calls up into Artemis by name today
+(`repl.c:539-541`, `S" %llu HERA-BLK-ATTACH-REQ" S" Artemis" VM-EXEC`), with a comment
+explaining it is a direct `VM-EXEC` rather than a real message because Hera can't use her own
+`MSG-SEND` there. That precedent exists; this section is about not *depending* on it.
+
+### XIV.4 — The one real hazard in the persistence ruling, and the shape that avoids it
+
+**Kernel-Hermes must not depend on Artemis for the persistence it needs during its own
+failure.** This is the same structural trap as §VIII: if Hermes must write something at death
+and reaching Artemis requires routing, the dependency closes a circle on exactly the mechanism
+that is broken. §VIII solved the *signalling* case with a semaphore; the persistence case
+needs the same discipline rather than a second special case.
+
+**Recommended shape — analysis, not a ruling, Captain Bob's call: kernel-Hermes holds only
+reconstructible state.** If the arbiter's routing state can be rebuilt from the live VM
+registry (which `capsule_birth.c` already maintains as the authority on who exists), then:
+
+- Hermes has nothing that *must* be persisted, so the Artemis dependency never arises.
+- §VII.4's "what does warm restart mean for Hermes" becomes trivial — rebuild from the
+  registry, no saved state to reconcile.
+- Losing in-flight messages when the arbiter dies is consistent with §VII.1 step 3's "no
+  lingering, no partial states," and with §VIII's clean-shutdown window.
+
+This costs message durability across an arbiter death. **Flagged as the real trade**, and the
+one to rule on: if in-flight messages must survive Hermes dying, Hermes needs durable state,
+and that durable state cannot route through Artemis at death-time.
+
+### XIV.5 — Still open, and now more urgent, not less: the scheduler firewall
+
+Raised 2026-09-18 and **not yet ruled on**. Recorded here because §XIV.1 changes its timing.
+
+The fleet already has a scheduler: §XXVIII built timer-driven preemption, and `MSG-SEND`
+(`messaging.4th` block 5021) already calls `SWITCH-MARK-WORK` → `sk_vm_switch_signal_mark_work()`,
+setting `has_work` on the target's switch slot; `sk_vm_switch_signal_tick()` switches when
+`readiness >= SK_SWITCH_READINESS_THRESHOLD` **and** `has_work`. **Message arrival is already
+a scheduling input.** This directly contradicts `VM-PHYSICS-DYNAMIC-FLEET-DESIGN-20260705.md`'s
+"Explicitly not wanted: a VM scheduler. Nothing gets built that decides whose turn it is to
+execute" — a live tension in the project that predates this document and is not this
+document's to resolve, but is this document's to not make worse.
+
+**Why §XIV.1 sharpens it.** Today that coupling runs FORTH `MSG-SEND` → C primitive → switch
+slot. With the FORTH legacy, **kernel-Hermes becomes the caller of
+`sk_vm_switch_signal_mark_work()` directly** — eligibility marking moves inside the arbiter.
+That is the consolidation to guard against, and it happens by default unless the boundary is
+stated up front. Greenfield is the right time to state it; retrofitting it later is how this
+becomes a conventional scheduler by accident.
+
+**Proposed invariant, for ruling:** *kernel-Hermes carries, resolves and ACL-checks. It
+publishes facts — "this VM has mail" — and never reads readiness, never orders traffic by
+priority, and never decides turn order. `switch.c` remains the sole owner of "who runs next."*
+
+The argument for it is empirical and from this project's own history: §XXVIII.2 is a record of
+switch-storms caused by **two sources of truth disagreeing** about who was running
+(`vm_log_attributed_vm()` vs. the real trampoline state) — QEMU pinned near 100%, serial log
+frozen solid. This codebase punishes duplicated authority with hangs. Two deciders would be
+worse than one scheduler.
+
+### XIV.6 — Punch list after these rulings
+
+- ✅ **Item 3 (§III.4, the root) — RESOLVED** by §XIV.1. Kernel owns messaging; FORTH is legacy.
+- ✅ **Item 4 (§III.3) — DISSOLVED** by §XIV.1; §XIII.1's inventory becomes cleanup input.
+- ✅ **Item 5 (§IV.2) — DISSOLVED** by §XIV.1, as §IV.2 option 3 predicted.
+- ✅ **Item 13 — ABSORBED** into the dead-FORTH cleanup pass.
+- ⬜ **Item 14, NEW** — rule on §XIV.5's scheduler firewall invariant. **Raised, not ruled.**
+- ⬜ **Item 15, NEW** — rule on §XIV.4: does message durability survive an arbiter death? If
+  yes, Hermes needs durable state that cannot route through Artemis at death-time.
+- ⬜ Items 6, 7, 8, 9, 10, 11, 12 unchanged and still open.
+
+**Note the shape of what remains.** With the root dependency resolved, the surviving open
+items are no longer about *mechanism* — they are about *authority*: who may birth (6, 7), who
+decides a VM is dead (8, 11), who owns turn order (14), and what survives a death (15). That
+is a better class of question to be left with, and §IX's "authority only ever flows down the
+birth graph" is the principle most of them should be tested against.