admin/LithosAnanake
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

FABRIC.md: item 4.2 -- third ruling, VMUuid on VM struct (Option A)

Browse Source 
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 <noreply@anthropic.com>
This commit is contained in:
Robert Allan James
2026-08-05 14:28:24 -04:00
co-authored by Claude Sonnet 5
parent 658459b564
commit 4b26be90c3
1 changed files with 18 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
FABRIC.md
+18
View File
@@ -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: