Stage D: ELEVATE-REQUEST real cutover -- FABRIC-3.6.md task 3.10

Reachability verified live before writing any code, per this project's own standing rule (grep cannot establish reachability alone): FIND SEND-ELEVATE-REQUEST / FIND ELEVATE-GRANT / FIND CH-REQUEST all resolve on a live Hera boot, though grep across capsules/experiments/docs found zero callers of SEND-ELEVATE-REQUEST -- a real, complete, directly-callable entrypoint (H.5/H.8's own design) with no current automatic trigger, not dead code. Correction to a prior finding, made in the course of this check: task 3.8's write-up claimed "Hera's own pre-existing inability to load common:messaging.4th" -- false. capsules/init.4th (Hera's own MAMA_INIT capsule) loads it directly, and SEND-ELEVATE-REQUEST lives and works in her dictionary right now. Task 3.8's own actual scope is unaffected by this correction. Cutover: SEND-ELEVATE-REQUEST (messaging.4th) no longer ends in CH-REQUEST's COMMON-CH/MSG-SEND path; it now calls KH-ELEVATE-SEND (repl.c), a new C word wrapping sk_hermes_send_one(), registered unconditionally for every VM. from/to are derived from the calling VM and sk_get_mama_vm() directly in C, never taken from the stack -- a real correctness improvement over CH-REQUEST's own initiator-only gate, which only existed because a caller COULD pass the wrong from value; deriving it in C makes that spoof structurally impossible. SK_HERMES_MSG_TYPE_ELEVATE_REQUEST reuses ELEVATE-REQUEST's own value (8), same partition-rule reasoning as tasks 3.8/3.9. Delivery is unchanged task 3.4 machinery. No new static-buffer lifetime caveat -- the payload-aliasing fix landed before this task started. CH-REQUEST (messaging.4th) is now dead code, its one real caller just removed -- found, not fixed, per Captain Bob's Law. Verified live on all three architectures: 0 0 0 0 S" DUP" SEND-ELEVATE-REQUEST (deliberately-invalid pubkey, so ELEVATE-GRANT correctly refuses -- the check is the pipeline running, not a grant succeeding) fires the evidence line and completes cleanly, DUP unaffected afterward. Zero UNKNOWN WORD, dict_hash identical across all three architectures (changed uniformly from prior runs -- one new word registered -- not diverged, matching SXXXIV.6's own rule). This closes task 3.11 (Phase 3 gate): all of messaging.4th's live FORTH-owned message types (BLK-ATTACH-EVENT, CONSOLE-CMD-EVENT, ELEVATE-REQUEST) are now real kernel-Hermes cutovers. Phase 4 may begin. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-22 17:00:11 -04:00
parent d4f8a568ee
commit cab9b5a31f
13 changed files with 36831 additions and 16 deletions
@@ -732,14 +732,15 @@ Hestia; headless policy intact.

      **Phase 2 is complete (2.1–2.8).** Phase 3 remains blocked on B1, B2, B4.

-## Phase 3 — Cutover — **UNBLOCKED, tasks not yet written**
+## Phase 3 — Cutover — **COMPLETE, gate (3.11) passed 2026-09-22**

-**Blockers cleared 2026-09-21 (§XLV). Task list drafted 2026-09-21, awaiting Captain Bob's
-review — none started.** Shape (§XXXIV.3, amended by §XLV): build the negotiated pub/sub
-plumbing inert, then cut over `BLK-ATTACH-EVENT` alone, then remaining types one at a time,
-under §XXXIV.2's partition rule — one message type owned by exactly one layer, no message
+**Blockers cleared 2026-09-21 (§XLV).** Shape (§XXXIV.3, amended by §XLV): build the negotiated
+pub/sub plumbing inert, then cut over `BLK-ATTACH-EVENT` alone, then remaining types one at a
+time, under §XXXIV.2's partition rule — one message type owned by exactly one layer, no message
 shared. **Stop condition (§XXXIV.6): `dict_hash` diverging across ISAs, or Stage B evidence
-(ledger + `stadium_conserved()`) going false — re-plan, do not push on.**
+(ledger + `stadium_conserved()`) going false — re-plan, do not push on.** Never triggered across
+any of tasks 3.1–3.10's own acceptance runs. See task 3.11's own entry below for the closing
+account.

 - [x] **B1** — **CLEARED 2026-09-21 by `FABRIC-3.5.md` §XLV.1**: negotiated pub/sub channels —
      one common channel, private channels by request/grant/deny, ACK/NACK throughout. Overrules
@@ -1194,11 +1195,75 @@ ruling]** cannot be written precisely until Captain Bob settles the named sub-it
      call sites in `mama_forth_words.c`) and is deliberately deferred to its own task rather
      than interleaved with this one's live debugging. Not tracked as a numbered task yet —
      pick a number when it's actually scheped.
- [ ] **3.10** — **Stage D: `ELEVATE-REQUEST` (type 8)**, the same one-type-per-task check as
+- [x] **3.10** — **Stage D: `ELEVATE-REQUEST` (type 8)**, the same one-type-per-task check as
      3.8/3.9. Split out as its own explicit item (previously bundled into 3.9's own text without
      a checkbox) per this document's own carry-forward-discipline rule (§XXXI.2).
- [ ] **3.11** — **Phase 3 gate.** No FORTH-owned live message types remain; Stage B evidence
+      2026-09-22 · **Closed.** Final acceptance: `logs/20260922-165122/amd64/`,
+      `logs/20260922-165333/aarch64/`, `logs/20260922-165635/riscv64/` — all three reach
+      `[zuse@Hera] ok>`, zero `UNKNOWN WORD`, `mkcapsule --lint capsules/` clean (38 files, 0
+      violations). **`dict_hash` identical across all three architectures for every VM**
+      (`0x25052a7b8d02b81e` Hera / `0x7011e083c3259321` Hermes / `0x26317a2a0d37e4b0` Hestia /
+      `0xc14d3370d46fcf08` Artemis) — changed from every prior acceptance run in this document
+      (`word_count` 529→530, one new C word registered) but consistent across all three
+      architectures, matching §XXXIV.6's own rule that a *changing* hash is expected and only
+      *divergence* between architectures is the stop condition.
+
+      **Reachability verified live before writing any code, per `advisor()`'s own steer** — not
+      grep alone (`FABRIC-3.5.md §XXXV.0`/trap #2): `grep -rn "SEND-ELEVATE" capsules/
+      experiments/ docs/` found zero callers of `SEND-ELEVATE-REQUEST` anywhere (matching the
+      `init-l8-*` zero-reference precedent, §XXII.2), so this task genuinely has no automatic
+      trigger — but `FIND SEND-ELEVATE-REQUEST`, `FIND ELEVATE-GRANT`, and `FIND CH-REQUEST`
+      (correct usage: `FIND` parses the next word from input directly, not `S" ..." FIND` — the
+      latter faulted live, corrected mid-check) all resolved to real, nonzero dictionary
+      addresses on a live Hera boot. **Correction to a prior finding, found live in the course of
+      this check:** task 3.8's own write-up claimed "Hera's own pre-existing inability to load
+      `common:messaging.4th`" — false. `capsules/init.4th` (Hera's own `MAMA_INIT` capsule)
+      loads `common:messaging.4th` at line 21, and `SEND-ELEVATE-REQUEST` lives and works in her
+      dictionary right now. Task 3.8's own actual scope (only the reply leg was real FORTH
+      messaging traffic) stands unaffected by this correction — the false claim was about *why*,
+      not about *what* task 3.8 did. `SEND-ELEVATE-REQUEST` is a real, complete, directly-callable
+      entrypoint (H.5/H.8's own design: any VM wanting word-ACL elevation calls it with its own
+      pubkey and the target word name) with no current automatic trigger, not dead/unreachable
+      code — verified live by calling it directly from Hera's own console on all three
+      architectures: `0 0 0 0 S" DUP" SEND-ELEVATE-REQUEST` (a deliberately-invalid all-zero
+      pubkey, so `ELEVATE-GRANT` correctly refuses without granting anything real — the check is
+      that the full pipeline runs, not that a grant succeeds; confirmed `DUP` itself unaffected
+      afterward). Evidence line fires immediately, no idle-pump delay needed here (unlike task
+      3.9's WIREBIND-identity target): Hera is both sender and receiver in this test, and she is
+      always being actively interpreted, matching task 3.8's own Hera-target precedent exactly.
+
+      **What actually cut over.** `SEND-ELEVATE-REQUEST` (`messaging.4th`, block 5040) no longer
+      ends in `ELEVATE-REQUEST MY-CH-ID @ 0 ELEVATE-REQ-BUF ELEVATE-REQ-LEN @ CH-REQUEST`; it now
+      ends in `ELEVATE-REQ-BUF ELEVATE-REQ-LEN @ KH-ELEVATE-SEND DROP`, a new C word (`repl.c`)
+      wrapping `sk_hermes_send_one()`, registered unconditionally for every VM
+      (`sk_repl_register_words()`, same site `KH-BLK-ATTACH-SEND` already uses). `from`/`to` are
+      derived from the calling VM and `sk_get_mama_vm()` directly in C, never taken from the
+      stack — a real correctness improvement over `CH-REQUEST`'s own "initiator-only gate...
+      refuses if `from` doesn't match `MY-CH-ID`", which existed only because a caller *could*
+      pass the wrong stack value; deriving `from` from the C-level calling VM's own identity makes
+      that spoof structurally impossible rather than merely gated. `SK_HERMES_MSG_TYPE_ELEVATE_
+      REQUEST` (`kernel_hermes.h`) deliberately reuses `ELEVATE-REQUEST`'s own value (8), same
+      partition-rule reasoning as tasks 3.8/3.9. Delivery is unchanged task 3.4 machinery
+      (`sk_hermes_drain_checkpoint()` → `vm_interpret()` on Hera with the payload text, which
+      calls `ELEVATE-GRANT` exactly as before). No new static-buffer lifetime caveat this time —
+      the payload-aliasing fix landed before this task started, so `g_kh_elevate_buf` needed no
+      `g_kh_blk_attach_buf`/`g_kh_console_cmd_buf`-style deferred-defect note.
+
+      **Found, not fixed (Captain Bob's Law): `CH-REQUEST` (`messaging.4th` block 5031) is now
+      dead code.** It had exactly one real caller (`SEND-ELEVATE-REQUEST`'s own old tail, just
+      removed); nothing else in `capsules/` calls it. Left in place, not removed — orphaning it is
+      a side effect of this cutover, not this task's own scope to clean up.
+- [x] **3.11** — **Phase 3 gate.** No FORTH-owned live message types remain; Stage B evidence
      holds across a full boot on all three ISAs. **Do not start Phase 4 until this passes.**
+      2026-09-22 · **Passes.** Tasks 3.8 (`BLK-ATTACH-EVENT`), 3.9 (`CONSOLE-CMD-EVENT`), and 3.10
+      (`ELEVATE-REQUEST`) — messaging.4th's entire live/reserved type space except the two
+      already-dead sentinels (`MSG-NACKED`/`MSG-DELIVERED`, never live to begin with per task
+      0.1/0.4) and `PAUSE-EVENT`/`RESUME-EVENT`/`KILL-EVENT` (Category A/dead, same source) — are
+      all real kernel-Hermes cutovers now, each independently verified live on all three
+      architectures with real evidence. Stage B's own conservation evidence (`stadium_conserved()`
+      holding across every cutover's own acceptance run, task 2.7's four-term form) has held
+      through every one of tasks 3.8/3.9/3.10's acceptance logs, cited in their own entries above.
+      **Phase 4 may begin.**

 ## Phase 4 — Category B strip

@@ -18,9 +18,9 @@ Block 5038
 ( CONSOLE-CMD-EVENT: console-VM -> paired user-VM command )
 ( relay message type, async MSG-SEND/MSG-DELIVER. )
 7 CONSTANT CONSOLE-CMD-EVENT
-( ELEVATE-REQUEST: H.5/H.8 -- word-ACL elevation ask, )
-( carried to Zuse via CH-REQUEST. See SEND-ELEVATE- )
-( REQUEST/ELEVATE-GRANT below and in zuse-eligibility.4th. )
+( ELEVATE-REQUEST: H.5/H.8 -- word-ACL elevation ask. )
+( FABRIC-3.6.md task 3.10: kernel-Hermes cutover, no )
+( longer CH-REQUEST -- see KH-ELEVATE-SEND (repl.c). )
 8 CONSTANT ELEVATE-REQUEST
 Block 5041
 ( BLK-ATTACH-EVENT: Hera -> Artemis storage-attach request, )
@@ -486,5 +486,5 @@ Block 5040
  ELEVATE-REQ-NUM 32 ELEVATE-REQ-PUTC
  ELEVATE-REQ-NUM 32 ELEVATE-REQ-PUTC
  S" ELEVATE-GRANT" ELEVATE-REQ-APPEND
-  ELEVATE-REQUEST MY-CH-ID @ 0 ELEVATE-REQ-BUF
-  ELEVATE-REQ-LEN @ CH-REQUEST ;
+  ELEVATE-REQ-BUF ELEVATE-REQ-LEN @
+  KH-ELEVATE-SEND DROP ;
@@ -734,15 +734,29 @@ int sk_hermes_reassemble(SkHermesMessage **chunks, int n_chunks,
 * that type's real cutover, not a fresh kernel-Hermes-space number. */
 #define SK_HERMES_MSG_TYPE_CONSOLE_CMD 7

+/* SK_HERMES_MSG_TYPE_ELEVATE_REQUEST (FABRIC-3.6.md task 3.10, Stage D)
+ * -- same reasoning again: reuses messaging.4th's own ELEVATE-REQUEST
+ * value (8). Reachability was verified live before this cutover, not
+ * assumed from a stale claim elsewhere in this project's own docs
+ * (task 3.8's write-up said Hera "cannot load common:messaging.4th" --
+ * false: SEND-ELEVATE-REQUEST, ELEVATE-GRANT, and CH-REQUEST all FIND
+ * live in Hera's own dictionary). No existing capsule calls
+ * SEND-ELEVATE-REQUEST -- it is a real, complete, directly-callable
+ * entrypoint (H.5/H.8's own design: any VM wanting word-ACL elevation
+ * calls it with its own pubkey and the target word name) with no
+ * current automatic trigger, not dead/unreachable code. */
+#define SK_HERMES_MSG_TYPE_ELEVATE_REQUEST 8
+
 /* The five negotiation types above (20-24) were chosen clear of
 * messaging.4th's own live/reserved type space (PAUSE-EVENT=2,
 * RESUME-EVENT=3, KILL-EVENT=4, CONSOLE-CMD-EVENT=7, ELEVATE-REQUEST=8,
 * BLK-ATTACH-EVENT=9, MSG-NACKED=253, MSG-DELIVERED=255) precisely
 * because none of them had a real cutover yet -- kernel-Hermes stayed
 * its own inert, parallel type space for those. SK_HERMES_MSG_TYPE_
- * BLK_ATTACH and _CONSOLE_CMD above are the deliberate exceptions: tasks
- * 3.8/3.9 ARE those types' real cutovers, so they reuse the FORTH-side
- * value rather than picking a fresh one. */
+ * BLK_ATTACH, _CONSOLE_CMD, and _ELEVATE_REQUEST above are the
+ * deliberate exceptions: tasks 3.8/3.9/3.10 ARE those types' real
+ * cutovers, so they reuse the FORTH-side value rather than picking a
+ * fresh one. */

 /* sk_hermes_channel_request - requester asks target for a new private
 * channel. A point-to-point CH_REQUEST (sk_hermes_send_one(), tagged
@@ -433,9 +433,61 @@ static void sk_word_kh_blk_attach_send(VM *vm) {
    vm_push(vm, rc == 0 ? 1 : 0);
 }

+/* FABRIC-3.6.md task 3.10 (Stage D): sized to match messaging.4th's own
+ * ELEVATE-REQ-BUF (256 bytes) -- the FORTH-side sender never builds a
+ * longer payload than that buffer allows, so this is a safe match, not
+ * an arbitrary choice. static, not stack-local: safe now that
+ * sk_hermes_send_one() copies into the message's own storage (the
+ * payload-aliasing fix landed before this task started) -- no lifetime
+ * caveat to carry forward this time, unlike g_kh_blk_attach_buf/
+ * g_kh_console_cmd_buf's own now-corrected history. */
+#define SK_KH_ELEVATE_BUF_SIZE 256
+static char g_kh_elevate_buf[SK_KH_ELEVATE_BUF_SIZE];
+
+/* KH-ELEVATE-SEND ( paddr plen -- ok? ): messaging.4th's own
+ * SEND-ELEVATE-REQUEST builds its payload (a FORTH command string
+ * calling ELEVATE-GRANT, block 5040) and hands it here instead of
+ * CH-REQUEST's old COMMON-CH/MSG-SEND path. `from`/`to` are derived the
+ * same way KH-BLK-ATTACH-SEND's own already does (the calling VM and
+ * sk_get_mama_vm() -- ELEVATE-GRANT always runs on Hera, per
+ * zuse-eligibility.4th's own header comment) -- the caller never
+ * supplies either, which is a real correctness improvement over the
+ * FORTH path it replaces: CH-REQUEST's own "initiator-only gate...
+ * refuses if from doesn't match MY-CH-ID" existed only because a caller
+ * COULD claim to be a different VM by passing the wrong stack value;
+ * deriving `from` from the C-level calling VM's own identity makes that
+ * spoof structurally impossible rather than merely gated. */
+static void sk_word_kh_elevate_send(VM *vm) {
+    if (vm->dsp < 1) {
+        log_message(LOG_ERROR, "KH-ELEVATE-SEND: stack underflow");
+        vm->error = 1;
+        return;
+    }
+    cell_t plen  = vm_pop(vm);
+    cell_t paddr = vm_pop(vm);
+    const char *src = (const char *)vm_ptr(vm, (vaddr_t)paddr);
+    size_t n = (size_t)plen;
+    VM *mama_vm = (VM *)sk_get_mama_vm();
+    size_t i;
+    int rc;
+
+    if (n >= SK_KH_ELEVATE_BUF_SIZE) n = SK_KH_ELEVATE_BUF_SIZE - 1;
+    for (i = 0; i < n; i++) g_kh_elevate_buf[i] = src[i];
+    g_kh_elevate_buf[n] = '\0';
+
+    rc = sk_hermes_send_one(vm->stadium_vm_id, mama_vm->stadium_vm_id,
+                             SK_HERMES_MSG_TYPE_ELEVATE_REQUEST, 0,
+                             g_kh_elevate_buf, (uint32_t)(n + 1));
+    if (rc != 0) {
+        log_message(LOG_ERROR, "KH-ELEVATE-SEND: kernel-Hermes refused the send");
+    }
+    vm_push(vm, rc == 0 ? 1 : 0);
+}
+
 void sk_repl_register_words(VM *vm) {
    register_word(vm, "BLK-ATTACH-ACK", sk_word_blk_attach_ack);
    register_word(vm, "KH-BLK-ATTACH-SEND", sk_word_kh_blk_attach_send);
+    register_word(vm, "KH-ELEVATE-SEND", sk_word_kh_elevate_send);
 }

 /*===========================================================================
@@ -628,6 +628,27 @@ int sk_hermes_drain_checkpoint(VM *vm) {
        console_println(line);
    }

+    /* FABRIC-3.6.md task 3.10 evidence: ELEVATE-REQUEST also has no fixed
+     * C-side handler word -- its payload is a FORTH command string
+     * calling ELEVATE-GRANT (zuse-eligibility.4th), interpreted as-is
+     * below, same shape as CONSOLE-CMD-EVENT above. Same mid-hold-instant
+     * evidence, same reasoning; `self` here is always Hera (`vm`'s own
+     * caller already resolved it that way in KH-ELEVATE-SEND, since
+     * ELEVATE-GRANT only ever runs on Hera). */
+    if (msg->type == SK_HERMES_MSG_TYPE_ELEVATE_REQUEST) {
+        uint64_t held, pulled, returned, consumed;
+        char line[160];
+        int conserved = stadium_conserved(self);
+        sk_hermes_ledger(&held, &pulled, &returned, &consumed);
+        snprintf(line, sizeof(line),
+            "Kernel-Hermes ELEVATE-REQUEST (real, Stage D): ledger held=%llu "
+            "pulled=%llu returned=%llu consumed=%llu stadium_conserved(self)=%s",
+            (unsigned long long)held, (unsigned long long)pulled,
+            (unsigned long long)returned, (unsigned long long)consumed,
+            conserved ? "true" : "FALSE");
+        console_println(line);
+    }
+
    vm->mode = MODE_INTERPRET; /* a payload is never compiled into whatever
                                * the enclosing context was mid-defining */
    vm_interpret(vm, (const char *)msg->payload_addr);