From 4b26be90c3595fecdabeeb3872b5cf86572e5da5 Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Wed, 5 Aug 2026 14:28:24 -0400 Subject: [PATCH] FABRIC.md: item 4.2 -- third ruling, VMUuid on VM struct (Option A) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Punch list §25 item 4.2 acceptance amended (scoping only, no code). Found while scoping the C/FORTH primitive layer: all three stadium_word_dispatch() call sites in vm_core.c hardcode vm_uuid_hera(), already flagged inline as this item's job, but fixing it needs a running VM* to know its own identity -- VMUuid exists only on VMRegistryEntry, never on VM itself. Ruled: add a VMUuid field to VM under __STARKERNEL__ (Option A), set once at birth from the same VMRegistryEntry.vm_id already assigned, not threaded through the call chain (Option B). Done-when extended with a Hermes-word-heat-lands-in-Hermes's-own-reservoir check. Co-Authored-By: Claude Sonnet 5 --- FABRIC.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/FABRIC.md b/FABRIC.md index 1370273..b24e74c 100644 --- a/FABRIC.md +++ b/FABRIC.md @@ -3328,6 +3328,19 @@ document and committing that amendment as its own item.* > invented here. `HERMES.md`'s non-negotiable — all Hermes-side logic in StarForth, > zero new C beyond this primitive layer — still applies; these five words are the > entire C surface this item may add. + > 3. **`vm_core.c`'s hardcoded `vm_uuid_hera()` — Option A, add a `VMUuid` field to `VM`.** + > Found while scoping this item, not a new bug: all three `stadium_word_dispatch()` + > call sites in `vm_core.c` (item 4.1) hardcode `vm_uuid_hera()`, with an inline + > comment already naming this as 4.2's job ("Tripod is pruned to Hera alone; revisit + > at item 4.2"). Fixing it requires a running `VM*` to know its own identity, which + > nothing today provides — `VMUuid` exists only on `VMRegistryEntry` (`capsule_run.h`), + > never on `VM` (`include/vm.h`) itself. Ruled: add a `VMUuid` field to `VM`, guarded + > `#ifdef __STARKERNEL__` in the same block as the existing `VMCallState` lifecycle + > fields (`include/vm.h` ~line 523) — not Option B (threading vm_id through the call + > chain without touching the struct). `VM` is shared/vendored, same as `DictEntry`, so + > the hosted build's layout must stay untouched outside the `__STARKERNEL__` guard. + > Set once, at VM creation, from the same `VMRegistryEntry.vm_id` the birth path + > already assigns (`capsule_birth.c`) — not invented at the dispatch call sites. > > **Open, surfaced not resolved:** mapping Hermes's message/channel lifecycle onto the > closed `STADIUM_BEHAVIOUR_*` set (`MIGRATE`/`DELIVER`/`EXPIRE`/`COOL`) — `DELIVER` and @@ -3347,6 +3360,11 @@ document and committing that amendment as its own item.* > eviction-fallback paths in `stadium_admit()`, verified by a resident cell's > evict-credit landing in the correct VM's reservoir with two VMs holding quotas > (Hera + Hermes) — not just asserted from reading the code. + > - `VM.stadium_vm_id` (or equivalent name chosen at implementation time) exists under + > `__STARKERNEL__`, is set correctly at Hermes's birth, and all three `vm_core.c` + > `stadium_word_dispatch()` call sites pass it instead of the hardcoded + > `vm_uuid_hera()` — verified by a Hermes-dispatched word's heat landing in Hermes's + > own reservoir, not Hera's, with both VMs' conservation checks closing independently. > - Hermes's message and channel lifecycle (`MSG-ALLOC`/`MSG-FREE-NODE`, `CH-ALLOC`/ > `CH-FREE-NODE`, `MBR-ALLOC`/`MBR-FREE-NODE`) run entirely through Stadium admission/ > eviction — no parallel free list, no parallel heat field. Per §11, this is atomic: