Stage D: CONSOLE-CMD-EVENT real cutover -- FABRIC-3.6.md task 3.9

Send-side cutover: sk_repl_dispatch_line()'s FORTH-string
"CONSOLE-CMD-EVENT 0 3 S\" ...\" 0 MSG-SEND" interpret is replaced with
a direct sk_hermes_send_one() call (SK_HERMES_MSG_TYPE_CONSOLE_CMD,
kernel_hermes.h, deliberately reusing CONSOLE-CMD-EVENT's own value 7,
same partition-rule reasoning as task 3.8's BLK-ATTACH-EVENT cutover).

Real finding along the way: kernel-Hermes's drain only ever runs as a
side effect of vm_interpret() being called on the target VM. Task
3.8's target (Hera) is always being interpreted via the interactive
REPL loop; task 3.9's target is a WIREBIND identity's own ~user VM, a
passive receiver nothing else drives. The existing idle-loop pump only
ticked VMs with the old FORTH MSG-TICK word ACL-allowed -- a VM minted
with the STD79-lockdown personality never has it, so the pump silently
skipped it forever and queued messages never delivered. Fixed by
adding an unconditional, direct sk_hermes_drain_checkpoint() call in
the same pump loop, independent of the MSG-TICK gate.

Verified live on all three architectures: WIREBIND-attach a real
identity, USE into it, type a plain console line, confirm the Stage D
evidence line and correct relayed execution result. Zero UNKNOWN WORD,
dict_hash identical across all three ISAs and matching task 3.8's own
baseline. The FABRIC-3.md-documented USE/BINDSTEP crash did not
reproduce in any of these live sessions (recorded as a finding, not
chased further).

Depends on the zuse_root_pubkey_known fix already landed in ac4d431 --
without it, WIREBIND cannot attach any identity on a fresh boot at
all, which blocked this task's own verification until found and fixed
separately.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

FABRIC-3.6.md

@@ -1117,18 +1117,86 @@ ruling]** cannot be written precisely until Captain Bob settles the named sub-it
       invisibility rather than producing new acceptance evidence. All superseded by
       `105501`/`105758`/`110304`, cited above, once the disk-reset-before-each-arch procedure and
       the final single-line evidence design were both settled.
-- [~] **3.9** — **Stage D: `CONSOLE-CMD-EVENT` (type 7)**, then **3.10 `ELEVATE-REQUEST`
-      (type 8)** — one type per task, each with the 3.8 check. Any type found live beyond these
-      three is added here, not bundled.
-      2026-09-22 · **PAUSED, not started-and-blocked by its own scope** — the send-side cutover
-      (`SK_HERMES_MSG_TYPE_CONSOLE_CMD`, `kernel_hermes.h`; `sk_repl_dispatch_line()`'s new
-      kernel-Hermes call, `repl.c`) is written but uncommitted. Orienting for verification (Bob
-      ruled: full QMP/serial-socket-driven real console session, not a self-test) surfaced the
-      task 3.8 payload-aliasing defect recorded in the findings log above — real fix changes
-      `SkHermesMessage`'s shape and is bigger than this task. Paused pending Bob's call on
-      sequencing. `g_kh_console_cmd_buf` (this task's own new static buffer) inherits the exact
-      same defect shape if committed as-is — do not commit until the task 3.8 fix lands, or this
-      task ships the same bug a second time.
+- [x] **3.9** — **Stage D: `CONSOLE-CMD-EVENT` (type 7)** (§XXXIV.3). One layer owns it; FORTH
+      Hermes still routes every other type. *Check:* a real interactive console-session relay
+      works end to end on all three ISAs, via `USE` into a live WIREBIND identity followed by a
+      plain (unquoted) console line; the same task 3.8 evidence discipline (ledger +
+      `stadium_conserved()`, `fleet_conserved` not accepted as evidence).
+      2026-09-22 · **Resumed and closed** — Captain Bob ruled 2026-09-22 to land the send-side
+      cutover first (already written, per the pause note below) and fix the task 3.8
+      payload-aliasing defect separately; that sequencing decision stands, the aliasing fix is
+      still its own open item (findings log above). Final acceptance:
+      `logs/20260922-132142/amd64/`, `logs/20260922-132512/aarch64/`,
+      `logs/20260922-132848/riscv64/` — `disk/artemis.img` and
+      `disk/thumbdrives/{zuse,bob}-thumb-ident.img` reset (`git checkout --`) before each of the
+      three, disk-reset-before-each-arch procedure unchanged from task 3.8. 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**,
+      matching task 3.8's own baseline exactly: `0xb8052b99f1d75f59` (Hera) /
+      `0xecad3d867c9bfec2` (Hermes) / `0xdf59e557986c9009` (Hestia) / `0xa8999a854545f274`
+      (Artemis).
+
+      **What actually cut over**, matching task 3.8's own precedent: `sk_repl_dispatch_line()`'s
+      "`CONSOLE-CMD-EVENT 0 3 S\" ...\" 0 MSG-SEND`" FORTH-string-interpret is gone; a plain
+      (unquoted) console line typed while paired to a live WIREBIND identity now calls
+      `sk_hermes_send_one()` (`repl.c`) directly, with `SK_HERMES_MSG_TYPE_CONSOLE_CMD`
+      (`kernel_hermes.h`) deliberately reusing `CONSOLE-CMD-EVENT`'s own value (7), same
+      partition-rule reasoning task 3.8 already established for `BLK-ATTACH-EVENT`. Delivery is
+      task 3.4's `sk_hermes_drain_checkpoint()`, calling `vm_interpret()` on the target identity
+      VM with the payload text — the console line itself, unwrapped, since kernel-Hermes's
+      payload is raw bytes, not a FORTH string literal.
+
+      **Real finding, found live verifying this exact task, not folded into the send-side
+      cutover's own write-up:** kernel-Hermes's drain only ever runs as a side effect of
+      `vm_interpret()` being called ON the target VM (`vm_core.c`'s own outermost-interpret
+      checkpoint hook, task 3.4) — it has nothing to do with the old FORTH `MSG-TICK` word. Task
+      3.8's target was Hera herself, who is *always* being interpreted (the interactive REPL
+      loop), so her own queue drained as a side effect of ordinary console activity. Task 3.9's
+      target is a WIREBIND identity's own `~user` VM — a passive receiver nothing else drives.
+      Confirmed live: `sk_hermes_send_one()` returned `0` (queued correctly) but the payload sat
+      undelivered indefinitely — no crash, no error, matching `FABRIC-3.5.md §XXXV.0`'s own named
+      failure signature exactly. Root cause: `sk_repl_idle()`'s existing round-robin pump
+      (`SK_MSG_PUMP_BATCH`/`g_msg_pump_cursor`, built for the *old* FORTH `MSG-TICK` system) only
+      gives a live VM an interpret tick if `vm_find_word(vm, "MSG-TICK", 8)` finds an
+      ACL-allowed entry — a VM minted with `MINT_PERSONALITY_STD79_LOCKDOWN` (FORTH-79/83
+      standard words only, no `common:messaging.4th`) never has that word, so the pump silently
+      skipped it forever, and kernel-Hermes's drain checkpoint never got a chance to fire.
+      **Fixed in the same pump loop** (`repl.c`, `sk_repl_idle()`): an unconditional, direct call
+      to `sk_hermes_drain_checkpoint((VM*)ent.vm_ptr)` for every live non-Hera VM visited each
+      beat, independent of the MSG-TICK/VM-EXEC dispatch below it — no FORTH word required,
+      since kernel-Hermes's own drain is a plain C function designed to be called standalone
+      (`kernel_main.c`'s own boot self-test already calls it exactly this way). Verified live:
+      relay now delivers, typically one idle beat after the send (bounded, not instant — the
+      pump runs once per idle cycle, matching the existing MSG-TICK dispatch's own latency
+      characteristic, not a regression this task introduced).
+
+      **Second real finding, also worth recording though it did not block this task:** the
+      `FABRIC-3.md §XXX` (2026-09-15) documented `USE`/BINDSTEP crash ("interactive `USE
+      <identity>` on a freshly-attached identity halts the kernel outright") **did not
+      reproduce** in this task's own live testing, on any of the three architectures, across
+      several repeated `USE rajames` calls on a freshly-WIREBIND-attached identity. Not chased
+      further — either something in the intervening 3.6-series work fixed it as a side effect,
+      or the specific reproduction conditions differ from this task's own test shape. Recorded
+      as a finding, not claimed as a fix (no root-cause investigation was done here).
+
+      **Also found and fixed along the way, its own separate commit
+      (`ac4d431`, already landed before this task's own final acceptance run):**
+      `zuse_root_pubkey_known` never got set after a same-session fresh genesis mint, silently
+      blocking WIREBIND for every identity attach on any boot that reset `artemis.img`
+      fresh — which is exactly what this project's own acceptance convention does before every
+      run. See that commit's own message for the full account; not restated here.
+
+      **A prompt-format change was requested mid-task (Captain Bob), attempted, found to
+      regress live (`[zuse@Artemis]` instead of the intended reformat), and reverted back to the
+      original, unmodified `[zuse@Hera]`-style format before this task's final acceptance run** —
+      confirmed by every log cited above. The reformat needs real new state (separating "which
+      identity" from "which machine," last discussed as needing changes across 8+ save/restore
+      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
+      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
       holds across a full boot on all three ISAs. **Do not start Phase 4 until this passes.**